Skip to main content

Building and Managing a Requirements Center of Excellence. Part I.

Maximize Application Quality; Minimize Cost and Time-to-market.

The phrase “the world runs on software” is almost cliché now. Everyone’s life is a daily testament to this adage. Software is ubiquitous and is without question business critical. Virtually every modern-day business has some, if not all, of their business-critical functions implemented in software. In the software game, if you “get it right” the benefits of implementing business in software can be tremendous. If you don’t “get it right” you can find yourself out of business.

Errors in a software development projects have to be confronted if you are to deliver a product with any degree of quality – it isn’t a matter of “if” you fix them, it’s a matter of “when”. Most errors in a software development project originate very early in a project during requirements definition – 68% in fact [Standish]. This represents a huge opportunity to improve software project performance since it is well known that errors are exponentially cheaper to fix when detected earlier in the development life-cycle. But how do we find errors at this early stage and/or prevent them altogether? How do we unambiguously communicate the requirements to developers, testers, and support personnel in a language they understand? Once these questions are answered, how then do we make this a core-competency of our software development capability across all projects? This is what a Requirements Center of Excellence (CoE) is intended to address. It is an investment to capitalize on what is one of the largest opportunities related to software development, and therefore business, today.

In short, a Requirements CoE is the consolidation and centralization of Requirements expertise, knowledge, process, and tools, so that it may be continually improved and leveraged to maximum advantage across all projects in an organization. With a Requirements CoE, valuable new lessons from one project, instead of taking months or years to propagate “organically” can be quickly leveraged across the organization thereby driving rapid improvement.

Just some of the benefits from implementing a Requirements CoE include:

Cost Savings. Early error detection and correction dramatically reduces rework

Efficiencies. Consolidation of disparate requirements initiatives

Reduced Time to Market. Reduced rework results in finished products sooner

Product Predictability. Early error detection reduces risk, improving predictability

Quality. Higher quality requirements and automatically generated inputs for Developers and Testers means less rework and higher quality results

Rapid Improvement. Requirements investments are leveraged across the organization much faster

One of the most promising aspects of a Requirements CoE is that it allows for consistent measuring performance from the perspective of business and end-user results across the organization – not just measuring systems and components at a project or departmental level. With all projects addressing requirements with a consistent approach, common metrics can be established and directly related to business objectives.

A Requirements CoE can be built incrementally with return on investment measured at every stage. For the more risk-averse you can start small, consolidating and leveraging existing requirements resources, and expand as the value is proven.

A Requirements CoE can dramatically reduce the cost of software development for the organization and provides mechanisms to make the benefits sustainable.

What is a Requirements Development Center of Excellence?

A Requirements CoE is an internal group focused on optimizing the quality of requirements produced for all software development projects, ensuring that the requirements reflect true business needs and that they can provide the basis for efficient and effective product development.

The types of activities a Requirements CoE performs include:

  • Requirements tool evaluation, standardization, purchase for the organization
  • Requirements process definition, standardization, and tailoring
  • Requirements Metrics definition, automation, collection, storage, reporting
  • Requirements Training and mentoring services for company staff
  • Project “Startup” services (assess, recommend tools, process, training, mentoring)
  • Requirements component reuse storage, repository, cataloguing, and guidance
  • Requirements model review and consulting services for projects
  • Requirements guidelines, standards, and best practices
  • Representation in industry Requirements community

    (a more comprehensive list is provided later in this article)

Through the Requirements CoE approach, project teams are able to take advantage of all of the expertise, process, toolsets, and best practices the Requirements CoE has developed and consolidated. This section provides an overview of the Requirements CoE and examples of the services it can provide. The next section takes a closer look at the business value of implementing a Quality CoE

Traditionally every project team is an island with its own staff, tools, and practices. The Requirements CoE model centralizes the expertise and processes, brings Key Performance Indicators (KPIs) to requirements initiatives, and can actually reduce total headcount needed to develop, test, and deliver higher quality applications.

Checklist:

You Should Transition to the Requirements CoE Model soon if you have

  • Chronic overruns of project budget or schedule, or regularly change scope of application to meet targets
  • Inability to estimate the cost and schedule impacts of proposed changes during development
  • Different approaches to expressing requirements from project to project
  • Project success seemingly dependent on involvement of a few key individuals
  • No perceptible improvement in predictability of projects from one to the next
  • Applications that are difficult to modify or customize, and expensive to maintain
  • Incomplete or inaccurate technical documentation for an application

