- Protecting the People Constraint
- Protecting the Time Constraint
- Protecting the Scope Constraint
- Protecting the Budget Constraint
- Protecting the Resource Constraints
- Local Safety
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Protecting the Scope Constraint
The functionality of the system represents another constraint. Once again, the agreed scope represents a promise. Failing to deliver the agreed functionality means a broken promise. Broken promises are bad for business.
If the scope constraint is to be protected, it must be buffered with more scope. In essence, the manager must gain agreement with the customer that some of the scope would be "nice to have" but doesn't need to make it into the currently agreed deliverable.
In other words, if the scope constraint is to be protected, then the scope of required functionality must be prioritized. The customer (or product marketing) must determine the ranked order of importance for the functionality in the scope. This could be as simple as assigning a value on a 3-point scale to each required function, for example, "must have," "preferred," and "nice to have." Functionality priority is actually a two-dimensional problem. When a customer is asked how important any given feature in the scope might be, the answer is likely to be, "It depends." What the customer means is that the importance varies according to the delivery date. This is best explained with an example.
With an investment banking application, a new feature is required to meet new government legislation. The feature must track stock trading activity of "insiders" within periods shortly before public announcement of trading results. The new law takes effect at the beginning of the fourth quarter. If the customer is asked how important the feature is, they will say it is a "must have" feature. The company stands to be heavily fined if the feature is not delivered on time. However, if the question is rephrased to ask how important the feature is for delivery by the end of the first quarter of the same year, the answer will be different. Naturally, the feature is useless at that time. Early delivery makes everyone feel comfortable about the new regulations, but it is not necessary for the business. The new feature will not be used until October 1. There is no Throughput value in early delivery.
Hence, it is important to gather the time-varied priority for each requirement in the scope. The program manager should plan to agree on a scope with the customer that includes a number of "nice to have" requirements that perhaps later become "must have." Engineering would agree to schedule these requirements in the plan, but the customer agrees to let them slip, in the event of unplanned events disrupting the schedule. This concept of prioritizing requirements is addressed in greater depth in Chapter 16, Agile Product Management.
I can hear a chorus of people shouting, "Wait! You can never get agreement on such a scope buffer." Why not? This is caused by a lack of trust. The customer will assume that buffered requirements will never be delivered. This is based on experience with poor software development organizations who never deliver what they promise and would certainly never overdeliver. Hence, the scope is nonnegotiable.
As a precursor to ever being able to buffer scope, a development organization must provide end-to-end traceability, transparency, and repeatability. It must be capable of building trust with its customers and showing that it can deliver on promises. Only when the customer learns to trust the software development organization, through an understanding gained from visibility into the software process, will the customer agree to prioritize and buffer scope.
Hence, it should be taken de facto that scope buffering is not available to the immature software production system as a protection mechanism against uncertainty. Trust must be earned through a series of deliveries that met expectations. After this, it is possible to negotiate a scope buffer.
Trust
Establishing trust is the most important goal for any development manager. Trust is the most valuable weapon in a development manager's arsenal. Trust is gained through a combination of transparency and delivering on promises. Show people how the system works, what is involved, how long it takes, and what went wrong when it does go wrong, and trust will grow. Lack of trust is usually a symptom of lack of understanding. The organization doesn't need to run like a well-oiled machine. It doesn't need to perform like an automaton in order to win trust. It is all right for things to go wrong. Customers understand human frailty. In fact, they often like it. What they want to see is honesty. They will accept problems occurring when they can see and understand the reason for them.
It is possible to build a customer relationship where buffering scope is a regular occurrence. It requires a mutual trust. Trust must be earned. Managers can earn trust by delivering on a few promises.
Hence, it may be easier initially to use buffers in time and people, to insure that the agreed scope is delivered. It may not be possible to buffer scope until a mutual trust is established. After two or three projects or product deliverables which were on time, and on budget, the customer may be willing to discuss prioritizing requirements and buffering scope.