A checklist for maintaining control over software development projects
A checklist for maintaining control over software development projects
My colleague, Rick Mosca, recently discussed the costly mistakes an inexperienced or unqualified vendor can make during the course of a large scale IT project, in The High Price of Selecting the Wrong IT Partner. Rick details a typical chain of events that can lead to an IT project fail. And relying wholly on an IT vendor from the outset, to manage your technology project and protect your investment is the first critical mistake.
Beyond avoiding mistakes, taking charge of your project and proactively creating a checklist of items will keep you fully engaged in your IT project’s progress, keep your budget in check, and help ensure success.
1. Specify a list of changes you need your vendor to complete. Do your research, be diligent, and have a thorough understanding of the unfolding nature of a software development project. Success criteria will change as the development team starts implementation and the customer stakeholders start interacting with the software. For any project, the team (vendor and customer) knows the most about the project at the end, not at the beginning. Plan for changes and be able to adjust, because change is going to happen.
We recently took over a project for which the client originally listed “6 things we needed to do,” with no specificity. By the end, there were actually over 200 items to be addressed.
2. Require an issue tracking system, to which you have access, that houses the change list and serves as a communication vehicle between you and the vendor for status updates, inquiries and overall project management. At all times, you can manage your project, your vendor and objectively evaluate the status of what’s done and what’s not done. This creates transparency and accountability.
3. Validate progress and completion with data, not reports. Formulate a data driven validation process that enables you to independently assess a project’s status. So when your vendor reports that the job is 95% completed, you have already defined exactly what “completed” means. Include coding, testing, and customer approval in this agreement. You make the final determination on project completion – and success – not your vendor.
4. Establish a well-defined plan for migrating a legacy system from one platform to another. Just because the application code is written doesn’t mean people can use it. Insist on a roll back plan in the very likely event of unanticipated problems, such as a process that doesn’t run or a report that doesn’t work in a particular browser, or limited functionality due to obsolete underlying technologies.
5. Go for a test ride. Once the vendor has completed internal testing, you should do the QA because you know your own system better. You vendor does the work to fix an issue, but you should validate the fix. Working software is more valuable than any status report.
6. Create an exit plan with your vendor, and be sure to have access to the source code. That source code is your intellectual property and you need to ensure that your IT vendor appropriately guards it. This empowers you to manage your vendor and protect your investment. It also gives you leverage in the event that something goes awry, such as the departure of the vendor’s key developer, who happened to be the only one on the project with domain knowledge.
Don’t wait until the end, or even the middle of the project to figure out what the status of your own project is. As the customer, you need to be able to independently validate your project’s success, not just read a progress report. Engage in your project and arm yourself with knowledge. You will become a powerful partner in the development of projects that impact your bottom line – rather than a passive observer.