The proposal process is always an interesting time for us. It’s a little like dating. Both parties are taking some time to get to know one another before deciding if you want to get married or part ways.
Our clients range in size from 5 to 1000 employees, so every engagement is different. Not only in regard to the nature of their network, IT infrastructure, and business, but also what type of personnel you will be working with. It can range from companies with no internal IT staff at all to companies with robust IT departments.
In this particular situation, it was a setup we see too often – one single internal IT person. For the sake of the story, we will call him “Chuck”. We are always slightly more aware when we are looking at a scenario with a single IT resource since there are a number of risks associated with it and one of them reared its ugly head this time.
We had been speaking with the company for a couple of weeks and were preparing a proposal with the understanding that Chuck would continue on his current role as IT manager. Our primary role was to handle things that were outside of Chuck’s core competency or related to the new out-of-state locations the company was opening. They were growing pretty quickly and their IT was rapidly becoming more complex.
We were really close to pushing a final proposal when we got a panicked call from the prospect – Chuck had quit. It was a Tuesday and Chuck let them know his last day would be Friday. We immediately kicked into scramble mode. Our proposal was shot, because it was all based on Chuck being there. Our immediate goal was to download as much of the history that Chuck had about the environment before he left. He had been managing their systems on his own for several years and most of the configuration information about the infrastructure lived solely in his head.
This scenario was tough enough but then Wednesday rolled around and there was no sign of Chuck. No answer when we or the client called. Same went for Thursday and Friday. Chuck had disappeared and taken his knowledge and the history of the environment with him. Admin passwords, configurations, reasons for architecture decisions, and knowledge of proprietary systems were all gone! Add to it that there was minimal documentation of any kind, and we and the client were left flying blind.
As a result, we had to start from scratch requiring many extra hours reverse engineering how things were configured; much of which could have been avoided with a professional hand-off from Chuck or detailed documentation. The result was unnecessary business disruption and pretty big expense to the client. A key lesson here is you need to think hard about who owns the mindshare of your technology. Make sure if they disappear – your IT doesn’t go with them.

