Project Scope Management
Darren Wich
IS 6840
11/6/09
Introduction
According to the 2009 Standish Group Chaos report only 32% of ITprojects are delivered on time, on budget and have the requiredfeatures and functions asked for. In addition 44% of projects werelate, over budget and were delivered with incomplete features orfunctionality. The final 24% remaining were complete failures dues tocancellation prior to completion or were delivered and never used (4).These failures have cost numerous companies millions of dollars andcountless reputation points as a result. These facts put a high premiumon successful project management in the IT world today. There are manyaspects to successful project management but it starts with a projectmanager's ability must simultaneously manage the four basic elements ofa project: resources, time, money and most importantly scope (8).
How Project Management Works
The four basic elements of project management are further elaborated as:
- Resources: People, equipment, hardware/software
- Time: Task durations, schedule management, critical path
- Money: Costs, contingencies, profit
- Scope: Project size, goals, requirements
It is up to the project manager(s) to successfully manage all fourof these elements throughout the lifespan of the project in orderachieve success in the end. First off, the proper resources must beavailable for the project and those resources must be managedeffectively. For example, a software company designing a new databasefor a client must have experienced enough programmers to get the jobdone or else the project is doomed from the start. The project managermust know the capabilities of their team and when they may needadditional help. Time management is the second piece of the puzzle,without managing the time spent on each task the ability to stay withinbudget will likely be compromised. Under or overestimating the timespent on each task can produce several adverse results. For example toolittle time can result in a rushed or poorly designed product.Conversely spending extra time will likely result in an over budgetproduct that is unnecessarily detailed and took too long to complete.Next, the cost element comes into play. Often this aspect is the onemetric that upper management looks at the most when deciding if aproject is successful. Every task has a cost associated with it,whether its labor hours for programmers or buying new hardware for acertain task. All these costs are estimated and a budget is createdbased on the estimated cost. Additional resources may be set aside on acontingency basis to allow for slight changes throughout the durationof the project. Everything that goes into planning the budget isdesigned to maximize the profit that will result from the potentiallysuccessful project. The final and most important element of the projectmanagement process is scope. The scope is simply defined as all thework that goes into the project to create the end result, or thetotality of all the elements mentioned above. Maintaining proper scopeis the key to any project.
Why is scope so important?
Anyone who has ever completed a project will surely have tales ofhow scope changes have had a negative overall effect. Scope change isbound to happen and is expected in most cases, but the goal is to keepyour scope as focused as possible in hopes of creating as straight of aline to you and your client's goal as possible. Thomas Cutting of TheProject Management Hut had this example: "My father is semi-retired,which means he would rather be working than sitting around. He nowdrives a tractor for a potato farm in western New York State. In orderto plow a straight line he focuses on a point at the far end of thefield and aims for it. One time he finished a row and found that thepoint he had picked was the head of a duck that was walking back andforth along the edge of the field. Needless to say, that row was noteven close to straight. If you allow your scope to waddle back andforth your project will experience similar consequences." (17)If a projects scope is clearly identified and properly associated tothe resources, time and budget throughout the project lifespan thelikelihood for success is greatly improved. Allowing your scope to movearound like a ducks head may get you to your goal eventually, but notvery efficiently. Going deeper reveals that scoping can be broken downto 5 step by step components to guide you through the process smoothly.These components are project initiation, scope planning, scopedefinition, scope verification, and scope change control (17).
Project Initiation
Projects are initiated when a business need arises. This may mean aconsulting company is asked by a customer to redesign their website orpossibly the consulting company itself needs to update its ownintranet. Whenever a need appears project initiation is a way toevaluate that need and come up with an acceptable solution. A projectmanager is assigned to the potential project at this point of theprocess. Before the project gets the green light a feasibility analysisis done. Project feasibility analysis is comprised of technical,economic, and financial aspects. Technical feasibility determines ifthe company has the technological expertise to carry out the project.Economic feasibility evaluates cost-benefit ratios of the differenttechnological options available and projects the rate of return for theprojects expected lifespan. Financial feasibility deals with all of thepotential costs associated with the project. A detailed feasibilityanalysis is the most important output from the initiation phase ofscope management. This allows management to give the go-ahead forproject to proceed or to shelve it (17).
Scope Planning
This stage of the scoping process is all about developing an initialWork Breakdown Structure (WBS). A WBS is a results-oriented family treethat captures all the potential work to be done in the project in anorganized way. It is often portrayed graphically as a hierarchicaltree; however, it can also be a list of element categories and tasks.Large complex projects are more easily understood by breaking them intoprogressively smaller pieces until they are a collection of defined"work packages" that may include a number of tasks. A $1,000,000,000project is simply a lot of $50,000 projects joined together (2).The WBS is used to provide the framework for organizing and managingthe work in smaller deliverables. The summary of the WBS at this stageof the project identifies the key deliverables that the project shouldprovide. Assigning deliverables allows the team to focus on eachsmaller piece and add details to it where they see fit. Without abreakdown the project would appear too broad and lack the attention todetail of a more defined project.
Scope Definition
At this point most of the pieces of the project have been put intoplace: 1) A project manager has been assigned 2) team formed 3) theproject has been deemed feasible 4) summary of the WBS has been formed5) the budget and schedule have been outlined. Now it's time to adddetails to the project as a whole. The WBS will be expanded to includeexactly the type of work that will be done, detail is very importanthere. This involves working closely with the client and getting what iswanted out of the project into the WBS (17). Forexample if the customer and consulting firm are discussing ways tochange or improve the customer's website, all the conclusions will betaken down here and a detailed final design will be the result.Everything from the colors of the front page to what emotional reactionthe customer wants its visitors to get from the site will be defined inthis stage. By this phase actual work on the project has begun.
Scope Verification
Scope verification by nature is interwoven with the definition andplanning phases. It also provides an opportunity for the client to comeback after some of the initial work has been done and verify that thework is deemed acceptable. Since the different components of scopemanagement are aimed at the same goal of providing a uniform scopethroughout the project all of them tend to overlap at times but this isa natural process. Because of this it's a possibility to see scopeverification many times during the process. If the client prefers theirwebsite to be a different color scheme or function differently now isthe time to work with the consultant on these changes. The purpose inmind is to keep both parties goals as close to the uniform straightline as possible. This phase is designed to strengthen and reinforcethe initial scope definition through feedback.
Scope Change Control
During any project, scope change is inevitable as two or moredifferent parties work towards a goal that satisfies everyone. Here theconcept of scope creep is introduced, which applies to any unauthorizedchanges to the project scope. Because of the potentially disastrousconsequences of scope change whether wanted or unwanted, testing isvital at this point of the process. If during testing changes areneeded there must be documentation. A change control is the type offormal documentation that provides official statements about anychanges in project scope to guide the process as smoothly as possible.A scope change control should be put in place as early as possible toclassify the types of requests that take place during the project.Changes in scope can have a great effect on every element of theprocess with the most important being cost. Defining these changes inan orderly fashion will help keep the client involved and ultimatelyaffect the schedule, cost, and quality of the finished product.
Scope Creep
Throughout the process of determining scope and managing a projectone of your biggest enemies will be scope creep. Allowing your scope towander too much can wreak havoc on your budget, time deadline and justabout any aspect of a project that you can imagine. "Scope creep is anatural part of every project", says Douglas Brindley, senior vicepresident of consulting firm Software Productivity Research (SPR).According to SPR, requirements in an internal development project groweach month by about 2% of the original list. But as time passes,accommodating requests becomes more expensive, with new requirements atthe coding or testing stages costing an order of magnitude more thanthose added during the first three months (19)."The projects that are successful are the ones that create a tightprocess to manage creep from the beginning. Knowing what a feature willcost before it's approved is key" adds Brindley (19).Clearly one the most damaging aspects of scope creep is increasingproject cost. Not only does adding more features drain the projectbudget, but adding the time they require also pushes back completiondates causing a loss to the potential profits that would have beenrealized with an on time finish date. Scope creep can also create alarger and more complex end result that costs more to maintain in theend, thus cutting into the profits that a newer more efficient systemwas supposed to realize. So what causes scope creep and how can thoseproblems be fixed? A few reasons that allow scope creep to become anissue are as follows:
1. Poor Work Breakdown Structure
Some customers only have a vague idea of what they want or tend tohave "I'll know it when I see it" syndrome. Since there is a lack ofknowledge about what is required moving into the project there is oftena need for extra unplanned resources which end up increasing the costand lengthening the duration of the project. (5)Often the solution to this problem is a more thorough WBS along withmore time spent with the customer specifically going over what is inand out of scope while putting it down in writing. A firm agreement onthe initial WBS can save many "who's to blame" accusations further downthe road.
2. Underestimating the Complexity of the Project
Many times when a company takes on a newer project or does somethingfor the first time they run into problems staying within scope. Withoutknowing what to expect out of a particular project things can go astrayquickly, typically causing the project to be over budget and oftenlate. These types of projects should have a degree of contingency builtinto them; allow some extra time and resources for when things getbigger than you expected (5). Allowing a little extraroom for time and money concerns can make the process of doingsomething new and exciting a little less scary from a budgetperspective.
3. Lack of Change Control
As talked about previously having a change control process is veryimportant once the project gets underway. Without proper documentationscope creep can run wild without the company or customer being heldaccountable. A customer who changes the layout of their website 3 timesduring a project but files no paperwork may be shocked when the finalprice comes down to them. Each individual change took time andresources that won't be apparent once the final design is complete, butwill be reflected in the final bill. If changes to the scope are madethey need to be accompanied by an official change request form alongwith them with a cost and time span attached to them. Going through aformal process of a change control form helps establish the value ofthe change to the customer when it's being considered.
4. Gold Plating
This problem occurs during the design process when a developer addson features outside of the initial scope in an attempt to make theproduct better or add some type of "wow" factor. In the end thesefeatures usually just add to the time and budget of the projectunnecessarily. While the developer may think that a certain feature isneeded the customer may not always see it that way, leaving the addedfeatures unused or even worse, unusable. This problem is solved bymaking sure that all team members are aware of staying within theproject scope and stick to it as closely as possible. Emphasize theimportance of completing the project on time and only with the featuresasked for within the WBS. While an experienced developer who's seenmany similar projects may think they know what's best, it's a good ideato keep in mind that the customer, not developer, will be using the endresult. 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 trustsyour team to come up with the right design provides an environment fordevelopers to let their imaginations go without fear of therepercussions of programming outside the box. This is often not thecase as it provides a number of budgeting and time requirementproblems, but in some unique cases it may be the best way to go inorder to get the most creativity out of the project team.
Conclusion
With the issues that scoping a project presents it can seem like adaunting or almost impossible task to avoid scope creep in some form.Back in 1994 a whopping 80% of 160 IS professionals surveyed byComputerworld said scope creep "always" or "frequently" occurs, whileonly 20% said it seldom happened (12). Thoughtoday's Standish Group Chaos Report seems gloomy by itself there hasbeen some improvement in project success rates. Most importantly theimprovement has been in the project success category, where from 1994to 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 thatthe importance of proper scope management has become a focal point forproject managers everywhere. It's much easier to manage the scope ofyour project in several proven ways: using effective customer clientcommunication throughout the process, staying within the limits of yourteam, properly documenting important events in the development processand staying within the guidelines provided are all great ways to manageyour scope effectively. Proper scope management greatly improves yourteam's ability to stay within budget and use time effectively. Aboveall else the most important aspect of the process is coming up with anend 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.)
