Insights on Business Management Software and ERP
SYSPRO Smarter ERP Blog

Posts by Topic

More...

Subscribe to Email Updates

Defining and Managing Project Scope

Posted on 10 January 2013 by Cathie Hall

Find me on:

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.

 

Topics: Business Strategy, project ownership, project scope, Project management, ERP Implementation


Cathie Hall

Cathie Hall is the Operations Director of K3 SYSPRO, where she is responsible for providing customers with business solutions through SYSPRO.

Cathie leads a strong team of support, customer services and technical consultants, along with project managers to provide SYSPRO customers in the UK and Europe with high levels of service throughout their ERP journey.

Cathie’s approach is to always put the customer first, and to build and support a strong internal team of people, ensuring that each individual has a secure place within that team.

Cathie holds a BBA in Management from Lancaster University. Prior to joining K3 SYSPRO, she worked at a manufacturing company as their Group IT Manager, where her first challenge was to select a new ERP system for the company. SYSPRO was chosen and this was when Cathie got her first taste of the ERP industry. Following that, Cathie ran her own ERP Consultancy and implemented various ERP systems in different regions, across the world.

In her spare time Cathie is an Explorer Scout Leader, providing fun, challenge and everyday adventure for 14-18 year olds in West Lancashire, UK. She also enjoys running and riding motorbikes.

 

Subscribe to Email Updates