All that project management talk recently had a purpose.
Phase F – Migration Planning in TOGAF is when you finalize your plans.
Don’t forget the environment. Even if all of the risk, cost and time estimates argue for one direction – you may still be forced to go in an alternate direction because….emotions. Mostly fear. Especially when you are arguing to consolidate and get rid of things. Because – without those things…what are they going to do? Have you inadvertently diminished that stakeholder’s importance? Reduced his/her power? Scary stuff.
At the end of all of this will be a final target architecture for your Learning Ecosystem. We hope.
Phase F has a few steps.
- Making sure your plans align with any management frameworks within the organization.
- Are you (still) aligned with your organization’s business strategy and desired outcomes? This should be a consideration throughout ALL of these processes. More easily said than done at times – especially when there is misalignment between what the organization says it wants and what is actually happening.
- Are you aligned with the Enterprise Architecture for your organization? Real important if you are expecting IT support. No alignment = no help when you get into trouble.
- Are you aligned with the Portfolio, Program and Project Management frameworks? This will help you get this stuff done.
- Are you aligned with Operations? This will help you run the thing when it is finished.
- I am also going to add – are you aligned with DevOps (development to operations, or the bridge between when something completes as a project and when it becomes something you operate)? If your organization HAS DevOps.
- I have found over the years that most implementations struggle and/or fail because project teams are so focused on finishing the product that they neglect to consider pesky things like training and support until the last minute (usually after they have pushed training off and they are 1 week out from go-live and realize that real people actually have to use the thing. Then the support teams find out about it after the first angry end user calls….)
- Assign a business value to each work package.
- I’ll go into business value in a later post, but fundamentally you are looking at:
- Performance evaluation criteria (ie – what are the uptime / downtime expectations, speed between screens, etc)
- Return on investment criteria (you should have some of this from your cost numbers crunching)
- Business value
- Critical success factors (this should have been defined in your Architecture Vision)
- Measure of effectiveness (is it doing what you think it should do?)
- Strategic fit (with the greater business and with the target architecture)
- Refine your estimates for resource requirements, project timing and delivery vehicles
- This is essentially the planning estimates for each project you will need to perform as you move from your baseline to your target architecture.
- As you initiate each project, these planning estimates go into the Initiating and Planning process for that project.
- Confirm your architecture roadmap and update your architecture definition document
- Include any transition architecture and how long you anticipate that transition architecture to be in place.
- Generate the implementation and migration plan.
- Include the following:
- All projects, activities and dependencies – internal and external to your architecture. Basically – anything that might impact your learning environment.
- The impact of the change. Make sure you address any potential negative impacts to areas outside of your learning architecture.
- The timing of any resource availability needs. I would also make sure to include any necessary skills required here. This should allow some time for any necessary upskilling OR external sourcing.
- Complete and finalize your architecture documents (or the ADM) and document lessons learned from this cycle.
- Make sure you get any necessary formal signatures and approvals. Especially important in more formalized or politicized organizational cultures.
At the end of all of this, you should have:
- An implementation and migration plan
- A project and portfolio breakdown of the implementation
- Project Charters – to launch the projects
- Finalized architecture documents – including
- The Architecture Definition document
- Architecture Roadmap
- Transition and Final Target architectures
- Architecture Requirements Specification
- Reuseable architecture building blocks
- Any implementation governance models – especially for formal cultures
- Change requests for the architecture capability as a result of the lessons learned.
There might be a request for a completely new iteration of the whole cycle and a redo of the architecture work.
Technologies change, business needs change, environments change. Often faster than you can implement your first target and faster than you can go through this cycle the first time.
As you have seen over the past year or so from my postings (and the fact that I have written a lot of this out of order) – this often isn’t a tidy process.