Managing outsourced work
Now that you’ve made your decision, picked a supplier, and written a contract, just kick back and let them do the work and deliver a final product. After all, they won’t fail because they promised they wouldn’t. And besides, you won’t pay them any more than they bid.
Not so fast.
Don’t assume you can turn over management of the outsourced software to the supplier. Plan on staying closely involved with the outsourced development and use the language you wrote in the contract that described how you intend to manage the work and what data and progress/status reports you expect of them.
Don’t assume you can turn over management of the outsourced software to the supplier. Plan on staying closely involved with the outsourced development and use the language you wrote in the contract that described how you intend to manage the work and what data and progress/status reports you expect of them.Hold regular reviews, either in-person (preferred) or virtually. Discuss status and technical issues. Keep control of the master schedule and monitor task completion to understand if the supplier’s team is staying on schedule.
Since you are allowed to see the code while it is being developed (because you wrote that in the contract), check on code quality and conformance to standards and validate progress by taking a look.
Since you specified incremental deliveries, be sure they’ve organized the development so this can occur. When an operational portion of the code can be tested early you will be able to see how well they’re doing unit testing and whether they’re building what you asked. When they deliver an increment, test it yourself right away. This means you need an in-house test team. Did you include that in your costs?
There will be questions, clarifications, and changes. Sometimes the supplier’s questions and clarifications will lead to these changes in requirements. That usually means that something important was left out or something was stated incorrectly or vaguely. If this means that there is added work for the supplier’s team, then they deserve some additional payment. This process can get tricky and benefits from an experienced project manager who can judge whether this clarification really is additional work or if the supplier is just trying to get well.
Sometimes changes are requested by your own management or by a customer. These changes often will require additional work from the supplier (or re-work of something already completed). This change order process should be managed carefully. Very carefully. With requirement baselines, a change request/tracking tool, and processes. You should be sure the supplier understands the change, gives you a bid for the additional work, and knows if and when the change is authorized. Again, a tricky management process that benefits from an experienced project manager.
What will you do when you discover bugs in the code they’ve delivered? What is the liability of the supplier? If your supplier’s contract is complete before you’ve finished your testing, you will have to have an in-house team fix the bugs or you will have to write a new contract for the continued work: work caused by the supplier’s software defects. Think through how you will handle this before you start, and make sure that you and your supplier agree on the process for fixing bugs. Of course, the issue here will be one of “what one party calls a ‘bug’, the other calls an ‘enhancement’“. Or a “missed requirement“. Another opportunity for an experienced project manager.
If you find that things are going along smoothly, the supplier’s team is on schedule, you’re testing software that works and looks good, then celebrate. You’ve done a great job managing a high-quality supplier. And you are in the minority.
If, instead, you find that the supplier is consistently late but promises to make up schedule later (as the team gets used to the project), and you have not had a chance to see any software working together because of some excuses that you really can’t understand, then :
more next post.