Contracting with an external company to develop applications is a very common scenario in the corporate world where companies do not have the technical expertise (or enough staff) to develop their own software.
While in-house projects can be cost-efficient as you leverage your already existing technical resources, outsourced contract projects can get pricey as you are transferring most of the risks to an external company and of course, you will be charged for this accordingly.
Whether you find yourself as a stakeholder or as an in-house technical staff involved in an outsourced project development, it is very important that you keep tabs on the actual value that you are getting from this contract.
We’ve put together some tips to ease up the process and increase your chances of having a successful project. Keep in mind that these tips are focused on the stage where a vendor has already been selected for the job. There is a lot to be said about best practices for selecting vendors but that will remain on our to-do list for another post.
These suggestions could apply to either the general service contract with the vendor or the statement of work for this particular project. Just make sure you have a clear statement on the following.
This is the way the deliverables will actually be produced and it gives you an idea of what to expect when checking for progress. It would be a huge red flag if the methodology isn’t even mentioned in the contract or project proposal. Most common software development methodologies are Waterfall, Rapid Application Development and Agile (usually SCRUM). Whatever the method is, make sure this is mentioned somewhere everyone can see and sign off to it. While I won’t go into detail into the different methodologies, I usually recommend Agile SCRUM. There is a ton of resources online about all the different existing methodologies, so if you see one mentioned in the project documentation and you are not sure about what it is, just google it and try to understand it. It’s important to be familiar with the chosen methodology before the project starts, **especially if you want to make a preliminary assessment on whether it will fit well in your company’s work culture**.
These are absolutely tied on what work methodology has been selected for the project. If the methodology is Agile then expect to have a lot of deliverables during the course of the project. If it is Waterfall then expect to have well-defined Milestones.
The most important thing is that at the end of the project you have concrete deliverables readily available on your end. Some of the things to watch out for:
* Source code will be on the third party’s end and not available to you until final delivery: Avoid this at all costs and if possible have them work in your own code repositories.
* No clear definition on documentation: The documentation is key and you should know what documents will be part of the deliverables, this includes both project and product documents.
* Testing: This is often overlooked but critical to the project’s success. While an entire post could be written about this alone, testing is not just validating with your users, it’s about having a solid strategy that goes from testing a single component in the code to testing the whole system and its integrations.
* Working environments: You should have at least one testing and one production environment up and running as part of the deliverables.
If you ever read the PMBOK (or any project management book really), then you know about the existence of the Communications Plan. This is a document that details how different pieces of information will travel through and through everyone involved in the project. It determines for example, if project status updates should be sent via email or delivered in paper in the context of a meeting. Or whether a change in a requirement will have to be communicated to stakeholders. The issue with this document is that it does not address a key aspect of the project, which is bigger than communication and that is collaboration.
People can communicate and understand each other clearly without ever achieving anything of value. When we talk about collaboration we mean the way people communicate by working together to achieve something. This is why we believe having a Collaboration plan makes much more sense. This plan document should contain detail about the teams involved in the project, how they will be working together (for example weekly meetings, daily stand-ups) and what collaboration tools will be used and to communicate what (Slack, Teams, Jira, SharePoint, etc.).
When you get to the point where wheels are already in motion, there are a few important aspects to consider.
A lot of companies relax at this point and let the contractors do “their thing”. This can’t be stressed enough: By any means find the time to be present checking the status of the project periodically. Rely on the Collaborations plan to make sure things are flowing, otherwise, a nasty surprise will surely reveal itself when the time comes to check the deliverables.
If you are not the one directly benefiting from the result of the project, make sure you check in with the real clients of the project every now and then to tap into any potential problems that could become bigger if left unattended. These people are much more invested and passionate about the project and will certainly let you know if they are worried about something. When that happens, it is time to talk to the contractor company and find a solution.
At the end of the project, the resulting product should add value to the current business state. This seems obvious but in the real world, just the opposite happens much more often than you’d think.
Nothing worse than a large, sophisticated and expensive system that does not solve a single problem for the users. Even worse, a lot of times this new system is there to replace a legacy application or a manual business process but actually manages to make things harder for everyone. Don’t be afraid to go back to the drawing board with the contractors until at least the larger part of the initial problem has been solved.
Make absolutely sure that you have everything you need to continue with the project once the engagement is over. This means things like source code, design assets, and documentation should be in your possession. It is strongly recommended doing an internal knowledge transfer (to whoever will be doing support) so all the deliverables in the package can be checked for sanity and consistency (for example, the source code should compile, deploy successfully, and documentation understandable by a human being).
So this concludes our suggestions about getting the best out of your software development contracts. It is true that practice makes perfect in this case and you may have to go through a couple of rounds to get more comfortable with a third party developing software for your company and learning the ropes on what things to watch out for. Having that said, we hope you find our suggestions useful.
If you can think of other aspects to take into account feel free to get in contact with me! In the meantime, I hope you find this information useful in your next project.