Each week, project management veteran Tom Mochal provides valuable advice about how to plan and manage projects. Tom first describes a common problem scenario, based on a real-life situation. He then offers a solution, using practical project management practices and techniques.
Tim called me the other day to discuss his project to introduce wireless devices to the sales organization. The pilot project has been outsourced, but the long-term support will need to come from our internal IT department.
“We are in the middle of the pilot project to deploy wireless devices to a few of the sales groups,” Tim said. “From what we have seen, it looks like the sales people are finding value in the devices. Now my customer wants us to start preparing for the full rollout and support.”
This was good news. “Cool,” I said. “What are your thoughts about the follow-on project?”
“The second project could be a long one,” he said. “The full deployment will probably take three months, and I am not sure how to handle the ongoing effort. Should it be a separate project?”
“It sounds like this second part is ongoing support,” I replied. “Why do you think it is a project?”
Tim thought for a few seconds. “I think of support as being routine and ongoing work,” he said. “The wireless world is all brand-new. We will need new skills and new processes to support this effectively. I don’t see how the support organization can take this on now.”
Now it was my turn to think for a few seconds. “I think I am halfway in agreement with you. There is a separate project here to build these new support capabilities and processes. We just need to be careful to precisely define the objectives and scope.”
There are some fundamental differences between project and ongoing support work. The biggest is that a project has a finite start and end date. This is in contrast to support (or operations). Support may have a start date, but it does not have an end date. Support continues until the product being supported is retired or replaced. Projects also create deliverables of some kind. In general, support tends to be service-oriented.
There is some confusion in Tim’s situation about the transition from project work to support. However, with some careful planning, it is possible to structure the work to keep everything straight. Here is how I proposed to structure the work.
The wireless pilot project is under way. In Tim’s case, much of the work was outsourced, including close support for the small number of people using the devices.
Wireless support infrastructure
The day we start to roll out the wireless devices to the rest of the organization is the same day we will get our first support calls. So we need to first define and build the skills and processes necessary to support the environment. All of this is done in partnership with our current infrastructure and support groups.
In a normal project, this probably would have been done in the design and construct stages. However, since it was not a part of the original project scope, we will need a separate project. If the customer is confident the pilot will be successful, this second project could be defined and started now. There is some risk, of course, that this work will be wasted if the pilot turns out to be unsuccessful.
Wireless deployment and close support
If the pilot project is successful, this is a follow-up project to roll out the wireless capability to the rest of the sales organization. The project can consist of the actual deployment, plus a short time frame for close support to make sure everything is working fine to begin with. However, this close support must be strictly defined so that there is a firm and understood end date.
After the deployment and close support project completes, there is a transition to the support organization. At this point, the support team needs to follow the processes and utilize the skills that were developed in the wireless support infrastructure project.
This approach allows the remaining work to be organized into logical projects that are manageable, have clear scope, and have a clear focus. This combination of related projects should ensure that the full wireless deployment, as well as the ongoing support, will be successful.
Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project-management and life-cycle skills. He's also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.
Do you plan support needs after new projects end?
Tell us about your experiences with incorporating new support needs into staff responsibilities. How do you calculate the increased need? Post a comment below or send us an e-mail.