The Requirements Session Has Started. Do You Know Where the Business People Are?


Posted by Geneca - 03 April, 2012

The Role of the Business in Driving Requirements.

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. Yet, the requirements process is often cited as the area most lacking in best practices.

Lack of alignment on requirements is an ongoing source of frustration in most organizations. In fact, a recent study of business analysts at Fortune 500 companies revealed that only 37% of the analysts polled said their projects met users’ needs. As many as 71% of software projects fail because of poor requirements management, making it the single biggest reason for project failure.

While the vast majority of executives in our survey recognize the importance of accurate requirements, they routinely struggle in two key areas: upfront requirements definition and managing those requirements throughout the development cycle.

Key Survey Findings.

  • 94% of respondents acknowledge that the quality of requirements is a leading factor in the success of their software projects.
  • Over 70% acknowledge that there is room for improvement in their requirements practices.
  • 75% agree that better articulation of business and IT roles/responsibilities in requirements gathering would go a long way toward improving project outcomes.
  • While most companies acknowledge that the business has at least some input into requirements definition, requirements are often unclear.
  • Over 80% of respondents indicate that they do not learn about missed requirements until too late in the development cycle.
  • Only about half of the respondents feel that business and IT teams have a consistent view of project status.
  • Over one third of respondents state that progress is not consistently tracked in business milestones, resulting in rework and missed deadlines.

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 disappointing outcomes.

The degree of business involvement in driving requirements varies greatly within our survey. However, respondents overwhelmingly agree that when the business is directly held accountable for clearly defining their needs, project outcomes improve. Respondents also mention the need for better articulation of business and IT roles and responsibilities in the requirements process.

A successful project means more than making sure that what is specified is delivered. The right requirements must also be specified before development begins. If the business is not 100% committed to making this happen, even the most skilled development teams cannot predictably deliver what the business needs.

Engage the Business Early, Often and Methodically.

For successful requirements definition, the various players need to be involved in ways they might not have been before. We asked our survey respondents to describe some of the benefits they enjoy when the business is fully engaged in upfront requirements sessions.

Software development organizations with the ability to accurately define requirements upfront realize benefits throughout the project lifecycle. These teams do a better job eliminating guesswork and rework, supporting change control, improving testing efficiencies and, most importantly, meeting business objectives.

Business Milestones: Now You See Them. Now You Don’t.

Most survey respondents agree that project metrics must define progress and value in terms the business understands and appreciates. Approximately 50% report that business and IT teams in their organizations share a consistent view of project status.

An agreed upon definition of success, using common metrics between business and IT, provides benefits throughout the development cycle, including:

  • Clear visibility into progress based upon business objectives
  • Better management of business expectations and requirements
  • Consistent view of project health
  • Reduced rework and conflict due to unclear requirements

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 our survey, all agree that it is critical to find out as early as possible whether key requirements are missing. However, most respondents indicate that they become aware of missed requirements during User Acceptance Testing (UAT) or after deployment.

There is room for improvement here for IT to measure progress consistently with the business based on business milestones and objectives.

About to Start Requirements? Make the Business Accountable.

During the requirements phase of a project, expectations are high and there is a sense of optimism. However, this is also the phase where lack of best practices begins to undermine success and worst practices often prevail. Most survey respondents admit that at least part of their requirements process is broken.

If you are about to start the requirements phase of your project, there is a first step that can keep the business stakeholders fully engaged and accountable. Take a close look at the “condition” of your people, processes and metrics. By answering the following questions, you will be able to pinpoint the areas of your organization most likely to erode your ability to satisfy business expectations.

How do you achieve alignment?

  • Do all business stakeholders agree on the goals of the project?
  • Who owns defining requirements? Is this different from who owns “documenting” requirements?
  • How do you know when a particular part of a project is complete? How do you know when the overall project is complete? Does your team have this information and does it align with business objectives?
  • In general, after collecting requirements, are Change Requests introduced during the first 30% of the development cycle?

How do you track projects?

  • Do project status reports show progress in terms the business understands or is it in “IT speak” requiring translation for the business?
  • Is project success determined by being on budget? On schedule? Meeting the original business objectives and ROI? Which one?
  • Does your team use one internal project tracking report for status while the external report is different? Or is there a common report showing progress on the project?
  • Do business and IT team members typically have a consistent view of project status and health?

Are project roles and responsibilities clearly defined?

  • Is there a single person and role accountable for technical issues?
  • If you deliver a solution that works but is missing key features required by the business, is there a single individual and role that is accountable?
  • Are your project managers accountable for tracking progress and making project health visible? Are the responsibilities for this role consistent across all projects and project managers?

Clearly, organizations that hold the business stakeholders accountable to define their needs enjoy better results. They have clarity and accountability throughout the development cycle. They experience less rework. Most importantly, they can predictably deliver exactly what the business wants.

Topics: Business, leadership, product definition, software development

Recent Posts

Geneca Ranks #18 of Top 100 Places to Work in Chicago

read more

Customer Service as a Marketing Tool

read more

Millennial's Talk: What Are They Saying About You?

read more