NL  |  FR  |  ES  |  PT  |  IT  |  DE  |  DK  |  NO  |  SE  |  FI  |  GR  |  JP  |  CN  |  KR  |  RU  |  AE

learn more...

Implementing CRM Systems

Buying CRM Systems

Selecting Consultative Choices

Making the Conversions

Competing against a Customers Competition

The Consultative Selling Process

Selling Return on Investment

Norming the Value of your Sales

Empowering Box Two with Added Value

Templating Proposable Leads

Zeroing in on Consultative Targets

Social Marketing and Online Gaming: Colossal Market Growth

Positioning Profit Improvement

Bringing Customers Closer to Your Norms

Allying Box Two

  Report this article

Controlling the requirements may be the most important aspect of achieving success on a project and ensuring the full usability of the developed system. Control does not mean that there are never any changes to the original baselined requirements. It does mean that all of the stakeholders in the project are informed of and involved in a requirements control process that eliminates the single greatest threat to any system development project — requirements creeping. Requirements creeping can and probably should be viewed as a villainous saboteur who, like a chameleon, takes on many different colors. This villain strikes out with only one purpose: get someone, anyone on the project, to make a change in the baselined requirements without assessing the impact and logical disposition of the change and informing all parties of the need for the change. To eliminate requirements creeping:

- Make certain that there are baseline requirements.

- Have a change control method in place for handling any type of modification to baselined requirements.

- Make certain that all people involved in the project, both on the publishing side and on the development side, understand the process and methods used to baseline requirements and to affect change to the baselined requirements. The requirements list baseline is established following the customer review meeting and should be given a unique identifier at that time. It must be distributed to all participants as the only requirements list to be used as design work commences. The identifier should have provisions for indicating the version or edition or release. If an approved change is made to the requirements list, the identifier must be updated and the revised requirements list distributed to all participants.

Controlling the Change of Requirements

For example, say that as the design of the Graphical User Interface (GUI) gets underway, the designer realizes that there is no requirement for the GUI to provide transportation to the query subsystem, a function the designer thinks will be essential to the user. Using the requirements control process, the designer does not add the function (which would creep the requirements). Instead, the designer prepares an incident/problem report that notes the fact that there is not a requirement for the GUI to query transportation and notifies the keeper of the requirements list, who may be the quality assurance manager, the engineering manager, the project manager, or someone in configuration management. The information provided by the designer is assessed for project impact and disposed of in one of the following ways:

1. The change is approved as a necessary component of the current system development effort. In this case, the schedule and budget will be assessed for impact. If the schedule must be maintained, a management decision will need to be made regarding adding a resource to do the programming, increasing hours for one or more existing programmers, or contracting out that piece of work. If the budget is already at bare bones and the schedule must be met, then the increased hours most likely will be included in the nonpaid exempt employee overtime category, but management must realize that they are increasing the pro ject risk.

2. The change is approved as a modification to the current system to be implemented in the first software release subsequent to the initial delivery of the system. A work-around may or may not need to be developed for the initial implementation. The point is to make sure that there is agreement with the customer as to who is going to develop the work-around should it be needed. The other critical point to be made here is that the change control records and the process for using them must be implemented so that items such as this do not fall through the cracks as development for the next release gets underway.

3. The change is approved as a potential future enhancement to the current system without a specific schedule for implementation. Similar to the change approved as a modification, the change control records must be precise to ensure that the decision specific to this change is not lost. Because this change will not become part of the next release, it will go back to wish list status and be carried through the entire requirements process. The reason for this is to make certain that the development of this enhancement is scheduled for work and delivery within the context of all other existing work.

4. The change is rejected. This closes out the incident report. No work is scheduled now or for the future. There may be many reasons for this type of a response. Whatever the reason, the rejection action and the reason for rejection should be recorded within the change control process. A record of all closed changes is maintained to ensure accurate project history and to provide the rationale on why the change was rejected.

Whenever any software is released to the customer, the release should follow a defined release management process that includes the specific identification of all of the components that are included in the software release as well as the components that are assumed to be present (i.e., system software). This identification also should include the specific incident/problem reports that were corrected by the release and any work-arounds that were developed for the known problems that exist in the software.