Software Requirements: Are The Business People With You?
The Role of the Business in Driving Software Requirements Definition
Many of us believe that the single hardest part of building a software system is deciding precisely what the business needs. No other part of a project has as much impact on the final outcome as requirements definition. Yet, the requirements process often ends up as the area most lacking in best practices.
I recently participated in a survey of IT executives at a Chicago trade conference. Some of the results of the survey were what I expected and some were surprising. But either way, the results are very relevant for teams looking for perspective on their own development practices. This week, I’ll report some of the basic findings of the survey.
Most of the executives in the survey recognized the importance of accurate requirements and admitted to routinely struggling in two areas: Connecting with the business and managing requirements throughout the development cycle.
Key Survey Findings
- 94% of respondents acknowledged that the quality of requirements is a leading factor in the success of their software projects.
- Over 70% acknowledged that there is room for improvement in their requirements practices.
- 75% agreed that better articulation of business and IT roles/responsibilities in requirements gathering would go a long way toward improving project outcomes.
- While most admitted that the business has at least some input with requirements definition, requirements are often unclear.
- Over 80% of respondents indicated that they do not learn about missed requirements until too late in the project development cycle.
- Only about half of the respondents felt that business and IT teams have a consistent view on project status.
- Over one third of respondents stated that progress is not consistently tracked in business milestones, resulting in rework and missed deadlines.
It’s Unanimous: Business Involvement Has a Big lmpact
It is not uncommon for business stakeholders to “throw their requirements over the fence” and expect to come back later to a successful working system. In practice, however, this approach leads to rework, project delays, cost overruns, and other disappointments.
Although the degree of business involvement varied within the survey, respondents overwhelming agreed that when the business is directly held accountable for clearly defining their needs, project outcomes improve. Respondents also mentioned the need for better articulation of business and IT roles and responsibilities in the requirements process.
Business Milestones: Now You See them. Now You Don’t.
Another big area of concern for survey respondents was managing requirements throughout the project. Most agreed that project metrics must define progress and value in terms the business understands and appreciates. Approximately 50% reported that business and IT teams in their organizations share a consistent view of project status.
Another important benefit of using common metrics is more awareness of when requirements are due. All too frequently, IT learns about missed requirements too late in the development cycle.
In the case of the survey, all agreed that it is critical to find out as early as possible whether key requirements are missing. However, most respondents indicated that they become aware of missed requirements during User Acceptance Testing (UAT) or after deployment.
What level of commitment do the business stakeholders have in requirements definition in your organization and how does this impact project outcomes?
Next week, I’ll write about some of the steps you can take to pinpoint the areas of your organization most likely to interfere with your ability to satisfy business expectations.
Category: Business-IT Alignment, Defining Success, Requirements Definition