CHAPTER 13
Applying Complexity Thinking to Projects with Poorly Understood, Volatile Requirements
| Project Profile | |||
|---|---|---|---|
| Complexity Dimensions | Independent | Moderately Complex | Highly Complex |
| Requirements Volatility and Risk |
|
|
|
Project complexity ensues when requirements are unstable and poorly understood, functionality is likely to be complex, or customer/user support is insufficient. In this chapter we explore the elements that make dynamic, poorly understood requirements complex and recommend management techniques that the project leader and team can use to manage the resulting complexities.
WHAT MAKES DYNAMIC, POORLY UNDERSTOOD REQUIREMENTS COMPLEX?
“Individual requirements are rarely complex in themselves; it is the relationships and interdependencies between them that result in complexity—so it is these that need to be spotted and managed.”
—DAN ROSSNER, PA CONSULTING GROUP
Defining and managing requirements is hard—very hard—for many reasons. The complexity of the requirements management effort is rooted in widespread deficiencies in requirements practices, inadequate involvement by key stakeholders, and numerous interdependencies among individual requirements.
DEFICIENT REQUIREMENTS PRACTICES
“In the U.S. alone, up to 60 percent of software developers are involved in fixing errors.”
—CAPERS JONES
SOFTWARE PRODUCTIVITY RESEARCH
Dan Rossner of PA Consulting Group, a leading management, systems, and technology consulting firm, tells us that requirements flaws most often lurk in complex projects when the following conditions are present:1
Requirements are not visualized or communicated in the right way to the right audience.- The same level of detail is applied to all requirements, regardless of the need.
- A disproportionate amount of effort is expended managing the requirements process rather than managing the requirements themselves throughout the life of the project.
INSUFFICIENT STAKEHOLDER INVOLVEMENT
It is often extremely difficult to get the appropriate stakeholders engaged and committed to help define, progressively elaborate, and manage requirements throughout the project. After all, they have a business to run; business stakeholders often believe that requirements definition is the responsibility of the project team, not the business leaders.
REQUIREMENTS INTERDEPENDENCIES
It is the relationships and interdependencies between requirements—far more than the requirements themselves—that result in complexity. And then there are the changes. Requirements are dynamic, changing as they are progressively elaborated and more information is discovered, and changing as the business transforms. Managing these changes adds another layer of complexity.
CASE STUDY: POORLY UNDERSTOOD, VOLATILE REQUIREMENTS
COTS ERP System Acquisition and Deployment
For an example of poorly understood, volatile requirements, we look to the project undertaken by a leading vendor to provide a major enterprise requirements planning (ERP) software solution for a government agency. The vendor promised to provide commercial-off-the-shelf (COTS) ERP solutions for finance, human capital management, customer relationship management, and business intelligence applications tailored to the needs of the government sector. The vendor also committed to provide best-in-class service and support.
The first module was to be the human capital management application. The management team of the human resource (HR) directorate committed to adopting the management practices embedded within the system rather than making wholesale changes to the purchased application. An implementation team was formed consisting of vendor representatives and key members of the HR group; together they developed a project plan and budget that assumed little or no customization. The team worked diligently for many months to prepare for the new system, installing and testing the system and training the IT team to provide maintenance and support. This initial effort took about 18 months and cost almost $20 million.
As preparation for the installation and deployment of the new system proceeded, the organization underwent a major reorganization and many members of the HR directorate management team were replaced. During user training and acceptance testing, it became apparent that the system did not support the current HR practices, yet the new management team was not prepared to change “the way things have always been done around here.” The project team had neglected to continually validate requirements with the business at key decision points and was therefore unaware of the change in expectations. The result was a failed and canceled project.
HOW TO MANAGE POORLY UNDERSTOOD, UNSTABLE REQUIREMENTS
Several strategies can be effective in managing requirements complexity. We recommend conducting rigorous enterprise analysis, establishing a framework for managing requirements complexity, and adopting agile requirements analysis and solution development techniques.
RIGOROUS ENTERPRISE ANALYSIS
Rigorous enterprise analysis should be performed prior to project funding and before the project leader seeks executive approval for the project scope and approach.
Complete Rigorous Analysis Prior to Project Funding
Most organizations do not conduct a complete and thorough analysis of the area of the enterprise undergoing change prior to funding significant business projects. As a result, many projects get underway with unclear expectations and a poor understanding of the business need.
A thorough analysis of the enterprise prior to project initiation may include vision and business planning, problem structuring, stakeholder and purpose analysis, behavior modeling, value modeling, solution structuring, and feasibility analysis. Through these activities the business can define the problem or opportunity, select and define the solution concept, and prepare the business case.
If these activities have not been performed prior to project initiation, we recommend that the project leader secure the help of a core team of experts from the business and technical communities. The requirements definition that is completed after project initiation will still be challenging, but it will be significantly easier and less risky.
Secure Executive Approval for the Project Scope and Approach
A complex project needs strong executive support. If the initiative does not have a strong and committed sponsor who is responsible for delivering the business benefits promised in the business case, recruit one. Share the results of the enterprise analysis activities captured in the business case with the sponsor. Make sure the initiative is prioritized, approved, funded, and strategically important to both the sponsor and the enterprise.
A FRAMEWORK FOR MANAGING REQUIREMENTS COMPLEXITY
For complex projects, we strongly suggest establishing a framework for managing requirements complexity. Establishing this framework involves several key steps:
- Establish requirements integration teams
- Recruit a professional business analyst
- Insist on adequate customer, end-user, and technical involvement
- Establish a requirements knowledge management system.
Establish Requirements Integration Teams
Set up a requirements integration team to manage requirements relationships and interdependencies. Identify boundaries and ensure that each team knows its area of responsibility and is aware of the areas of overlap. For these teams to be successful, they must have expert knowledge of the business domain, IT, and the requirements definition and management process.
Recruit a Professional Business Analyst
Critical, complex projects need a full-time, senior business analyst (BA) and will likely need a business analysis team to elicit, analyze, specify, validate, and manage requirements. Secure the involvement of a full-time, senior BA to lead the requirements activities and manage the requirements integration teams. It takes a great deal of knowledge about the business and experience managing requirements to strike the right balance between too much and too little detail, so look for experience. Secure the help of a Certified Business Analyst Professional qualified by the International Institute of Business Analysis (IIBA; see http://www.raeng.org.uk/news/publications/list/reports/Complex_IT_Projects.pdf).
Ensure that the BA updates the business case at key decision points to validate that the investment in the project is still warranted. Review the updated business case and project documents with the executive sponsor to secure funding for the next iteration/phase of the project.
Insist on Adequate Customer, End-User, and Technical Involvement
Secure key resources from the relevant business and technical organizations to participate as full-fledged members of each requirements integration team for the life of the project. With the help of the business and technical representatives, continually validate the team boundaries and ensure that each team knows its area of responsibility and the dependencies it must manage. Require each team to document and manage interrelationships with requirements outside its responsibility, as well as interrelationships between the requirements the team owns. Assign each requirements integration team responsibility for tracing its requirements throughout design, construction, and test work products, as well as for integrating its requirements into the overall solution.
Establish a Requirements Knowledge Management System
Requirements come in many forms, for example, a requirement specification, model, or process description. In addition, requirements are embedded in many business artifacts: plans, goals, objectives, executive presentations, a document or a section of a document, policies, procedures, business rules, or even email verbiage. Establish a knowledge management system that links requirements to their relevant business source documents.
AGILE METHODS
The agile movement is flourishing because requirements are so volatile and so difficult to manage. To reduce requirements complexity, we recommend several agile approaches:
- Agile, iterative requirements definition and analysis techniques
- Sophisticated requirements visualization techniques
- Test-driven requirements definition techniques
- Incremental solution development techniques.
The world of agile analysis challenges business analysts to become the communications mentors and coaches of project teams when needed and to get out of the way when appropriate. To do this, one of the tenets of agile methodology must be followed: active stakeholder participation throughout the project life cycle. The focus changes from working to find out what customers want to helping them determine what they want and need.
The obvious enabler to active stakeholder participation is co-location of the business and technical teams. However, the business community cannot always free critical resources to work with the development team on a full-time basis. In this case, the business analyst conducts interviews and workshops with the business community in its own environment, with key members of the development team present to hear “the voice of the customer.”
SCOTT AMBLER
Agile Analysis2
As presented by Scott Ambler, agile analysis is a highly iterative and incremental process whereby developers and project stakeholders actively work together to understand the domain, identify what needs to be built, estimate functionality, prioritize the functionality, and (optionally) produce artifacts that are just barely good enough. Ambler describes the characteristics of agile analysis as follows:
- Communication-rich. Analysis is communication-rich, valuing face-to-face meetings and teleconferencing over documentation and email.
- Highly iterative. Agile analysis is highly iterative. Analysis and design activities are dependent on each other and in practice are matured in an iterative manner. Indeed, since estimating is part of analysis, it is impossible to estimate the cost of a solution without knowing the solution design.
- Constant feedback. Agile analysis is highly incremental, so that components of the solution can be implemented for customer feedback before committing to further investment in development. Hence, estimation and prioritization of requirements in increments are essential. This approach facilitates tradeoff analysis and critical decision-making on the part of the customer.
- Just enough. Agile analysis follows the premise that good is good enough. It is the art of applying just the right amount of rigor—no more and no less.
Use Agile, Iterative Requirements Definition and Analysis Techniques
Avoid spending too much time early in the project striving to define requirements in detail. Use the 80/20 rule to uncover 80 percent of requirements at the start of the project. Change happens, so we need to just get over it. It is futile to try to develop and freeze requirements and then limit changes. Expect, plan for, and welcome changes that add value to the business. It is simply a fact that new information about requirements will be discovered in the course of the project.
Reduce the cost of change by using incremental development methods. Define requirements and early design concurrently and collaboratively. Know what needs to be done at the front end to understand the basic requirements; the goal is that these will become firm, with little chance of changing (see the discussion of firm basic requirements in Chapter 9).
This approach requires a paradigm shift from trying to define detailed requirements up front to letting requirements emerge through more creative, adaptive, and agile approaches. The focus is not on managing changes to requirements, but rather on managing requirements throughout the project life cycle.
JIM JOHNSON
Lessons Learned from the Agile Community3
Jim Johnson offers some advice for analyzing requirements:
- Use an iterative development style; it is the heart and soul of an agile process.
- Collaborate with team members as part of the agile development process.
- Follow up with rapid feedback, which promotes quickness and velocity—the cornerstones of agile methods.
- Recognize that the agile process instills better testing and code quality controls than conventional software development.
- Consider using a Web-based standard infrastructure as a key component to the agile style.
- Adopt a policy of no new releases and implement features and functions in a rapid pace on a standard infrastructure.
- Rethink that old adage about doing risky things first.
Use Sophisticated Requirements Visualization Techniques
The more customers can visualize the solution, the easier it will be for them to validate that all requirements have been satisfied. Create a blueprint (a view or conceptual model) of what the solution will cover. This view will serve as the starting point for scoping the effort and defining the timing of critical and non-critical functionality. The blueprint should depict the business scope in terms of processes and functions and identify the key stakeholders who will interact with the solution. The visual should also depict what the new solution will not handle so that the effort to develop manual procedures can be understood.
Create requirements-understanding models, simulations, and prototypes to make the requirements visual. Develop “a-day-in-the-life” scenarios to help clarify and validate requirements. Communicate, communicate, communicate! Use technology to share information when the team members are geographically separated—for example, video recordings of user operations; webcasts of business vision and rationale for change; and live, interactive usability testing.
Use Test-Driven Requirements Definition Techniques
Requirements that are not testable are not complete. Build the test case before or concurrently with documenting requirements. Sometimes building the test case clarifies the requirement, helps define it, or even changes it.
Use Incremental Solution Development Techniques
Agile development is a highly iterative and incremental process, where developers and project stakeholders actively work together to understand the domain, identify what needs to be built, and prioritize functionality.4 Use agile development methods when project value is understood; firm basic requirements are clear; the customer participates throughout the project; the customer, designers, and developers are co-located; incremental feature-driven development is possible; and visual documentation (cards on the wall versus formal documentation) is acceptable.
Iteration is the best defense against uncertainty and unpredictability. Use iterative approaches when defining requirements and building systems to manage changes to requirements throughout the life of the project. Determine lessons learned after each iteration with two goals in mind: (1) to drive down the cost of change and (2) to increase innovation and the value of the solution.
In this chapter we first explored the causes of project complexity when requirements are unstable and poorly understood. We then recommended management techniques for you to consider to help you and your team manage the complexities brought about by dynamic, poorly understood requirements. Specifically, we discovered:
- We sometimes cause requirements defects by neglecting to depict and communicate requirements in a way that ensures the various stakeholders can understand them.
- We should not try to define the requirements in detail up front or to apply the same level of detail to all requirements regardless of the need.
- A disproportionate amount of effort is expended managing the requirements process rather than managing the requirements themselves throughout the life of the project. To manage poorly understood requirements, a complete analysis should be performed prior to project funding and the support of a strong executive sponsor should be enlisted.
- A framework for managing requirements complexity that involves requirements integration teams, a professional business analyst, and adequate customer, end-user, and technical involvement should be established.
- A requirements knowledge management system that links requirements to business plans and goals should be established.
- Agile methods should be used to manage change and limit rework; these may include agile, iterative requirements definition and analysis, requirements visualization, test-driven requirements definition, and incremental solution development techniques.
When requirements are expected to be volatile, it is prudent to use both conventional and adaptive project management approaches (Table 13-1).
TABLE 13-1. Approach to Managing Projects with Poorly Understood, Volatile Requirements
| Managing Projects with Poorly understood, Volatile Requirements | |
|---|---|
| Complexities | Management Approaches |
Requirements alone are not complex; it is the interdependencies and interrelationships that make them complex:
|
Adaptive
Conventional
|
NOTES
1. Dan Rossner, “Flushing the Requirement Gremlins Out of Complex Programmes: Viewpoint on Complexity,” PA Consulting Services Limited (2005). Online at http://www.paconsulting.com/insights/managing_complex_projects/ (accessed February 2008).
2. Scott W. Ambler, “Agile Analysis.” Online at www.agilemodeling.com/essays/agileanalysis.htm (accessed March 2008).
3. Jim Johnson, My Life is Failure: 100 Things You Should Know to be a Successful Project Leader (West Yarmouth, MA: The Standish Group International, 2006), 8.
4. Scott W. Ambler, “Agile Analysis.” Online at www.agilemodeling.com/essays/agileanalysis.htm (accessed March 2008).