Handing off a Project

Sunday, November 9th 2014, 3:45 pm

In the life of most projects, there usually comes a time when the project must be handed-off. Sometimes the hand-off happens because the product behind the project has reached end of life, other times because management has decided to allocate the project to another location, and yet some other times because the project was meant to be handed-off all along.

Unfortunately, many times these hand-offs are not successful. For example: the support team, in a product that has reached end of life, finds itself unable to fix a critical security bug; or the team that receives a project in a new location cannot deliver any of the new features planned for the project. The development progress then comes to a crawl, and both the original and receiving team start pointing fingers, each one blaming the other for the current state of affairs. In essence the hand-off failed.

A failed hand-off

If you are a software engineer, it is easy to understand why these project hand-offs go wrong. For every line of code in a project, there are many decisions that must be made before the line is written. Many of these decisions are trivial, but there are others that are the result of knowledge that the original team thinks of as self-evident; this knowledge being thought of as self-evident, goes undocumented. However, what is self-evident to the original team is completely foreign to the receiving team. It is these undocumented decisions that prove to be the undoing of the hand-off. The receiving team, unaware of the reasoning behind the code, is unable to understand the code properly and thus, is unable to modify it.

Shore, in The Art of Agile Development, discusses a number of alternatives that can be implemented by a team in order to prevent such disastrous hand-offs (2008):

  1. The first one of these alternatives is keeping a decision log. The team should record every big decision taken during the project and provide a summary of it during hand-off. The summary should include non-obvious information, error conditions that may arise from the decision and possible remedies.
  2. A second alternative is doing a gradual hand-off. During a gradual hand-off, both the receiving and the original team work together for a period of time doing normal development activities. Working together, allows for a natural transmission of information from the original team to the receiving team. This transmission happens in a way that is very similar to that of getting a new team member up to speed.

I believe that the best of these two alternatives is to always keep a decision log. In my experience most projects are eventually handed off and in the rare event that your project is not handed off, the decision log can always be used to smooth the induction of new team members. A period of working together however, is usually harder to obtain.

Chow & Cao, in a survey study of Agile, found that a good delivery strategy is the single most important factor in the success of an Agile project (2007). The top five factors from this study are reproduced below. Improving your delivery strategy by striving to always have a decision log seems like an obvious step to ensure your project's success.

Critical Success Factors for Agile
1Delivery Strategy
2Agile software engineering techniques
3Team capability
4Project management process
5Team environment

Journal of Information Systems and Software, p.967 by Chow & Cao 2008.


  1. Chow, T., & Cao, D. B. (2008). A survey study of critical success factors in agile software projects. Journal of Systems and Software, 81(6), 961-971.
  2. Leonard, B. (2013). Bridging the Gap for Effective B2B Videos [Blog Post]. Retrieved from http://www.acsellerant.com/bridging-gap-effective-b2b-videos-2/
  3. Shore, J. (2007). The art of agile development. O'Reilly Media, Inc.
comments powered byDisqus