The success of building any product requires that many different individuals supply many different types of requirements to the Program Manager. The individuals providing these requirements can be from within a single business community or they can be from different business communities - both inside and outside of your organization. These business communities include both Information Technologists as well as different business areas. Where they are is not as important as the fact that they are involved in the requirement effort. If even one business community is missing, the resulting gap in knowledge can potentially destroy any chance of succeeding with the product.

Here are two examples of what can happen when there is a Gap in Participation.

1. We've seen this occur in several projects. Late in the process an additional group was brought into the development of a new initiative. The group that was brought in late had to "catch-up." This caused a delay of the product rollout, which resulted in reduced market share and revenue. The ripple affect was that this new group then had to stop all other projects (also causing them to be delayed) in order to catch-up with their involvement in this new initiative.


2. This next example occurred in a project that was very far along, almost near completion. Very late in the project, legal was finally called in. It was found that "assumptions" made for the project were actually illegal and the project had to be stopped.

The Requirements Engineering tip, Gathering Requirements for the Network Planning Group, discusses information relevant to a Gap In Participation Requirement Anti-Pattern. A similar pattern dedicated to network engineers is discussed in this PDF and is covered in greater detail in the book A Requirements Pattern: Succeeding in the Internet Economy (AWL, 11/01).

In other Requirement Engineering tips, we'll discuss the use of organization charts to identify internal communities and business model tolerance indicators to identify external communities. Both are a means to ensure that you have interviewed everyone who needs to be part of the program. Each of these communities will have requirements that may impact the software product or need to produce other deliverables that are key to the success of the program and product (e.g. advertising plans, legal partnership contracts). Identifying all internal and external communities will ensure that you have captured a complete requirements set. These are also covered in the Requirements Pattern book mentioned above.

As an exercise for your current project, take a look at the different communities in the Requirements Set Framework™. Take a look at past projects as well. Select a community that you have found to be the most difficult to include in the requirements effort. Think about what type of Anti-Pattern could be developed that would assist in identifying requirements for that area.

If you have difficulty trying to define an Anti-Pattern for your project, please feel free to contact SBDi. We can give you ideas of common requirement-related mishaps, which can be avoided with properly developed and implemented anti-patterns. Or if you have an interesting scenario, SBDi may choose your project as an example and develop the anti-pattern in a future tip.

SBDi is available to work with your organization on Requirement related or Project/Program Management Anti-Patterns.

Our services include:

• Education of the management and development team on the value of the development, implementation and use of anti-patterns.
• Teaching how to identify, develop, validate, and implement anti-patterns.
• Developing project specific anti-patterns.
• Developing a divisional or corporate process for the development and implementation of anti-patterns.
• Review of existing anti-patterns for quality.

Pat Ferdinandi