As a matter of fact they did have requirements; they were just incomplete and misunderstood. From this angle it is hard to tell, but inside the bank, the ATM is at floor level and fulfilled all of the requirements regarding ease of removing deposits, stocking cash, maintenance and repair. So what happened? Bad business requirements.
IEEE did a study a few years back estimating that of the annual $1 Trillion (that’s with a T) spent on IT projects, 15% of them would be abandoned. ‘Poorly defined requirements’ was a top reason why they would fail.
So, how do you make sure you not in the 15%?
1. Understand the difference between business and system requirements
One of the more common mistakes is in not understanding the difference between business requirements and system requirements.
Business requirements are the strategy, the ‘what.’ Written in business language they describe the business need and what value the new application must deliver to be successful. System requirements are the tactics, the ‘how.’ System requirements describe how the application will satisfy the business requirements.
2. Talk to enough stakeholders
Sure Sally is a go-to person, the SME (Subject Matter Expert), but she’s only one person. It is critical to talk to as many people from the business side as you can in the time allowed. The more diverse your audience, the more perspectives you get and the more inclusive your business requirements will be.
Be sure to also get the right cross-section of stakeholders. Look to get coverage across different roles, locations and levels of management. Make sure you have a complete picture of what the application should do.
3. Be aware of assumptions
Know that human beings think and speak in models when describing a process and inherent in those models are assumptions.
One of my favorite exercises to illustrate this point is to have a group write down the instructions for making a PB&J. Inevitably, they forget important steps like taking the bread out of the bag or opening the jars.
When you talk to the stakeholders and users they are also talking in models and leaving important steps out of the process. It is important to dig in and ask questions. Don’t be afraid to play a little ‘Columbo’ (ask your parents) to get the stakeholder to provide more details.
4) Talk to the users
The Standish Group estimates that up to 45% of system functionality developed is never used. It is important to understand how the end user is most willing or most likely to use the application.
Talking to your users will give you insight into how the new application will need to work in order to fit seamlessly into the user’s workflow and the language they use. Even simple differences in semantics can result in huge project shortfalls.
Business requirements are crucial for project success. Follow these four principles and you’ll be fine.