Some of the worst practices in the project delivery industry are perpetuated by scary assertions and beliefs.
The vendors question, "Can we deliver?"
For example, software vendors are often petrified of organizations doing their own business requirements as, they believe, this will identify needs that their software cannot meet. As a result, software vendors are not great fans of you doing your business requirements (they’d rather you take their software ‘vanilla’ *).
This fear was valid in the 1980s when software was very fixed in what it could and could not do. Nowadays, however, software is designed to be configured to meet a wide range of business requirements.
In practice, we have found, most business requirements definitions only identify around six or so “needs” that any appropriate software does not readily meet. Most other requirements are found to be matched by the software, done better by the software or not so well by the software (but the difference is not significant).
Where you have the six or so major mismatches, if the business requirements have been done correctly, the business will have a very clear idea as to the business value of each of these mismatches. It can then assess the net value of customizing the software to meet these requirements. This customize or forego the requirement decision then becomes an informed, value-based business decision. (If the number of mismatches is more than, say, ten, then you may have the wrong software!)
The Business's Question, "Do we have time?"
Internally, however, there is another school of thought that says, “Doing business requirements thoroughly takes up to 12 months”. Now that is a scary thought!
However, it is also a nonsense. In fact, if you do take 12 months to do your requirements they will be a disaster because, by the time you get to month 12 you’ll have forgotten most of what you discovered in months 1 to 9 anyway.
This “12-month” requirements argument is used to justify not doing the business requirements thoroughly (if at all). A whole industry has grown up around the idea of generating requirements “fast”.
The results include
- interactive, iterative, agile requirements — we’ll talk to you, we’ll design something and you can tell us what you don’t like and then we’ll improve it, and …
- instant requirements — we’ll hold a workshop, debate what you need and then deliver that
- default requirements — we’ll show you what the software does and you can justify any changes that need to be made, otherwise what you see is what you'll get.
All of these approaches have one thing in common — an inability to get to the real business requirements.
Everything you do today has to be either eliminated or accommodated in the future solution. Everything.
When you take people through a process to identify what really happens now and to identify the strategic intent of each process, you can define exactly how you want to do business, compete and make money in the future — your real business requirements.
And this identification of your real business requirements can be done across a whole company in less than 100 days. It defines your current state (your starting point for change), your future state (your target business outcomes and benefits), your process and information flows and what has to change to get you there from here (your high level project delivery plan).
To not start with this level of comprehensive business requirements is the really scary approach.
You can both radically simplify and define your business requirements in detail using the TOP Business Simplification program. Explore more.
