With the materials in the preceding three posts, we are in position to create the inputs for a plan; but with a number of caveats. First of all, the tasks listed might not all be relevant to the organization, so this plan is available for editing. Second, the time estimation will vary according to tool and scope. Last of all, what has not be considered so far, but is the final piece of the puzzle, is who needs to be involved in each of the activities – we consider this in the final post.
Summary: We’ve now examined what tasks are involved in rolling out a tool; what drives their size and how you might want to restrict scope accordingly; and how each item depends on other items. Below I present a template plan based on the previous posts and discuss what roles need to be involved.
Below is a template Gantt chart implementing the high-level structure seen previously. In this plan, the implementation is for a bank, and they have decided to use the ITIL and BIAN frameworks. The tool vendor has a solution for ITIL, which the bank has purchased, whereas the BIAN implementation needs to be created from scratch.
There are a few points to note in this plan. First of all, while it largely sequences activities one after the other within the constraints of the dependencies that we identified in part 3, we schedule several activities as a priority; the governance workshop, agreeing modeling standards, defining data fields, investigating the data format for import from other tools, and the dashboards workshop.
The common theme with all of these is that they require input from stakeholders, probably from a number of several stakeholders. This creates the predictable problems of a) getting the stakeholder’s time, b) getting agreement, and c) getting a definitive decision. The reality is that this is an idealized plan – “No plan survives contact with action”, to paraphrase General Moltke. So it is important to arrange these activities as early as possible so that if delays occur around them (for example, getting access to the SME for an external repository), the plan can adjust accordingly.
The plan assumes that one individual is tasked with rolling the tool out on a full time basis. If this is not the case, this could open the door to greater parallelism (for multiple workers) or slower rollout (if the rollout must compete for time with other activities).
Now, the sequence of tasks is one input into project planning; the other aspect of planning is resource availability. As noted above, one of the key areas that can delay implementation is access to the stakeholders and SMEs that need to give input. Below is a chart that shows possible involved parties for each activity.
These past four posts have attempted to provide greater insight into what is involved in rolling out a modeling tool along the lines of Orbus Software’s product. While it’s not possible to create a perfectly defined plan that is also appropriate for every implementation, the structure presented does provide a framework that implementers can adapt as needed.
More Enterprise Architecture Talk!
Peter Harrad's 4 part tool implementation series is complete but don't worry - we have much more where that came from! Check out his white paper discussing architecture KPIs below, and find more from him in the Orbus Software Resource Library. Hundreds of white papers, posters and videos at your fingertips. Register here.