Coping with Project Scope; Eight Real-World Strategies

If history has taught us anything it is this: “No matter how well a business application project’s scope is defined, it changes time after time.” Managing the scope of a project is always plagued with some form of scope creep. Scope creep has been the bane of project managers since project management began. The scope of a project is somewhat fluid in nature and tends to morph as the project progresses. Like hurricanes, the path followed can only be projected within a certain margin of error. However, hurricane path forecasting utilizes different models, each based on a series of uncontrollable factors that can and do change over the course of its life. The closer the hurricane is to landfall, the more accurate the projections.

Unfortunately, most scope-management frameworks are designed around the definition of a finite scope based on limited knowledge and advocating tight controls to manage change. Scope changes can be driven by many factors, including new ideas, regulatory change, change of needs, poor understanding of requirements, heuristic discoveries, financial circumstances, changes in leadership and more. In addition, in the absence of an agreed-upon objective and quantitative methods, assessing the impact that scope changes will have on the success of the project, emotions and politics will most likely rule the day.

The challenge is how to weave change and scope recalibration rules into the fabric of the project that proactively allows for resources, budgets and delivery times to change without attracting management’s ire. Here are eight strategies you might find useful in meeting the scope management challenge:

1. Use a Discovery Phase to Establish a Stable Scope

One of the quickest ways to improve your ability to develop an accurate and creep resistant scope is to conduct a “scope discovery phase” out of which a detailed understanding of deliverables will be developed. Typically, these phases are like mini- design phases with requirements traceability from objectives through workflows to applications, programs and data structures. The result is a very detailed list of deliverables making it easier to spot any additions to the mix. In addition, since the deliverables can be classified as to their complexity and type, it is possible to use standard estimating metrics to compute the effort needed for completion. Finally, understanding the business processes, applications, programs and data structures in play allows you to identify the talent and resources needed to support the effort. Discovery Phases typically take from one to three months to complete and consistently yield scopes that are 95 percent accurate (and that ain’t bad!).

2. Develop Formula- and Event-Driven Models for Establishing Budget Needs, Resource Requirements and Delivery Dates

Imagine a project scope that was virtual in that it was constantly recalibrated based on predefined criteria and events. Only the most uninformed and naïve believe that the factors that influence a project remain static over the life of that project. Every experienced project manager knows that the scope set at the beginning of a project in terms of budget and deliverables is at best an educated “best guess” at the time and is going to change; thus the reason for “change orders”.

A mature management will want to approach projects in such a way that the remaining time to complete and monies that need to be spent, reflect the most accurate possible appraisal of reality. However, in most cases management wants to cast early estimates in concrete and threaten grave punishment to the project manager should they miss budgetary and delivery date targets. This in turn often incents those leading the project to lie about progress, representing to management that the project-amazingly–is as complete as the monies that have been spent. The old adage that “project progress can be declared on track right up to the remaining 10 percent of the effort” has roots in this contradiction–and management’s stupidity in such matters.

A more mature and sane approach to managing projects is to recognize from the beginning that events can occur that could substantially impact the project’s budget and delivery date. Based on this analysis, a set of planned recalibrations can be forecast, along with the trigger points that would indicate a change in scope was needed. Being proactive in this regard is the key to being intelligent about true scope management.

3. Drive Scope Changes Based on Delivery Date Impact

Truth be known, when push comes to shove, delivering a project on time is more important than delivering it on budget about 99 percent of the time. This is because any project that sports an attractive ROI is worth having sooner than later. In addition, most mission-critical projects have a window of opportunity that, once closed, might not reappear for some time. Using a Delivery Date-driven approach to scope management provides a great yardstick for evaluating whether a change in scope is worth the acceleration or delay of the project’s due date.

Under this method, the cost of the change would be equal to the actual cost to perform the work plus/minus the loss/gain in return. This pendulum swings both ways as sometimes the elimination of a deliverable can shave precious time off the delivery date.

