Project Scope Management
Darren Wich
IS 6840
11/6/09
Introduction
According to the 2009 Standish Group Chaos report only 32% of IT projects are delivered on time, on budget and have the required features and functions asked for. In addition 44% of projects were late, over budget and were delivered with incomplete features or functionality. The final 24% remaining were complete failures dues to cancellation prior to completion or were delivered and never used (4). These failures have cost numerous companies millions of dollars and countless reputation points as a result. These facts put a high premium on successful project management in the IT world today. There are many aspects to successful project management but it starts with a project manager's ability must simultaneously manage the four basic elements of a project: resources, time, money and most importantly scope (8).
How Project Management Works
The four basic elements of project management are further elaborated as:
It is up to the project manager(s) to successfully manage all four of these elements throughout the lifespan of the project in order achieve success in the end. First off, the proper resources must be available for the project and those resources must be managed effectively. For example, a software company designing a new database for a client must have experienced enough programmers to get the job done or else the project is doomed from the start. The project manager must know the capabilities of their team and when they may need additional help. Time management is the second piece of the puzzle, without managing the time spent on each task the ability to stay within budget will likely be compromised. Under or overestimating the time spent on each task can produce several adverse results. For example too little time can result in a rushed or poorly designed product. Conversely spending extra time will likely result in an over budget product that is unnecessarily detailed and took too long to complete. Next, the cost element comes into play. Often this aspect is the one metric that upper management looks at the most when deciding if a project is successful. Every task has a cost associated with it, whether its labor hours for programmers or buying new hardware for a certain task. All these costs are estimated and a budget is created based on the estimated cost. Additional resources may be set aside on a contingency basis to allow for slight changes throughout the duration of the project. Everything that goes into planning the budget is designed to maximize the profit that will result from the potentially successful project. The final and most important element of the project management process is scope. The scope is simply defined as all the work that goes into the project to create the end result, or the totality of all the elements mentioned above. Maintaining proper scope is the key to any project.
Why is scope so important?
Anyone who has ever completed a project will surely have tales of how scope changes have had a negative overall effect. Scope change is bound to happen and is expected in most cases, but the goal is to keep your scope as focused as possible in hopes of creating as straight of a line to you and your client's goal as possible. Thomas Cutting of The Project Management Hut had this example: "My father is semi-retired, which means he would rather be working than sitting around. He now drives a tractor for a potato farm in western New York State. In order to plow a straight line he focuses on a point at the far end of the field and aims for it. One time he finished a row and found that the point he had picked was the head of a duck that was walking back and forth along the edge of the field. Needless to say, that row was not even close to straight. If you allow your scope to waddle back and forth your project will experience similar consequences." (17) If a projects scope is clearly identified and properly associated to the resources, time and budget throughout the project lifespan the likelihood for success is greatly improved. Allowing your scope to move around like a ducks head may get you to your goal eventually, but not very efficiently. Going deeper reveals that scoping can be broken down to 5 step by step components to guide you through the process smoothly. These components are project initiation, scope planning, scope definition, scope verification, and scope change control (17).
Project Initiation
Projects are initiated when a business need arises. This may mean a consulting company is asked by a customer to redesign their website or possibly the consulting company itself needs to update its own intranet. Whenever a need appears project initiation is a way to evaluate that need and come up with an acceptable solution. A project manager is assigned to the potential project at this point of the process. Before the project gets the green light a feasibility analysis is done. Project feasibility analysis is comprised of technical, economic, and financial aspects. Technical feasibility determines if the company has the technological expertise to carry out the project. Economic feasibility evaluates cost-benefit ratios of the different technological options available and projects the rate of return for the projects expected lifespan. Financial feasibility deals with all of the potential costs associated with the project. A detailed feasibility analysis is the most important output from the initiation phase of scope management. This allows management to give the go-ahead for project to proceed or to shelve it (17).
Scope Planning
This stage of the scoping process is all about developing an initial Work Breakdown Structure (WBS). A WBS is a results-oriented family tree that captures all the potential work to be done in the project in an organized way. It is often portrayed graphically as a hierarchical tree; however, it can also be a list of element categories and tasks. Large complex projects are more easily understood by breaking them into progressively smaller pieces until they are a collection of defined "work packages" that may include a number of tasks. A $1,000,000,000 project is simply a lot of $50,000 projects joined together (2). The WBS is used to provide the framework for organizing and managing the work in smaller deliverables. The summary of the WBS at this stage of the project identifies the key deliverables that the project should provide. Assigning deliverables allows the team to focus on each smaller piece and add details to it where they see fit. Without a breakdown the project would appear too broad and lack the attention to detail of a more defined project.
Scope Definition
At this point most of the pieces of the project have been put into place: 1) A project manager has been assigned 2) team formed 3) the project has been deemed feasible 4) summary of the WBS has been formed 5) the budget and schedule have been outlined. Now it's time to add details to the project as a whole. The WBS will be expanded to include exactly the type of work that will be done, detail is very important here. This involves working closely with the client and getting what is wanted out of the project into the WBS (17). For example if the customer and consulting firm are discussing ways to change or improve the customer's website, all the conclusions will be taken down here and a detailed final design will be the result. Everything from the colors of the front page to what emotional reaction the customer wants its visitors to get from the site will be defined in this stage. By this phase actual work on the project has begun.
Scope Verification
Scope verification by nature is interwoven with the definition and planning phases. It also provides an opportunity for the client to come back after some of the initial work has been done and verify that the work is deemed acceptable. Since the different components of scope management are aimed at the same goal of providing a uniform scope throughout the project all of them tend to overlap at times but this is a natural process. Because of this it's a possibility to see scope verification many times during the process. If the client prefers their website to be a different color scheme or function differently now is the time to work with the consultant on these changes. The purpose in mind is to keep both parties goals as close to the uniform straight line as possible. This phase is designed to strengthen and reinforce the initial scope definition through feedback.
Scope Change Control
During any project, scope change is inevitable as two or more different parties work towards a goal that satisfies everyone. Here the concept of scope creep is introduced, which applies to any unauthorized changes to the project scope. Because of the potentially disastrous consequences of scope change whether wanted or unwanted, testing is vital at this point of the process. If during testing changes are needed there must be documentation. A change control is the type of formal documentation that provides official statements about any changes in project scope to guide the process as smoothly as possible. A scope change control should be put in place as early as possible to classify the types of requests that take place during the project. Changes in scope can have a great effect on every element of the process with the most important being cost. Defining these changes in an orderly fashion will help keep the client involved and ultimately affect the schedule, cost, and quality of the finished product.
Scope Creep
Throughout the process of determining scope and managing a project one of your biggest enemies will be scope creep. Allowing your scope to wander too much can wreak havoc on your budget, time deadline and just about any aspect of a project that you can imagine. "Scope creep is a natural part of every project", says Douglas Brindley, senior vice president of consulting firm Software Productivity Research (SPR). According to SPR, requirements in an internal development project grow each month by about 2% of the original list. But as time passes, accommodating requests becomes more expensive, with new requirements at the coding or testing stages costing an order of magnitude more than those added during the first three months (19). "The projects that are successful are the ones that create a tight process to manage creep from the beginning. Knowing what a feature will cost before it's approved is key" adds Brindley (19). Clearly one the most damaging aspects of scope creep is increasing project cost. Not only does adding more features drain the project budget, but adding the time they require also pushes back completion dates causing a loss to the potential profits that would have been realized with an on time finish date. Scope creep can also create a larger and more complex end result that costs more to maintain in the end, thus cutting into the profits that a newer more efficient system was supposed to realize. So what causes scope creep and how can those problems be fixed? A few reasons that allow scope creep to become an issue are as follows:
1. Poor Work Breakdown Structure
Some customers only have a vague idea of what they want or tend to have "I'll know it when I see it" syndrome. Since there is a lack of knowledge about what is required moving into the project there is often a need for extra unplanned resources which end up increasing the cost and lengthening the duration of the project. (5) Often the solution to this problem is a more thorough WBS along with more time spent with the customer specifically going over what is in and out of scope while putting it down in writing. A firm agreement on the initial WBS can save many "who's to blame" accusations further down the road.
2. Underestimating the Complexity of the Project
Many times when a company takes on a newer project or does something for the first time they run into problems staying within scope. Without knowing what to expect out of a particular project things can go astray quickly, typically causing the project to be over budget and often late. These types of projects should have a degree of contingency built into them; allow some extra time and resources for when things get bigger than you expected (5). Allowing a little extra room for time and money concerns can make the process of doing something new and exciting a little less scary from a budget perspective.
3. Lack of Change Control
As talked about previously having a change control process is very important once the project gets underway. Without proper documentation scope creep can run wild without the company or customer being held accountable. A customer who changes the layout of their website 3 times during a project but files no paperwork may be shocked when the final price comes down to them. Each individual change took time and resources that won't be apparent once the final design is complete, but will be reflected in the final bill. If changes to the scope are made they need to be accompanied by an official change request form along with them with a cost and time span attached to them. Going through a formal process of a change control form helps establish the value of the change to the customer when it's being considered.
4. Gold Plating
This problem occurs during the design process when a developer adds on features outside of the initial scope in an attempt to make the product better or add some type of "wow" factor. In the end these features usually just add to the time and budget of the project unnecessarily. While the developer may think that a certain feature is needed the customer may not always see it that way, leaving the added features unused or even worse, unusable. This problem is solved by making sure that all team members are aware of staying within the project scope and stick to it as closely as possible. Emphasize the importance of completing the project on time and only with the features asked for within the WBS. While an experienced developer who's seen many similar projects may think they know what's best, it's a good idea to keep in mind that the customer, not developer, will be using the end result. Ultimately giving the customer what they want is the goal (5).
Positives of Scope Creep
Managing the scope of a project can prove difficult and there are even cases where scope creep can be viewed positively. (12) A situation where a client has little idea what they want but trusts your team to come up with the right design provides an environment for developers to let their imaginations go without fear of the repercussions of programming outside the box. This is often not the case as it provides a number of budgeting and time requirement problems, but in some unique cases it may be the best way to go in order to get the most creativity out of the project team.
Conclusion
With the issues that scoping a project presents it can seem like a daunting or almost impossible task to avoid scope creep in some form. Back in 1994 a whopping 80% of 160 IS professionals surveyed by Computerworld said scope creep "always" or "frequently" occurs, while only 20% said it seldom happened (12). Though today's Standish Group Chaos Report seems gloomy by itself there has been some improvement in project success rates. Most importantly the improvement has been in the project success category, where from 1994 to 2009 we've seen a jump from 16.2% to 32% (9). There have been ups and downs over this time span but it is clear that the importance of proper scope management has become a focal point for project managers everywhere. It's much easier to manage the scope of your project in several proven ways: using effective customer client communication throughout the process, staying within the limits of your team, properly documenting important events in the development process and staying within the guidelines provided are all great ways to manage your scope effectively. Proper scope management greatly improves your team's ability to stay within budget and use time effectively. Above all else the most important aspect of the process is coming up with an end result that satisfies the customer.
Works Cited
Web Sources:
1. Babu, Suresh. 2005. "Scope creep is not only inevitable; it's natural." Online. uca.eis.googlepages.com/ScopeCreep.pdf
2. Chapman, James. "Work Breakdown Structure." 1997-2004. Online. http://www.hyperthot.com/pm_wbs.htm
3. Cutting, Thomas. "Scope Creep." October 8, 2007. Online. http://www.pmhut.com/scope-creep-part-5
4. Galorath, Dan. "2009 Standish Chaos Report.. .Software Going Downhill." Online. http://www.galorath.com/wp/2009-standish-chaos-report-software-going-downhill.php Dan Galorath
5. Haughey, Duncan."Scope Creep Running Away with your project." Online. http://www.projectsmart.co.uk/stop-scope-creep-running-away-with-your-project.html
6. Helms, Hal. "In Defense of Scope Creep." September 20, 2002. Online http://www.alistapart.com/articles/scopecreep/
7. Phillips, Joseph. "Real World Project Management: Managing the Project Scope." January 28, 2005. Online. http://www.ciscopress.com/articles/article.asp?p=363892
8. Reh, F. John. "Project Management 101." Online. http://management.about.com/cs/projectmanagement/a/PM101.htm
9. Standish Group Onine. http://www.standishgroup.com/newsroom/chaos_2009.php
10. Turbit, Neville. "Defining the Scope in IT Projects." 2009. Online. http://www.projectperfect.com.au/info_define_the_scope.php
Non-Web Sources:
11. Anthes, Gary H. "No more creeps!" Computerworld. May 2, 1994. Vol. 28, Iss. 18, p. 107 (3 pp.)
12. Boivie, Catherine A. "We Want Usability, Not Just Features." Canadian Computer Reseller. May 26, 1999. Vol. 12, Iss. 10, p. 22
13. Buckler, Grant. "Staking One for the Team." Computing Canada. October 22, 2004. Vol. 30, Iss. 15, p. 16-17 (2 pp.)
14. Buschmann, Frank. "Learning from Failure, Part 1: Scoping and Requirements Woes." IEEE Software. Nov/Dec 2009. Vol. 26, Iss. 6, p. 68-69
15. Ingardia, Mike. "12 Steps to Keep 'Scope Creep' From Destroying Design Project Profit Margins." Principal's Report. July 2006. Vol. 06, Iss. 7, p. 1,10-14 (6 pp.)
16. Kahn, Asadullah. "Project Scope Management." Cost Engineering. June 2006. Vol. 48, Iss. 6, p. 12-16 (5 pp.)
17. Kraus, William E "Bill". "Cost Estimating and Analysis." Cost Engineering. April 2008. Vol. 50, Iss. 4, p. 3-4 (2 pp.)
18. Kwon, Regina and Virzi, Anna Maria "Containing the Pain of Scope Creep.". Baseline. March 1, 2002. Vol. 1, Iss. 4, p. 69
19. Tynan, Dan. "Worst Case Scenario: IT Survival Guide." InfoWorld. January 30, 2006. Vol. 28, Iss. 5, p. 24-26,28,30,32 (6 pp.)
20. Zimmerman, Eric. "Preventing Scope Creep." Manage. February 2000. Vol. 51, Iss. 3, p. 18-19 (2 pp.)