Framework: An Integrated Approach to Portfolio, Program and Project
|[AACE HOME] -- [TCM HOME] -- [BUY THE TCM FRAMEWORK] --[DOWNLOAD PDF VERSION]|
[TOC] [PREVIOUS] [NEXT]
II. STRATEGIC ASSET MANAGEMENT PROCESS - CHAPTER 3 - STRATEGIC ASSET PLANNING
3.1 Requirements Elicitation and Analysis
Requirements elicitation and analysis is the entry process to TCM and the first of the strategic asset planning processes. It is a process of identifying stakeholders and their needs, wants, and expectations; probing deeper into them; and documenting them in a form that supports planning, communication, implementation, measurement, and assessment. The goal of requirements elicitation and analysis is to understand the problem or opportunity and state what will be required of any solution. A design team will consider the requirements and formulate alternate solutions that will be decided upon for implementation. Asset performance assessment and change management identify the business performance issues (problems and opportunities) for the existing asset and project portfolio (Sections 6.1 and 6.2).
Generally speaking, requirements deal with what users or customers need to accomplish, and not how the solution or assets (i.e., facilities, products, systems, etc.) will achieve the desired result. The asset planning process (Section 3.2) determines and specifies the scope of asset alternatives and how they will function, and the project implementation process (see Section 4.1) sets in motion the processes to determine how the selected asset alternative will be implemented. The alternatives may be a project to create or modify a capital asset or product, or a non-project maintenance or operational corrective action to an existing asset or product.
In as much as the project process or system is also an asset of the enterprise, requirements for solutions to project problems and opportunities, in general or in respect to a particular project, are elicited, analyzed, and specified as well.
Requirements originate from the user, customer, or other stakeholders perceptions of problems or opportunities that stimulate a request to address it. A user requirement is a condition or capability that particular users communicate and agree any solution must have to address their perceived problem or opportunity. Requirement specifications however are derived by eliciting and analyzing all stakeholder input. Specified requirements that result from the analysis process are sometimes called derived requirements because, unlike user requirements, they are not expressed directly by the stakeholder. This distinction is important because if the elicitation and analysis process is done poorly, the final derived requirement specifications may diverge from what the stakeholders want or need.
In TCM, requirements are sometimes imposed (e.g., as a business or government mandate, a condition of a contract, etc.) by or upon the business. These requirements may be directly documented as a requirement specification and may influence the derivation of other requirements. The TCM process does not include business strategy development during which many of these more "strategic" requirements are established. The process described in this section is most applicable to derived requirements.
It is important to recognize that needs, wants, and expectations are not requirements until they have been elicited, analyzed, and documented through a requirements elicitation and analysis process. The desired characteristics of a requirement include the following:
Solution free or technology independent. Multiple design options may satisfy a requirement. The term "design constraint" is often used when there is only one feasible solution that can meet the requirement. It should define what the asset will do, and not how it will do it or how it will be implemented. The "hows" are defined in the asset planning process (Section 3.2).
Organized. A hierarchical structure is preferred. The structure should ensure that the requirements are complete, readily locatable, sorted by type, and integrated without conflicting with each other.
Clear. Short, simple, unambiguous requirement statements are preferable; however, any qualifications regarding the requirements should be noted.
Prioritized. The value of each stakeholder requirement may be ranked.
Traceable. Each requirement should be specific to a stakeholder or other origin. This facilitates the change management process (Section 6.2).
Requirements can generally be categorized as either a functional requirement (i.e., what the solution has to do), or a constraint or non-functional requirement (i.e., qualities or attributes that a solution must have). A functional requirement is usually a verb-noun description of what the solution needs to be able to do (e.g., it must pump water). A constraint is usually an adjective description (e.g., it must be reliable and profitable).
Some might add business requirements (i.e., enterprise or operations missions, goals, or drivers) as a category, but, in general, these can often be categorized as constraints. For example, the main business objective of a corporate enterprise may be to maximize the total long-term economic return of or profit from its asset investments (see Sections 2.3 and 3.3); the need for profit can then be expressed as a constraint for an investment.
TCM and other quality-driven processes rely on measurement. Therefore, the description of each functional requirement and constraint must also include a measurable performance quantity or statement. The quantified aspect of a functional requirement or constraint is called a performance requirement. For example, the requirement to "pump water" could be expanded to specify " at X capacity." Likewise, the required attributes of being "reliable and profitable" could additionally specify " with downtime less than X percent and return on investment of at least Y percent."
The overall document of requirements, and output of this process, is a requirements specification (not to be confused with the more common "design specification"). A requirement specification can be a conceptual or broad representation of the customer wants and needs for an overall solution, or detailed and specific enough to support the design and procurement of individual solution components.
.2 Business Strategy and Requirements
The business strategy development process must align with the strategic asset management (i.e., strategy deployment) process. Balanced scorecard is a common methodology that aligns these processes. Balanced scorecard seeks to ensure that business strategy development and deployment look at performance from a "balanced" perspective, measuring business drivers in addition to traditional financial metrics. Most balanced scorecard implementations focus on four perspectives in the asset planning, measurement, and assessment processes: financial, customer, business process, and learning and growth. For each perspective, the business identifies strategic objectives (e.g., "exceed shareholder expectations" from a financial perspective or "faster order process" from a business process perspective). In some cases, the objectives may be expressed in the form of a requirement (i.e., an imposed business requirement or constraint such as a return on investment measure). In other cases, the requirements elicitation and analysis process is used to translate the objectives to quantified requirements.
The number of requirements established, and hence asset performance measures to capture and assess, can be quite large. Therefore, most enterprises that used a balanced scorecard approach focus on a few key requirements or performance indicators (KPI) that are measures believed to most directly correlate with successful achievement of business objectives.
Addressing "balanced" objectives from many perspectives adds several challenges to requirements elicitation and analysis: stakeholders may be difficult to identify and communicate with; their individual priorities and goals may differ and conflict; their awareness and understanding of their needs (let alone business strategy) is sometimes unclear or difficult to articulate; and their needs may differ depending on shifting conditions in the environment in which the enterprise exists. In addition, requirements may change (e.g., by refining or clarifying details, by stakeholders changing their mind, etc.) during the life cycle of the asset. Therefore, considering balanced perspective during requirements elicitation and analysis puts a premium on having an effective established process such as TCM.
.3 Cost Management and Requirements
A balanced requirements perspective also includes the early consideration of costs. Traditionally, the primary cost management concern during the requirements elicitation and analysis process has been business requirements regarding profitability. Functional requirements were usually determined initially with little regard for cost and it was not until a solution alternative was designed and estimated that costs were considered. This often resulted in costly, time-consuming design rework when the alternatives were found to be too costly and/or unprofitable.
However, target costing methods (includes design-to-cost [DTC] and cost as an independent variable [CAIV]) are being used more frequently. In these concepts, cost is an imposed or derived constraint (or preference), and the costs of meeting functional requirements are considered from the very start of strategic asset planning. Quality function deployment (QFD), which has traditionally been focused on "deployment" of functional requirements, is also evolving to consider cost as a requirement. If the QFD variation called cost deployment is going to be used in strategic asset planning, then cost constraints will also need to be considered in requirements elicitation and analysis.
3.1.2 Process Map for Requirements Elicitation and Analysis
Figure 3.1-1 illustrates the process map for requirements elicitation and analysis. The input is customer requests and information about performance problems and opportunities and the output is improved, actionable knowledge in the form of a requirement specification.
While the map is shown as a sequential process, the elicitation, analysis, and review steps are likely to be more concurrent and iterative in practice. For example, at a detailed requirements interview with a given stakeholder or team (for a problem of limited scope), an analyst or planner may simultaneously elicit, analyze and review information, and specify a requirement that addresses that stakeholders needs. As the analysts elicit information, they are constantly and simultaneously evaluating to test if the stakeholders are saying what they mean, and assuring that the stakeholders agree with a specified requirement.
A complex problem will have many stakeholders, often with conflicting needs. There may be separate interviews as described above, followed by analysis and review steps to resolve conflicts. This is to assure a balanced perspective, and to test whether, after negotiation and compromise, the specified requirements are still addressing everyones perceptions of the problem or opportunity. Also, the process is applied iteratively with asset planning (see Section 3.2) in a phased manner as understanding of the problem and planning of the solution is progressively elaborated.
These variations need to be kept in mind while considering the illustrated process and the process step discussions that follow.
Figure 3.1-1. Process Map for the Requirements Elicitation and Analysis
The following sections briefly describe the steps (i.e., sub-processes) in the requirements elicitation and analysis process.
.1 Plan for Requirements Elicitation and Analysis (and Asset Planning)
The requirements elicitation and analysis process is performed throughout the life cycle of an asset or project. Discrete or periodic efforts may occur as part of a regular capital or operating budgeting or asset management cycle. Requirements are also reconsidered regularly during change management, and prior to conducting a forensic performance assessment (Sections 6.2 and 6.4, respectively). In any case, the process requires that leadership for the assessment process be established. Process leadership, working with the client or sponsor (i.e., generally a business manager or management team for whoever is investing in and/or will own the asset), must first define the general nature and boundaries of the business problem that must be solved. These boundaries include the scope of the asset portfolio components affected (e.g., facilities, products, etc.) and where they fit in the business environment (i.e., the context). The process leadership must then select or develop appropriate methods and tools for the process. Because strategic asset planning processes (requirements elicitation and analysis, asset planning, and investment decision making) and methods (e.g., target costing, QFD, etc.) are generally integrated, planning for the process should address the effort as a continuum.
The process leadership then identifies and obtains the resources required to perform the study process (i.e., the feasibility study or product development team). The team then gathers or identifies sources of applicable information relative to the subject asset and context and appropriate to the methodology.
Basic inputs to requirements elicitation and analysis planning include the business strategy and objectives relative to the study scope. Enterprises generally have strategic planning and business modeling processes that help identify and frame market and other improvement opportunities. For existing assets, improvement opportunities are identified by the asset performance assessment process (Section 6.1), and the need for changes in requirements is identified in the asset change management process (Section 6.2).
Historical data regarding the performance of existing assets in relation to their requirements provide lessons as to past challenges and successful approaches (Section 6.3). However, changing organizations, business environments, and markets call for periodically refreshing requirements.
Finally, a key planning task is to identify stakeholders. It is their needs, wants, or expectations that are assessed by this process. Stakeholders are persons and organizations such as shareholders, customers, sponsors, performing organizations, and the public who may obtain, own, and/or use the asset as well as those whose interests may be otherwise affected by the existence or use the asset. They also include those who may be actively involved in associated projects, or whose interests may be affected by execution or completion of the projects. They may exert influence over the management and use of assets and/or the project and its deliverables.
.2 Elicit Requirements
As was defined earlier, some requirements may already be documented and imposed (e.g., existing standards or specifications) and these need to be identified. Other requirements must be drawn out of or elicited from the stakeholders. There are many techniques for eliciting requirements. The most basic methods include questionnaires, surveys, interviews, checklists, and group brainstorming sessions. As the business problems, systems, and requirements become more complex and uncertain, prototyping, modeling, and other techniques may be applied.
Individuals are often poor proxies for organizations, constituencies, or systems. Stakeholders may be difficult to identify and communicate with, their awareness and understanding of their needs is sometimes unclear or difficult to articulate, and their needs may differ depending on shifting conditions in the environment in which the enterprise exists. Other stakeholders may be inappropriately certain as to what the requirements and/or scope of the asset alternative are. Or their awareness and understanding of the requirements may be incomplete. These factors may require that a variety of elicitation techniques be used with the various stakeholders, and that modeling be used. Historical requirements elicitation and analysis information is also useful as it may identify requirements otherwise overlooked.
In QFD and other processes, technical performance metrics (i.e., performance constraints) are identified in this step. Competitive benchmarks (see Section 6.1) for performance metrics may also be identified for consideration in the analysis step.
Elicitation is an iterative process with asset planning (Section 3.2). All requirements are not elicited at once; requirements are progressively elaborated and become more detailed, moving from defining overall business requirements (e.g., translated from goals such as maximized return on investment) to functional requirements for components of an asset as its scope is elaborated in the asset planning process.
As was noted, elicited needs, wants, or expectations of the stakeholders are not requirements until they have been analyzed, validated, and documented. In many cases, various needs will conflict, will not be quantified, or otherwise will not yet form a basis for strategic asset management.
.3 Analyze Requirements
The goal of analysis is to take the generally unstructured input from the elicitation step and make it suitable as a basis for asset planning and performance assessment. Section 184.108.40.206 describes the characteristics of a good requirement for performance assessment. Analysis techniques may vary from an analyst simultaneously eliciting, analyzing and reviewing information and specifying requirements that address stakeholder needs on the spot, to a workshop held by a study team, to elaborate requirements modeling. Modeling can help describe or simulate the interaction of a system, its stakeholders, the enterprise, and the context within which they all exist. That context includes society, politics, the environment, and so on (see Chapter 11). The purpose of modeling is to ensure that all the requirements are identified and that their interaction and conflicts are identified over the course of the life cycle of the requirements application.
If target costing methodologies are being used, the identified "wants" of the market must be translated to a target price for the asset and subsequently to a cost requirement. For example, if the business problem (or opportunity) is a need for more electrical power, and the market price for power is a certain cost per kilowatt-hour, then any planned alternative solution must provide the power at some cost that allows for the desired investment rate of return. Methodologies that consider life cycle costs are generally preferred.
Regardless of whether costs are considered in requirements elicitation and analysis, effective requirements documentation should include the priorities or value placed on the requirements by the stakeholders. This information will be an important input to later asset planning and decision making. The QFD process specifically calls for requirements to be prioritized and rank ordered.
While requirements do not cover the "hows," which are specifically defined later in the asset planning process, it is not uncommon that ideas for asset solutions to the business problem begin to emerge during the requirements elicitation and analysis steps. These ideas and options should be captured for later consideration. At the end of the analysis step, the requirements are documented for review and communicated to the appropriate stakeholders who will participate in the review.
.4 Review Requirements
Requirements must be reviewed and tested to determine if they are:
Valid. The requirements accurately describe the need for a solution to a problem. For example, a productivity measurement shows that a manufacturing line is producing X units per hour less than planned. The plant manager concludes that there is a need is for a new training program because the equipment operators are incompetent, when in fact the need is to reduce the downtime of the equipment and there is no problem with operator skills.
Complete. The requirements address all needs. In the previous example, if there was really a need for both better training and less downtime and only one is addressed, then the problem will persist.
Consistent. The requirements are not contradictory.
Balanced. Requirements of all the stakeholders are fairly captured. When there are disagreements among stakeholders, they must be negotiated or otherwise resolved.
The review should also ensure that the requirements elicitation and analysis process is still working on the right business problem by considering any changes in the enterprises situation. This and other issues identified during the review may require recycling through the requirements elicitation and analysis process.
As with analysis, techniques may vary from an analyst simultaneously eliciting, analyzing, and reviewing information and specifying requirements that address stakeholder needs on the spot, to a workshop(s) held by a study team. Review and testing may use techniques such as intuition, checklists, models (see previous section), comparison to historical assessments, group reviews, and so on.
Negotiating conflicts usually involves prioritizing each stakeholders requirements and trying to include each stakeholders most important requirements, while compromising on those that are less important. When testing if requirements are valid, the performance measurements and assessments may need to be challenged (e.g., is the plant manager in the prior example effectively measuring operability and downtime).
.5 Document and Communicate Requirements
The final step of the requirements elicitation and analysis process is to document and communicate the validated requirements. The requirements documentation (often called a requirements statement or specification) identifies and characterizes the requirements as described in Section 220.127.116.11. The requirements are then communicated to those who will be responsible for asset planning (Section 3.2) and asset performance assessment (see Section 6.1) and are entered in a database as appropriate (Section 6.3).
In a project environment, to ensure that the asset planning team (e.g., feasibility study team, product development team, etc.) understands the requirements, kick-off or alignment meetings may be held at the start of requirements elicitation and analysis work and then again as asset planning begins. As was mentioned, the requirements elicitation and analysis and asset planning processes are iterative and are generally managed as an integrated process.
The requirements specification is a living deliverable that is a representation or notation of the requirements; not the requirement itself. The stakeholders change and, in a dynamic enterprise, market, and social environment, their needs and desires change constantly. The requirement specification is also likely to change as asset planning is progressively elaborated. In any case, as was mentioned, change must be managed through the asset change management process (Section 6.2).
3.1.3 Inputs to Requirements Elicitation and Analysis
.1 Stakeholder Input/Customer Requests. Stakeholder needs, wants, or expectations are elicited. A need is something that is required for the system to function; a want is a demand or motivation by the customer; a request is not necessarily a requirement.
.2 Imposed Requirement. Some requirements (typically constraints) are already documented and imposed on the system. These may be a matter of enterprise policy (e.g., decision policy in Section 3.3).
.3 Enterprise Business Strategy and Objectives. Business strategy and objectives are described in sufficient detail to provide a basis for strategic requirements elicitation and analysis and to support review (i.e., to ensure that objectives are achieved).
.4 Asset Basis Information. The scope of the asset portfolio components affected by the business problem (e.g., facilities, products, etc.) is described to provide a basis for strategic requirements elicitation and analysis.
.5 Asset Improvement Opportunities. Asset performance assessment (see Section 6.1) identifies problems and potential improvements to asset performance.
.6 Alternative Scope Development. Asset planning (see Section 3.2) progressively elaborates the scope of the asset alternative solutions for which requirements will need to be elaborated as well.
.7 Asset Change Information. Changes to or new problems with business and/or asset performance may require that requirements be reassessed and changed (see Section 6.2).
.8 Performance Benchmarks. Performance metrics for competitors (see Section 6.1) are sometimes considered requirements (i.e., potential constraints).
.9 Enterprise Context. The requirements are analyzed in part to determine if they address the needs of or interaction with society, politics, the environment, and so on (see Chapter 11).
.10 Historical Information. Historical information supports each step of the assessment process by providing lessons learned, examples, and so on from past approaches (see Section 6.3).
3.1.4 Outputs from Requirements Elicitation and Analysis
.1 Requirement Specification or Statement. (See Section 3.2.) The asset planning process progressively elaborates the scope of the asset solution for which requirements need to be elaborated and become more detailed.
.2 Basis for Strategic Performance Assessment. The requirements establish quantitative measures against which the performance of the asset portfolio can be assessed (see Section 6.1).
.3 Asset Change Information. The documented requirements establish a basis against which potential changes can be assessed (see Section 6.2).
.4 Historical Information. The documented requirements and other deliverables from the process are information captured in a database to support future requirements elicitation and analysis (see Section 6.3).
3.1.5 Key Concepts and Terminology for Requirements Elicitation and Analysis
The following concepts and terminology described in this chapter are particularly important to understanding the requirements elicitation and analysis process:
.1 Needs, wants, or expectations of stakeholders. (See Section 18.104.22.168).
.2 Requirements (including user vs. derived, functional vs. constraint, and performance). (See Section 22.214.171.124).
.3 Stakeholders/Customers. (See Sections 126.96.36.199 and 188.8.131.52).
.4 Balanced Scorecard. (See Section 184.108.40.206).
.5 Target Costing. (See Section 220.127.116.11).
.6 Requirements Statement or Specification. (See Section 18.104.22.168).
Further Readings and Sources
Requirements elicitation and analysis is a key concept in various practice areas such as systems engineering, requirements engineering, configuration management, quality management, and product development. Government acquisition and software engineering fields have been leading sources of development in practices. The following references provide basic information and will lead to more detailed treatments.
Burman, Deepak. "The Design to Cost (DTC) Approach to Product Development," AACE International Transactions. Morgantown, WV: AACE International, 1998.
Cokins, Gary. Performance Management (Finding the Missing Pieces to Close the Intelligence Gap). New York: John Wiley & Sons, 2005.
Nuseibeh, Bashar and Steve Easterbrook. "Requirements Engineering: A Roadmap," Proceedings of the International Conference on Software Engineering. New York: ACM Press, 2000.
Poortinga, Herman C. "From Business Opportunity to Cost Target," AACE International Transactions. Morgantown, WV: AACE International, 1999.
Project Management Institute. The Guide to the Project Management Body of Knowledge, 3rd ed. Upper Darby, PA: Project Management Institute, 2004.
Robertson, James and Suzanne Robertson. Mastering the Requirements Process, 2nd ed. New York: Addison-Wesley Professional, 2006.
Wollover, David R. "Quality Function Deployment as a Tool for Implementing Cost as an Independent Variable," Acquisition Review Journal. Defense Acquisition University, 1997.
[TOC] [PREVIOUS] [NEXT]
2008 By AACE® International www.aacei.org