Control Models in Agile

Can traditional Project Control Models (stage-gate, phase-gate or whatever you prefer to call it) work in agile settings?

The short answer is yes, but they have to be used in the right way. They are frequently a source of lots of discussions and can also frequently cause a lot of trouble for organizations transitioning to agile.

First of all, control models need to be adapted to iterative and agile ways of working. This means you will ask for different kind of results at the different gates. This can usually make sense, especially when you consider what the underlying purpose is with the different gates. Lets take an example with a couple of gates:

• Verify business feasibility – will normally require no change.
• Verify technical solution and feasibility – will more often demand that you have verified by setting up or coding parts of the solution, but in many projects this might not be necessary to take the right decision.
• Scaling up and final development – here the major risks should normally be under control. Traditionally this was taken care of by writing lots of documents. Experience has shown that this is usually not the best way of mitigating risks so in all but really simple projects you have to build parts of the application to be allowed to pass this gate in an agile and iterative setting.

Interesting to notice is that, according to me, agile ways of working is actually a much more natural way of fulfilling the purpose of the gates. Do you believe writing comprehensive design documents of the entire solution is a better way of reducing severe technical risk than developing code – if you have to choose between the two? The same example goes for user experience.

Let’s take a step back now and discuss the purpose of a control model. The major purpose is to control the projects to be able to manage risks and make it possible to stop projects in an early phase if the are not under good control. It sounds like this makes sense in an agile setting as well.

In Scrum each sprint can be seen as a mini-project. But this is not what we traditionally mean with a project. Many companies have projects that run for many months or even years.

Is agile the end of this? I say no and I believe there is significant risk in not accepting the need for Project Control Models in agile environments.

Why? Let’s examine this need by looking at the practices of Project Control and Portfolio Management used by many large organizations. Portfolio Management Models normally get their information by being fed with data from the Project Control Model.

The purpose with using Project Control Models and Portfolio Management Models is:

• To be able to quit or redirect projects that are not performing as expected
• To compare and prioritize versus other projects
• To control the risk of the projects

It is not (or should not be) to control the people doing the work (whom we don’t trust).

So when there is a significant need to control the development of a project by people other than the Product Owner it could make sense to use a Control Model.

Now, I am talking about other decision than prioritizing of the Product Backlog – that can well be handled by the Product Owner – at least if you consider these Product Owner issues.

I am talking about decisions like:

• Project cancellation – it might be tough for a Product Owner to terminate a project developing his only product (might potentially make him redundant).
• Resource reallocation, moving a lot of resources to another project – same as above

Of course you can make decisions without using Project Control Models – but sometimes they can support in situations like these. If you have a common view on the maturity level of the project and a way to compare business cases and risks it can help a lot.

The following are examples of projects that will often likely benefit from a control model. Assuming we are talking about projects with significant complexity and risk and within an organization with many ongoing projects:

• New product development
• Bought product implementation in organization
• Complete rewrite of existing application

So using a Project Control Model might be helpful in agile settings. It supports us in making good decisions on a level above the individual project. Scrum support us really well in working with and prioritizing a single backlog – but Scrum does not really help us with decisions on the level above that.

That being said, using Project Control models are probably just adding waste a lot more often then they add value. If your project and organization is not fitting to the description above you should carefully consider if you are not better of without it.