How a Requirements CoE works: Five Simple Examples

The examples below contrast how an organization might respond to real-world situations with and without a Requirements CoE.

Example 1: A key employee with several years’ experience in business analysis leaves the company mid-way through a critical project

  • With a Requirements CoE.: The company’s best practices for Requirements Development are defined and shared through the Center of Excellence. All Requirements Center models and sub-models developed by the Analyst over the years are immediately available from the Requirements repository maintained by the Requirements CoE. The Requirements CoE can provide short-term relief to the current project with Business Analysis skills, and/or help ramp up a replacement with any training and mentoring that may be required.
  • Without a Requirements CoE. The project scrambles to find a replacement and then ramp up that replacement on the manner in which this project works with requirements. Information, notes, emails, and any other bits of information found are gathered in an attempt to reconstruct requirements in their current state. Co-workers and past colleagues are polled to find historical knowledge from the employee.

Example 2: Acquire a Company

  • With a Requirements CoE. All projects of the “host” company develop requirements in a consistent and effective fashion in accordance with the company’s best practices for Requirements Development as defined and shared through the CoE. CoE experts assess the acquired company’s Requirements Development capabilities and make recommendations for transition and any modification to existing assets (eg. Project Start-up packages, courses, packaged services, etc.). Training and mentoring packages of the CoE are used as part of a transition plan to educate staff of the acquired company. Project Start-up packages, maintained and delivered by the CoE, are used to launch new projects within the acquired company or as a basis to plan transition of projects in progress, where appropriate. A focused transition with well-defined “end-state” where all expectations of host and acquired staff can be managed effectively. Acquired staff gets a sense they are transitioning to a well-managed environment.
  • Without a Requirements CoE. Host organization differs in Requirements Development approach from project to project, with low level of consistency. Not clear what acquired company should transition to, if to transition at all. Result is perpetuating acquired company’s requirements approach thereby creating yet another “stovepipe” in the organization, inhibiting integration of the acquired company and the efficiencies that should have been gained because of it. With no clear “end-state” for the requirements discipline the expectations of acquired staff are difficult to manage and they lack a sense of moving to something better. Instead they have a sense of being assimilated into a chaotic environment. Morale diminishes among the acquired staff increasing turnover, reducing productivity, and increasing risk of failed acquisition.

Example 3: External party (customer, prospect) to review or audit software development capability.

  • With a Requirements CoE. Requirements Development process including best-practices, sample artefacts, templates, guidelines are maintained by the Requirements CoE and made accessible to all projects. Project performance measures collected analyzed and reported on by the CoE are also available. Any mappings of adherence to industry models (CMMi, ISO, etc.) are also be maintained by the CoE. All this information is available for review by the external party and can be explained and discussed with experts from the CoE. Projects in progress can be shown to adhere to the standard process and any can be chosen as an example for further examination.
  • Without a Requirements CoE. An effort is launched to canvas projects seeking the “nicest” examples of requirements artifacts. Any process descriptions are similarly gathered or created in order to explain how requirements activities are performed. Directories for old projects are scanned, again seeking good examples of requirements artifacts. Metrics on performance are gathered where they exist, and attempts made to normalize and reconcile them in order to extract some meaning.

Example 4: A new, business-critical project initiative is being considered and accurate estimates of time and cost are required in order to make a decision to proceed.

  • With a Requirements CoE. Requirements models for past projects in the repository are examined for reusable models and sub models. Metrics on past project performance are analyzed. A high level, abstract Requirements Center model is created and supplemented with any reusable sub-models found. This model, along with performance metrics gathered, is used as key basis for estimating the new initiative.
  • Without a Requirements CoE. Pull most knowledgeable, senior people from current assignments together and collect subjective impressions from past projects of similar nature, magnitude and complexity, if they exist. Estimate for new initiative is based on these impressions and personal experience.

