<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">

3 Essential Tips When Ending A Consultant Engagement

Development Process, Culture

By Justin Freeman

As a Software Consultant, I have been on many projects. I’ve worked countless hours on these projects but eventually these assignments come to an end. No one works on a project forever right? Eventually the client ends the engagement or the project ends and it is time to move on to something else. But even though your engagement is ending, you are not completely done with it. You want to end your engagement gracefully.

In software development, you want to make sure you leave your client with everything they need to not only support the software you developed but to continue improving on it even when you are long gone. So how you do end your assignment gracefully? Here are some tips that I follow at every consulting assignment.


I know this sounds simple but there are some things that can be overlooked. Documentation isn’t just comments in the code. You also want documentation on how your development and test environments are set up. In the course of developing software, all developers come across some quirks they had to overcome to get the environment up and running. Nothing is ever clear cut. You want to write these things down so not only the current developers, but future developers, know so they do not waste time trying to get their development environments up and running. You not only want to have documentation about development processes, you also want documentation around test and deployment processes for the particular application you develop. No two deployments are the same so you want to make sure everyone is aware of what to do when deploying new code to the existing server(s) and deploying old code to a new server(s). Upgrades are going to happen when you are gone so you want to make sure anything that is different from a “normal” deployment is documented and explained.

Code Location

A lot of companies store their code in different ways. Some use version control and some don’t. Some use remote servers and some don’t. It all depends on how sophisticated your client’s development operation is. You will want to make sure everyone is aware of the location of all source code you developed and all the versions of it, whether it be a production or test version.

Software Development Versions

If you worked on an application for any significant amount of time, you have upgraded a few times, whether it be the IDE, Java, Database Drivers, Spring, Hibernate, AJAX Libraries etc. The list is endless. All of these things need to be communicated to the current developers. I consider this to be the most important because they might run into version conflicts or something that works in your version of Software XXX but not in a version of Software YYY. You want to make absolutely sure that if they use all the versions of software that you give them, they will be able to build and deploy the source code from scratch with NO issues. If they can’t do that, then something is missing and this will cause a whole of heartache. You never want to leave a client without the ability to continue development without you. It is not good business and the tech community that is undesirable.
At the end of the day, you want to make sure all your knowledge about a particular project is transferred to the client no matter how small you think it is. If you took the time to figure it out, it is something important that should be passed on. Here at Isos Technology, we make sure all of our consultants follow this philosophy.

Managing JIRA at Scale White Paper

TAGS: Development Process, Culture

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Subscribe to Our Newsletter

Recent Blog Posts