4.8 An it Implementation Strategy Example

< Day Day Up >

We built a new campus in which the local area network (LAN) design called for switched fast Ethernet with several high-speed laser printers attached to the LAN on each floor. We were in the build-out stage of the project, with just ten weeks left before the first 300 tenants were due to move in, when I got bad news from one of my spies. The user requirements surveys had finally come in, albeit late. They revealed a requirement that, to be honest, had escaped my attention. Apparently, the survey team had discovered that at the sites the users were moving from, they ran hundreds of print jobs directly off the mainframe network, often using "mainframe printers" that had features like forms handling and huge cut-sheet capacities. Though chagrined, I immediately recognized two problems:

The company was phasing out the dedicated mainframe network, so it was not extended to our new site.
The printers we were installing in the new site did not provide these specialized features support forms, or high volume. ^[3]

In other words, our site technology could not meet a significant user requirement. Whether we should have known about this many weeks or months before was irrelevant at this point. So I scrambled around to understand this "new" requirement and identify someone who could help us. After a few false starts, the right experts were identified. Fortunately, I had enough networking experience to feel comfortable with these new team members and their approach. After a few more sessions with them, I was able to submit the following implementation strategy to management:

In the legacy sites, users print from mainframe applications to printers attached to the dedicated mainframe network. This infrastructure is separate and distinct from the Ethernet LANs constructed in legacy sites, and at our new campus as well. The corporation is phasing out the proprietary network, so it was not extended to our new site. Therefore, without an alternative plan, there will be no way to produce all the mainframe print jobs at the new site. What we will do is redirect all these mainframe print jobs to the LAN at the new site, where they will be output from the LAN-attached printers using Transmission Control Protocol/Internet Protocol (TCP/IP).

This will require changes to the print definitions in the impacted mainframe applications. It also may require installing IP-compatible, mainframe-style printers with continuous forms, high-speed or high-volume features that the LAN laser printers being installed at the new site do not have, but that meet the user requirements as their old printers at legacy sites do.

A team with experience in converting mainframe printing to the LAN/IP environment has been engaged to do the analysis, design, implementation, and testing. They will also provide project management, and coordinate any special purchases as required. The main project will pick up any labor costs associated with this conversion, but the customer will be charged for any new hardware or software if required.

This real-world implementation strategy identifies the requirements, issues, and plan components at a high level. This provides completeness and keeps it reasonably brief. That is important because what you just read is basically all I needed to know about mainframe printing for our project.

There is one last benefit of using implementation strategies. The project from which I pulled this example had a dozen or so other deliverables. Although I had to develop and understand 11 other implementation strategies, that was a lot easier than trying to carry thousands of tasks around in my head. It was also easier to speak with others about this project because I had crisp stories to tell, instead of having to memorize the Manhattan telephone directory and be able to pronounce all the names in it.

If this presentation has convinced you that implementation strategies have value, then you have just added a very powerful weapon to your arsenal. It is interesting to note that if you cannot recount a major project deliverable in this manner, then either you do not know enough about that deliverable, or it has yet to take shape. In either case, further action is necessary. Either you need to find out what is going on with that requirement, or it has not congealed to the point that it can be packaged in this manner.

The idea here is to craft implementation strategies before gathering all the associated tasks and populating the Gantt chart. Therefore, the strategy should include all relevant aspects of the plan. If you start early enough, requirements gathering should be included. ^[4] In other words, the implementation strategy is the game plan for successfully implementing that project requirement. Risk, dependencies, team or task assignment, procurement processes (e.g., a request for proposal [RFP]), and hiring consultants for design, implementation, and documentation should be included if relevant. Any postimplementation requirements, such as training and support, should be noted if a significant work effort is anticipated. This is particularly true if the deliverable or its implementation represents a departure from business as usual.

You need an implementation strategy for each major deliverable, plus a "rolled up" implementation strategy that shows how the all the pieces fall into place. This latter plan provides a higher-level story (i.e., the infamous 30,000-foot view). It should incorporate external events or dependencies. You should also identify whether or not key events are serial or parallel (i.e., sequential or concurrent, to give your anecdote a temporal sense). As is the case with individual implementation strategies, it is important that you can tell the whole story. Look at it this way; if you cannot tell it, you cannot manage or rally support for it.

^[3]We are talking about 1000-page long print jobs here!

^[4]As described earlier in this chapter with the countertop example.

< Day Day Up >