The Wonderful World of Scope Creep

Posted by Brad Egeland

In the wonderful world of scope management and scope creep…as a project manager all you have to go on is your organization of the project and your reporting tools. I’ve found that the three best ways to combat scope creep are:

  1. Establishment and signoff (by the customer) of a Scope Statement or Document.
  2. Establishment of a work-in-progress detailed project plan that the customer is reviewing with you on an on-going basis.
  3. Management of the project driven by a detailed project plan and weekly status reviews of the project – that includes the customer – utilizing customized reporting from the detailed project plan.

For #3, my preference is to create custom filters in MS Project and utilize those filters to create 6 customized reports:

  1. Tasks Completed Last Reporting Period
  2. Tasks Started Last Reporting Period
  3. Tasks Planned For Completion This Reporting Period
  4. Tasks Planned To Start This Reporting Period
  5. Tasks Past Due For Completion
  6. Tasks Past Due To Start

Items #1 & 2 cover your areas of Progress on the weekly status report. Items #3 & 4 cover the Planned areas of the status report. And items #5 & 6 cover the Issues area of the status report.

I then include a section in the weekly status report that covers action items, who they are assigned to, and when they are expected to be completed. This area is meant to handle the on-going issues that come up during the project but that don’t really fall under the category of a Task to be included in the project plan
When your customer needs work that falls outside of the agreed upon scope of the project, then we usually need to turn to two things – a Phased Implementation and/or Change Orders.

Phased Implementations

Many times requirements will either change or become more refined resulting in work that needs to be performed outside the original scope – either timeframe, budget or both. To keep the project on track in terms of implementing necessary functionality within the agreed upon timeframe, one way of keeping the customer happy is with a phased implementation approach.
Usually this will also have budgetary implications as well, since if it is effort beyond the original timeframe then it is likely effort beyond the original budget.
Working with the customer to agree upon implementing ‘x & y’ functionality by June 1st and moving ‘z’ functionality to September 1st is a way of keeping at least most of the project on track while redefining when the full functionality will be ready.
This likely results in one or more change orders, which we’ll address next.

Change Orders

Unless the PM or the PM organization is involved in the sales process (and I think they should be!), then the PM’s first chance to increase cash flow for the organization is to recognize additional customer needs and out of scope items. These are usually handled in the form of change orders. Some customer’s cringe at the mention of change orders and may even have you sign an agreement that there will be no change orders on the project. In those cases you just have to adhere to the original project scope and allow nothing to get in the way. However, when functional requirements are being fully fleshed out and turned into a technical design doc, many IT projects will realize the need for change order work. This can be a need for additional personnel with different skill sets added to the project, more reports, new screens, additional queries built into the software, more integrations than were originally planned…..you get the idea…the list goes on and on. In one case on one of my projects, the customer liked the Business Analyst so much that they wanted him onsite for the entire project rather than just for a couple of weeks at the beginning of each phase of the project. This customer had money and liked the team and wanted to ensure that everything went smoothly. They happily signed on for nearly $100k in change orders over a 3 month period including increased hours and living expenses to accommodate the BA onsite for the duration.

Conclusion

The PM definitely has help from his project team to keep the project on track as originally scoped. The BA and developer(s) will be watching for things that fall outside of the scope during design sessions. However, the PM has overall responsibility to track the scope, identify discrepancies and originate discussions and paperwork that will lead to changes such as a phased implementation and change order work. The earlier this is identified and the quicker it is discussed with the customer, the greater the likelihood of customer satisfaction. Document everything, create detailed change orders and get customer signoffs so that there are no questions at invoicing time.

Share this post:
  • LinkedIn
  • TwitThis
  • Facebook
  • del.icio.us
  • Digg
  • StumbleUpon
  • Sphinn
  • Mixx
  • Propeller
  • Technorati
  • Print this article!

Related posts:

  1. Project Status Reporting
  2. Agile Project Management
  3. Project Management on a Budget
  4. The Art of Negotiation – Part 2
  5. Achieving Stakeholder Satisfaction Through Project Control

Tags: , , , , , , , , , , , , , , , , , , , , , ,

6 Comments to “The Wonderful World of Scope Creep”

  • Brad, great piece! How would you implement the proposals in projectoffice.net? More specifically the task reporting? Thanks, alek

  • Alek- unfortunately I’m not familiar with ProjectOffice.net, but I’m open to learning or a demo. I’m assuming it has some custom reporting capabilities…and that’s really what I created in MS Project with the filters. Let me know how I can get in and learn some of the details of ProjectOffice.net. I may have a client that could use it – the pricing looks like it would be right for them. Thanks!

  • I see big risks on having the scope fixed at the start of the project:
    -committing to impossible/impractical features
    -committing to ill defined features
    -leaving out higher value features

  • Gabriel- I agree with you. I don’t think you can ever have your project scope ‘fixed’ at the beginning of a project. That’s what gave and take is for, that’s what phased implementations are for and that’s what change orders are for. However, I do believe that if the PM or the PM organization is more involved in the sales process up front before the SOW is finalized, then you have a better chance of your SOW more closely matching the true customer needs and business requirements than if it is just thrown over the fence to the PM after the deal is done and the project is ready to be kicked off. Because, ultimately, it becomes the PMs responsibility to manage the scope, track all changes to it, and negotiate the change orders with the customer. A customer who is bombarded with change orders because the SOW was off is not likely to be a happy, referenceable customer.

  • Change orders should not be thought of as a bad thing. If a change order review committee (with budget authority) decides it is in the best interest of the company to add something, then that improves the project. It may cost more money, but what are the alternatives? A bad system.

    Also, I chuckled a little to myself about the phasing. I don’t know how many times I have responded to some great ideas that came up during a design phase with the term, “we will definitely look at that for phase 2″ or after a while just “phase 2″ for short. :) Unfortunately, many IT projects never get to phase 2 because the business elements that are important to make the phase 1 launch successful (process, change management, etc..) are not done well and/or the requirements were not performed with the right stakeholders.

  • change management model…

    Have you read my change management model blog post? Usually applying those steps towards change are useful in any situation….

Post comment

Spam protection by WP Captcha-Free