The only thing you can guarantee with projects is there will bechanges, asserts Dave Schmitz, who has seen his share of both inhis role at Deloitte Consulting. With projects come changes, andwith changes comes the possibility the project will wander off in adirection that's to no one's liking.

For Schmitz, a director focusing on insurance operationstechnology, and others dealing with managing projects, the successof a project depends on how you control those changes. When thescope of a project changes, you have scope creep, and that affectsthe bottom line, warns Maurice Edwards, program manager for UnitedHealth Group. “When you have a project budget of $100 million andthe scope changes, it could cost your company a couple of milliondollars easily,” he says. “Being able to keep on track of yourtarget means [scope creep] won't have as big an effect on yourbottom line.”

A business project involving technology is not exact science,explains Piyush Singh, senior vice president and CIO of GreatAmerican Insurance Group, who adds putting together an IT projectcan't be compared to constructing a building, for instance. “Youare trying to build something that doesn't come with a set ofblueprints,” he says of IT projects. “You are building somethingthat is a little nebulous in nature. As people start to get a feelfor the project, they learn a little bit more.”

Successful projects usually first must be well defined. Oncethey are defined, dealing with the project's scope comes next,indicates Singh. “Do you really want to achieve Utopia on the firstround, or do you want to focus on a business need?” he asks. “Iliken it to the to-do list you make every weekend at home. Do youget everything done each weekend? Probably not. But you prioritize.You get the most important things addressed first, and the nextweekend, you go back and do the next most important thing. You alsoknow between this weekend and next weekend things change. What'sthird in queue this weekend might be seventh in queue nextweekend.”

Edwards' experience with scope creep at United Health Group hasnot been bad because the company does the upfront work that isnecessary, particularly meeting with both the technology and thebusiness groups. “When you communicate with the technology peopleprimarily or the business people primarily, you have a lot ofopportunity for scope to creep in,” he remarks. “When you engageboth teams at the same meeting, you tend to have fewer things thatsurprise you in the end.

“One of the things we've done is what we call an event modelingsession,” Edwards says. “The scope of the project doesn't have tobe fully signed off on at that time, but we go into event modelingsessions where we have the technology and the business, and we tryto understand the scope, how it will affect our current systems,and what elements of the system are being changed.”

Once a company has started work on a project, Schmitz cautionsit already is too late to worry about scope creep. “It all startsat the beginning when you define the project,” he says. Whencompanies discover scope creep is taking over, the business side,IT, and IT leaders will debate whether the issue under discussionwas in scope or out of scope to begin with. “You need to do thingsupfront when you initiate a project to make scope clear,” headvises. “That means having a business model in place, a processmodel, your business case defined, and your road map thatcommunicates what it's going to look like for business and IT.Having your scope well defined to begin with is the way to startand critical to being able to identify what to change.”

Schmitz points to three different tactics carriers must use insuch situations: governance, project management and methodologydiscipline, and the relationship between business and IT.

With respect to governance, Schmitz mentions one Deloitte clientrecently told him any changes in scope with strategic projects haveto go before a governance council operating similarly to a changecontrol board. “At the very least, when you have changes in scope,cost, or time, there has to be a threshold established for theproject manager to say as long as you are within this threshold youare free to make decisions,” he says. “Once you go beyond thatthreshold, you have to do a certain amount of documentation andbring it to a steering committee for approval.”

Another client of Deloitte complained about the workingrelationship between the business and IT sides at his company.“Some companies use relationship managers or put in a PMO [projectmanagement office] structure to bridge the gap between IT andbusiness and smooth things along so it's not an 'us vs. them'relationship but more of a collaborative relationship,” saysSchmitz. “Sometimes it makes sense to have that in place.” PMOs andgovernance councils often serve the same function fororganizations, although the governance council likely would providemore direction as far as strategic issues.

Another tactic Schmitz recommends is to time-box a project. Bythat he means establishing issues each side agrees on that have tobe in scope; everything else is possibly in scope or possibly not.“What you actually build and deliver is based on how much time youhave,” he says. “You can do this only if you have a strongpartnership between business and IT.”

Raed Haddad, senior vice president of client programs for ESIInternational, a project management training group, likes to gothrough a checklist with his customers, and the first item is toidentify or establish the current state of project management.“What I mean by that is how badly or how well are you running yourprojects?” he says. “But more important, assess the folks you have.What kind of knowledge do they have in soliciting requirements,data modeling, and other skills? Are they equipped enough with thetools approach to sit down with the nontechnical user and translatethe information [they receive] into IT-speak? That's the usualuser-IT dilemma, where someone is speaking in English and the otheris speaking in IT language.”

The second step is establishing a business requirements document(BRD). “You would be amazed at the incomplete or insufficientlydocumented BRDs that exist out there for large projects,” notesHaddad. It is important to get the BRD correct by using the rightpeople to solicit the requirements and document them. “Make sureyou have buy-in and signature from the user and key stakeholders,”he says. “That way you are starting off a project with a clear,identified set of requirements and a certain amount of scope.That's half the problem right there. Many projects are ambiguousupfront, so the scope creep can increase exponentially.”

