When two worlds unite

Over the past few years, I have seen many references to automation as part of the project management process. These vary from defining all the processes associated with project management to automating these using advanced workflow tools.

The bottom line, in terms of these references, is that not many take both sides into account. Typical project process management and electronic workflows are seen as two different worlds.

This is because it is delivered by two different breeds of people - one being the typical 'suit', who likes to draw pretty pictures that do not mean anything, and the other, the 'techie', who just wants to develop something. The problem with this approach is that without one, the other cannot function.

Let me try and explain...

"Let's understand your business and its processes and the way you run projects." This is typically what the 'suit' will say from day one. A lengthy analysis of the business will be conducted to understand what the best-fit processes for the company would be in the management of projects. When understanding all of this, a typical recommendation will be done and it is something in the line of: "For your business and your industry, it is a proven fact that this process and methodology will work."

Based on the outcome and the processes decided on, the typical document templates and best practice collateral associated with these need to be determined. Once all of this has been completed, everything will be documented, and all processes will be printed out and stuck on boardroom walls and all over the business premises, as this is what needs to be followed.

One little problem to highlight: who is controlling all of these and what type of governance is around this? This is typically managed by a whole team of people trying to manually source all the information available and track this accordingly. In my opinion, this is very unproductive - it is virtually the same scenario as sending a document for approval electronically, then printing it out to sign, scanning it back in and sending it back to the originator electronically!

"Forget the paper stuff, let us automate everything and save some trees." Sound familiar? Don't you just love techies! The biggest problem comes in that no matter how much a process is automated, there will always be the human aspects that have to be taken into account, and who wants to redevelop something every time a small change is done?

Typical project process management and electronic workflows are seen as two different worlds.

Simple example: identifying a risk on a project. The process can be automated as much as necessary, but if someone does not use logic in identifying a risk and logging it somewhere, there will be nothing to automate. The problem typically comes in with processes like this being seen as workflows and not processes. This ultimately means the company will manage the automated workflows manually, and this is also unproductive.

So, what difference does the project process make to the execution of the workflow? The simple answer to this question is nothing! When realising that these two aspects and two different worlds have to co-exist, productivity and proper governance will come to the fore. Let me try and explain how this can be done.

When defining the processes, consider automation and workflow. A process is actually a very easy thing to understand. It has three main aspects: input, action and output. This is the same example of a risk management process:

* Input: identify the risk
* Action: log and manage the risk through its life cycle
* Output: mitigation or contingency plan

This, in itself, will lead to another process being followed. The question remains, however, how is this different from the way things are done now? Typically, these worlds are seen differently, but should in fact be one, ie, the process designer should consider the automation actions that can be used in designing the process and not just document the action, ie, design for execution. This, in itself, will cause a lot of controversy in many companies. However, it is simply a matter of teaching them to think outside of the box and consider automation first - but with a human hat on.

The most important aspect to remember when considering this suggestive approach is that in optimising or defining new project processes, human and technology should work together. No process can just become a workflow and no workflow can work without human interaction. When defining the process and or methodology to be used, it does not help to just use one, and typically, this is what will happen when a single human process is designed.

In a company that has adopted an agile approach to all projects, what should be done when executing a construction project? Try building a house or building agile.

This has many challenges, including the methodology to be used. The straightforward answer to this is: it does not matter. Companies need to find what will work for them. This could be multiple methodologies or multiple ways of doing things, as long as it all adheres to the same reporting outcomes and it was designed to run optimally, taking human and automation into account.