Taking over an existing project is one of the toughest things our customers ask us to do. By the time a customer is fed up enough with their previous developer to want transition the project to us, the software is almost guaranteed to be a mess. The project is behind schedule, and the customer is stressed out, and we are called in to be the Silver Bullet.
Usually when we first talk to a customer about what we need to do, out comes an avalanche of features, bugs, performance problems, and in the same sentence the customer wants to know when it will be done (usually in the form of saying “It needs to be done by next week, because that’s what we promised our customers.”).
Whoa! Calm down! Being too eager to dive in and start doing things is always a mistake. These project rescues often need to slow down before they can speed up. Before you even think about touching the code, let alone changing it, you need to get the project in good shape.
Here’s our checklist of things we need before we start. Missing any one of them? Get them sorted before you touch a single line of code.
1. Is the entire system under source control?
2. Is there a documented backlog of some sort?
3. Is there a test environment that accurately mimics production?
4. Is there a documented deployment process? To both test and production?
5. Is the deployment process automated? To both test and production?
6. Are all databases backed up and automatically moved to redundant storage?
7. Is there a diagram of all resources in the production system, such as VMs, database servers, FTP sites, etc.? Can you log into all of those resources?
8. Does it have an automated test suite? Is the code coverage at least 75%?
9. Bonus Item: Access to previous developer.This isn’t always possible, but most of the time, we find the previous developer is willing to work in a professional manner to hand off the project even if they are losing the customer.
All of these might seem obvious. However, when you are taking over a large system, if these nine items aren’t in place, their importance is magnified. (A great case study is our story about The Lost Boys: An Agile Software Development Case Study where we took over a troubled project and brought it back to life.)
Going through this list with your customer and helping them understand the need for every single one will help them understand where things are really at with their project. Usually working on the code itself is the easy part; it’s getting the whole thing under control which is hard.[/vc_column_text][/vc_column][/vc_row]
