When people talk about the three critical factors of projects, they refer to scope, time and cost. It is well documented that you can’t change one without impacting the other two, yet it still seems to come as a surprise when a change in scope delays a project or increases the cost.
One of my early mentors in project management used to drum into me the importance of scope management. “Where’s the scope documented?” would be the first response whenever you went to her for advice.
The first issue is one of how to document the scope. In software projects, the scope is often defined as part of the sales process, and then refined in the definition phase of a project. The problem is the scope is defined in the mind’s eye of each project member. A simple sentence on an invitation to tender or within a project initiation document is often agreed by all, but interpreted differently by everyone. Most times this doesn’t cause an issue, but when the difference in expectation leads to a difference in time and cost, suddenly you hear the words: “But surely you understood that; but you spent three days in our business, you can see we… or; it’s simple, every customer must work that way.”
The cost associated with defining the precise scope with respect to every item within a project is too high to justify, but high risk areas should be documented in more detail – including screen shots, prototypes and examples.
The second problem is one of “scope creep.” The first change is seemingly insignificant. It hardly seems worth raising a change control for one hour of additional development within a contract worth 20 days. Then follows another few hours, a day and before you know it the scope has drifted away from the initial documentation, and you’re faced with a bill for additional developments that you have no chance to refute.
The solution is to ensure you have proper change control in place from the outset. Even if the initial changes are small and go through at zero cost, it sets the expectation that changes must be requested and approved.
I did a project in 2007 which demonstrated some of the best scope management I had ever seen. The customer was determined that the site would go live with minimal bespoke. Every change request submitted was bounced back. The internal project team were told to find a workaround for go live and that the bespoke would be reassessed after three months. The final result was a 200 user system within only two pieces of bespoke code.
The third area of scope that causes issues within projects is what I call “consultancy drift.” It’s where a consultancy topic takes up budget when it didn’t form part of the original scope. The topic comes into play whilst the consultant is discussing a related area. So, you’re working through a sales order entry when forecasting is mentioned, suddenly the conversation turns to forecasting. Of course, the consultant should push back and explain that isn’t within their remit, but often that isn’t easy when the customer is asking questions and demanding answers.
There are two ways to resolve this issue. The first is to make sure all sessions have a leader who can keep the session on track – making sure people stick to the point and record decisions. The second is to make sure that you have contingency put aside in the project to allow the team the freedom to follow up on new ideas. If you go the second route, then you need to use a change control process to allow that contingency to be consumed, otherwise you risk the pot being blown for no ascertainable output.
So in summary, when managing project scope:
- Make sure you prepare the project scope, documenting all high risk areas.
- Be strict about change control and learn to say no to requests.
- Set aside a contingency and manage the budget.
- Keep consultancy sessions and meetings focused.
