Project Management Issues

At the beginning of this iteration, the customer has requested additional features that are outside the scope of the agreed project.

7.4.1 Request for Additional Features

The customer has asked us to implement an additional feature that will enable the user to apply certain image filter operations such as edge detection and noise reduction. The requested features are quite advanced, and it will take a substantial amount of time to analyze the requirements and design and implement these features. The requirements are as follows:

• image_noise_reduction: The photo editor application shall enable users to reduce noise in an image by using a Gaussian noise reduction algorithm.
• image_edge_enhancement: It shall be possible to enhance edges in an image. A Sobel filter shall be available for the user to highlight edges (vertical and horizontal lines) within the image.

Without explaining the requested functionality in detail, it is clear that these features are additional effort that was not planned for. Therefore, in the discussion with the customer, project management provides three proposals on how to proceed with the request.

Feature Trading (Resolution Proposal 1)

The newly requested features will be provided within the released project, but certain other features will not be included. The only way to provide the new functionalities within the project timeframe is to "trade" them for features that were planned for (and that would need the same effort to implement). For example, the optimization of image-processing features or the three-dimensional text displays could be traded for the new features.

Deadline Extension (Resolution Proposal 2)

The deadline for the project is extended. The effort for the new features is estimated, and the project deadline will slip by that amount that time. By extending the deadline, we can deliver the additional features with this version of the product.

Rescheduling (Resolution Proposal 3)

Rescheduling is the preferred solution by the project team. The features will be added to the defect tracking list as wishes. The features will then be considered for a later release of the project. Adding them to the defect tracking list as a wish adds them to the project so that they will not get lost. The project team can plan for the new features in one of the next releases, combined with eventual bug fixes.

It is important to mention which proposed solution is the recommended one by the project team. Very often, the customer will choose the recommended option if good reasons are provided for it. In our case, we argue that the requested functionalities are very advanced features that will be used by only a few users. It seems reasonable to provide these advanced features in the second release of the photo editor application.

7.4.2 Resolution of the Request

The customer decided to follow our recommendation to schedule the functionality for a future release. Therefore, the two new requirement keys are added to the defect tracking Excel sheet that can be found in the doc directory of the sample solution on the accompanying CD.

The described scenario is very common. The customer tries to squeeze in more functionality without considering the impact on the project team and the schedule. Because our requirements were described in sufficient detail, the customer could not increase the scope of the project without providing new requirement keys. Therefore, it was obvious that the newly requested functionality was not in the scope of the project that was agreed upon.

Difficulties can arise if the requirements are not described in enough detail. Imagine a requirement key with this description:

image_graphics_special_effects: Some advanced image-processing functionality shall be provided by the application. The functionality provided is, for example, a rectangular frame with fading colors toward the center of the rectangle.

If the requirements key had been described in such little detail, the customer could easily have argued that the requested functionality was within the scope of that requirement key. After all, the one example given was only one exampleone of several features that should be provided.

Even though this argument sounds trivial, it has happened in more than one project we have worked on. Projects are often under tight time pressure in the planning phase, and project management is tempted to neglect planning, requirements analysis, and even design. The implementation starts as early as possible without much planning. But jumping into implementation without a planning phase makes the project basically unmanageable. If a customer can squeeze additional features into the project's scope without having to introduce new requirement keysa process often termed feature creephow can you estimate the project's effort in advance? Furthermore, how can you measure the progress of the project? How do you know which functionality to implement? How do you know what to test? How will you really know that the project is finished? I am sure we could find many more reasons that vague requirements can cause a project to fail. But the sheer unmanageability of the project is enough to show why requirements should contain enough detail to describe the functionality to be implemented.

We cannot emphasize enough that the planning phase is crucial for the project's success. If the planning of the project is cut short, then the project is most likely doomed to fail.