For example, assume a set of deliverables (not functionally critical of course) were estimated to cost about $75,000 and take two months to deliver. If the original project budget were $5 million and the estimated return was 20 percent, then the monthly value of the return would be over $80,000 a month. Therefore, to add this change to the project would have a cost of $235,000 (75k + (80k X 2), while deleting these deliverables would have a equivalent savings. This approach can be very sobering to management and keep things very honest and above board.

4. Build Recalibration Point into the Project Plan Based on Changes to External Factors and Knowledge Gains

For over 12 years, I have been building recalibration points into project work plans. These points often coincide with milestones or phase breaks and, by design, are planned opportunities to revisit the scope of the project and its value to the organization. Not once has management seen this as an issue–it has embraced the forward-thinking it represents, providing them options at critical junctures during the project. Each recalibration point consists of a set of tasks that includes validating the delivery time, resources requirements, opportunities for acceleration, assessment of new risks, market conditions, external events and, of course, a recasting of the budget. Once completed, a “go forward” recommendation is submitted to management and – if approved – the project continues.

These short sanity checks only take a few hours to perform because they are planned, and most of the work completed before the date due. There are times that, without the use of this strategy, projects that ended up being successful might have crashed and burned in failure.

5. Drive Budgets and Delivery Dates Using More Granular Deliverable Definitions

In September of 2007, gantthead published my article entitled “Identifying Requirements from BPI Documentation”, where I presented a method for extrapolating very granular requirements from high-level BPI documentation. By granular I am referring to every explicit and implicit input, process and output that is needed to support the improvement opportunities identified in a BPI initiative. This same approach works outside the BPI environment and is based on a set of rules that can be applied to any set of processes and data structures. I encourage you to read this article; the approach has been well-tested and goes hand-in-hand with the discovery strategy previously presented.

6. Add a New Deliverable Assessment/Acceptance Process to the Project Governance Framework

Nothing vets a proposed change to a project’s scope than a pre-defined process for assessing and evaluating the change requests. As stated in the beginning of the article, people are going to change their minds about what they need and want – it’s just part of human nature. To suppress this process is to invite people to buy out of the project and become points of continued angst and risk. Every week, change requests should be consolidated and an associated impact analysis performed. Then, as part of the normal project portfolio status meetings, the requests should be scored and ranked based on the assessment criteria (i.e. value to project, impact on delivery date, cost, resource availability, trade-offs, etc.). The project plan is updated (budgets, timetables, etc.) for changes that are approved. In this way, the change process is orderly and manageable and-voila!-scope creep is a thing of the past.

7. Allow for a Deliverables Trade-off Process

Sometimes, requested increases to the scope of a project can be accompanied with offsetting scope reductions. This is often the case when budget is rigid and, in essence, the organization wants as much as it can get for a finite investment. Under this strategy, people requesting new deliverables must also be willing to trade-out other deliverables. Just like in the above strategies, this is best accomplished using a predefined set of evaluation criteria so the value of the trade-offs can be quantified, reducing the emotional side of the equation in the decision process as much as possible.

Once again, the project plans are recalibrated to reflect the changes approved and things continue on, business as usual.

8. Create a “Time Boxes” Releases Strategy

“Time boxing” is a well-accepted method for chunking deliverables into a series of smaller groups that can be delivered quickly. Not all projects lend themselves to time boxing, but many do. The most difficult part of this strategy is to get people to accept a partial set of deliverables. Often, those using business applications are fearful that they will only get one chance to get what they want and thus pile on the requirements until the project is so big and costly they end up with nothing at all. This of course reinforces their fear, and thus a cycle of self-fulfilling prophecies occurs.

The interesting dynamic is that once time-boxed projects are successful, the user population usually insists on this approach on all future projects. This presents an excellent opportunity to implement a formal release strategy that offers upgrades to the application base on a quarterly or semi-annual basis. Once in place, maintenance costs are typically reduced as a much more prudent approach to change management is employed. Under the release strategy approach, requests for application improvements are accumulated and mapped into the existing application base.

Similar requests can thus be combined to take advantage of any economies of scale that might exist. This reduces the overall cost and labor that would otherwise be experienced. The improvement requests are then parsed into a series of logical releases based on what can be accomplished in three- to six-month segments. Few IT organizations ever really get this level of order and stability to their project environment, when it comes to the care and feeding of the installed application base. Of course, this approach does not lend itself to new application deployments like an ERP, CRM or data warehouse project.

Summing it up

Armed with eight real-world strategies, you are ready to tackle and master the process of project scope management. Scope creep should be a thing of the past and, if successful, you should expect your PM prowess to be that of legend. Good luck!

References

5.0 Project Scope Management
Wikipedia on Project Scope Management
Project Scope Management
Tutorial – Project Scope Management
Managing Project Scope – a neglected dimension of effective performance on diverse projects – by Walter A. Wawruck
Defining the Scope in IT Projects – Neville Turbit
Business Dream – Project Scope Management

Don’t forget to leave your comments below

---

Michael Wood is a CPA, and Subject Matter Expert on IT Strategy and Business Process Improvement. He is currently a freelance consultant. Prior to that, he was the President of The Natural Intelligence Group. In the late 1990s, Michael was the Executive Vice President of Outcomes Management for the Corporation for Standards and Outcomes (CS&O), a leader in the development of outcome-based management methods and Internet applications in the behavioral healthcare industry.

Before joining CS&O, Michael was the Vice President of MIS for Showboat Operating Co. In addition to his traditional CIO duties, he led the implementation of all technology used at Showboat’s newest properties in Sydney, Australia, and Northwest Indiana.

From 1981 through 1989, Michael headed Helix Corporation, a management consulting company, with clients in the entertainment, aerospace, healthcare, gaming and distribution industries.
As an educator, Michael served as an Adjunct Professor in Pepperdine University’s MBA program and as Associate Professor at California Lutheran University.

His broad industry background and experience has positioned Mr. Wood as an expert in the field of business process improvement and reengineering, which is the focus of his new book The HELIX Factor: The Key to Streamlining Your Business Processes. http://www.amazon.com/exec/obidos/ASIN/0965980936/qid%3D969905403/102-7216132-7996939

Copyright © 1999-2006 gantthead.com, Inc. Reproduced by permission of gantthead.com, Inc.