Question about changing owners - from project to steady state

Submitted by obrienjay on Thursday August 25th, 2016 2:36 pm
in

Forums

A couple of manager friends of mine were talking about a chronic challenge that they face - the transfer of ownership when projects end. What solutions would you suggest they try? Here are the details: IT project managers run projects to deploy new or upgraded systems. Technical engineers work on these projects. When a project ends and the system is deployed, the engineers become responsible for supporting the system. The chronic challenge is that, over the course of the project, the PM becomes the known expert. People go to the PM for help or information about the system. Even the engineers who worked on the project will consult the PM when stuck. And so the PMs have trouble extracting themselves from the role of supporting these systems in perpetuity. The managers of both teams want the handoff to happen effectively. How can they best encourage that outcome? Thanks in advance for any suggestions that you have.

Submitted by altadel on Sunday August 28th, 2016 1:18 pm

Change management

Sounds as though change management is missing. As important as managing a project is managing the change this brings to the organization.

Submitted by jrb3 on Sunday August 28th, 2016 10:00 pm

Make the hand-off explicit

One "trick of the trade" I've seen from a few PM friends is to have a closing task which makes the hand-over explicit. It's usually in the form of designating a specific primary contact for the new systems, often a manager of IT staff or a senior engineer. That designee gets all the documentation, project notes, and a written list of loose ends. The PM reassigns any and all defects/issues from himself to the primary contact, meets the primary contact for a last hand-over conversation, then folks go out for something to eat/drink to mark the occasion.

Thereafter, the PM redirects all inquiries on the system to the relevant primary contact.

The PM might of course offer up observations, caveating that his knowledge is stale, and that the primary contact for a system knows the current state of what's under support. The quicker the observations cease, and the inquiry redirected without commentary or delay, the better.

Submitted by obrienjay on Wednesday August 31st, 2016 12:57 pm

Thanks for the advice

Thanks for the tips. I'll pass them along to the PM manager. Do you have any advice for the engineering manager, or do you fael that only the PMs have the power to change this dynamic?

Submitted by Kevin1 on Thursday September 1st, 2016 12:02 am

Multi steps

There are probably multiple steps needed. Maybe some of them are already there.

Most similar companies would have a phase in the project methodology for 'Transition'
Transition would include documenting the project details to a detailed level such that any engineer, any time in the future, should be able to see what was implemented, what was trying to be achieved, and importantly, anything that was deliberately left out of the project (extra modules, training, performance testing) and why,
Transition would also include a handover meeting to formally go through the documentation and 'train' those who will have to support it.
There sould also be a Transition gate such that unless the ongoing supporting team signed off on the Transition being adequate, the Transition would not be considered complete and the Project team would continue to 'own' supporting the issues for the customer until such time as the Transition was complete.
There may also be components of the transition which include the customer in the process, an introduction to their new ways of logging issues and getting support, etc.

Hope this helps a bit.

Kind regards

Kevin

You are here