4.4 How do I Use this Implementation Strategy?

< Day Day Up >

The key to bridging the gap between design and implementation details by using the implementation strategy can be found in one of the characteristics presented in the review of the kitchen countertop story, specifically this one:

Approach; this is the logic driving the project plan (i.e., "how we will do this")

I love the word "logic" in this context because it implies that we are applying some cognitive procedure to this process of generating a useful plan from the jumble of ideas and personalities that presently lie before us; however, I refer to this process as implementation strategy, not implementation logic, because there is more alchemy than science in this process, no matter how you cut it.

The one leap of faith I ask you to take is to agree that the implementation strategy must be created before you move toward scheduling the tasks that comprise your project activities. Final planning is the topic of Chapter 6, so this business of an implementation strategy is an interim step, but a crucial one. We take it to gain a full understanding of the attributes of the work to be performed, though not necessarily the detail of that work. In fact, other than the critical elements described in the countertop review, you need little else to construct your implementation strategy.

Our next step to see how the implementation strategy works is to fill in the two blocks (see Exhibit 3).

Exhibit 3: Fill in the Two Blocks

click to expand

It is not always easy to decide how best to present a theory. What I generally do is show a process and its application before rationalizing it, so here we go again. Most project managers would look at the two boxes in Exhibit 3 and try to match them up into a plan, because there appears to be a one-for-one relationship between the boxes and their contents, save for the inspection box thrown in at the bottom of the right side. For instance, the wood countertop is detailed on both sides. The left side represents the key design elements, while on the right, the discrete steps required to get a finished countertop onto the island are documented. This is repeated for the other key design elements of that project: the gas cooktop and the ventilation system.

So, as was just said, we appear to have our plan, right? Unfortunately, that is not true. If you are not knowledgeable about kitchen building, then it would be understandable if you do not appreciate how unrepresentative the right side is of how this project would be executed by an experienced builder, even though the basic high-level tasks are accurately depicted. What is wrong or misleading about it, you ask?

What is wrong is what is missing, and this includes steps 4 and 5 from our planning review (i.e., those steps identified earlier in the chapter as the heart and soul of the implementation strategy), namely:

The sequence in which those components and processes are built.
The sequence in which these components and processes are integrated together.

In plain English, the issue is that, although the right side accurately captures the high-level tasks in sequence for implementing each of the three key deliverables, it does not show the actual flow of work that would lead to the successful implementation of the entire project.

Before I lose too many of you, let me jump ahead for a moment. Any complex IT project will probably contain design elements that are unknown to you. Even if you know everything, the shear volume of detail on complex projects is overwhelming. Therefore, no matter how technically savvy you may be, I ask you to consider that this parable of my kitchen remodeling nightmare remains compelling. If you must, think of the three key elements of countertop, cooktop, and ventilation as stand-ins for Web sites, data center moves, switched ATM networks, or whatever mush your complex project currently approximates.

Though running the risk of delving too deeply into kitchen construction processes, I would like to close this section by asking you to take a look at the following illustration. In it, the implementation detail boxes previously placed on the right have been moved to the left side of the page. In the revamped drawing in Exhibit 4, the right side now reflects the implementation strategy articulated at the start of this chapter in a more graphic form.

Exhibit 4: Reflecting the Implementation Strategy

click to expand

Before ending this part of the discussion on implementation strategies, a few comments are in order:

If we did a good job of devising an implementation strategy, then the boxes on the right that were derived from that strategy accurately reflect the upcoming flow of project work.
All items listed on the left were transformed to the right using the implementation strategy-bridging tool.
By no means does the right side substitute for the final plan, whether it captures all detail or not.

At this point, however, the level of detail shown is quite close to what you should shoot for when you create implementation strategies. For example:

It would take pages and pages to write up the details behind the seemingly innocent item called "Install electric, gas, and ducts" that appears in the Implementation box at the bottom of the right side.
Many more pages would be required to document other information, such as risk, that factors into the real implementation.
Even though this was an implementation plan wherein I personally will own 95 percent of the tasks, all that detail was ignored as irrelevant when we devised the implementation strategy for this piece of our kitchen remodel.
At that point, I was not scheduling anything, so I really did not care whether I needed just Saturday morning or the whole weekend to implement the wiring requirements.
The fact that I was the task owner did not color my job as project manager to assemble the implementation strategy. If the line item was "Install and configure routers" instead of "Run electric," the story would not change.

There is no guarantee that when we build the final schedule, it will mimic the implementation strategy side of Exhibit 4. What is a sure thing is that it will be pretty close, whereas the boxes on the left are practically useless as the basis for a valid project calendar. This is why I urge you to use the implementation strategy as a transformation tool to get a leg up on approximating the real project schedule.

Two project views must be considered to capture this method:

Deliverable view. If your project has seven major deliverables, such as systems, network infrastructure, disaster recovery, and the like, then you should have seven implementation strategies. Presumably, the appropriate team leads would create these, although it has been my experience that you should facilitate this process with them.
Roll up view. In the end, you are far more responsible for the aggregated output of the various teams, so your personal focus should be on the overall strategy. This may seem strange if the deliverables are stand-alone, but you should create a strategy that covers all of them. Chances are that some dependencies or linkages do exist among your deliverables. Even if that were not true, you still need to sequence your own efforts as each deliverable moves through the process from the Big Thirteen to operational handoffs.

< Day Day Up >