Requirements: better off being generally right than precisely wrong

I’m used to getting a reaction from people when I outline the Alignment Trap, and my article in the Agile Journal - and the subsequent report on InfoQ - certainly stirred up some reaction.

Immo Huneke mailed to point out that the Sloan piece doesn’t discuss how you measure alignment. I’m not sure how I would go about measuring alignment myself, after all what is alignment? Can it be measured objectively?

There is a point here, and I myself am a guilty of making a jump from alignment to requirements. I’ve also used the phrases “doing the right thing” and “doing things right” quite loosely.

The other point which we could argue about is “IT”. The Sloan piece talks about IT. There is no information on whether this relates to hardware, software, IT support or software development.

Despite these caveats I think the central message still holds: getting effective is more beneficial than getting.

Still, I want to make it clear I think knowing what you are doing is essential. And in the long term requirements aligned to the business are very important - see the blog entry that comes after this one.

Its all a question of context.

If you want to fix a broken IT organization I claim, and I believe the Alignment Trap supports this claim, it is best to start by making the organization effective then determining what needs doing.

This context implies that there is an organization, and it is doing “stuff”. It knows some of what needs doing. You might be able to remove some “stuff” (or add more) but basically it is not short of work to do.

I believe that in this situation discussions over what to do (alignment, requirements) are not effective because the history of failed deliveries means there is no trust and it means the business side tries to game the system by asking for more than they need because they believe It will always under deliver.

This context also implies that the IT group is, in general, supporting the business. If your company sells Payroll software and your developers are currently writing a competitor to Grand Theft Auto then I think you would be right in question requirements on day one. But in general, if you sell Payroll software it is likely that your development group are working on Payroll software.

In other words: you are better off being generally right than precisely wrong.

Before you can tackle the requirements problem (and alignment) you need to build a delivery machine that can tackle it.

The Machine that Changed the World contains an example I think illustrates the point here.

Producing the body of a car requires a “stamp” to shape the metal for the car body. These stamps are large and take many months to create. In the 1980’s at General Motors a new car would be designed and when the design was finished work on a “stamp” would start. This created a delay of a year or more in producing the new car.

At Toyota the general size parameters of a new car would be agreed early on in the process. The stamp team would start work on the new stamp before the design was finished. Only as the design neared completion would the stamp team complete the stamp. As a result Toyota did not have the same delay.

The Toyota guys started off being generally right and narrowed in on the exact dimensions over time. At GM the desire to be always right held work back.