A brief hiatus in posts, as I was busy with our client conference. During the conference, I was discussing with a contemporary the thorny issue of managing scope and the challenge of keeping stakeholders happy. While there are plenty of material out there regarding good approaches to control scope, I find not many address that in conjunction with managing stakeholders.
In my 12 years, first as a developer of IT systems, then leading development teams and now managing project deliveries to internal and external stakeholders, I have never seen a project delivered as it was first conceived. Uncertainties are an inherent nature of projects. Regardless how succinct the agreed requirements are, the course requires some adjustment. This may be the result of stakeholders getting a clearer understanding of what they themselves want. Other times it could be something that had been missed as an original requirement or something totally outside the control of the project team – like change in legislation, re-positioning of the organisation in the market, internal re-prioritisation, budget cuts etc.
PRINCE2 Organisation Theme - OGC
Regardless what causes the requirement to be adjusted, it is a change in scope. While the business requirement may still be the same and you are still delivering the same, it is a change to the baseline. This will likely impact the type of resource you need to pull it off and consequently impact time, budget or quality. Scope creep is not necessarily adding new requirements, it is also changes to agreed baseline, on which your cost and milestones are based. Some small adjustments will be continually be asked for. At the end of the project they do add up. If you are part of a delivery organisation and working on a project for a key client, there is pressure to accommodate small creeps within your organisation. If you were to slap a change request every time any such adjustments, while you are correct, will do more to damage stakeholder relationship than achieve scope control. Odds are the client will go above you and squeeze you into making concessions.
Now that I’ve spent long enough explaining the dilemma, what is my preferred method to avoid this? I have found the PRINCE2 organisation theme as providing the best guidance. The key is to form a “one team” approach, including your own organisation and the client. Remember, you as the project manager are not responsible for any change to the baseline scope. Get the Change Authority to earn their money. My view is the project manager needs to be part of the change authority. However, it must include user representatives. When it goes back to the Project Board, it needs to come through that it is the Change Authority that is approving or rejecting the change and you are left to plan the resulting impact. In a large project, you may not be able to spend time in the Change Authority. In that case use your trusted Business Analyst.
Using PRINCE2 also enables a clear set of roles and responsibilities. You as the project manager is not the arbitrator of change control. The client is responsible and the Change Authority is the mechanism. Your responsibility is to ensure you deliver within the tolerances afforded to you in terms of scope (currently agreed), time, cost, quality and risk. It is amazing when the client realises that the cause for scope creep is not you, but the requirements imposed either by them or external forces, how much easier it becomes to either negotiate a delayed implementation of the requirement or to agree on a change to the baseline.