As we all know, projects are complex. That applies even more to ICT projects.
The problem with complexity is that it creates unpredictability. We do not like unpredictability because both customer and supplier want to have a successful business case and need to know in advance whether the project is going to deliver within the boundaries as defined by the business case.
The classical, non agile, approach to unpredictability is to do more analysis upfront and follow a rigid change management method, usually combined with a large requirements document, contract and project plan. The assumption is that by doing a lot of thinking most of the potential problems can be addressed and that the few other loose ends can be managed effectively by change management.
I’m afraid this assumption is wrong. Not only because we continuously underestimate the number of changes during the project and are very poor in predicting the future. The larger problem is that the contract has become the project’s goal, not the underlying business case. This potentially creates a severe misalignment between customer and supplier.
Every time something unexpected happens there are two points of view.
The customer reasons from his needs, towards an ideal situation. From that point of view it is likely that changes are needed. Changes are considered necessary and an opportunity to create a better solution.
The supplier reasons from the contract (deal). Changes are considered a bad thing. It means that all the thinking didn’t create the desired results (a smooth and predictable project process). In most organisations projects are considered to be successful if the project is finished within the set boundaries of time, costs and scope (quality). It means that someone has to tell upper management that things do not go according to plan. It is in the interest of the project management team to reduce the amount of changes, to steer the project towards the boundaries set by the contract.
Though this misalignment happens in lots of projects, I do not think it is that difficult to turn the situation around. It requires an other mindset.
First you need to make clear within the supplier’s organisation that a project is successful when the underlying business case is successful. This means that time, scope and costs may change, it does not necessarily cause a problem.
Secondly I would advise the following action plan for each potential change:
- Determine the ideal situation
Talk to the customer and ask for his needs. (In fact, don’t wait for his initiative and make some suggestions yourself).
- Look at the contract
Only then determine what has been agreed upon by contract or project plan and determine the gap between deal and ideal.
- Change management
Determine the right course of action. This can be something operational (managed by the project manager) or something on the project board level or both.
Thirdly, it is also wise to repeat this process frequently, even when there are no problems. It is an excellent process to keep the project healthy, to prevent unspoken assumptions and expectations. It also is a nice fit to the concept of learning and improving.
Of course you agile project managers already know all of this.
For you guys I have an additional suggestion. This process can also be applied to any situation where people need to work or live together. Between you and your team, between the team and Product Owner and yes, even at home between you and your partner. 🙂