Flood Control

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

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

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

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

Edwards' experience with scope creep at United Health Group has not been bad because the company does the upfront work that is necessary, particularly meeting with both the technology and the business groups. “When you communicate with the technology people primarily or the business people primarily, you have a lot of opportunity for scope to creep in,” he remarks. “When you engage both teams at the same meeting, you tend to have fewer things that surprise you in the end.

“One of the things we've done is what we call an event modeling session,” Edwards says. “The scope of the project doesn't have to be fully signed off on at that time, but we go into event modeling sessions where we have the technology and the business, and we try to 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 cautions it already is too late to worry about scope creep. “It all starts at the beginning when you define the project,” he says. When companies discover scope creep is taking over, the business side, IT, and IT leaders will debate whether the issue under discussion was in scope or out of scope to begin with. “You need to do things upfront when you initiate a project to make scope clear,” he advises. “That means having a business model in place, a process model, your business case defined, and your road map that communicates what it's going to look like for business and IT. Having your scope well defined to begin with is the way to start and critical to being able to identify what to change.”

Schmitz points to three different tactics carriers must use in such situations: governance, project management and methodology discipline, and the relationship between business and IT.

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

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

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

Raed Haddad, senior vice president of client programs for ESI International, a project management training group, likes to go through a checklist with his customers, and the first item is to identify or establish the current state of project management. “What I mean by that is how badly or how well are you running your projects?” 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 the tools approach to sit down with the nontechnical user and translate the information [they receive] into IT-speak? That's the usual user-IT dilemma, where someone is speaking in English and the other is speaking in IT language.”

The second step is establishing a business requirements document (BRD). “You would be amazed at the incomplete or insufficiently documented BRDs that exist out there for large projects,” notes Haddad. It is important to get the BRD correct by using the right people to solicit the requirements and document them. “Make sure you 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 ambiguous upfront, so the scope creep can increase exponentially.”

The next point is to make sure there are systematic and controllable change management processes in place. “You know things will change down the road,” says Haddad. “As long as you come back to the data you started with, you can make much better decisions vs. comparing it with a gray document where people say, 'I thought you meant this.'”

One ESI client uses risk managers to examine the change management process to undergo effective peer review. “Their sole role is to poke holes in the BRD or in the scope amount before you start the work,” he says.

Many carriers have change control boards in place. These groups identify the impact of changes, explains Singh. Based on the projected impact, the proposal then goes to a project governance committee, which Singh indicates could be an executive sponsor or an even larger group. “If a project suddenly goes from size X to 2X, you might need to take [the changes] to a larger group because there are other projects waiting for resources,” he advises. “You have to evaluate the impact of delaying the next set of projects.”

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

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

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

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

While the management of scope creep is much better than it ever was, according to Haddad, it still remains a large issue for companies. To combat it, companies need to get their requirements done correctly the first time around. “Organizations that have invested more upfront–not necessarily from a project management point of view but with business analysis and requirements-gathering techniques–make the role of the project manager easier and managing scope easier throughout the life cycle of the project,” he says.

In almost every study Haddad has seen about the failure of projects, scope creep and poor scope management always are cited in the top two positions as the culprit. “The simple reason behind that is organizations don't realize it takes a specific type of skill to bridge the gap between the user community and the IT folks,” he says.

While some companies rely on the project manager or other professionals to interact with the clients and users in order to analyze the current state of the operation and validate the requirements, document the requirements, and put testing plans together, Haddad believes someone serving the operation as a business analyst should perform those functions. “Some [project managers] can do that, but generally speaking, [these are] Type A skills that not all project managers would possess, and instead you need to look for individuals whose job function is a business analyst,” says Haddad. “[Business analysts] are the folks who use their specific skills and approaches that a project manager wouldn't have.”

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

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

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

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

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

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

At United Health Group, Edwards reports, project finances are tracked on a monthly basis, which gives the carrier the ability to see variances. Sometimes those variances can be attributed to a changing scope of the project, so project managers have to include those changes in the change management process. “If you introduce the new scope of the project, you have to match the budget item with the scope to incorporate that into the original budget of the project so you don't have a big variance,” says Edwards.

Another problem to be addressed occurs when business units try to get more out of the project than what they invested. Cullari points out a good project manager can minimize that issue by explaining the project doesn't have the luxury of dedicated resources forever. “[IT resources] are expected to work on certain things for a certain amount of time, and then they are going to be moved to a different project,” he says. “If you increase your scope and add another month to your project, your resources already are allocated to another project at that start date. The priority project takes precedence and it keeps the resources, and the other project suffers the consequences.”

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

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

There are different methodologies involved with PMOs, adds Schmitz. A key part of what the PMO does centers on the quality and clarity of the business requirements in order to make sure everyone understands the scope of the project. Schmitz also believes the project team needs to continue to refine the scope from what it had been in the project initiation stage. That means having requirements that are well documented and done in a way that business can understand, so both sides don't have disagreements about whether the change really was a change in scope or whether it actually was in scope all the time. The project team needs clarity in the requirements and to have those requirements tied to the company's business perspective. “You reach the point where you can't do everything and need to decide what goes and what stays,” says Schmitz. “Being able to point back that certain things bring specific benefits to the business case and other things don't have an impact on the business case can help you prioritize the process.”

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

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

“I think you find more likelihood of scope creep with outsourced projects because then it is purely a dollar figure involved,” he says. “As long as you are willing to pay [outsourcers], you can allow the scope creep. Whereas if you are doing it all in-house with the resources you have available, those resources are generally committed to something else at a certain date. You really are locked in.”

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

Some projects involve a multiyear commitment, but Haddad doesn't believe a company's approach to projects should depend on the length of the project. “If you have a 12-month project, you will handle it differently than a three-year project, but it is just as important to identify as much as you know about the scope,” he says. “There are a lot of unknowns with three-to-five-year projects, but the process has to be the same.”

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

Haddad recommends a company undertake a series of interventions in which they go back and measure performances a year down the road, for example, assessing the roles between the project manager and the business analyst. This study should be led by the systems architect or the person who sat down with the users and elicited the requirements the IT people used to develop the project requirements.

Edwards believes there are lessons to be learned at the end of each project. All documents from each project are placed in a repository, and that allows another project manager to go to the repository and compare projects, see where the shortfalls were, and determine what was successful. “At least 60 percent of most projects are repeatable,” he says. “We try to see any process we do be repeatable, and we have the same outcome and consistent results.”