Managing the Creeps

While some of your team members may occasionally seem like creeps to you, that is not creep management I am talking about. Creeps here refer to minute changes in the project due to the obscure, and for awhile unnoticeable, actions of team members. Many of these go undetected until their cumulative effect creates a problem that raises its ugly head. You need to be aware of four types of creeps so you can take the appropriate management action. They are described in the sections that follow.

Scope Creep

Scope creep is the term that has come to mean any change in the project that was not in the original plan. Change is constant. To expect otherwise is simply unrealistic. Changes occur for several reasons that have nothing to do with the ability or foresight of the client, the project manager, or a project team member. Market conditions are dynamic. The competition can introduce or announce an upcoming new version of its product. Your management might decide that getting the product to market before the competition is necessary. Scope creep isn't necessarily anyone's fault. It is just a reality that has to be dealt with. It doesn't matter how good and thorough a job you and the client did in planning the project, scope creep is still going to happen. Deal with it!

Your job as project manager is to figure out how these changes can be accommodated — tough job, but somebody has to do it. Regardless of how the scope creep occurs, it is your job as project manager to figure out how, or even if, you can accommodate the impact.

Hope Creep

Hope creep happens when a project team member falls behind schedule but reports that he or she is on schedule, hoping to get back on schedule by the next report date. Hope creep is a real problem for the project manager. There will be several activity managers within your project team who manage a hunk of work. They do not want to give you bad news, so they are prone to tell you that their work is proceeding according to schedule when, in fact, it is not. It is their hope that they will catch up by the next report period, so they mislead you into thinking that they are on schedule. The activity managers hope that they will catch up by completing some work ahead of schedule to make up for the slippage. The project manager must be able to verify the accuracy of the status reports received from the team members. This does not mean that the project manager has to check into the details of every status report. Random checks can be used effectively.

Effort Creep

Effort creep is the result of the team member working but not making progress proportionate to the work expended. Every one of us has worked on a project that always seems to be 95-percent complete no matter how much effort is expended to complete it. Each week the status report records progress, but the amount of work remaining doesn't seem to decrease proportionately. Other than random checks, the only effective thing that the project manager can do is to increase the frequency of status reporting by those team members who seem to suffer from effort creep.

Feature Creep

Closely related to scope creep is feature creep. Feature creep results when team members arbitrarily add features and functions to the deliverable that they think the client would want to have. The problem is that the client didn't specify the feature, probably for good reason. If the team member has strong feelings about the need for this new feature, formal change management procedures can be employed.

Here's an example of how feature creep can occur. The programmer is busy coding a particular module in the system. He or she gets an idea that the client might appreciate having another option included. The systems requirements document does not mention this option. It seems so trivial that the programmer decides to include it rather than go through the lengthy change process. If this feature is not documented, it will go unnoticed until it's too late, and trouble will result. (Trust me, I have seen it happen on several occasions.)

Here's another example, which I personally experienced. This time it was induced by the client, and I was the project manager. The project involved the collection, storage, editing, retrieval, and reporting of an extensive database of teacher education data. The client called ahead and told me that she had just come up with a major design breakthrough with the raw input data and wanted to come over and show me. A few minutes later, she arrived at my office door. She proceeded to go through a lengthy demonstration of the color coding scheme she developed and used for the most recent data set. She was so proud of what she had done and it really was a stroke of genius, but not for me, because I had to read and interpret the data sheets. It broke my heart to have to tell her that I was profoundly color blind and couldn't read her data sheets.

Even when adding a feature or function seems rather insignificant, you need to look at the possible consequences. First of all, if the feature is not in the system requirements document, it is also not in the acceptance test procedure, the systems documentation, the user documentation, and the user training program. What will happen if something goes wrong with the new option? How will another programmer know what to do? What will happen when the user discovers the option and asks for some modification of it? You can see the consequences of such an innocent attempt to please. The message here is that a formal change request must be filed, and if it is approved, the project plan and all related activities will be appropriately modified.