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
Last 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.
Category: For Practitioners, People, Requirements Definition