Business Drivers and Requirements Specification
Achieving the right balance of documentation is often the most difficult part of any project. Too much documentation often wastes time, is not read by the stakeholders, or is poorly maintained as the project naturally evolves. Poor documentation leads to confusion in later stages. Our philosophy is to provide a minimalist approach to documentation. We will focus on the required elements and the process that leads to the creation of the document. These can be tailored to the needs of the organization.
The Business Drivers and Requirements Specification is the document that describes what the business is attempting to achieve. This specification becomes the guiding light of the project and will be used until the system is operational to assess the business impact. When the development team is provided this level of information, it helps them stay focused on the goals leading to a higher probability of success in the development phase. To see the full Business Drivers and Requirements Specification, please see Appendix A. Note that the brackets in the tables refer to specific information to be added to the table.
Introduction
The introduction should be a short executive overview of the specification. In addition, any special aspects of the project should be addressed, including the sponsoring organizations and business champion. A history of the initiative would be helpful as well. At the end of this section the reader should have an understanding of who, what, why, and how the business initiative and strategy evolved.
Scope
This section defines the scope of the Business Drivers and Requirements Specification, specifically whether it is enterprise wide, or for a specific business unit or business initiative.
Key Participants
All stakeholders in the requirements process should be identified, including business managers, the sponsoring organizations and business champions, and owner of the proposed initiative. The artifacts created in this process will be used by enterprise architects and developers to ensure technology solutions are aligned with business requirements.
Statement of Purpose
The statement of purpose is a succinct section used to communicate the business goals and functions of the initiative. It makes the business case for the initiative. It does not include implementation of the technology. One of the more important aspects to address is the impact to the organization once the initiative is complete. Large initiatives will have a major impact that will transcend the technology and affect how people work. Many projects have failed because the corporate culture was not ready for the change.
The business drivers should be a simple and clean statement of the problem. For example, bring cars to market quicker and more cost effectively than before. This section should only have one or two items. Each item should be classified according to the categories we discussed at the beginning of this chapter. If there are too many drivers then the initiative should be reconsidered. Is more than one initiative being addressed?
The business strategy should align with key strategic business initiatives, such as improving business efficiency through process improvement. The functional scope should define the business processes included in the initiative.
The business goals are used to measure and assess the achievement of the business initiative. Examples are reducing design and engineering time from 48 months to 18 months or reducing costs by 20%. These goals need to be realistic to be believed by the business stakeholders as well as the ITorganization. This section should outline the benefits to the organization in both subjective and objective terms of achieving the goals. Each of the goals and benefits can then have a value attached to them, whether they are financial, a competitive differentiator, or focused on customer satisfaction. This section makes the business case for the initiative. An extremely useful element of this section is a description or use case of how things will be different as a result of the initiative.
A statement of purpose should be completed for each proposed business initiative. Figure 2-1 (page30) is an example Statement of Purpose.
Cost Estimates
With the approach in hand, this section of the specification should list high-level costs and an estimated time frame. Costs at this point should be a rough order of magnitude and used for budgeting purposes and estimating ROI. It must be understood that these will be refined in the follow-on phase with the next level of detail. Figure 2-2 (page 31) is an example cost estimate.
Figure 2-2. High-Level Cost Estimates
ROI
This section documents the potential or expected ROI for the business initiative under consideration. Although cost estimates are still at the ballpark stage, it is critical to do an ROI analysis based upon the benefits, cost, and organizational impact.
You can use the template shown in Figure 2-3 (page 32) to guide your assessment of an ROI for any initiative. If the ROI is low, it may be necessary to get a better handle on the costs and the organization might only give a provisional approval to proceed until costs and impacts can be refined.
Figure 2-3. ROI Analysis Template
Metrics
The metrics for success refine the business goals into measurable key performance indicators (KPIs). In some cases, the business goals may be of sufficient detail to translate directly into KPIs. Metrics should be defined by business goals. For each goal there can be more than one metric. In addition to the value of the metric, it should include details on how to collect, frequency of collection, and owner, as shown in Figure 2-4 (page 33).
Figure 2-4. Metrics
Risks
A risk analysis should be conducted that defines the known areas where there are significant lack of detailed information; difficult issues such as organizational, cultural, technical, or management challenges; and ability to achieve the desired business result.
The risks are a collection of everything that can or may go wrong. The risk analysis may also include a list of assumptions that may be wrong or need further information to be validated. Each risk should be associated with a plan to mitigate the risk and the owner of the risk. Figure 2-5 (page 33) is an example of a risk analysis table.
Figure 2-5. Risks
Conclusions and Commentary
This section should provide any final comments on requirements. It should include any known constraints or other business factors that could affect architecture, design, and implementation.
The Business Drivers and Requirements Specification becomes the guiding light of the project. When the development team is provided this level of information, it helps them to stay focused on the goals, leading to a higher probability of success in the development phase.
Best Practices
Ensure that all enterprise integration efforts are closely aligned with business goals and objectives
Involve IT in strategic business planning
Appoint business project managers for all IT projects
Create business metrics to measure success of IT projects
Revisit business goals and objectives throughout the integration life cycle
Next Steps
At this juncture the process can differ for strategic and tactical projects, as shown in Figure 2-6. You must define the integration strategy and technology to use on the tactical projects, but it is far better if the recommendation comes from the Enterprise Integration Strategy and Architecture Plan. This ensures that the solution fits into the overall infrastructure and enables agility and reuse on follow-on projects. Having an Enterprise Strategy and Architecture Plan in place is critical to having a long-term supportable environment.
Figure 2-6. Integration Road Map
It is especially important to understand how a tactical solution fits into the overall enterprise architecture. For example, enterprises looking to maximize agility and implement real-time processes may view each tactical implementation as a building block in the overall architecture. Rather than take the fastest and most economical path to integration, they may decide to invest in creating reusable business services. Even if the implementation has little bearing on the overall enterprise architecture, it is still important to ensure that enterprise standards are met.
Introduction
The introduction should be a short executive overview of the specification. In addition, any special aspects of the project should be addressed, including the sponsoring organizations and business champion. A history of the initiative would be helpful as well. At the end of this section the reader should have an understanding of who, what, why, and how the business initiative and strategy evolved.
Scope
This section defines the scope of the Business Drivers and Requirements Specification, specifically whether it is enterprise wide, or for a specific business unit or business initiative.
Key Participants
All stakeholders in the requirements process should be identified, including business managers, the sponsoring organizations and business champions, and owner of the proposed initiative. The artifacts created in this process will be used by enterprise architects and developers to ensure technology solutions are aligned with business requirements.
Statement of Purpose
The statement of purpose is a succinct section used to communicate the business goals and functions of the initiative. It makes the business case for the initiative. It does not include implementation of the technology. One of the more important aspects to address is the impact to the organization once the initiative is complete. Large initiatives will have a major impact that will transcend the technology and affect how people work. Many projects have failed because the corporate culture was not ready for the change.
The business drivers should be a simple and clean statement of the problem. For example, bring cars to market quicker and more cost effectively than before. This section should only have one or two items. Each item should be classified according to the categories we discussed at the beginning of this chapter. If there are too many drivers then the initiative should be reconsidered. Is more than one initiative being addressed?
The business strategy should align with key strategic business initiatives, such as improving business efficiency through process improvement. The functional scope should define the business processes included in the initiative.
The business goals are used to measure and assess the achievement of the business initiative. Examples are reducing design and engineering time from 48 months to 18 months or reducing costs by 20%. These goals need to be realistic to be believed by the business stakeholders as well as the ITorganization. This section should outline the benefits to the organization in both subjective and objective terms of achieving the goals. Each of the goals and benefits can then have a value attached to them, whether they are financial, a competitive differentiator, or focused on customer satisfaction. This section makes the business case for the initiative. An extremely useful element of this section is a description or use case of how things will be different as a result of the initiative.
A statement of purpose should be completed for each proposed business initiative. Figure 2-1 (page30) is an example Statement of Purpose.
Figure 2-1. Statement of Purpose
Cost Estimates
With the approach in hand, this section of the specification should list high-level costs and an estimated time frame. Costs at this point should be a rough order of magnitude and used for budgeting purposes and estimating ROI. It must be understood that these will be refined in the follow-on phase with the next level of detail. Figure 2-2 (page 31) is an example cost estimate.
Figure 2-2. High-Level Cost Estimates
ROI
This section documents the potential or expected ROI for the business initiative under consideration. Although cost estimates are still at the ballpark stage, it is critical to do an ROI analysis based upon the benefits, cost, and organizational impact.
You can use the template shown in Figure 2-3 (page 32) to guide your assessment of an ROI for any initiative. If the ROI is low, it may be necessary to get a better handle on the costs and the organization might only give a provisional approval to proceed until costs and impacts can be refined.
Figure 2-3. ROI Analysis Template
Metrics
The metrics for success refine the business goals into measurable key performance indicators (KPIs). In some cases, the business goals may be of sufficient detail to translate directly into KPIs. Metrics should be defined by business goals. For each goal there can be more than one metric. In addition to the value of the metric, it should include details on how to collect, frequency of collection, and owner, as shown in Figure 2-4 (page 33).
Figure 2-4. Metrics
Risks
A risk analysis should be conducted that defines the known areas where there are significant lack of detailed information; difficult issues such as organizational, cultural, technical, or management challenges; and ability to achieve the desired business result.
The risks are a collection of everything that can or may go wrong. The risk analysis may also include a list of assumptions that may be wrong or need further information to be validated. Each risk should be associated with a plan to mitigate the risk and the owner of the risk. Figure 2-5 (page 33) is an example of a risk analysis table.
Figure 2-5. Risks
Conclusions and Commentary
This section should provide any final comments on requirements. It should include any known constraints or other business factors that could affect architecture, design, and implementation.
The Business Drivers and Requirements Specification becomes the guiding light of the project. When the development team is provided this level of information, it helps them to stay focused on the goals, leading to a higher probability of success in the development phase.
Best Practices
Ensure that all enterprise integration efforts are closely aligned with business goals and objectives
Involve IT in strategic business planning
Appoint business project managers for all IT projects
Create business metrics to measure success of IT projects
Revisit business goals and objectives throughout the integration life cycle
Next Steps
At this juncture the process can differ for strategic and tactical projects, as shown in Figure 2-6. You must define the integration strategy and technology to use on the tactical projects, but it is far better if the recommendation comes from the Enterprise Integration Strategy and Architecture Plan. This ensures that the solution fits into the overall infrastructure and enables agility and reuse on follow-on projects. Having an Enterprise Strategy and Architecture Plan in place is critical to having a long-term supportable environment.
Figure 2-6. Integration Road Map
It is especially important to understand how a tactical solution fits into the overall enterprise architecture. For example, enterprises looking to maximize agility and implement real-time processes may view each tactical implementation as a building block in the overall architecture. Rather than take the fastest and most economical path to integration, they may decide to invest in creating reusable business services. Even if the implementation has little bearing on the overall enterprise architecture, it is still important to ensure that enterprise standards are met.
Introduction
The introduction should be a short executive overview of the specification. In addition, any special aspects of the project should be addressed, including the sponsoring organizations and business champion. A history of the initiative would be helpful as well. At the end of this section the reader should have an understanding of who, what, why, and how the business initiative and strategy evolved.
Scope
This section defines the scope of the Business Drivers and Requirements Specification, specifically whether it is enterprise wide, or for a specific business unit or business initiative.
Key Participants
All stakeholders in the requirements process should be identified, including business managers, the sponsoring organizations and business champions, and owner of the proposed initiative. The artifacts created in this process will be used by enterprise architects and developers to ensure technology solutions are aligned with business requirements.
Statement of Purpose
The statement of purpose is a succinct section used to communicate the business goals and functions of the initiative. It makes the business case for the initiative. It does not include implementation of the technology. One of the more important aspects to address is the impact to the organization once the initiative is complete. Large initiatives will have a major impact that will transcend the technology and affect how people work. Many projects have failed because the corporate culture was not ready for the change.
The business drivers should be a simple and clean statement of the problem. For example, bring cars to market quicker and more cost effectively than before. This section should only have one or two items. Each item should be classified according to the categories we discussed at the beginning of this chapter. If there are too many drivers then the initiative should be reconsidered. Is more than one initiative being addressed?
The business strategy should align with key strategic business initiatives, such as improving business efficiency through process improvement. The functional scope should define the business processes included in the initiative.
The business goals are used to measure and assess the achievement of the business initiative. Examples are reducing design and engineering time from 48 months to 18 months or reducing costs by 20%. These goals need to be realistic to be believed by the business stakeholders as well as the ITorganization. This section should outline the benefits to the organization in both subjective and objective terms of achieving the goals. Each of the goals and benefits can then have a value attached to them, whether they are financial, a competitive differentiator, or focused on customer satisfaction. This section makes the business case for the initiative. An extremely useful element of this section is a description or use case of how things will be different as a result of the initiative.
A statement of purpose should be completed for each proposed business initiative. Figure 2-1 (page30) is an example Statement of Purpose.
Cost Estimates
With the approach in hand, this section of the specification should list high-level costs and an estimated time frame. Costs at this point should be a rough order of magnitude and used for budgeting purposes and estimating ROI. It must be understood that these will be refined in the follow-on phase with the next level of detail. Figure 2-2 (page 31) is an example cost estimate.
Figure 2-2. High-Level Cost Estimates
ROI
This section documents the potential or expected ROI for the business initiative under consideration. Although cost estimates are still at the ballpark stage, it is critical to do an ROI analysis based upon the benefits, cost, and organizational impact.
You can use the template shown in Figure 2-3 (page 32) to guide your assessment of an ROI for any initiative. If the ROI is low, it may be necessary to get a better handle on the costs and the organization might only give a provisional approval to proceed until costs and impacts can be refined.
Figure 2-3. ROI Analysis Template
Metrics
The metrics for success refine the business goals into measurable key performance indicators (KPIs). In some cases, the business goals may be of sufficient detail to translate directly into KPIs. Metrics should be defined by business goals. For each goal there can be more than one metric. In addition to the value of the metric, it should include details on how to collect, frequency of collection, and owner, as shown in Figure 2-4 (page 33).
Figure 2-4. Metrics
Risks
A risk analysis should be conducted that defines the known areas where there are significant lack of detailed information; difficult issues such as organizational, cultural, technical, or management challenges; and ability to achieve the desired business result.
The risks are a collection of everything that can or may go wrong. The risk analysis may also include a list of assumptions that may be wrong or need further information to be validated. Each risk should be associated with a plan to mitigate the risk and the owner of the risk. Figure 2-5 (page 33) is an example of a risk analysis table.
Figure 2-5. Risks
Conclusions and Commentary
This section should provide any final comments on requirements. It should include any known constraints or other business factors that could affect architecture, design, and implementation.
The Business Drivers and Requirements Specification becomes the guiding light of the project. When the development team is provided this level of information, it helps them to stay focused on the goals, leading to a higher probability of success in the development phase.
Best Practices
Ensure that all enterprise integration efforts are closely aligned with business goals and objectives
Involve IT in strategic business planning
Appoint business project managers for all IT projects
Create business metrics to measure success of IT projects
Revisit business goals and objectives throughout the integration life cycle
Next Steps
At this juncture the process can differ for strategic and tactical projects, as shown in Figure 2-6. You must define the integration strategy and technology to use on the tactical projects, but it is far better if the recommendation comes from the Enterprise Integration Strategy and Architecture Plan. This ensures that the solution fits into the overall infrastructure and enables agility and reuse on follow-on projects. Having an Enterprise Strategy and Architecture Plan in place is critical to having a long-term supportable environment.
Figure 2-6. Integration Road Map
It is especially important to understand how a tactical solution fits into the overall enterprise architecture. For example, enterprises looking to maximize agility and implement real-time processes may view each tactical implementation as a building block in the overall architecture. Rather than take the fastest and most economical path to integration, they may decide to invest in creating reusable business services. Even if the implementation has little bearing on the overall enterprise architecture, it is still important to ensure that enterprise standards are met.
Introduction
The introduction should be a short executive overview of the specification. In addition, any special aspects of the project should be addressed, including the sponsoring organizations and business champion. A history of the initiative would be helpful as well. At the end of this section the reader should have an understanding of who, what, why, and how the business initiative and strategy evolved.
Scope
This section defines the scope of the Business Drivers and Requirements Specification, specifically whether it is enterprise wide, or for a specific business unit or business initiative.
Key Participants
All stakeholders in the requirements process should be identified, including business managers, the sponsoring organizations and business champions, and owner of the proposed initiative. The artifacts created in this process will be used by enterprise architects and developers to ensure technology solutions are aligned with business requirements.
Statement of Purpose
The statement of purpose is a succinct section used to communicate the business goals and functions of the initiative. It makes the business case for the initiative. It does not include implementation of the technology. One of the more important aspects to address is the impact to the organization once the initiative is complete. Large initiatives will have a major impact that will transcend the technology and affect how people work. Many projects have failed because the corporate culture was not ready for the change.
The business drivers should be a simple and clean statement of the problem. For example, bring cars to market quicker and more cost effectively than before. This section should only have one or two items. Each item should be classified according to the categories we discussed at the beginning of this chapter. If there are too many drivers then the initiative should be reconsidered. Is more than one initiative being addressed?
The business strategy should align with key strategic business initiatives, such as improving business efficiency through process improvement. The functional scope should define the business processes included in the initiative.
The business goals are used to measure and assess the achievement of the business initiative. Examples are reducing design and engineering time from 48 months to 18 months or reducing costs by 20%. These goals need to be realistic to be believed by the business stakeholders as well as the ITorganization. This section should outline the benefits to the organization in both subjective and objective terms of achieving the goals. Each of the goals and benefits can then have a value attached to them, whether they are financial, a competitive differentiator, or focused on customer satisfaction. This section makes the business case for the initiative. An extremely useful element of this section is a description or use case of how things will be different as a result of the initiative.
A statement of purpose should be completed for each proposed business initiative. Figure 2-1 (page30) is an example Statement of Purpose.
Figure 2-1. Statement of Purpose
Cost Estimates
With the approach in hand, this section of the specification should list high-level costs and an estimated time frame. Costs at this point should be a rough order of magnitude and used for budgeting purposes and estimating ROI. It must be understood that these will be refined in the follow-on phase with the next level of detail. Figure 2-2 (page 31) is an example cost estimate.
Figure 2-2. High-Level Cost Estimates
ROI
This section documents the potential or expected ROI for the business initiative under consideration. Although cost estimates are still at the ballpark stage, it is critical to do an ROI analysis based upon the benefits, cost, and organizational impact.
You can use the template shown in Figure 2-3 (page 32) to guide your assessment of an ROI for any initiative. If the ROI is low, it may be necessary to get a better handle on the costs and the organization might only give a provisional approval to proceed until costs and impacts can be refined.
Figure 2-3. ROI Analysis Template
Metrics
The metrics for success refine the business goals into measurable key performance indicators (KPIs). In some cases, the business goals may be of sufficient detail to translate directly into KPIs. Metrics should be defined by business goals. For each goal there can be more than one metric. In addition to the value of the metric, it should include details on how to collect, frequency of collection, and owner, as shown in Figure 2-4 (page 33).
Figure 2-4. Metrics
Risks
A risk analysis should be conducted that defines the known areas where there are significant lack of detailed information; difficult issues such as organizational, cultural, technical, or management challenges; and ability to achieve the desired business result.
The risks are a collection of everything that can or may go wrong. The risk analysis may also include a list of assumptions that may be wrong or need further information to be validated. Each risk should be associated with a plan to mitigate the risk and the owner of the risk. Figure 2-5 (page 33) is an example of a risk analysis table.
Figure 2-5. Risks
Conclusions and Commentary
This section should provide any final comments on requirements. It should include any known constraints or other business factors that could affect architecture, design, and implementation.
The Business Drivers and Requirements Specification becomes the guiding light of the project. When the development team is provided this level of information, it helps them to stay focused on the goals, leading to a higher probability of success in the development phase.
Best Practices
Ensure that all enterprise integration efforts are closely aligned with business goals and objectives
Involve IT in strategic business planning
Appoint business project managers for all IT projects
Create business metrics to measure success of IT projects
Revisit business goals and objectives throughout the integration life cycle
Next Steps
At this juncture the process can differ for strategic and tactical projects, as shown in Figure 2-6. You must define the integration strategy and technology to use on the tactical projects, but it is far better if the recommendation comes from the Enterprise Integration Strategy and Architecture Plan. This ensures that the solution fits into the overall infrastructure and enables agility and reuse on follow-on projects. Having an Enterprise Strategy and Architecture Plan in place is critical to having a long-term supportable environment.
Figure 2-6. Integration Road Map
It is especially important to understand how a tactical solution fits into the overall enterprise architecture. For example, enterprises looking to maximize agility and implement real-time processes may view each tactical implementation as a building block in the overall architecture. Rather than take the fastest and most economical path to integration, they may decide to invest in creating reusable business services. Even if the implementation has little bearing on the overall enterprise architecture, it is still important to ensure that enterprise standards are met.
0 comments