Blog Post

Taking Over Someone Else’s Project: How to Handle the Transition

I sometimes find myself taking over other people’s projects. These could be projects that have been abandoned or left incomplete by another freelancer, or it could be a redoing of a finished product, like rewriting existing website content, updating an old e-book or completing unfinished designs.

But taking on another person’s project can be very challenging, especially if they are no longer around, or are uncooperative. So how can you make the transition as smooth as possible?

Keep culture in mind. Your communications with the other people involved in the project should serve another purpose: learning their culture. This includes the culture of each individual in the team, as well as the team as a whole. This culture is the summation of their work processes, habits, interactions and attitudes. Keeping culture in mind can provide you with useful clues that will help you figure out how to talk to them, how to interpret their words, and what your potential challenges will be.

Debrief. Get your hands on as much of the project’s materials, resources, and tools as you can — even if you’re not going to use them. It helps to review the status of the project before you were assigned to handle it. Here are some questions you might want to ask:

  • Did the project meet all of its objectives? Why/why not?
  • Why did the person in charge leave? If the reason is relevant to the project, how will it affect your own work? How difficult will it be to reach him/her if needed?
  • Which of the resources and materials are truly useful? Which of them just add clutter?
  • If you’re able to communicate with the person who used to be in charge, how open are they to working with you during the transition? If it’s hard to get their cooperation, how can you change their mind?

Manage expectations. A crucial aspect of a successful transition is managing expectations. This includes the expectations of everyone you’re working with as well as your own. Some points to consider:

  • What deliverables are expected of you? How are you expected to respond to queries and suggestions?
  • Among the things expected of you, which are affected by how the project was previously handled?
  • What can you do to ease any concerns or worries that your client or team has when it comes to working with you?

Assess. Given the information you’ve gathered, do you think it’s possible to continue the project in its current state or is it better to start afresh? While continuing the project may seem easier, sometimes it’s not the best approach to take — especially if it didn’t meet any of the established objectives.

Archive. File away all the old documents and materials pertaining to the project’s previous incarnation. Don’t throw them away, just make sure that they filed away but are easy to refer to later on. This helps you start without the existing physical and mental clutter caused by the project.

Restart. Even if you’re starting with someone else’s unfinished work, it helps to approach it as if it were a new project. Thinking of it as a blank slate helps you to break free from existing standards and processes that didn’t work.

Restarting or completing someone else’s project can put you through a rough transition. But after that, it’s just a matter of getting the work done.

Share your tips for managing project transitions below.

Photo by stock.xchng user webguitou

Related content from GigaOM Pro (sub. req.):

2 Responses to “Taking Over Someone Else’s Project: How to Handle the Transition”

  1. Joop Eggen

    Nice points made. Other soft side themes:
    – Do not expect all problems being mentioned, especially from the higher echelons.
    – You may find willingness to trim requirements. Prune only structural (difficult) features.
    – Provide accountability by generated lists.
    – Communicate, explain what, why and how things were and are to be done. And what are your assumptions.

  2. I have been involved in a couple of projects where the hand over is minimum and the resources few, and in handovers where there is simple 2 much info.

    I really think your artical is to vague, given that there are more types of hand over than you describe

    e.g. your given the task of adding new functionality or worse updating a old system where all the previous developers have gone and not one really understands the business logic, and it just works. doing one of these at the moment, and it basically involves learning the business logic from the code writing a requirement document backwards, updating the system on to more modern tech (e.t. .net 1.1 to 3.5) all the time supporting the existing system.

    or your handed over that project that is stuck in management, I did one of these for the NHS and through sheer force of will got it build after 10 years of it being first propose, though it took me 3 years to sort management ouot and about a year to build,

    But that being said the steps to deal with the hand over are simple enough:

    Get all the Document, source code, passwords, business knowlege and put in to version control if not already. have that long meeting with both the client and the previous developer (if possible), get a wiki about the project to store all the info that is going to be flung at you. And above all treat it as your project develop it how you want to, and dont put up with some one elses poor design problems.

    Oh and dont forget with some projects you get baggage of project managers that have given up, business people that have given up, so as the new guy you have to be the optimisitic one and come full of energy, I find bringing home baking to meetings really helps especially the first few, to cheer up the old project staff.