The next point is to make sure there are systematic andcontrollable change management processes in place. “You know thingswill change down the road,” says Haddad. “As long as you come backto the data you started with, you can make much better decisionsvs. comparing it with a gray document where people say, 'I thoughtyou meant this.'”

One ESI client uses risk managers to examine the changemanagement process to undergo effective peer review. “Their solerole is to poke holes in the BRD or in the scope amount before youstart the work,” he says.

Many carriers have change control boards in place. These groupsidentify the impact of changes, explains Singh. Based on theprojected impact, the proposal then goes to a project governancecommittee, which Singh indicates could be an executive sponsor oran even larger group. “If a project suddenly goes from size X to2X, you might need to take [the changes] to a larger group becausethere are other projects waiting for resources,” he advises. “Youhave to evaluate the impact of delaying the next set ofprojects.”

Three factors–scope, schedule, and budget–need to be put inplace when a carrier begins a large project, states Schmitz.“Anything that is of additional scope but doesn't impact cost ortime, we're OK with,” he says. “You always like to build somecushion around the project. If it is going to be more than a fivepercent or 10 percent variance–or whatever you built in as acushion–[that change] has to go before the change controlboard.”

Exceptions to such rules happen, but Ed Cullari, director of theproject management office for Amerisure Insurance, believes howthose exceptions are treated depends on the visibility of theproject. “[Change] happens, but you have to make a decision: Do Iwant to impact other projects? Can I continue with theseresources?” he asks.

To handle scope creep, Edwards contends a company has to makesure it has a good change control process in place and the businessand technology partners understand the process upfront. “When thereis an element that is out of scope, it goes through [the change]process to estimate the cost and assess whether the business trulywants to add that functionality,” he says.

Once the estimate has been produced by the technology side, theproject manager goes back to the business and relays what thechange will cost and how it will affect the schedule. “At thatpoint, there will be a formal approval process to decide whether toundertake it as part of the project or delay it for another phaseof the project,” Edwards says.

While the management of scope creep is much better than it everwas, according to Haddad, it still remains a large issue forcompanies. To combat it, companies need to get their requirementsdone correctly the first time around. “Organizations that haveinvested more upfront–not necessarily from a project managementpoint of view but with business analysis and requirements-gatheringtechniques–make the role of the project manager easier and managingscope easier throughout the life cycle of the project,” hesays.

In almost every study Haddad has seen about the failure ofprojects, scope creep and poor scope management always are cited inthe top two positions as the culprit. “The simple reason behindthat is organizations don't realize it takes a specific type ofskill to bridge the gap between the user community and the ITfolks,” he says.

While some companies rely on the project manager or otherprofessionals to interact with the clients and users in order toanalyze the current state of the operation and validate therequirements, document the requirements, and put testing planstogether, Haddad believes someone serving the operation as abusiness analyst should perform those functions. “Some [projectmanagers] can do that, but generally speaking, [these are] Type Askills that not all project managers would possess, and instead youneed to look for individuals whose job function is a businessanalyst,” says Haddad. “[Business analysts] are the folks who usetheir specific skills and approaches that a project managerwouldn't have.”

Many companies rely on analysts to do that work as they realizethe best solution to contain scope creep is getting therequirements done right and the scope established properly upfrontbefore doing any work. “The companies that are not doing this, inmy opinion, pay for it down the road,” comments Haddad.

If a project manager is keeping close touch with the businessowners–the stakeholders–and if all parties are focused on theirjobs, Cullari thinks scope creep needn't be as big a problem as ithas been previously. He has a change management process in place,so if something is heading astray, the project managers are on apretty tight leash.

When changes are proposed, Amerisure goes back and redocumentsthe project. “Changes have to be approved, and everyone understandsthe repercussions,” says Cullari. “We've found for our developmentprojects, some of the scope creep is abated because you have moreopportunities to control it. With an iterative approach, you areable to fold changes in with the next release.”

Companies go wrong when they try to squeeze too many things intoa project, Cullari believes. “In years past, I've worked onprojects where the business owner says he has to get it all in withthis iteration because there might not be funding for a seconditeration,” he relates. “If you could call the initial project'phase one' and then go back to the table for 'phase two,' thateliminates scope creep.”

Schmitz finds there are companies that worry too much about theprocess, and the process becomes more important than the project.The solution to that is giving more latitude to project leaders interms of making decisions. “There are cases where a minor change isneeded, and to go through an estimate and put it on a form takeslonger than actually to make the change,” he says. “Where's thevalue?”

When organizations insist every single change must go through aprocess, they are creating overhead, and the additional worksometimes scares people from using the process, reports Schmitz.Team members begin to work outside the process, and you get adifferent set of issues. “Some organizations are more nimble interms of how they align with business and how they operate vs. onesthat are more hierarchical and there's not as much alignment,” hesays. “[The less nimble companies] are where you see the morerestrictive controls in place that may not be necessary.”

