|
Wiki Home
Members
To join, please contact us. Improve MIKE 2.0
Need somewhere to start? How about the most wanted pages; or the pages we know need more work; or even the stub that somebody else has started, but hasn't been able to finish. Or create a ticket for any issues you have found.
|
The 5 Phases of MIKE2From MIKE2.0 Methodology -> You are here: MIKE2.0 Case Studies > The History of MIKE2.0 > Business Solution Offerings > Master Data Management Solution Offering > The 5 Phases of MIKE2
In order to realize results more quickly, the MIKE2.0 Methodology has abandoned the traditional linear or waterfall approach to systems development. In its stead, MIKE2.0 has adopted an iterative, agile approach called continuous implementation. This approach divides the development and rollout of anentire system into a series of implementation cycles. These cycles identify and prioritize the portions of the system that can be constructed and rolled out before the entire system is complete. Each cycle also includes
Following this approach, there are five phases to the MIKE2.0 Methodology:
These phases are described in detail (along with underlying activities in tasks) in the Overall Task List of the Overall Implementation Guide.
The Strategic BlueprintPhase 1 and Phase 2 make up what is called the Blueprint. The Blueprint is comprised of two elements. First, it's a relatively high-level vision for developing the envisaged future-state. Beyond that, it's a model that defines the prioritised transitions to get there. The Blueprint includes the following key pieces:
The established IT Principles and business priorities will drive the Blueprint's ultimate solution. Much of the focus of this phase of work is on the Business Strategy and Technology Architecture Once completed, the Blueprint can be seen as relatively static representation of the current-state and future-state with identified intermediate states. Early on, the future-state is a "vision" that is not strictly defined. However, it consists of generally agreed-to "themes" to which all participants will adhere. Strategic technology vendor decisions are also made during the Blueprint phase. Roadmap and Foundation ActivitiesPhase 3 (the Roadmap) is derived from the Blueprint. Phase 3 represents a translation of the Blueprint into a dynamic representation of ‘what it takes’ to actually do the implementation. What's more, it is the first phase in the continuous implementation approach explained below. The Phase 3 Roadmap is critical: it links the relatively static definition of the vision in the Blueprint with the diffferent implementation phases. This ultimately defines overall strategic programme. The end result of Phase 3 is several tactical implementations. The Roadmap will contain content not represented directly in the Blueprint--i.e., certain parts may not be able to be implemented immediately. Ultimately, the Roadmap is completed by what are called Foundation Activities. These activities cover areas such as preparing the infrastructure environment, modelling information, prototyping, taking a detailed look at the data and, in some cases, addressing data quality issues. The Blueprint and RoadmapThe Blueprint/Roadmap approach is one the key differentiators to the MIKE2.0 methodology. To be sure, it is common for organisations to embark on an "IT Blueprint" to establish a vision of their information management environment. However, what this really means is often less than clear, a frustrating situation for all involved. Just the term ’Blueprint’ can be confusing and connote different meanings. As a result, the IT Strategy Blueprint/Roadmap often leads to different disappointment as a result of being:
The MIKE2.0 approach gives detailed structure and definition to what will be produced in the Blueprint and Roadmap. It focuses on:
Remember that Phase 1 and Phase 2 are called "the Blueprint" and Phase 3 is called the "Roadmap." It is important to understand, however, that the Blueprint and Roadmap are also specific deliverables in the form of summarised versions of all detailed working papers for each phase. The rationale behind the summary Blueprint and Roadmap is one of Continuous Communication and feedback with the client. These summary documents provide a single point of reference for the long-running programme to which clients can always refer. Doing so allows them to understand the current state of the project in relation to the strategic objectives of the programme. Continuous feedback complements the continuous implementation delivery approach during the build, testing, and deployment phases. Although there are many deliverables in Phase 3, the summary documents consist of the content that will be reviewed by senior project sponsors. These documents should always be kept updated. Ideally, they are completed in a form easily presented. Part and parcel of this approach is that it is tied directly to the following:
The approach has been tweaked over time to focus on the areas of greatest risk and highest business value that have been seen on other programmes. This is referred to as XBR (eXtreme Blueprinting and Roadmapping). XBR comes with a starter kit of assets. Incremental Development, Testing, Deployment and ImprovementPhases 4 and 5 are focused on the detailed design, development, and deployment of software. Collectively, these include:
This Continuous Implementation (CI) concept is central to the IM implementation approach. CI provides an opportunity to divide the project team into groups organized by implementation activity, specializing on a specific implementation role. As the implementation iterates through the cycles, the processes and skills of each team are refined. In this sense, CI enables each team to improve quality and reduce cycle time, key measures for sure. Perhaps most important, implementation activities also provide a mechanism for establishing a continuous system enhancement and feedback process for the client when the initial implementation team is no longer involved in the project. If performed properly, IM environments are never "complete." Each cycle includes a feedback step to evaluate and prioritize the implementation results, strategy changes, and improvement requests on the future implementation cycles. Governance and Operating ModelTo be sure, IM projects cannot be viewed in a vacuum. At a minimum, the successful adoption of new technologies and methods should:
CI takes place after the system is live, as it focused on enhancing the existing solution to improve quality, capability and efficiency. Most of the implementation changes, however, are not technology-based. They are focused on improving IM practices, compliance levels, policies and measurement across the program. Ideally, they are concentrate on building a culture of IM excellence. Major aspects include:
The initial discovery of these issues is conducted in the Business Assessment phase, using tools such as IM QuickScan and through the documentation of the current-state information processes. Activities such as Data Profiling help to quantitatively identify the major data quality issues. The deliverables that support the Governance & Operating Model will vary considerably based on the scope of this phase. |
Wiki asset search
Toolbox
Views
Wiki Contributors
|

