A lesson learnt in the PMBOK perspective.
When a project starts, there are usually a raw high level scope and an order of magnitude of cost. Generally, in the very first step, project managers focus in detailing these aspects and this rapidly appears being endless. Indeed, influences come in the early stage to the latest ones and related changes they required may render the project unstable.
Using my own project experience, this article will first present you a typical project context I met at an important customer. Then, it will show you how managing influences helps keeping project stability.
1.1 Organizational process assets
Our project was planned over 3 years to build 4 new products to target 4 identified markets. As a result, the project was split into 4 sub-projects requiring the full engineering cycle described in organizational process assets (i.e. the customer’s corporate project management rules):
- Phase 0 Proposal: develop business case and project statement of work
- Phase 1 Concept and planning: develop the sub-project scope and baseline its schedule and costs
- Phase 2 Construction: develop the product
- Phase 3 Acceptance: verify and control scope
- Phase 4 Transition: release the product and close phase
1.2 Enterprise environmental factors
Organization is a balanced matrix structure. Functional and project managers share the control over resources and schedules. The Project manager’s trust in the functional manager is a key of success.
Functional managers have consequently a strong influence level on the project. Most of the time, this influence is materialized by solution design changes, risks escalation and resources availability changes.
Market representatives are also very influent on products scope. As they lately acquired enough knowledge about markets expectations, this influenced the project scope definition and prevented from having a complete sub-project baseline.
1.3 Project management team
The project management team was composed of one project manager, one dedicated project management officer and one process coordinator.
The project manager is accountable for delivering the product and making decision on the way to do it. The project management officer is responsible for monitoring the project and implementing continuous improvements. The process coordinator performs quality controls and helps to accommodate methodology with best practices.
Now we painted the landscape, let’s have a look at the origin of changes in each project phases.
2 Origin of changes
2.1 Phase 0 – Proposal
This phase assessed an order of magnitude of costs and a high level plan which didn’t take into account the lack of knowledge about markets expectations. This resulted in underestimating the product complexity and risk contingency.
Involved processes in this phase: scope, time and costs management
2.2 Phase 1 – Concept and planning
As a consequence of the previous phase, scope definition had to deal with many request for changes (RFC) to be analyzed and taken into account when markets expectations came into the game.
Involved processes: scope, time and costs management
2.3 Phase 2 – Construction
Many schedule compressions and fast tracking were analyzed and then decided in order to meet with business case assumptions. This resulted in managing many RFC in this phase too.
Involved processes: integration, time and costs management
2.4 Phase 3 – Acceptance
Markets were also involved in this phase and we had to deal with many RFC in this phase too.
Involved processes: scope and costs management
2.5 Phase 3 – Transition
When releasing the final products, operation support and customer support requested more support from developers to complete their activities.
Involved processes: costs management
Influences are permanent and come in each phase materialized by changes in different areas. Managing influences consequently requires managing changes then.
3 How to manage changes
As we identified the origin of changes and the involved processes, then we defined a coordination process named ‘change management process’.
Change management is triggered when:
- a RFC is expressed by any stakeholder
- a risk on schedule, time or cost is identified and requires to change the project
A change record is then created (step 0):
To ease the process, I recommend that a change should express a single requirement.
It was identified 3 types of change:
- ‘Scope’ related change: the change extends or reduces the project scope
- ‘Deviation’ related change: without changing the project scope, the change upgrades or downgrades the solution performances
- ‘Baseline extension’ related change: the change is a scope change on parts of the project which baseline is not approved yet. Once baseline is approved, these related changes are consequently integrated into the baseline.
They are used to calculate 3 types of variances compare to the planned value. Actual costs are consequently the planned value plus all accepted change records.
Status is used to follow up the change thru the next steps:
1. Defining activities to develop the change.
If no solution is possible, go to step 6.
If designing the solution is too complex (effort is over a determined amount of effort), go back to step 0 to create a change to request this effort.
2. Scheduling activities.
This will lead to decide whether to embed them into an existing release or to create a new one.
3. Estimating the cost
This action can be parallelized with the previous one.
4. Submit it to the change control board (CCB).
If CCB requests more data, go back to step 1.
If CCB refuses it, go to step 5.
If the schedule or cost variance caused by the change is superior a threshold, CCB can decide to go to step 6.
If CCB accepts it, go to step 7.
5. Archive change record
6. Put the change in the product backlog.
This means the change go outside the project.
7. Update project documents.
Then communicate them to stakeholders.
Managing influences requires first of all managing changes. This involves many project management activities and it allows controlling influences as long as stakeholders are kept informed step by step. This consequently requires using specific tools and reports that are continuously improved. That is the reason why I recommend the project management team to be composed of more than a single project manager.