- IT / Communications
"Sometimes, it's just easier to start over..."
At one time or another in your career, you will inevitably be challenged to "pick up" a project in-flight from someone else who initiated it.
Sometimes this may be taking over from a resource within your company who is moving on, other times it will be your company coming in and taking over (AKA"saving" or "fixing") a project from another company.
One project that really taught me a lot was an example of the latter situation: A large Real Estate Investment Trust (REIT) client of ours (I was working as IT Director at a strategic Marketing & Investment firm at the time) was undergoing a complete re-branding (name, logos - everything), led by a different Graphic Design firm & their internal marketing department, and they got into a dispute with their web developer and fired them halfway thru the job and with a fixed launch date for the new brand, and we were asked to complete the job.
Even once we got the source code, trying to reverse-engineer the logic behind another group's design and development decisions was maddening, and nearly impossible under the tight time constraints, and we very nearly missed the deadline as we were coding until the launch weekend!
As Project Managers, we try to avoid the additional cost and effort associated with rework, however, in the case where you pick up a project from another company, it is almost unavoidable, as you typically don't have the context to inform your work enough to avoid going down the wrong path before correcting course.
The situation is worse when you're taking over from a different company; there may be legal issues, and once a company has been fired, there is typically a significant disinterest in supporting the company taking over for them, however, even when replacing a resource in the same company, knowledge transfer is always lacking, and the exiting resource may not have the cycles to support you appropriately as you get up to speed.
The negative experience I had salvaging this website project really informed how I document my projects now - not only do we have to document more/better, but we have to document differently - providing more context to the logic behind decisions.
- WHEN EXITING A PROJECT: Focus on ensuring that all your key decisions are captured, as well as the reason for each decision. This can be equally important to technical documentation.
- WHEN PICKING UP A PROJECT: Do your best to negotiate more time than you think necessary for knowledge transfer. If the project is well documented, spend your time asking leading questions to gain context around key decisions made on the project. This is true for all decisions, but even more so for key design / architecture decisions, as these are often foundational.
- WHEN WORKING ON A PROJECT: Utilize a RAID Log to capture Risks & Issues, but also Decisions and Actions as you go - this way, knowledge transfer & documentation won't be such a heavy lift!
Remember - sometimes it CAN be quicker and less costly to start over. Tracking decisions and context gives stakeholders the required information to do so earlier in the game.