Do It Yourself

One of the biggest competitors to any purchase of an external software package is your own internal software resources. Why not use your existing IT staff to develop a solution that meets your individual need? There are pro’s and con’s to both approaches, attached are some of the key issues you should consider when framing your decision about whether to spend money on internal resources or purchase an external software package:

• 1. Is the business process you wish to enhance something your developers have already completed projects in?
• 2. Is the technology chosen important? Could it change? Are your developers equipped to deal with new technologies?
• 3. Is it possible you will be making ERP upgrades or changes in the next 2-5 years that will require a re-write of the in-house solution? Is the solution scalable?
• 4. How quickly do you need the solution? Will you have time to wait on in-house developments?
• 5. How many other business critical projects does your IT team currently have on their plate? Where will your project fit in their list?
• 6. What is your attitude to risk? Is your development hinging upon one key developer? What happens should they become ill or change jobs?
• 7. What is the political landscape? Who will have ultimate project management responsibility should issues arise.
• 8. Are your internal costs and efforts fixed costs? When comparing prices are you considering that research has shown that IT projects which are in familiar areas are typically underestimated by a factor of 3. IT projects that are in completely new business processes are typically underestimated by a factor of 9.
• 9. Are you re-writing the wheel? How will you deal will enhancement requests? What are the risks and implications to program errors? What value do you put on these risks?
• 10. Is software development your company’s core competence?

External software providers come with their own risks. Important questions that need to be considered are:

• 1. How much experience do they have in the business process they propose to enhance?
• 2. What technology are they using? How often do they provide new releases?
• 3. What will happen to your solution if you upgrade your key components such as ERP or banking relationship?
• 4. When can they deliver? Is their a project backlog?
• 5. What other projects are they contracted to provide? Where will you be in their list of priorities?
• 6. What is the risk in the project? Have you a contract which safeguards your cash in case of specific vitally important issues?
• 7. Are you dealing with someone you can trust who has pull and power in the organisation to get the project completed?
• 8. What are the project costs? What are the future annual costs and how do they compare with internal costs to maintain a system? Has the company provided fixed costs in the budget or is it an open-ended project?
• 9. How strategically important is this project to the software provider? How will they deal with enhancement requests?
• 10. Do you trust this external company’s commitment to your project? Is it their core competence or something fundamentally new to the company?

The key mistake most people make is that software development is easy. Here are some examples of the work involved in software development:

• 1. Defining a development specification. This is part science, part art. Defining all the requirements, reports, and possible impacts for a new IT project is something you get better at with years of experience rather than a few weeks of hard effort.
• 2. Having a development team that can understand and translate a specification document is important. IT and finance need great communication to deliver a great IT project.
• 3. Does the code work? Has everything been thought of? What about scope creep? Is it likely that additional reports and functions will be required? Is the process complicated? Scope and project changes can often expand costing more and more internal funds.
• 4. How much time has been allocated for quality assurance? Validating software in a proper test environment is a time-consuming but fundamental part of any project often taking up more time than the actual technical development. Do you have someone experienced in quality assurance and test scripts?
• 5. Go-live support cross-over. Is this a standard procedure which will ensure that the software tested and validated is actually what you end up using in your live environment?
• 6. Once the project is live is their a structured method of dealing with software enhancements or issues?

This article was not intended as a destructive critique on in-house development projects. There are many companies who have engaged internal resources and got a solution completed at a price less than the project price of an external software provider. There are many other companies though who unfortunately have been hoodwinked by internal resources into “purchasing” a solution internally that takes longer than original estimates, has limited functionality, never goes live, and makes individuals indispensable to your organisation. Consider your alternatives carefully before doing it yourself.