How to hand over a project systematically?

Question

Hi,

We have a project hand over from on shore team to our team (off shore) not long ago. However we were having difficulties for the hand-over process.

1. We couldn't think of any questions to ask during their design walk-through, because we were overwhelmed by the sheer amount of information. We wanted to ask, but we didn't know what to ask. Since they got no question from us, the management think that the hand-over process was been done successfully.

2. We had tried to go through all the documentation from our company wiki page before attending the handover presentation, but there are too many documents, we don't even know where to start with.

I wonder, are there any rules or best practices that we can follow, to ensure a successful project hand-over, either from us, or to us.

Thanks.

Answer 1

As a start, define the exit criteria for the handover. This should be discussed, negotiated and agreed with both parties and make sure higher management knows this. Then write up a checklist of all things needed to achieve the exit criteria and chase it.

Answer 2

My basic process for receiving a handover would be:

1. Get a general overview of the app, document it
2. Get a list of all future work that the client expects
3. ... all known issues
4. ... any implementation specifics
5. As much up-to-date documentation they have
6. If possible, have them write some tests for critical components of the system (or at least get them thoroughly documented)

If there is too much documentation (possible) just confirm that it is all up to date, and make sure you find out from them where to start, if it is not clear.

Ask as many question as possible; anything that comes to mind, because you may not have the chance again.

Answer 3

In terms of reading the documentation, personally I'd go for this order:

1. Get a short overview of the basic function of the application - what is it meant to achieve. The business case is probably the best document which will already exist.

2. Then the functional specification. At this point you're not trying to understand any sort of how or technology, just what the app is meant to do. If it's massive, ask them what they key business processes are and focus on those.

3. Then the high level technical overview. This should include an architecture diagram, required platforms, versions, config and so on. List any questions you have.

4. Then skim any other useful looking technical documents - certainly a FAQ if there is one, test scripts can be good too as they outline detailed "how to" type scenarios. Maybe it's just me but I find reading technical documents before I've seen the system a waste - it's too academic and they're normally shockingly written. It's certainly an area I'd limit the time I spent on if I didn't feel I was getting a reasonable return for the time I was spending.

If there are several of you arrage structured reviews between you and discuss the documents you've read, making sure you've got what you need to out of it. If the system is big then each take an area and present to the others on it - give yourselves a reason to learn as much as possible and knowing you're going to be quizzed is a good motivator. Make a list of questions where you don't understand something. Having structured reviews between you will focus your minds and make it more of an interactive task, rather than just trawling through page after page of tedious document.

Once you get face to face with them:

1. Start with a full system demo. Ask questions as they come up, don't let them fob you off with unclear answers - if they can't answer something have it written down and task them with getting the answer.

2. Now get the code checked out and running on your machines. Do this on at least two machines - one they lead, one you lead. Document the whole process - this is the most important step. If you can't get the code running you're screwed.

3. Go through the build process. Ensure that you can build the app (including any automated build and unit tests they may have). Note that all unit tests should pass - if they don't or if they say "oh, that one always fails" then they need to fix that before final acceptance.

4. Go through the install process. Do this at least twice, one they lead, once you lead. Make sure that it's documented.

5. Now come up with a set of common business functions carried out with the application. Use this to walk the code with them. The code base will be too big to cover the whole thing but make sure you cover a representative sample.

6. If there is a database or an API do a similar exercise. Come up with some standard data you might need to extract or some basic tasks you might need to carry out using the API and spend some time working through these with them.

7. Ask them if there's anything they think you should know.

8. Make sure that any questions you've written down anywhere else are answered.

9. You may consider it worth going through the bug list (open and closed) - start with the high priority ones and talk through anything particularly worrying looking. Even if they've fixed it it may point at a bit of code which is troublesome.

10. And finally if the opportunity exists - if there are any outstanding bugs or changes, see if you can pair program a couple.

Do not finally accept the app unless you are 100% sure you can:

1. Get the code to compile
2. Get the code to build (including the database)
3. Get the application installed

Do not accept handover is complete until they have:

1. Documented anything you picked up on that wasn't covered to your satisfaction
2. Answered ALL of your questions - a question they won't answer after being asked repeatedly screams of something they're hiding

And grab their e-mail addresses and phone numbers. Even if it's only informal they'll probably be willing to help out if the shit really hits the fan...

Good luck.

Answer 4

Check out "Software Requirements" and Software Requirement Patterns for ideas on questions to ask when gathering information about a project. I think that just as they would work for new development, they would also help you to come to terms with an existing project.

Answer 5

Most handovers, perhaps all of them, will cause a lot of information to be lost. The only effective way to perform a handover that I have seen is to do it gradually. One way to do it is to allow a few key people from phase One to stay on the project well into Phase Two.

The extreme solution is to get rid of all handovers, and start using an Agile mindset.