Studies and experience show that higher quality and better value solutions are achieved by projects that attain a thorough and unambiguous understanding of business and user requirements. Teams may choose to express these requirements in different ways and may follow different approaches—whether waterfall or agile—but requirements analysis is a key underlying discipline.
Yet some high profile projects still appear to ignore requirements engineering and the wider practice of business analysis. Take the revelations in Arstechnica, which refers to a case study in West Virginia.
The article cites:
…an absolutely scathing report […] by the state's legislative auditor [where] West Virginia officials are accused of overspending at least $5 million of federal money.
The cause of the controversy was the purchase of routers for use in public buildings. On the face of it, the article suggests that extremely powerful routers were bought for extremely small applications—leading to a $20,000 router being deployed in a one-room library. Reports suggest that a one-size-fits-all approach was taken, with little insight into what was actually needed.
The legislative auditor's report states:
…the cost of maintaining the Cisco 3945 routers after the extended maintenance expires may exceed the cost of simply buying new appropriately sized routers.
This is bound to leave an extremely sour taste in the mouths of the taxpayers who ultimately paid for this initiative.
This example serves as a poignant reminder of why requirements engineering and the wider discipline of business analysis are necessary. Examples of projects that have failed—either through non-delivery or by delivery of inappropriate or expensive solutions—are widespread.
How can we encourage our stakeholders to focus on doing the right thing and ensuring delivery of value, rather than pursuing the first or fastest thing? The precise actions we can take will vary depending on the circumstances.
First, it’s vital to understand the business objectives of the project by carrying out sound pre-project problem analysis—or what BABOK would term enterprise analysis. Even if we start work on a project that is mid-flow, we need to ensure there’s a solid foundation on which to build.
It’s clearly important to have a representative and unambiguous set of requirements whatever the likely solution. If a solution is being procured externally, a robust request for proposal process will help the project team to objectively evaluate varying vendors.
Business analysts often have a unique perspective on a project. They might see risks and assumptions that other team members miss. Business analysts have an obligation to proactively challenge what is wrong, to call out the elephant in the room, to push the boundaries, and to do what they can to prevent unfeasible and unnecessary projects from progressing. It’s worth having those difficult conversations to potentially save the project!
What do you think?
