Columns

Book Excerpt: Tips and techniques for managing scope creep

• August 1, 2004

This article is excerpted from Chapter 13 of “Complex IT Project Management: 16 Steps to Success” by Peter Schulte, ISBN 0-8493-1932-3. This chapter is printed with permission from the author and Auerbach Publications

It usually begins innocently enough. You barrelled into discussions with beneficiaries. You gave them a reasonably in-depth look at your project by taking them through the “features, functions, benefits” spiel; highlighting key dates; and soliciting their support. Perhaps at that time, or soon thereafter, you are approached by an emissary who expresses concerns about the project. This conversation is neither rancorous or difficult, but some issues are elevated to you, most likely in the “heads up” format. As a consequence, you agree to a series of meetings with beneficiaries and appropriate members of your team. Your expectation is that your team will provide clarification that will reassure beneficiaries that everything has been well thought out. By way of response, the beneficiaries ratchet it up a bit, making you aware of certain technology or date-driven facts that give you pause to wonder what else might have been missed. Before you know it, these discussions have turned into joint planning sessions. Polite inquiries from beneficiaries have now turned into demands, or at least discussions of new requirements for your project.

That, of course, should immediately set off bells in your head warning you that the project has been infected by the scope creep virus. Chances are, however, that you remain on cruise control, doing what project managers do best, which is to arrange and referee meetings with the right people at the table. Discussions become very complicated and the pressure starts to mount. Soon you find yourself back-peddling, and explaining why the project was not planning on doing so and so by such and such a date. Again, this is another warning sign of scope creep, but like most project managers, myself included, your focus remains on relationship building, and looking for real risk that requires this level of detail and concern.

There are a few warning signs you should definitely keep in mind, however, to become aware that scope creep is lurking at your door. Here are my favorites:

• Schedule changes. If you find yourself going back to the project calendar, and trying to squeeze start and end dates, or move milestones around by more than a week, you are flirting with scope creep.
   
• Design changes. After meetings with beneficiaries, your engineers start talking to you about additional hardware or software tools. When you ask why these items were not on their original wish list, they tell you about customer or beneficiary-driven requirements that surprise you. This is definite evidence of scope creep. 
  
• Staffing changes. In a like manner, if team leads come to you requesting additional consulting or vendor dollars to beef up the programming, networking, or support teams, this could be shoddy planning, or their knee-jerk reaction to scope creep.

Reacting to scope creep
Whether you use these tips from the experienced, or Tarot cards, once scope creep is detected, you must react quickly. Those planning sessions that emerge from an initial beneficiary objection are like planning your own execution. The further you get into those discussions, the harder it is to extricate yourself from them without incurring beneficiary wrath. The psychology of scope creep is pretty interesting. Once you cross the line of information exchange between the project office and beneficiaries, to discussions regarding how to change the project to mitigate their risk, beneficiaries generally infer from this your acquiescence to accept their problems as yours to fix. It is admittedly hard to say no, but you must do something once you recognize you are getting stampeded into changing your plans significantly to suit your beneficiaries. What to do?

These discussions should be carefully documented. As a salesperson, I was taught, from the moment an objection is raised, to echo it back to the beneficiary in my own words, and haggle if necessary over the words until both sides are comfortable that the issue has been properly articulated. In the project context, you would likely engage operations or technologists on both teams to further explore the issue, possibly even to the degree of crafting a solution.

During this process you must make it clear that these conversations are provisional. You must specifically state your concern that while their risk is genuine, or these new requirements make sense in a general way, you are pretty sure that the project is neither tasked nor funded to address them. Do not create the impression that this process is bogus, but disavow the alternate perception that executing the emerging plan is a no-brainer and that you are empowered to address their requests in a manner that will please them.

You are not the scope police. You are the project manager. The issue driving potential scope creep should be thoroughly documented, with potential solutions written up as well. Make your beneficiary contact aware that you will present the findings to your management, and encourage your counterparts to do so as well. Let management fight it out once the issue is properly framed. Try to sublimate your own feelings when you send the package up your management chain. If you are asked your opinion, render it, but do not get emotionally invested in it, because it may come back to you as a new requirement. In other words, scope creep may be allowed, as it generally will be if the beneficiary has any political skill or organizational clout, and the issue is genuine enough. If this happens, you do not want to be on the record as fighting it. If you lose, your credibility and perceived level of power is publicly diminished.

Should this scope creep be blessed, be sure and put together the right plan. It should include a new schedule and design, as well as requisitions for additional funding and resources as appropriate. Just because the seniors approved this project change does not guarantee that you automatically get the relief you need to add this new set of requirements to your already full plate. It is up to you to make sure that happens. Figure 1 summarizes the right steps to take, and how to take them, when the diagnosis is “lurking scope creep.”

Scope creep poses two challenges to you and your team. 

• You face a funding challenge if you believe adding requirements, or making existing ones more complex, adds to your cost. 
  
• You face management and resource challenges if modified scope raises concerns about your team’s ability to absorb these new or more complex requirements and to deliver them with the skill, headcount, and timeframes at hand.

If either condition is true, it is time for you to ask management to consider whether the company should step up to the plate and fund the additional expenditures for hardware, software, consultants, or overtime. That is not your call, so rather than wasting time and creating enmity by serving as scope police, let the seniors duke it out. They should resolve these discrepancies, with your advice and consent, of course.

To read more information on Complex IT Project Management: 16 Steps to Success,  please visit the Auerbach Publications/CRC Press Web site at http://www.crcpress.com. About the Author: Peter Schulte is a program manager accomplished in the life-cycle implementation of multimillion dollar projects in network infrastructure and security, as well as Web and e-business apps. He can be reached through Auerbach Publications at (917) 351-7149.