Defining and Managing Project Scope

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:

  1. Make sure you prepare the project scope, documenting all high risk areas.
  2. Be strict about change control and learn to say no to requests.
  3. Set aside a contingency and manage the budget.
  4. Keep consultancy sessions and meetings focused.
Be Sociable, Share!
This entry was posted in Business Strategy, Project management and tagged , , by Cathie Hall. Bookmark the permalink.

About Cathie Hall

I have spent the majority of my career working within ERP. It’s an exciting place to work, continually at the forefront of organisational change, blending people, processes and products together, to deliver real value to businesses. As the Operations Director of K3 SYSPRO, I am responsible for providing customers with business solutions through SYSPRO. I am committed to putting our customers first, to building and supporting a strong internal team, and to giving each individual a secure place in that team. In this way, I know that my team and SYSPRO will deliver real lasting value to our customers.

One thought on “Defining and Managing Project Scope

  1. I agree with you 100%. Usually relates back to the executive buy in and support of the project charter.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>