Most IT systems are planned for 5+ years but the employees required to keep this system running have a half-life of much less than that. This brings home the inevitable reality of having to transition the project/product/solution possibly multiple times during its lifespan. The IT industry is plagued by steady growth, which means lots of options for employees/consultants which means the problem is going to get worse. In California, employees can leave on a 1 week notice period which means that companies need to be a constant state of readiness when it comes to transitions.
From the perspective of a consulting firm, one of the key reasons a company would prefer a relationship with a company vs. an independent contractor is perpetuity. Companies needs assurance that systems will continue to function and support remain available throughout the lifetime of a system – something independent contractors struggle to provide. This problem is more chronic in teams working on products (vs. those working on projects lasting a few months) – context becomes critical here in terms of the value of the consulting firm.
All this means that perpetuity becomes a key concern, not an event that shows up every now and then. Even with this, most transitions lead to loss of availability or in the very least, a lack of productivity or a palatable drop in the quality of service. While I am unaware of any ways to eliminate this completely, there are some ways one can mitigate the risks a departing employee poses.
Have two people to do the job of one. Keep them involved in each other’s work so as to ensure that one can take over the other if required. This is a resilient model and works well in most cases. Indeed it is the only option where continuity is critical. It still needs to be done right though; you can still have redundant backups come to you and say they don’t know anything about this or that module that the primary was working on.
This system however, intentionally introduces inefficiency in the work-process though. Pretty soon work expands to fill the time allocated to it. The cost of these inefficiencies needs to be considered carefully.
A strong SDLC (software delivery lifecycle) in the organization helps. Documentation on key milestones helps. Use new mediums of documentation. E.g. Enterprise Social Media tools like Yammer or video recordings of key events capture the history of a project in much richer context and are much easier to digest for new employees.
Streamline your SDLC to a Agile or waterfall industry (whatever works for your portfolio of companies/projects) but adhere to it strictly. A clear SCRUM backlog or a clearly defined/signed off scope of work makes transitions a lot easier.
Projects in support phases should always maintain issue logs and adhere to a ticket > evaluate > fix > release process strictly. As things streamline we tend to ignore these more and more but senior management needs to make sure there is a documented trail of issues and fixes.
Once again, there is a cost to process. It must be weighed and evaluated carefully against the customer’s needs for perpetuity and the probabilities of failure.
Take employee retention more seriously
Organizations need to do more to realize the cost of the departing employee. In terms of time spent on transitions, lack of productivity of the new resource, opportunity loss from drop in quality etc. Once these become clear, these can be weighed against the cost of retaining the resource. This could be through more money, a better work environment, flexibility, team bonding, exposure etc. Many tactics exist but are often only considered after the fact or are considered infeasible because companies dont quantify the losses /inefficiencies incurred from a constant need for redundancy. I’ve seen companies not give a 20% increment to a departing employee and loose a lot more than that in transitioning the project.
Lastly, when they leave, make sure they leave on a good note. If they can remain available to you a few weeks/months after they leave the job, that can usually be a great help.
All said and done, project transitions will usually not replace:
- Relationships: People are much more than projects and their relationships with clients are usually things that take time to adjust. Trust, in particular takes very long to recover.
- Undocumented context: No matter how hard you try, there will always be those things that didn’t get captured in a consumable form. The effort is to try and reduce this and to hire people who can read between the missing lines (usually through prior similar experiences)