Why Do We Need Better Requirements?
The following article is a frank, open and surprising discourse on why we need better requirements.
According to Standish or Gartner reports and other case studies, nearly “two-thirds of all IT projects fail” because of poor requirements and other causes.
Why Do Projects Fail?
Consider that a project fails when it overruns the budgeted allocation of resources, time or money or fails to deliver the intended business requirements or value.
Some teams are so deep into this, that throwing more money, people or extending the shipping date is their default solution to scope creep, budget overruns or project failure!
But project failure doesn’t have to become the norm for you.
With this in mind, the following post on “Why We Need Better Requirements” is designed to help business analysts, project managers, web managers or technical leads make a case for preventing project failure by gathering better business requirements.
The True Cost of Fixing Bad Mistakes
Gathering better requirements helps avoid fixing issues further down in the project when mistakes are guaranteed to be more expensive.
Consider a product feature that is not developed to the customer’s specifications because of incomplete requirements documentation.
The incomplete requirement is left to an open or wide interpretation from each member of the development team.
Depending on when the improperly coded requirements are discovered; (development, software testing or production), the cost of fixing these defects is guaranteed to be much higher than the cost of gathering, validating or documenting the complete or correct requirements at the project’s inception!
The Opportunity Cost of Missing Requirements
Discovering requirements late results in delays to the project or in shipping products that don’t meet or fall below the customer’s expectations!
This results in missed market opportunities, unhappy customers or an improper allocation of resources, time or money.
Why because, it costs more money to retool your product at later stages of the product development cycle than at inception.
And regardless of what you do, you will be late to market or reduce your customers positive experiences of your product.
The Cost of Working Incorrect Requirements
Perhaps, you’ve worked on a project where requirements are dispensed as favors because the Requirements Analyst lacks the authority or training to validate requirements properly.
This is the practice where requirements are imposed on the project team without meeting the business case or scope.
The cost of such a practice is that the project resources (people, money, time, infrastructure) are high-jacked to satisfy a few egos to the detriment of the organization’s strategic objectives, goals, missions or success!
Making The Case For Good Business Requirements
Note that when it comes to executing projects successfully you will always have the constraints of time, money or resources (people).
And regardless of who you work for, your project cannot be handled as if your organization has an infinite supply of these inputs.
So gathering incorrect, poor or wrong requirements will result in the improper allocation of resources and at the same time increase the risk of project failure.
Armed with this, don’t be a doormat, make a proper case to your management, stakeholders or project advisory team on the need or strategic importance of gathering better business requirements.
Action Plan: How To Gather Better Requirements
I’ve shown you why gathering better requirements matters and explained how you can make a case for sound requirement management practices at your organization.
Here is how you can help your organization adopt a better requirements management practice.
Empower your Requirements Analyst
Hire a capable requirements analyst for your project and then empower the resource to do their job.
Adding a Requirements or Business Analyst to your team without empowering the resource is a practice in self-deception at best.
So don’t start down that part, if your organization is not ready to rally behind their Requirements Lead.
Lead, Follow or Get Out of the Way!
Your Requirements or Business Analyst is there to help your project or organization succeed, so don’t make that resource into the enemy!
Educate your stakeholders, management team or customers on the benefits of following a sound, documented requirements management plan.
Find a champion who can lead that effort … then follow your chosen leader or get out of the way!
The Requirements analyst’s job is not to dispense requirements as favors but to be a custodian of the organization or customer’s strategic vision, aspirations or expectations.
By understanding, communicating, leading or championing better requirements practices, you reduce the risk of project failure and help your organization achieve a better Return On Investment (ROI).
- Getting Things Done: The Art Of Time Management
- Former Microsoft Product and Program Manager Looking for Volunteer Testers
- How To Lead or Manage Software Development Projects
- How To Become A Project Manager: Work On A Project!
- How To Get Into IT Management?
- Writing Better Requirements: Why Projects Fail
- Is your Project Sponsor a Servant Leader?