Squelching Project Creeps

by Verlane Edwards

 

 

 

 

We've all been there. The Project that never seems to end and then (finally!) ends badly. Unfortunately, the all-important post-project analysis is a step that's often left off the "to do" list, so how can you head off another project disappointment? Let's face it. Project plans are theory, so they can be picture perfect; project planning, however, is practice, and practice must take into account the inevitable changes that will occur throughout a project.  
"Plans are worthless;
planning is invaluable."
— Dwight Eisenhower

As a technical communicator, you can contribute greatly to dealing effectively with those inevitable changes that threaten the ability to deliver a product on time and within budget—in other words, according to the project plan. But you can't do it alone, so before you begin, or even if you're in the middle of a project, round up the team and discuss a key culprit that can sabotage even the best project plan: scope creep. Scope creep comes in several guises. At a minimum, plan to squelch these three creeps: Santa Creep, Perky Creep, and, most dangerous of all, Blue Sky Creep.

Santa Creep

Santa Creep is an intriguing phenomenon that is found particularly in systems development projects. Programmer analysts, generally creative and sometimes generous souls that they are, are the initiators. The customer didn't ask for it, but Annie Analyst decides she can easily add this little something extra, a feature that puts some sizzle in the soup, and she figures the customer will likely appreciate having another option included "gratis." Problem is, that innocent little "gift" can be costly to the project's success.

Possible ripple effects: It's not in the system requirements documents, and it hasn't gone through a change process review. So it's not in the testing procedures, the systems documentation, the user documentation, or the training materials for programmers or end users. That carefully balanced project triangle is about to turn into a polygram. And what will happen when the users discover it and ask for changes to this feature nobody else has even anticipated? Ho, Ho, Ho, indeed.  

Squelch Tactics: Reviewers and authors are the co-dependent elves in the Santa Creep scenario. During usability testing or quality assurance or even a quick look-see review of a developing system, subject matter experts often request added functionality or multiple style changes, unaware of the effort involved or the myriad dependencies inherent in any project involving more than two people. Too often documentation authors and systems developers comply with request after request, taking time from tasks that are defined in the project plans, and thinking it's so trivial it doesn't need to go through the change process. Think again. Make sure you have a communication plan in place for your project, and then use it. Share widespread communication of all requested changes among all shareholders, so everyone has a chance to think about the impact even seemingly minor changes can have.

Perky Creep

Pete and Pollyanna Positive are good people to have around, right? Nobody wants to work with a "nattering nabob of negativity." So when you ask Pete if he will get his material to you on time, he gives you a great big smile, a "can do" nod, and a firm affirmative. Problem is, he's just hoping he will get it to you on time. If you're the Project Manager, shame on you if you don't check the accuracy of all those weekly status reports. If you're the worker bee, shame on you for denying reality until it stings the entire team! (If you don't keep status reports, do not pass go; it's time to start this ill-defined project over again.)

Squelch Tactics: Perky Creep initiators are not inherently evil; they just need to squelch the inner voices whispering through the optimism haze, "you will catch up; you will catch up." Right. Slippage tends to grow exponentially, despite our best intentions. How long does it take you to write a comprehensive paragraph on a given subject? Create a Help topic? A graphic with call outs? Do you poorly estimate the rate of effort to output in project after project? Rectify that. There are all kinds of tools and tips for estimating time. Learn at least two of them.

And if every week's status report records progress but the amount remaining doesn't seem to decrease proportionately, stand up and wave a big red flag high and wide (metaphorically speaking, of course).

Blue Sky Creep

After the project has been defined, the graffiti from the kick-off party has been swept away, and everyone on the team is heads down diggin' in and doin' it, the Big Daddy (or Mommy) Scope Creep initiators move in. Management or marketing or some sales whiz kid promises the customer a pie-in-the-sky functionality (or two or three), seemingly with nary a thought to the effort involved.

Are they insane? Well, that's a possibility beyond the scope of this article. More than likely, however, they're riding the coat tails of some misguided "give the customer what they want" mind set. Everybody wants to please the customer. But for those who are actually creating the product, it's downright painful to try to deliver on someone else's ill-informed promises. And, of course, being the bearer of bad tidings if the promise cannot be kept does not a career make.

Squelch tactics:

1. Begin by listening carefully to the excited pronouncement of this great "addition" to the project (probably passed on to you by devoted underlings glowing in the excitement of the new promise).  
2. Smile and agree that the suggestion is a wonderful one. (If it is, this is easier than if it is in actuality ridiculous.)  
3. Calmly but firmly remind the bearer of these glad tidings that this is out of the scope of the project, and you will need time to assess the impact on the Project Plan. Tell them when you will get back to them.  
4. Then do it. Quickly. How bad is it? Will this change destroy the project plan? Involve so many hours morale will suffer, people will quit, and/or you will risk divorce or unacceptable mental health care expenses? Or does the project risk versus the business value call for a "go for the gold" response?  
5. Reply promptly and positively. How can you be positive if you think the request is unreasonable? Communicate to all involved that you can certainly incorporate this change in scope. Then concisely and comprehensively explain the impact on time, or cost, or resources (tools and people) that define the scope and quality of the project.  
6. As long as management is willing to accept the inevitable changes to those three factors that make up the project, you can redefine the project triangle, and move forward. Let the powers-that-be make that call after you've provided them with the information they need to exercise good judgment in evaluating the business value of that Blue Sky promise.

 

Immunization Against the Scope Creeps

Thousands of books have been written on project management. Read at least three of them; and attend at least one workshop (hands-on, not a talking-head seminar). Methodologies may sound different, terminology no doubt will vary, but on close examination, you will see that the underlying principles are pretty consistent. Learn them. All of them. For now, though, you can start with these core safeguards:

  1. Define everything you know about the project up front before a line of code is written, before a Help window is designed, before documents are drafted, or memos are circulated. Gather all the stakeholders together, and plan this puppy out. You can't possibly protect against scope creep if you don't know what your scope actually is. And keep going back to this document, so you don't lose sight of its original goals. That doesn't mean it won't change, only that everyone involved is starting with the same vision in mind, and everyone gets informed when the vision takes a turn.

  2. And that means don't forget to put a formal communications plan in place. Keep management, sales, marketing, training—everyone who is in any way impacted by this project in the communication loop. And solicit formal management sign off on the initial project definition and any major changes throughout the life of the project.

  3. Use the plan to monitor the project status. You're not done when you create a project plan. It's a living document. Keep reading it, revising it, communicating status based on it, breathing on it.

  4. In addition to pre-planning, establish an environment of trust and honesty. If your corporate culture is to "be positive" even in the face of overwhelming "Danger, Will Rogers" arm flapping, you're setting up your team for failure. Creativity and open communication can only flourish in a punishment-free environment. Make it easy for Pete and Polly Positive to tell you that they're worried they can't get their assigned tasks done on time.

  5. Leadership is about people; management is about things. There are usually plenty of good managers and seldom enough leaders. Be a leader.

Verlane Edwards, a writer at GuideOne Insurance, is our Perspectives! managing editor and is constantly stalking creeps.