- A New Perspective on Scope
- Classic Scope Control
- Managing Scope Change
- Common Scope Headaches
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Managing Scope Change
There are several change management techniques you can employ to avoid an adversarial relationship with the project sponsor.
The Project Triangle—Scope, Schedule, Resources
A cornerstone of the project manager's role is to ensure that stakeholders understand the tradeoff between scope, schedule, and resources. Tact, diplomacy, and good negotiating skills will go to waste if the client does not understand where their project sits along these three axes. The customer must be able to articulate which legs of the constraint triangle she is willing to change and understand their interdependence. This is a communication challenge that must be met with careful education and reinforced at every opportunity. Rather than being the "project policeman," a more effective approach is to assume a helpful "consulting" role that lasts throughout the duration of the project. As the helpful consultant, you assist the project stakeholders in navigating all sides of the project triangle.
Point–Counterpoint: Stakeholder Tradeoffs
When confronting the unforgiving tradeoffs of the project Triangle, always be a polite problem solver. You should be assisting stakeholders to navigate through difficult choices. Compare these two reactions to a change order that was issued late in the project.
"As the project manager it is my duty to inform you that we just can't cram this feature in and still make the deadline. It's entirely your choice, but if we issue this change order, there is no way my team can hit the deadline. We can't commit to the date if you really want to have this new feature. I must be frank and up front about this so your expectations will be in line with reality. The other option is to add this feature to Phase 2, which I strongly recommend. We can also hire additonal consultants, but you must decide that you're willing to waste $20,000. We'll need a decision within two days so we can revise the project plan."
"Yes, we certainly can build this feature! I've read the description, and I think I understand what you're asking for. In order to build it we'll all have to make some tough decisions. The work that this new feature requires would push us over the deadline, given our current staffing. One solution is to bring additional consultants on board. I ran this scenario on the project plan, and this option adds about $20,000 to the development fees. Optionally, we can move this feature into Phase 2. I suggest that we all sit down and make a list of the consequences that might result from pushing back the deadline. Then we'll measure these against the benefits of having this feature in Phase 1 and consider the budgetary impact of the $20,000."
Getting Project Documents Approved by the Client
As you collaborate with the project team to draft all of the requirements, you will also have to get those documents approved by your client, who will try to squeeze as much work as possible out of your team. The tug-of-war begins as soon as you post the first page mockups to the project Web site. Your new client may drag your team toward defeat by adding features while the deadline remains fixed. Other clients try to cut costs by haggling over every detail as they try to wring a few extra hours out of your overworked developers, or perhaps the first draft page mockups have launched the client into a brainstorming hurricane that spins aimlessly with no end in sight. Threatening to quit seems like a good option, but you'll have better luck scheduling a priorities meeting and applying a few time-tested techniques.
The Chinese Take-Out Menu Approach
A common approach to obtaining sign-off is to help the project stakeholders prioritize features. Once you have all of the decision makers in the room, pull out a complete "wish list" summarizing all of the features that have been suggested. Ask everyone to prioritize the list. If the room explodes into a frenzied debate, add structure by having each stakeholder work independently. After everyone has ordered his or her own list, ask them to present their list to the group with the reasons for their selections. As the group moves toward consensus, priority conflicts will emerge. The debate over some features will become deadlocked, and stakeholders will ask for more information about cost. When you hear "I can't decide—it depends which one is cheaper," then it's time to add the price column to your Chinese take-out menu.
Now that you have the prioritized list and you've taken note of the deadlocked or "tied" combinations, you can bring on the implementation team. Use a flip chart or white board and create two columns, one for time and the other for money. Don't provide actual figures in terms of days or dollars, since this information could compromise your negotiations with the client. Simply assign a scale of 1 to 5, from low cost to high cost. Determine which lower-priority features may be bundled with higher-priority features—for example, "If we decide to provide online music samples, then we can also include the film clips at minimal extra cost because they both use the same streaming media server." During this discussion, be careful to recognize the intrinsic value of software that you may be repurposing, as well as the "sunk costs," R&D, and other up-front investments that were poured into your technology infra-struture. Just because you've built a highly scalable solution that only takes an hour to adapt, it does not mean that the software is only "worth" an hour of a developer's time.
As you make progress, take a moment to introduce the concept of "Phase 2." Some of the riskier features may require a proof-of-concept or prototype. Consider developing "pilots" to test the business validity of a feature. Take baby steps. Create an e-mail newsletter campaign as a one-off, and send it to a small target list of customers before investing in the million-dollar publishing interface. Build a long-term relationship with your client through a series of small successes, and avoid the disastrously expensive "white elephant" or "Maginot Line" projects that become legendary failures.
The "Surgeon" Analogy
Cost is naturally a major roadblock to getting a client to approve a set of features. The "surgeon" analogy is a technique for helping the project stakeholder understand the hidden costs of software development ("Why are you billing him so much for tasks that appear to be no big deal?"). When discussing cost tradeoffs, some project stakeholders may try to reduce the terms of the discussion into pure man-hours. They will assume that the faster an application can be built, the less expensive it should be. These clients are computing the value of your work based on man-hours alone. Remind the client that graphic design and software development are not like automobile repair, factory production, or bricklaying. A better analogy is the complicated surgical procedure. In the case of laser eye surgery, the procedure takes only a few minutes, but the doctor is being paid for years of knowledge and expertise. The cost of a medical procedure reflects the thousands of hours of training and preparation that qualify the surgeon to provide a service that is both technologically complex and customized to the patient's needs.
Furthermore, rapid deployment and decreased time-to-market provide significant competitive advantages. The scalability of your team's software is a valuable asset. Your team should be rewarded for developing its expertise and infrastructure to the point that you can produce a quality product in a short amount of time.
Playing Defense
Project managers seek to define the project and then build a protective wall around the initial set of features. Scope "creep" usually manifests as a gradual erosion of this wall. Most project stakeholders are sensible enough to quell major changes, but the cumulative effect of tiny incremental changes takes its toll. How do you prevent new requests from coming in over the wall? Formalize the process. Establish a change committee and a formalized change procedure so that you will not find yourself desperately plugging leaks as small requests pour in from all directions.
Change Orders
Use a written change request document whenever there is a change in scope or requirements. The change request form should include mention of the relative priority of the change and the importance of the change in terms of time and resources. Be consistent about requiring the use of change orders, or the client may assume that a change has no cost impact. The purpose of this protocol is to manage expectations and costs, not to discourage change or to appear inflexible in the face of a dynamic business environment.
Problems with Classic Approaches
When your project feels like it is spinning out of control from scope "creep," you may be tempted into a destructive battle with stakeholders. From your standpoint, the objective of this tug-of-war is to aggressively limit the scope of deliverables. After the scope has been "set" and the project is underway, you will be called upon to battle the client to prevent changes. "Scope management" becomes a reaction to changes initiated by the project stakeholders, who are laying siege to the integrity of the original plan. Caught in a destructive dynamic, your team will begin to feel like a defensive garrison as you fend off salvoes of change requests that threaten to erode the fixed set of features. The traditional "siege mentality" creates an adversarial climate that quickly infects the entire project team. The fallout from this power struggle between the project manager and project sponsors sets a tone of conflict that can last for the duration of the project.
In this hostile environment, traditional project managers focus on the plan, tracking inputs, deliverables, and milestones against a fixed set of requirements. Unfortunately, the attempt to specify every feature ahead of time and draft a static plan has proved to be unrealistic for Web projects. During the lifetime of your project, stakeholders will learn about the technology as well as their own business needs. The overall business climate may change if the project lasts several months. In response to this reality, innovative approaches like Rapid Application Development (RAD) and Extreme Programming (XP) have taken the spotlight. These methodologies share an "iterative approach" to scope management.
Iterative Approaches
Given the limitations of the standard model when applied to the Web, you will be called upon to find creative ways of controlling requirements throughout the lifetime of the project. The details of implementation will cause the specifications to be modified on the fly. Several new methodologies have formalized this iterative process. RAD is one of the most commonly accepted iterative approaches.
The Rapid Application Development methodology was designed to build software with speed as the most important success criterion. The RAD approach is not appropriate for every Web project. RAD is best suited for projects that have a limited, well-defined scope and a measurable outcome. RAD works best with a small, tightly knit project team and an on-site stakeholder who is empowered to make quick decisons about functionality. The ideal team size is under ten people. RAD also requires a stable technical architecture: It is not well suited for creating large, complex systems on top of a completely new or untested infrastructure.
The cornerstone of RAD is rapid prototyping, wherein developers try to create a small working product as soon as possible. The working prototype is then refined based on direct feedback from the client. Each refinement, or "iteration," is a step closer to the finished product. RAD project managers use a technique called "timeboxing," in which scope is allowed to change but the delivery date remains fixed for each iteration. The main advantages of RAD are that the client is able to see results right away and frequent scope changes are allowed. With conventional methods, there is often nothing delivered to the client until 100 percent of the process is finished and the completed software is unveiled.
Extreme programming represents one of the most notable applications of RAD techniques to the Web. This client-centric approach aims to deliver just enough software to meet the customers' needs, incorporating the immediate feedback of clients during the development of a series of rapid prototypes. In fact, there is no distinction between the "prototypes" and the finished product. XP utilizes several innovative techniques like "pair programming" to encourage teamwork, creativity, and collaboration among developers. The interview section of this chapter describes how XP works in the real world.
Extreme Programming (XP) Resources See
http://www.extremeprogramming.org/
http://groups.yahoo.com/group/extremeprogramming/links.