Johannesburg, 07 Sep 2011
We often hear horror stories about companies appointing a software partner and, many millions of rands later, deadlines are missed and excuses are made for non-delivery. I have personally seen it happen with companies that have invested in good business plans, only to be stumped by a software project gone wrong. With big blue-chip companies who have comprehensive support structures, the same can happen: project deadlines keep getting missed, often with unrecoverable costs to the business.
So how does one go about choosing the right partner to ensure delivery in software projects?
Do due diligence on your potential partner
Not doing a proper due diligence check on a potential business partner is probably the biggest mistake one can make. You're under pressure and the person you're dealing with seems impressive and knowledgeable, so you go for it - only to find down the line that deadlines have been missed because of all sorts of issues and excuses, despite your partner having the best intent at the project outset.
Choosing the right partner should not be done hastily. Meet the directors of the company and do your homework on them; check for judgements, get SARS clearance certificates, phone clients for references and physically visit the company's premises and meet key staff. Ascertain if the company has the appropriate support structures, ensure there is a culture-fit with your organisation and, most importantly, review CV's and meet the people who will be working on your project. Understand how the potential partner manages projects similar to yours - ask for evidence or get expert consultants to conduct appropriate audits if need be. It is also important to ensure that the company is in a strong enough financial position to carry the costs of default if contract milestones are not met.
Note the quality of the proposal
Make sure that the potential partner writes a high quality proposal, understands your requirements and has accurately presented them. The most senior staff are typically responsible for writing proposals, and the quality of the proposal will tell you a lot about the company and its people. Engage with the supplier in this process and ensure that they are on the same page as you.
Own the source code
If a software product can't be demonstrated, or is not demonstrably rolled out to a number of clients, you can safely assume that the vendor is designing and developing a custom built solution. Most corporate systems have a significant amount of custom requirements because, more often than not, systems are tailored around a business, not the other way around.
Unless a solution is truly pre-packaged and supported, insist on owning the source code and ensure that this is stipulated in the terms of your agreement. Also ensure that appropriate technical documentation is delivered on handover, and that it is written in a way that it can be maintained by an alternative development team if need be. I have seen a number of companies being held over a barrel for exorbitant licence fees for a system that was developed exclusively for them, has been paid for in full, and then they still pay development fees for software upgrades that they don't own. Solutions that demand licence fees are typically highly commoditised with large footprints, such as accounting, relationship management, web management or online retail packages.
Make sure you are charged a fair hourly rate
If you are using an independent contractor that has been supplied by a labour brokerage, then it is fair to add a 15% to 30% margin on the actual fee paid to the contractor, this fee is often negotiable. The recruitment agency typically needs to recover the costs of advertising, sourcing the candidate, negotiating contracts and paying salaries. Independent contractors demand higher hourly fees as the contract risk is on them. Bear in mind that bringing in "bodies" from agencies and having teams effectively under your management does have more risk associated with it as there is little recourse in the event of poor quality output.
Alternatively, if you engage with a software vendor as a supplier, a premium can be charged with the proviso that more value will be delivered than just a team of contractors. The best form of engagement in our experience is for the vendor to take ownership of the delivery of a project. In this instance, ensure that the vendor has all the right credentials, supporting infrastructure, design processes, technologies and, most importantly, academically qualified software engineers or computer scientists. Would you hire an unqualified engineer to build and sign off a bridge? The same level of engineering professionalism should apply in the design and delivery of a piece of software - in particular if it is core to one's business.
To mitigate risks on a project I would recommend that the software vendor commits to a fixed price based on the delivery of specific milestones. For bigger systems, an initial "paid for" audit is usually conducted, with the outcome being milestone-based pricing, a project plan, functional specifications and an application level architecture design. The quality of this document can also serve as further security in the competence of the vendor before launching into a project.
Is it cheaper or lower risk to hire your own software staff or to outsource?
If you perform the equation "(time to delivery) times (hourly fees) over (quality as a percentage)", a good software outsource partner should come out at a lower number than if the project was performed by your in-house development staff. By quality I refer to a product that is easy to maintain, user friendly and bug free.
One large client of ours conducted an independent productivity audit on some of our teams and the results were quite staggeringly in our favour when compared to output levels of their in-house teams (after all why pay more when you can hire your own cheaper?). There are a number of reasons for this that are too lengthy to cover in this article, suffice to say that the output levels of a specialist design house will always be higher than one whose core business is something else. After all, would you go to the headache of sourcing, hiring and managing permanent staff to electrify and cable your expensive offices or would you use the services of a specialist electrical and cabling company?
Over and above complete project outsourcing, we have had huge successes where we have taken over technical leadership and ownership of delivery of projects, often working side by side with existing in-house support teams - where often all that is required to speed delivery up is some specialist input and guidance.
What is the make-up of a good software outsource team
In our experience, the best outsource projects work where the software vendor is given full ownership of design and delivery (assuming the right partner of course). Notwithstanding, a successful project requires a project champion on the client side to facilitate access to key business and technical people. In our experience, a typical outsource development team usually compromises a team lead who handles the client engagement, staff management and full life cycle of the project. The team lead must have strong prior development experience to lead effectively. A technical lead (or architect) needs to be involved during the initial design phases, while the rest of the team is usually made up of a senior software engineer who is a development environment specialist, followed by intermediate and junior level software engineers with proven problem solving ability and qualification. We have found, even with the best design process and methodology, the single most important factor in a software project is the quality of the people on the job, both from an attitude and problem-solving perspective. A good outsource partner should have a knack for consistently identifying, retaining and managing such people; otherwise it's a case of hit-and-miss.
Finally, how is it possible to gauge if the software partner is doing a good job?
In our experience, the best way to ensure that a project is on track is to follow an "agile" approach, i.e., set lots of small targets and make sure that these are met and continually aligned with the project plan. Weekly progress report meetings are important because software projects are never exactly defined up-front and involve some iteration. Expecting a business owner to define a detailed specification in advance is not reasonable in a complex system, so a level of on-going refinement in the build phase is part of the process. We often create by seeing, so this level of flexibility must be allowed by the software partner.
Getting the architectural basics right at the outset of a project is the most critical part of the project. If there is any doubt about a vendor's ability, it is at this time - before development work starts - that a technical audit should be done to see if the design is a good one. Building a system on a weak foundation that has not been designed with change in mind, is a recipe for disaster. A good software partner should understand where the system (and business) can potentially go and should cater for this at design time. After all, all large scale systems evolve just like a good business!