At United Health Group, Edwards reports, project finances aretracked on a monthly basis, which gives the carrier the ability tosee variances. Sometimes those variances can be attributed to achanging scope of the project, so project managers have to includethose changes in the change management process. “If you introducethe new scope of the project, you have to match the budget itemwith the scope to incorporate that into the original budget of theproject so you don't have a big variance,” says Edwards.

Another problem to be addressed occurs when business units tryto get more out of the project than what they invested. Cullaripoints out a good project manager can minimize that issue byexplaining the project doesn't have the luxury of dedicatedresources forever. “[IT resources] are expected to work on certainthings for a certain amount of time, and then they are going to bemoved to a different project,” he says. “If you increase your scopeand add another month to your project, your resources already areallocated to another project at that start date. The priorityproject takes precedence and it keeps the resources, and the otherproject suffers the consequences.”

Today's business world no longer affords business units an ITdepartment that is available for their beck and call, notesCullari. “That's not there anymore with the influx of fixed-costprojects,” he says. “The cost is figured out based on so many hoursfor this amount of work.”

PMOs are having a good effect on the industry, according toSchmitz. “In general, what a PMO does is add a little more rigorand discipline around the project management process,” he says.“Part of that project management process includes scope and changecontrol. Whether the PMO is in an oversight role or a guidancerole, it helps beef up your project management discipline.”

There are different methodologies involved with PMOs, addsSchmitz. A key part of what the PMO does centers on the quality andclarity of the business requirements in order to make sure everyoneunderstands the scope of the project. Schmitz also believes theproject team needs to continue to refine the scope from what it hadbeen in the project initiation stage. That means havingrequirements that are well documented and done in a way thatbusiness can understand, so both sides don't have disagreementsabout whether the change really was a change in scope or whether itactually was in scope all the time. The project team needs clarityin the requirements and to have those requirements tied to thecompany's business perspective. “You reach the point where youcan't do everything and need to decide what goes and what stays,”says Schmitz. “Being able to point back that certain things bringspecific benefits to the business case and other things don't havean impact on the business case can help you prioritize theprocess.”

However, a project management office might not be the completeanswer to managing organic growth of a project, according to Singh.Some organizations, he points out, have a core PMO with severalproject managers, and they provide project managers to a team.“Project managers are not those who are loaned to a team but ratherthose who actually are leading the project,” asserts Singh. “Theyare the ones who have context. You are not doing [projectmanagement] as a tracking exercise. You are doing it in the contextof the project.”

“The challenge people need to keep in mind when they areoutsourcing projects is the people who are working on the projectsdon't have a context for the business environment of the companythey are developing a project for,” says Singh. “You don't have thesame amount of interactivity going on.

“I think you find more likelihood of scope creep with outsourcedprojects because then it is purely a dollar figure involved,” hesays. “As long as you are willing to pay [outsourcers], you canallow the scope creep. Whereas if you are doing it all in-housewith the resources you have available, those resources aregenerally committed to something else at a certain date. You reallyare locked in.”

Cullari maintains American companies are finding outsourcing isnot a silver bullet. One area to watch is pricing. Some companiescome in with lower prices, but often that means a sacrifice inquality. “In a sense, [outsourcers] have you captive,” saysCullari. “You need to be careful of contractual terms. Fixed pricessound great. Many companies look at that as 'we got 'em,' butthat's very foolish. That doesn't mean it's not worthwhile to bringin an outside team for strategic projects, but many people justlook at the number. Often, that's not the real number.”

Some projects involve a multiyear commitment, but Haddad doesn'tbelieve a company's approach to projects should depend on thelength of the project. “If you have a 12-month project, you willhandle it differently than a three-year project, but it is just asimportant to identify as much as you know about the scope,” hesays. “There are a lot of unknowns with three-to-five-yearprojects, but the process has to be the same.”

Edwards claims he is not a big proponent of trying to cram ineverything a business user needs at the same time because there ismore risk in doing it that way. United Health Group tries to breaka project into smaller pieces or an iterative process. “That's agood methodology to keeping the project on track and the budget ona smaller portion of the project upfront, so people can begin touse some of the functionality from the project,” he says.

Haddad recommends a company undertake a series of interventionsin which they go back and measure performances a year down theroad, for example, assessing the roles between the project managerand the business analyst. This study should be led by the systemsarchitect or the person who sat down with the users and elicitedthe requirements the IT people used to develop the projectrequirements.

Edwards believes there are lessons to be learned at the end ofeach project. All documents from each project are placed in arepository, and that allows another project manager to go to therepository and compare projects, see where the shortfalls were, anddetermine what was successful. “At least 60 percent of mostprojects are repeatable,” he says. “We try to see any process we dobe repeatable, and we have the same outcome and consistentresults.”