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:
Establishment and signoff (by the customer) of a Scope Statement or Document.
Establishment of a work-in-progress detailed project plan that the customer is reviewing with you on an on-going basis.
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:
Tasks Completed Last Reporting Period
Tasks Started Last Reporting Period
Tasks Planned For Completion This Reporting Period
Tasks Planned To Start This Reporting Period
Tasks Past Due For Completion
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.
I originally authored this article for the PM Tips website. The original post can be viewed here.
Establishment and signoff (by the customer) of a Scope Statement or Document.
Establishment of a work-in-progress detailed project plan that the customer is reviewing with you on an on-going basis.
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:
Tasks Completed Last Reporting Period
Tasks Started Last Reporting Period
Tasks Planned For Completion This Reporting Period
Tasks Planned To Start This Reporting Period
Tasks Past Due For Completion
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.
I originally authored this article for the PM Tips website. The original post can be viewed here.
