I was at a networking event the other day and got talking to someone who was venting frustration with some software developers who had been engaged to build a solution. The team were unsatisfied with the result, and the situation had become so bad that each request for further improvements was being ignored as the developers had virtually thrown in the towel. Unfortunately for the client, that makes it very difficult. Even if they could get access to the source code, another developer might not be able to make sense of the progress made in order to complete the project. To be fair, this happens frequently as a client will send a brief, but on seeing the result say, “Oh I didn’t mean that, I wanted this” as it is often very difficult to envisage the end result before you can see a test version. From the developers’ perspective, they have fulfilled what was requested and it’s sometimes difficult to unpick the logic and reframe it, so they feel they have to ask for more money. The client thinks they have been taken for a ride and the whole project falters. More often than not, it is a breakdown in communication, not the technology. Business owners may not necessarily appreciate the complexity of computer programming – thinking everything is as easy as tapping on an iPhone app – and geeks are terrible at explaining anything in plain English. A lot of time and money can be wasted going down an “Alice in Wonderland” rabbit hole by venturing out on such tasks without checking a few things first. The following is a list of safety checks to help clear the trees so that you can see the wood.
Be clear about what you are trying to achieve.
With advances in Technology some of the promises made about deliverables may be a bit exaggerated. Having a clear idea of the desired outcome keeps everyone from being distracted by all the possibilities. Writing a business case with current issues and expected outcomes is a good start. These should include:
- No more than a few sentences without any technical jargon. (e.g. automate the manufacturing process to increase production)
- This should set the desired goals and state clearly the advantages and disadvantages of the venture. (e.g. a disadvantage that is often overlooked is the disruption that will caused as internal staff will have time away from their normal duties required to test and be trained on the new system ).
- If possible return on the investment should be measurable by a known quantity. (e.g. improve efficiency by 75% or provide cost saving of 150k).
- Test the assumptions before the project begins. This can be done with a demonstration or technical trial to force a reality check. Few projects fulfil 100% of the stated objective, but if it gets to 85% is that still worthwhile to proceed? This will then provide some sort of contingency and document early warning signs of possible problems later. It also manages expectations for all sides and highlights areas of risk or limited knowledge.
The stated objective should come first as technology should always be the tool to arrive at the desired result. Once that is completed as best as possible you can then start the process of comparing options whether to build or buy?
Next in the series: Software, Off the shelf or do it yourself:
Malcolm Ford as a business systems analyst advising organisations on which software solutions are suitable for their operations. He has 25 years’ experience in a variety of sectors from international law to manufacturing, media to professional services. He applies his accounting knowledge to the entire workflow to improve sales through CRM systems, automating accounting processes or cost control through improving procurement. Check the services page for information.
