Chapter 11: Manage Your Turnover

---

Your project should have a beginning, a middle, and an end. The first two phases should occur naturally, but it may take an act of the Creator to close it down. Obviously this is particularly true for poorly defined deliverables that never quite work, or if you have been infected with that nasty scope creep virus. Traditional project management methodology teaches us that the handoff of deliverables to "maintenance and operations" is your last task before typing up your lessons learned and moving on. The inability to do so deftly can also delay closure, sometimes forever, or so it seems. In this chapter, I review what it is going to take to get there.

11.1 The Handoffs

Depending on your project's deliverables, you can expect one or more of the following groups to be looking for handoffs from you.

• Desktop support

• Local area network (LAN) server support

• Mainframe and midrange services

• Data center operations

• Help desks (voice, data, applications, e-mail administration)

• Telecom (routers, switches and hubs, cable management)

• Network address administration

• Facilities (building management)

• Risk management

• Security

• Disaster recovery (DR) and business continuity

• Tape backup and archiving

Ideally, each of the impacted groups will play an aggressive, proactive role in your initiative, starting at the project kickoff meeting. Based on my experience, I would be looking to them for the following results:

• They will educate your team on current operations practices, tools, and direction. This would possibly have an impact on technologies you will have to use, documentation requirements, and implementation strategies.

• They should provide support for change control, specifically explaining how modifications can be made to the production environment for servers, connectivity, applications, and login IDs. Of particular interest in this area are maintenence windows, lead times, and possible blackout periods, ^[1] all of which can introduce dependencies into your scheduling.

• They will make sure that tape backups, disaster recovery, password administration, application access rights, virus scans, security applications, and "heartbeat" monitoring tools are properly planned for and implemented.

Perhaps I have worked for too many clients, but I find these processes, which are driven as much by bureaucracy and logistics as they are by technology or common sense, quite difficult to understand. This has other benefits, however, beyond the guide dog role I ask operations managers to play on the project team. In today's environment, many requirements will be placed on your technology rollouts from the support side of the house - requirements you will have to meet before your rollout will be taken under the corporate support umbrella.

For example, servers connected to the production network probably have to be built a certain way, possibly using specified makes and models. Software for virus and security scans, heartbeat monitoring, and remote access are commonly specified and required, too. At the very least, you can assume that operations-driven requirements will add tasks and costs to your implementation. It is best to know this up front, so you can plan the tasks, budget the costs, and identify resources you may need to ensure compliance with these operations standards.

By the way, if you think about it, the ongoing participation of the operations staff should be of value to them too. If, as is likely, you are rolling out new products, their early involvement should help prepare them to assume production ownership of your target state. At the very least, logic tells us that they should learn a lot by looking over your shoulder while you build out a new world. You may further reason that these people should enjoy learning new technologies, which would spice up what appears to be prosaic daily routines.

That is our theory, anyway. Experience, unfortunately, teaches us that such thinking is in reality a lame sales pitch project managers make to operations people in the hopes of luring them into the project early on. The reality is that asking them to line up shoulder to shoulder during your planning and implementations phases is somewhat akin to inviting the building maintenance staff to lend a hand when you are pouring the foundations.

^[1]Times when network changes are prohibited, most notably around fiscal year-end.

---