Example 5: A new project is being launched, and the “environment” consisting of process and tools needs to be established.

  • With a Requirements CoE. The Project Manager notifies the CoE of the new project. Experts from the Requirements CoE deploy the “Project Start-up” packaged service. They assess the project to deduce best fit, given project type, complexity, duration, budgets, people, etc. CoE experts deliver training and mentoring, deploy and configure the toolset, and put process in place. The CoE experts assist with project launch and deliver mentoring with emphasis during early stages of Requirements Development, ensuring staff are proficient with process and tools. Initial artifacts are reviewed by CoE experts to help staff converge on the optimal solution. CoE experts are involved in every major project review and are on call to provide “Just in Time” mentoring and assistance. CoE experts liaise with tools manufacturers as “single point of contact” for special requests and support on behalf of all projects.
  • Without a Requirements CoE. The Project Manager tries to secure time with process “experts” from wherever they may be in the company. Experts and senior project staff do “process engineering”, typically under project budget, to identify desired approaches, tools, templates, guidelines, etc. for the project. The results of this activity are highly dependent on the personal experience of the individuals involved. The project then puts all in place, must devise means of educating staff, acquires and deploys/configures tool(s). Interfacing with vendor is often done by designated project staff. When issues arise with process, tools, advice is sought in informal manner from whatever source might be available.

Start Small and Grow Organically

One of the key advantages of a Requirements CoE is that it can be established incrementally and show incremental returns on investment. A Requirements CoE can be built on a small scale initially with minimal capital expenditure and you can scale up its resources, services, and capabilities incrementally as its value is proven.

Initially the Requirements CoE could focus on the standardization of requirements artifacts including notations and formats. This can be followed by, or deployed in conjunction with, standardization of tool support for defining requirements. In time, the process by which requirements are developed based on the notations and automation can be formalized and tuned. The standardized process would include aspects made possible only by automated tool support, such as immediate validation of requirements using simulation and testability assurance. Still later a centralized repository for requirements artifacts to facilitate reuse could be added followed by a formal requirements metrics program to provide the basis for continual requirements improvement.

Therefore the CoE can grow both in capability and breadth of adoption across the enterprise at a rate that fits the constraints of the organization.

Requirements CoE Resources and Services

The Requirements CoE has the potential to become a competitive advantage for any company whose business relies on software. Since requirements are the cornerstone of the software development process with all other disciplines dependent on its artifacts and with 68% of all errors being introduced at this point, there is tremendous potential for cost-savings and quality improvement. The nature of the services that can be provided by a Requirements CoE include:

“Project Start-up” Services with Respect to Requirements

  • Leverage the growing Requirements Development knowledge and experience base
  • Provide expert assistance in assessing and devising best approach for tools, process, and training/mentoring needs for the project
  • Assist in setting up environment including project guidelines, standards, templates, and other assets
  • Deliver training and mentoring in Requirements Development process and tools

To be a Cross-product/divisional “Communication Hub” for Requirements

  • “harvest” business assets and make reusable
    • Business cases and studies to make it easier for other divisions to adopt
  • “harvest” technical assets and make reusable
    • Best practices in Requirements Development across projects
    • Reusable Requirements components
    • Reusable Requirements Training components
  • Establish mechanisms to foster communication in Requirements Development
    • Newsletters, bulletin boards, interest-group meetings

Requirements Development Tool Expertise

  • Single point of liaison with Requirements Development tool vendor. Promote organization’s interests, enhancement management, beta participation
  • First-line support for Requirements Development tool
  • Experts in tool configuration for specific project usage and application
  • Development of, and repository for examples templates that support process
  • Best Practices in tool usage for specific applications

Requirements Development Process Expertise

  • Generation and maintenance of standard Requirements Development process
  • Expertise to tailor and adapt the standard process to suit specific projects
  • Collection of empirical data and metrics to facilitate continual process improvement
  • Expertise to teach and mentor project staff in Requirements Development process

Education and Awareness of Requirements Development to the Larger Organization

  • In early stages this new discipline will be largely unknown to most. This center should be capable of fielding requests for information and providing introductory education
  • Should also be in a position to deliver demonstrations, learning sessions, and similar as part of awareness efforts

To Liaise with Industry Associations and Represent the Organization in these Forums

  • In order to “harvest” best-practices and approaches found by others, and to monitor trends in the discipline
  • In order to contribute organizational learning

To provide these services the Requirements CoE should maintain a core staff, whose levels will depend upon how aggressively the organization chooses to grow the discipline. Initially this could involve a part-time manager and single domain expert but could scale over time to support an enterprise.

In this article, we have discussed what a Requirements CoE, is and how it works. Stay tuned for next issue’s follow up, on why organizations should adopt a Requirements CoE, and step-by-step lessons on how to build one.

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].