Friday, June 20, 2008

Revisiting Requirements Management

The number one job of the Architect in an IT project is to manage requirements. The Architect is in the only position within the enterprise to look deep enough into the business and deep enough into the technology to understand the translation of the requirements between the two. It is the Architect who is on the front-lines of business-IT alignment, and people should look no further when IT seems "out of touch" with the business.

A requirement, in its simplest form is the codification of a business need. In this regard, requirements should trace naturally to the goals of a business and the metrics that the business uses to track their performance against those goals. Business goals and performance metrics should trace directly to the business plan - which is the embodiment of the business strategy. 

Requirements management, the domain of an Architect, is about managing the full life-cycle of a requirement; ensuring that the business value (goals & metrics) traced to that requirement is both: 
  1. effectively captured during requirements analysis and 
  2. efficiently delivered by the technology traced to that requirement. 
In this way, all technology and associated investment should trace naturally to business value. 

Therefore, the first half of an effective requirements analysis process is for the Architect to ensure that this traceability to the business plan is well-defined, and that the business context associated with the requirement is clear to IT. Architects are on the front-line of IT strategy and planning, and it is their responsibility to challenge and guide their business counterparts in applying the same rigor to the business strategy and planning process as they apply to the technology strategy and planning process.

The second half of the requirements analysis process is for the Architect to ensure that the traceability to the technology plan is well defined, and that the IT context associated with the requirement is clear to the business. The IT context associated with a requirement can be broken down into three main areas: 
  1. the expected impact of the requirement on the enterprise architecture, 
  2. the planning input for the project required to deliver it, and 
  3. the expected impact on IT operations to support it once it has been delivered.
The impact of a requirement (or set of requirements) on the enterprise architecture should be captured across three main enterprise technology views: the software architecture, the server(or hardware) architecture, and the network architecture. In order to properly trace a requirement from business to one of these technology views, the original requirement needs to be "refined". The process of requirements refinement is a meticulous one, that requires all of the skill of an experienced Architect. Refining requirements involves deriving new, more detailed requirements from the base requirement that are specific to the technology view being considered. This process should not add or remove from the scope of the original requirement nor otherwise alter the original requirement. The motivations, assumptions, and constraints considered while deriving a software, hardware, or network requirement from a business requirement should be well-documented by the Architect. This documentation serves as a feedback mechanism from the Architects to their business counterparts on their interpretation of the original requirement. Requirements refinement and associated documentation serves as the basis for involving the business in technology decisions by providing transparency to the IT strategy and planning process.

Planning input should include the basis of estimate that drives the variable costs, any required fixed costs, and any notable risks associated with delivering the requirement (or set of requirements).  The first half of the basis of estimate should be a quantifiable metric (other than hours) that drives effort. Some examples of quantifiable metrics include the number of expected users, a number of screens to be developed, or the number of entities in the data model. The second half of the basis of estimate should be an estimate of hours, by resource type, associated with delivering the requirement across that metric. For example, it may be estimated that it will take 6 hours of a DBA, 1 hour of a business analyst, and 1 hour of a project manager to implement the necessary physical database objects associated with a single entity. This information can then be easily used to generate the necessary staffing plan for a project to deliver the set of requirements being planned, which would smooth the consolidated effort estimate for each resource type across a set of requirements over the full timeline of the project being planned to deliver those requirements and associate a cost per hour for that resource type to determine the cost for that effort within the scope of that project. Fixed costs from subcontractors or vendors that will be providing specific services and / or products needed in the delivery of a requirement should also be included in the planning input for each requirement. Finally, any risks known at the time of planning associated with delivering the requirement should be well-documented. Included in the risk documentation should be a probability that the risk will be realized and its potential impact on project cost, time, and / or quality.

Lastly in the IT requirements analysis process should be the development or modification of a concept of operations for the requirement (or set of requirements) to be delivered. This concept of operations should include any on-going monitoring, management, or administrative activities required to operate the new software, hardware, and or network components delivered while fulfilling the requirement. Like project planning input, the concept of operations would document the basis of estimate for any ongoing variable costs, any regular fixed costs and their timing interval, and any risks associated with operations in support of the components being delivered to meet this requirement (or set of requirements).

Once proper analysis has been done for a requirement, an Architect's job is not over. It is the responsibility of the Architect to monitor the delivery and ongoing operations of each requirement for variances to plan. Variances in cost and time (efficiency) during delivery or operations, including the realization of risk, should be analyzed by the Architect to determine if they are one-time or systemic in nature. Systemic variances in IT efficiency discovered over time should be re-factored back into the requirements analysis output with proper change management controls in place to notify interested business and IT stakeholders. Finally, it is the Architect's responsibility to periodically review the business goals and performance metrics that each requirement is tied to to ensure that expected business value has been delivered by IT. Variances in delivering expected business value (effectiveness) should also be analyzed by the Architect to determine if they are one-time or systemic in nature. Systemic variances in IT effectiveness discovered over time should be re-factored back into the IT strategy and planning process with proper change management controls in place to notify interested business and IT stakeholders.

Architecture today often has the misconception by business and IT stakeholders as being a project-based activity. However; true requirements management, which is at the heart of all modern architecture, involves the regular monitoring and course-correcting (governance) of the business-IT alignment. Requirements management defines architecture as an on-going relationship activity between business and IT; one that should not be confined to the delivery of specific IT projects.