The business model is what defines the operating strategy for a corporation and this model needs to continually change to be successful in today's ever-changing business environment. This business model is part of the deliverable that is imperative for the success of the any product. It is a work product that cannot be omitted or developed only once without continual revisiting.

The business model is generally part of the business case which defines the customers, business relationships, revenue, expense flows, and so forth. This model should project costs and profits in the time slot of the first year (by quarters) up to five to ten years.

Executive management usually allocates the business idea and scope (also defined in the business case and the basis for the business model) to identify what they want to know and when they want to know it. It is not the responsibility of the Requirements Engineer to develop the business model, but he or she does assist by asking business strategy type questions. These questions must be asked to insure that the tolerance-related requirements are captured

The purpose of this questioning is to monitor the success of the product and the effect it has on the business. Each business community needs to know how they are contributing to the success of a product. Even large companies can sustain the growth of this business with other business units for only so long. The questions that the Requirements Engineer needs to elicit are as follows.

What is to be monitored to determine the success of the product?
This will identify what conditions are to be monitored. Make sure that information about monitoring business partner relationships is included.

What is the tolerance point?
This will identify the trigger of the condition. This information may vary by business community. For example, the sales department may have a lower tolerance point for a potential problem than executive management. This serves as a type of yellow flag to alert them to correct something before management notices the problem.

What information needs to be captured when the trigger is initiated?
This determines the action to take place. This will include actual information related to sales, cost (development of the product and running the business), analysis of customer feedback, service level agreement with business partners, and so forth.

When and how should the information be captured?
This determines that the activity may be continual with a trigger to stop capturing the information and report on it. The information to be captured may be from external sources (e.g., sales data of competitors).

Executive reporting must be part of the first iteration. We are in a fast-paced and ever-changing environment, which requires that all executives need to have information as soon as possible to react and correct a potentially negative situation as soon as possible.

The tolerance indicators are an executive-level report on (1) what has taken place, (2) a comparison of that with the business projections, and (3) an adjustment of the projections against the actuals. This can be handled as a separate project from the development of the B2C and/or B2B portion.

An anti-pattern can be created to prevent or monitor each situation that affects the business model by capturing specific tolerance parameters. Here lies the first business model anti-pattern: to capture tolerance requirements.

The Business Model Tolerance Indicators Anti-Pattern assists the Requirements Engineer in identifying all the conditional events that need to be triggered. The condition in this case is that a tolerance has been reached that indicates a need for a reaction from management. In order for management to be able to interpret the effects of reaching or exceeding tolerance, they will require information. Based upon this information, executive management will make key decisions that may affect the business model and/or affect the life of the corporation or business relationships.

The PDF Business Tolerance Anti-Pattern contains the anti-pattern language for this anti-pattern.

The objective of this anti-pattern is to spark discussion on how to monitor the success of a product. Each business community will have a monitoring need and will need to allocate the responsibility to clarify business risk and countermeasures for them. In addition, each business community will have input on what it wants to see happen. All of these actions will be dependent upon what the executive management wants to monitor. The goal is to not only illustrate the differences but also the similarities with the executive management's requirements.

Multiple tolerance indicators will be identified for each countermeasure. Each of the tolerance indicators will require different information to be captured, processed, and output in a specific format. Each tolerance indicator will probably have a value that will change as business conditions change.

As an exercise for your current project, take a look at your company's organization chart. Which departments do not have tolerance triggers? Do they need them? Would this anti-pattern have helped you with any gaps?

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