From MIKE2 Methodology
Activity: Information Management Roadmap Overview
Objective
The Information Management Roadmap Overview activity is a key aspect of the incremental development model. In this model the delivery of the information management environment is seen as a series of short projects, which may be referred to as "cycles", "releases”, “increments” or “projects”. Each major release is defined by a Roadmap.
Each release results in an output which advances the targeted architecture towards its goals in a concrete way. The incremental model can be contrasted with the waterfall model used to deploy operational systems, in which the system is seen as a monolith which is either finished or not. In the waterfall model, the analysis phase must meet strict criteria for completion before design begins. A consequence is that the user receives no functionality at all until the entire system is completed
The output of most releases should be something that is delivered directly to the customers or ultimate users of the system. Even an infrastructure-focused release should try and deliver some level of business functionality; else the level of interest from key users and sponsors quickly wanes.
The output of this activity provides detailed description of the increment for the overall programme. The fundamental strength of the incremental method is that it allows for mid-course corrections - at the end of each cycle it is even possible to rethink the whole plan (although the general approach is not deviate much from the Blueprint vision). The only cycle which has to be clearly and correctly defined is the one that starts tomorrow. Nevertheless, the Roadmap plan helps to maintain connectivity with the overall vision and the current cycle.
At the end of the Roadmap phase and periodically through the programme, the Blueprint should be checked and updated with any changes from the Roadmap and implementation phases. This would include changes in technology, timelines and release cycle functionality.
Major Deliverables
Project Roadmap, including:
- Summary of Overall Release Functionality
- Project Risks
- Project Design and Infrastructure Dependencies
- Acceptance Procedures
- Project Plan
Tasks
Define Overall Release Functionality
Objective:
This task defines the goals of the next cycle or increment of development. If the cycle will not result in delivery of partial system functionality to the users, then this task involves precise definition of the objectives of the cycle, and how these objectives contribute to overall project goals. 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:
- Business and Technology 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
- Testing Strategy
- Overall Blueprint Architecture
Output:
Identify and Prioritise 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 MIKE2.0 Supporting Assets, lessons learned from previous projects and it is advised to run a Risk Identification Workshop with the entire project team.
Prioritising 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 developers undergo training.
- Have a third party specialising in this technology review high level designs before coding starts.
- Prototype first two function points before the remainder of the code is developed.
Input:
Output:
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. This means that there will be development cycles whose purpose is to deal with risk issues.
Identify Infrastructure Dependencies
Objective:
On a service by service basis, identify the infrastructure needed in order to deliver the proposed functionality.
It is common to require that the infrastructure be working, at least in the sense of a beta release, before work begins on an application which assumes that infrastructure. On the other hand, it is often possible to simulate or otherwise stub off some infrastructure capabilities, and develop the actual infrastructure in parallel with project work. The deciding factor here is the degree of risk associated with the infrastructure in question. If the infrastructure project involves significant risks, then those risks should be resolved before application work begins. On the other hand, if project leaders are confident that the infrastructure can be built, then it may be appropriate to begin development of the system before the required infrastructure is in place.
Input:
- Business and Technology Blueprint, focused detailed referring to:
- Technology Blueprint Architecture
- Business and Technology Capability Deployment Timeline
- Roadmap Mission Statement and Summary
- Testing Strategy
- Technical Risks & Constraints
Output:
Identify Design Dependencies
Objective:
Software 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:
Output:
Define Acceptance Procedures
Objective:
The acceptance procedures define who will be responsible for evaluating the results of the work, and the acceptance criteria. If the product of this release is going to be delivered to users, release issues such as distribution and training should be addressed before the system goes live. This task begins to establish the requirements for acceptance.
Input:
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 MIKE2.0 plan as a baseline and add the required detail as needed
Input:
Output:
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:
Output:
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
BlogMarks
del.icio.us
digg
Furl
Simpy
smarking
