Subscribe via RSS Feed

Author Archive for Jessica.Chipkin

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

When it comes to software requirements definition, engage the business … early, often and methodically

ClassroomLast week, I shared the results of a recent survey taken at a IT trade conference on the role of business in driving software requirements. Most of the people taking the survey stated that they consistently struggle in two areas: Connecting with the business and managing requirements throughout the development cycle.  They also admitted that at least part of their requirements process is broken.

This week, I’ll provide some thoughts on how to pinpoint some of these broken processes.


About to Start Requirements? Read this First.

During the requirements phase of a project, expectations and confidence run high. However, this is also the phase where lack of best practices begins to undermine success and worst practices rise to the surface.

Before you start the requirements phase of your next project, take an important first step by looking very closely at the “condition” of your people, processes and metrics.

Before you start the requirements phase of your next project, take an important first step by looking very closely at the “condition” of your people, processes and metrics. In his white paper, “Doing More with Less: Best Practices for Processes, People and Metrics” [PDF], Geneca Vice President and Managing Director, Bob Zimmerman, suggests asking the following questions to draw out areas in need improvement.

How do you work with the business?

  • 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 lifecycle?

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 on 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?

By answering these questions, you should be able to hone in on the areas of your requirements practices most likely to impact your ability to satisfy business expectations.

For successful requirements definition, the various players need to be involved in ways they might not have been before. If the business is not 100% committed to making this happen, even the most talented development teams cannot predictably give the business what it needs.

Organizations that hold the business stakeholders accountable to define their needs enjoy better results. These teams do a better job eliminating guesswork and rework, supporting change control, improving testing efficiencies and, most importantly, delivering exactly what the business wants.

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.