From Open Sustainability
| Overall Content Model
|
| Where Activities Reside
|
|
|
Activity: Business unit assessment – project level
Objective
The Business unit assessment activity is a key aspect of the project level work. After defining the Sustainability Blueprint which is at a high level, we move on to the Sustainability Roadmap which maps out how the goals and objectives will be achieved.
At the end of the Roadmap phase and periodically through the program, the Blueprint should be checked and updated with any changes from the Roadmap and implementation phases.
Major Deliverables
Project Roadmap, including:
- Project Timeline
- Project Risks
- Project Design and Infrastructure Dependencies
- Acceptance Procedures
- Project Plan
Tasks
Define Project Timeline
Objective:
This task effectively defines the high level requirements for this particular project, revising the work that was done in Phases 1 and 2 to a more specific level of detail.
Input:
- Solutions Blueprint, focused on use of:
- Strategic Functional Requirements for Business Intelligence
- Strategic Functional Requirements for Technology Backplane
- Strategic Non-Functional Requirements
- Business and Technology Capability Deployment Timeline
- Roadmap Mission Statement and Summary
- Technical Risks & Constraints
- Overall Blueprint Architecture
Output:
- Overall Release Functionality
Identify and Prioritize Project Risks
Objective:
Project Risk Management is the discipline of understanding what might go wrong and taking appropriate actions to prevent it occurring. A Project Risk is different to a Project Issue in that a risk has a likelihood of occurring and often mitigation actions can be put in place to minimise or remove the risk. An issue is either a risk that has actually occurred or some unforeseen circumstance that has arisen that needs to be addressed. Issue management is dealing with a problem after it occurs. Risk Management seeks to prevent it occurring in the first place. Therefore having a good understanding of what might go wrong (risks) and putting together an appropriate risk minimisation strategy can prevent issues arising and help keep a project on schedule, budget and of the quality expected.
There several mechanisms to identify project risks. There is a list of common risks in the, lessons learned from previous projects and it is advised to run a Risk Identification Workshop with the entire project team.
Prioritizing the risk is based on a two axis evaluation – that is likelihood of occurrence and impact if it occurs. Highly likely, severe impact risks are the highest priority through a logical progression to unlikely, low impact risks being the least important.
Having determined the risks and their importance it is time to assign a risk mitigation strategy to each of them and actively work to lessen both the likelihood and impact of those risks.
A typical risk might look like this:
A typical risk might look like this:
- Risk Description
- There is a risk to schedule and quality as developers are unfamiliar with proposed technology for the project
- Likelihood
- Medium
- Severity
- Severe
- Mitigation Plan
- Have two key practitioners undergo training.
- Have a third party specializing in the issue review high level designs before project starts.
Input:
- Business and Technology Blueprint
- Roadmap Mission Statement and Summary
- Overall Release Functionality
Output:
- Technical Risks & Constraints
- Risk Management Plan
The simplest type of risk management plan is a "top-10 risks list. " This is the prioritized list of risks, and "the plan" consists of making sure everyone pays attention to it. The more formal approach to risk management is to factor it into the project schedule explicitly.
Identify Design Dependencies
Objective:
Technology components which are dependent on others will normally be implemented later, so in order to create the project plan, it is useful to dependencies between components. The output from this task will be a dependency model showing which software components and subsystems will call upon services from which others.
Input:
- Business and Technology Blueprint, focused on:
- Technology Blueprint Architecture
- Business and Technology Capability Deployment Timeline
- Roadmap Mission Statement and Summary
- Overall Release Functionality
- Technical Risks & Constraints
- Risk Management Plan
- Infrastructure Dependencies
Output:
Define Detailed Project Plan
Objective:
Given the output of the previous tasks, planning involves specifying the resources that will be devoted to the task, the timeline, the risks and the risk management plan, the deliverables, and the acceptance procedure. The detailed plan can use the FISDev plan as a baseline and add the required detail as needed
Input:
- Business and Technology Blueprint
- Overall Release Functionality
- Technical Risks & Constraints
- Risk Management Plan
- Infrastructure Dependencies
- Design Dependencies
- Acceptance Procedures
Output:
- Detailed Project Plan for this release
Assemble Key Messages to Complete Roadmap
Objective:
The purpose of this task is to bring together the overall messages for the Roadmap into a summary deliverable. This is used for communications throughout the continuous implementation phases. This document is more dynamic than a Blueprint as it provides a summary view of status as well as the planned approach.
Input:
- Summary view on status on all key deliverables
- Particular focus on:
- Overall Release Functionality
- Technical Risks & Constraints
- Risk Management Plan
- Infrastructure Dependencies
- Design Dependencies
- Project Plan and status
Output:
- Roadmap for a specific increment
Core Supporting Assets
Yellow Flags
- Major changes in increment scope from Strategic Blueprint
- Failures or serious delays in implementing previous increments of Blueprint
- Identification of a high number of dependencies or risks
- Project planning issues such as resource gaps or overloading
Key Resource Requirements
