Building and Managing a Requirements Center of Excellence. Part 2.
Why Adopt the Requirements Center of Excellence Model?
The Centers of Excellence (CoE) trend has gained traction recently within the IT departments of large organizations. In fact, the META Group refers to the model as “the next step in IT’s evolution” (Source: The Application Center of Excellence, META Group). This section summarizes costs, risks, and various limitations of traditional quality management practices and contrasts them with the Requirements CoE model.
Problems with Traditional Requirements Practices
Requirements Development not Rigorously or Formally Applied. Most organizations today will author requirements and then attempt to raise the quality of these requirements through manual document walkthroughs and reviews, which has proven to be an onerous, expensive and, to a large degree, ineffective approach. Any errors in the requirements will be detected at some point and have to be remedied, if not during development or testing then during operation by the user. With more rigorous application of requirements best practices and automation, the majority of these expensive errors can be detected early when they are easy and far less expensive to fix.
Traditional Methods and Tools Fail to Close the Gap between Business and IT. The traditional requirements approaches and toolsets continue to focus on managing requirements through a lifecycle with little regard to their quality or if these requirements truly address the business needs. The result is a continual procession of “Death March” projects [Yourdon].
Piecemeal requirements practices and toolsets. In many, if not most cases today, software development is distributed to some degree within an organization (across divisions, departments, or at least projects) and each area tends to be a “microcosm” of disparate tools, approaches and practices, workflows, and artefacts. There is typically little systematic learning and improvement in such an environment. The business incurs not only the obvious direct costs of this but also indirect costs associated with staff turnover due to frustration and dissatisfaction of working in such an environment
Disconnected Processes The different disciplines on the project that utilize the outputs of requirements definition often have processes that are not integrated with those of the requirements discipline. This discontinuity is especially pronounced if the projects and departments have no consistency of tools and/or process across them. Any and all attempts to leverage common services such as technical documentation, customer support and training development, not to mention consistent management reporting and oversight, result in huge inefficiencies in such an environment.
The Business Value of the Requirements CoE Model
Drive Errors out Early in the Life Cycle. A key focus of the Requirements CoE is to promote the definition of requirements whereby they evolve through successive iterations to a high level of quality. The direct result is that less rework is required during later phases of the lifecycle resulting in a higher-quality product, faster, and at lower cost.
Communicate Unambiguously with IT so they Build what Business Needs. The Requirements CoE fosters enhanced communication between Business and IT. Consistency of notation and process is a large part of it, but modern Requirements Definition practices and toolsets make this a reality.
Give the Business the Necessary Control of the Process. Historically the business attempted to express the need, this was interpreted and documented as well as possible, and then IT would proceed largely unchecked until some version of the developed product was made available. It was then that any misinterpretations and miscommunications became obvious. Unfortunately by this time most of the budget and schedule was spent, so changes translated into project over-runs or, where this wasn’t an option, the business would simply accept the inadequate product. The Requirements CoE endeavors, through process and automation, to provide business with meaningful points of control during development to prevent and detect misinterpretations and miscommunications early.
Integrated with Other Disciplines. One of the largest gaps in software development solutions today is the lack of end-to-end integration throughout the software lifecycle. This is true of both processes and automation. While it may be possible to greatly enhance the performance of an individual discipline, one then runs into a brick wall when the results of that work cannot be passed or integrated into another discipline that needs it. The Requirements CoE not only focuses on ensuring the definition of high quality requirements, but also the seamless communication of information with other software development disciplines (testing, development, etc.).
How to Build a Requirements CoE
The flexibility of the CoE model enables companies to start small, use existing resources, and achieve tangible benefits almost immediately. This section outlines a typical process for building a Performance CoE step by step.
The Assessment activity begins with clearly identifying and articulating the business goals that the CoE is fulfilling, or helping to fulfill. This step is critical to maintain the focus of the CoE on addressing business needs.
As an outcome of this activity objective success criteria (KPIs) for the CoE will be established, consistent with business goals. This will allow for clear assessment of progress as the CoE is implemented and set the targets that staff needs to meet. The criteria will be prioritized – often based on short, medium, and long term need, and used to drive implementation planning. This is often based on the most prominent issues that need to be resolved (i.e. “pain points”) but can also be based on risk, criticality, or other drivers. Also, an agreement on how to calculate Return on Investment (ROI) is typically done at this point, since such information is usually required following implementation to justify existence of the CoE. The specific measures required as inputs to the ROI are determined so that their collection can be planned for.
In addition to the above, the organization’s “environment” in which the CoE will play a pivotal role needs to be documented to serve as input to subsequent scoping and design activities. This environment considers the three perspectives:
People. The skill levels and proficiency of staff in the Requirements discipline, and of those who work from the requirements in adjacent disciplines (e.g. design, test, etc.). It takes into account the diversity or consistency of this across the organization.
Process. The existing process, specifically in the area of Requirements, is examined. The activities performed and the artefacts produced as a result are recorded, in addition to how these artefacts are used by adjacent disciplines. The interface points of the discipline with management processes in terms of review, tracking and reporting are also recorded. Once again the consistency of application across the organization is taken into account.
Automation. The tools currently used and planned for use in Requirements and adjacent disciplines are recorded, as well as the manner in which they are used. Any prominent issues with current usage in the context of the existing process are documented.
Finally, the set of current projects along with their status, priority, impending milestones and commitments are itemized.
This accounting of the business goals the CoE is to fulfill and how to measure them, the environment in which the CoE will play a role and the current state of projects and initiatives, along with the constraints of impending commitments provides a basis on which to plan an optimum implementation approach for the organization.
Based on the information gathered during the assessment, prudent decisions can now be made on how best to implement the CoE in an incremental fashion to ensure business objectives are met at minimal risk to existing operations and commitments. The result of the scoping activity will be the high-level approach for incremental implementation identifying:
- Which CoE capabilities will be implemented, in what order
- Across what part(s) of the organization and projects,
- What business objectives will be met, and how this will be measured
- justification for the approach based on risk, opportunity, and other criteria
This results in a high-level Implementation Plan for the CoE.
This activity will evolve the high-level Implementation Plan developed in the previous activity to the point where it can be enacted. These plans are most often based on a phased approach with the immediate phases being expressed in detail, and subsequent phases expressed in less detail as they will be updated based on lessons learned from the initial phases. The Implementation Plan will identify the activities that need to be performed, schedules, milestones, resources required, responsibilities, risks and mitigation strategies to successfully implement the CoE in an iterative fashion. Associated costs and budgets will also be determined.
It is important to note that the nature of the CoE is to consolidate and advance the level of corporate expertise in the area of Requirements. The very nature of this group is one of communication with other groups in the organization, and so the implementation of the CoE will require significant involvement of other groups and projects.
This activity results in the implementation of the CoE over time, by enacting the plan outlined during design activities above.
Continual monitoring of progress and measuring convergence on KPIs is performed throughout the implementation, along with risk monitoring to ensure objectives are attained without compromising existing projects and their goals.
A significant part of the initial implementation is education and awareness for everyone in the organization, and certainly those affected directly or peripherally so that expectations are effectively managed.
Once operational, the initial capabilities of the CoE are quickly assessed as to their effectiveness and their meeting of the objectives set, and adjustments made accordingly. Learnings from the implementations are used to influence detailed planning for subsequent implementation of additional CoE capability.
Validation is an essential step in managing the Requirements CoE implementation and growth based on the value-driven goals. In the validation activity, actual measures of KPIs are compared to targets set forth during Assessment.
Following deployment of the initial Requirements CoE capabilities, high-level plans for additional iterations can be reviewed, modified, and detailed based on the additional knowledge gained and any other changes (e.g. business environment changes, project actuals, changes in risk, etc.). Subsequent iterations will either expand capabilities of the Requirements CoE, or its breadth in the organization, or both.
In many cases there are some centralization activities in various areas of the company already – for example, a CoE focussed on performance validation or defect management. If this is the case, it may make sense to formalize the activities and processes between the individual centers as their individual capabilities grow.
Another approach is to start by using the Requirements CoE model to resolve one specific critical issue (e.g. excessive requirements “churn” in critical project), then:
- Gradually build up the resources and capabilities of the CoE to optimize Requirements processes and techniques on a project basis (pre-empt requirements issues through process consistency)
- Extend the CoE model to other areas such as capacity planning, code optimization, etc.
- Ramp up to standardized processes and solutions throughout the enterprise.
Answers to CIO Questions about a Requirements Center of Excellence
Q: How do I ensure quick results?
A: Use the iterative approach (approx. 2-3 months per iteration). Focus on the services that will generate immediate results, such as verification and validation of requirements
Q: What level of investment will be required?
A: An initial investment of even one FTE can be enough to deliver value by establishing an inventory of current practices and consolidating requirements toolsets. The iterative approach is a way to offset subsequent investments with returns from previous iterations.
Q: How do I ensure adoption of the CoE concept?
A: Executive commitment and support is considered essential. Find one or more project teams who are receptive to the establishment of a CoE. Leverage this collaboration to produce even a single success story that can be marketed to the next projects
Q: How do I prevent disruptions to the organization’s daily operation?
A: The initial focus on critical business issues will align CoE services with daily operations. At the same time, the CoE should be flexible enough to support specific project requirements and culture before it is used as the foundation for standardizing enterprise processes.
Q: How do I use the CoE model to compete with the alternative service providers?
A: Focus energies to ensure that you are faster and cheaper. This will overcome what are typically the biggest objections.
Q: How do I demonstrate value of the CoE ?
A: It is essential to measure CoE impact on the projects and CoE effectiveness. Some KPIs can include product improvement – lower defect rate, fewer change requests – as well as CoE efficiency – projects per person, project time, cost of project, etc.
Summary: 10 Tips for Building and Managing a Requirements CoE
- The earlier you plug into development and delivery processes the easier it is to deliver value to your internal customers
- The fastest path to success is to begin with high-value capability like automated verification and validation of requirements, and automated generation of tests. It is very easy to show value even on the first projects.
- Internal selling is essential. It is not enough to be the best technically. You need to communicate and demonstrate value to your organization
- You need to define your value proposition to compete for the projects where alternative providers may be under consideration. The emphasis in early projects will be the cost and speed of your services.
- Your organization might be unaware of all the capabilities and value of Requirements optimization and management. Educate your organization, evangelize IT management, and create workshops for the decision makers. Blueprint can assist you in this.
- Robust infrastructure and automation platforms are essential to success of the Requirements CoE. Simply having good processes will not prove that you do the job better than any other internal and external competitor
- Knowledge accumulation is critical for continual improvement of Requirements Development practices. You will need to ensure that every member of the CoE reports all findings in these areas
- Ensure that you measure your achievements. This is important for controlling the value of the CoE and also proving the value to the outside world.
- You need to provide your customers with high visibility into your progress, status, and findings. Lack of information drives customer dissatisfaction.
- While your goal is to standardize processes and practices to ensure lowest cost and the highest efficiency, you need to be “easy to do business with”. This means flexibility to adopt your approach and your capabilities to the customer’s project framework and even culture.
For Part 1 of this article click on: http://www.batimes.com/component/content/article/106-articles/500-building-and-managing-a-requirements-center-of-excellence-part-i.html
Don’t forget to leave your comments below
Tony Higgins is Vice-President of Product Marketing for Blueprint, the leading provider of requirements definition solutions for the business analyst. Named a “Cool Vendor” in Application Development by leading analyst firm Gartner, and the winner of the Jolt Excellence Award in Design and Modeling, Blueprint aligns business and IT teams by delivering the industry’s leading requirements suite designed specifically for the business analyst. Tony can be reached at [email protected].