Subscribe

Let the process lead

Which comes first - the project management methodology or the technology?

Anita Potgieter
By Anita Potgieter, chief operating officer at FOXit.
Johannesburg, 29 Mar 2012

In the corporate world, the application of project management technology to enhance operations does give companies an edge. But, what approach works best? Is it wise to follow the notion 'technology first, then project management methodology', or do they prescribe to the project management first, then technology approach?

My inclination is to shout from the rooftops: process, process and process!

Anita Potgieter is COO at FOXit.

Experience teaches that a process must always lead and the tool must follow.

Strategic use of this technology improves processes and procedures, and leads to greater productivity because of better use of resources. There is no doubt about the value of project and process management in the workplace.

Chicken or egg?

But, it is necessary (and interesting) to give credence to the question: which comes first - the project management methodology/process or the technology?

Personally, my inclination is to shout from the rooftops: process, process and process!

However, to answer this question fairly, I have to consider both options. Let's look more closely at what happens when technology comes before methodology.

A tool is a means through which certain functions are carried out. There are many tools in the market and the argument can be made that tools must lead the way and determine the relevant activities a company needs to carry out.

A lot of tools exist in the market and one can argue that tools must lead the way for activities a company needs to perform.

Let's say a company finds state-of-the-art technology that's 'in' right now. The company procures the services of a business implementing this solution, and while installing and configuring/developing this system, the company assigns a process analyst (one or more) that can help define processes that need to be set up in the system.

The company changes some expected outputs, even some of the day-to-day undertakings of resources to suit the tool's needs. The output starts to appear, just as the process analyst helped them envision it.

On the process side of things...

There are two definitions of 'process' that I personally like very much.

The first is: “Sequence of interdependent and linked procedures which, at every stage, consume one or more resources (employee time, energy, machines, money) to convert inputs (data, material, parts, etc) into outputs. These outputs then serve as inputs for the next stage until a known goal or end result is reached.”

The second is: “A series of actions, changes, or functions bringing about a result.”

A process is developed, painstakingly at best, without the support of technology, but with good understanding of the goals and objectives it's trying to realise.

Most of the times a process is set in place because of something that went wrong, For example: a company is working on a project for a client, and due to scope creep and the non-existence of a scope change process, the company gets burnt by the client and the project is delivered at a loss to the company. What will it do? It will ensure that it sets a proper process in place to prevent the loss in future!

Ducks in a row

Once a company has all the different processes defined, the project methodology is in place, and most importantly, the maturity of the project office, project managers and resources are in a good space - the company is ready to shop around for a tool that will help the company automate and govern these processes.

So which is the better approach?

If the company has young techno-savvy employees that can handle a lot of change, implementing a tool while defining the process will not be a bad way to go. If the company mostly comprises older people that are set in their ways - it will have more difficulty.

Let's be realistic. Adopting a system/tool and new processes at the same time is a recipe for failure. Six months down the line, people will either not be using the tool or finding out that both the tool and process needs to change because the vendor never understood the company's requirements. This could be a very costly exercise.

If the company has a proven process in place first, in my humble opinion, this will always be the best. As long as the company purchases an easily configurable tool, it can automate its processes without paying unnecessarily high costs to get someone in to make the smallest change to the process.

Share