Can you Find it – Business © 2017 THE FULL STORY…IT’S YOUR SYSTEM, MAKE SURE IT WORKSPublished in Can you find it Business Edition on Wednesday, June 1st 2015
FEW companies ever find the perfect software for their business – a package that does exactly what they want and no more.
For many, learning to live with the shortfalls and overkills of the nearest match is a sensible solution. For others, giving into this compromise is a huge false economy. Paying people to stick the wrong bit of information in the wrong place on the wrong screen “because it’s the only place to put it”, or to constantly re-key the same data into three different places because “the systems don’t talk to each-other” can really add up. A company with three staff each spending just 15 minutes a day working around a system’s shortfalls is likely to spend at least £15,000 on that extra time over five years.
Having your own system designed and developed is the obvious and often highly effective solution, but this approach comes with its own pitfalls and downsides. Software projects are notorious for cost and time overrun (400 per cent is average according to some research), and many projects never complete at all. But the business benefits are enormous if you get it right, so here are some pointers on avoiding common problems:
It is all too easy to duck the long-term cost issue, but it’s worth spending the time to do some calculations. If you think the bespoke option will make a department 10 per cent more efficient, what will that save you over five years? If it will give the directors better data upon which to base their strategies, what difference is that likely to make to the bottom line of the business? It’s hard to assign figures to these rather hazy benefits, but educated guesses are better than avoiding the questions altogether.
If you are an SME you probably won’t end up hiring a corporate developer, unless you’re an SME with a corporate-sized bank account. At the other end of the scale you may “know someone who can knock something out” for a few hundred quid. This sometimes works … in the same way that tossed coins sometimes land on an edge. In my experience, if someone talks numbers without asking questions, they’re just giving you the numbers you want to hear. To quote from a circular email: “If you can keep your head when all around you are losing theirs … you clearly don’t understand the problem.”
Between Big Blue and Student Grant lies a myriad of software development suppliers offering all kinds of approaches and aptitudes. If I were to value one attribute above all others it would be this: a business-side understanding of what’s needed. Unfortunately, in an industry almost entirely filled by technical minds, this is rare. Teaching someone to do basic programming is easy; teaching them to program well requires talent. By comparison, teaching someone what to program and why is akin to teaching houseflies to do the Lambada. Never underestimate the ability of a young, technically minded programmer to completely miss the blindingly obvious when it comes to the realities of business.
The test is relatively simple: Tell them what’s needed. If they come back with sensible questions, or can re-state what you’ve said in a way that shows that they’ve genuinely understood, you’re on the right track. If they ask questions that you think shouldn’t need asking, you can expect much more of the same if you proceed with a project. If they just say “yep, no problem” and start quoting technical stuff, nod politely while backing through the door as quickly as possible.
Start with the smallest possible set of functions with a measurable business benefit. Develop it, install it, work with it, then evolve it over time in bite-sized chunks. I’ve seen companies spend tens of millions on systems where the scope became so wide that by the time they were finished they were out of date and never even launched. (Now you know why cars and photocopiers cost so much …) If you want an all-singing, all-dancing system, you’ll find it on the top shelf just behind the flying pigs and the end of the rainbow.
Nowhere are fixed costs more important than with software development. Even if your supplier can only fix the cost a stage at a time (e.g. specification, then development, etc.) then get them to do it. Developers are often an optimistic lot, assuming that every project will pass without complication despite never having seen one do so. If you make overruns their problem too, then reality will soon kick in and you’ll all be pulling in the same direction.
Nothing generates new ideas like a new system. Genuinely good suggestions will come flying out of the woodwork, as do “essential” add ons that people forgot when the system was first discussed. It is hard to resist the temptation to add these ideas to the agreed scope, but resist you must. Unless something has changed to make a “scope creep” genuinely essential, it is usually better to continue with the existing specification and then add on the new bit in the next version.
My company has done a lot of development work on a remote-working basis – a result of corporate clients running out of travel budget by the fourth quarter of every year. We soon learned that when you’ve met face to face once, typed correspondence is almost always more effective than the spoken word when it comes to getting software designed and written.
Emails and internet chat programs ensure discussions are concise, accurate and – above all – traceable. Everyone knows exactly who’s said what to whom, when, and what was said in reply. Even if you can meet face-to-face, you’ll often find an internet chat conference or exchange of emails quicker and more effective.
As someone who’s managed lots of development projects, I know there are no innocent parties when it comes to causing problems. If a client is unavailable, indecisive, fickle, or just doesn’t like being “one of the team”, it can easily make a project impossible. Try to understand that there is bound to be a gap in understanding between you (the only expert on your business) and even the most intelligent analyst. You’ll need a lot of patience, some good communications skills and a willingness to give the project time, priority and focus.
It’s amazing how many projects go ahead with no contract whatsoever. To those who’ve been assured that their requirement is simple and therefore not worth writing down, there are two things I’d like to point out:
1. If you don’t have a contract that specifically grants you ownership of the copyright to the system and its code, you won’t own anything. In English law, ownership remains with whoever wrote it. I’ve had this little detail “pulled out of the bag” on clients more than once in the past year, and it’s not pretty.
2. Once you’ve started paying money and putting in time on a development project, the idea of pulling out and starting again can become quite unthinkable. You really don’t want to get caught in a “good money after bad” situation, so get a contract in place that prevents it.
Even for the smallest development, it’s essential to check mutual understanding of the requirement before anyone programs anything. You state what you want – in writing – and the supplier should be able to translate that into a detailed, written response showing how the system will fulfil that need.
Programming is typically only around a quarter of the time spent on a project. Planning, design, testing, implementation and support make up the rest. If your supplier can’t show that all of these stages are properly costed and planned, flag it as a problem.
I have never heard of a project where everything went exactly to plan – unless you count the projects where the plan included planning for problems that were unplanned. But that makes my head hurt, so I’ll move on.
You won’t get what you want at first. The supplier cannot realistically expect you to predict precisely what will work best, and this is why prototypes can be useful. Until you’ve actually tried to use a particular sequence of screens you can’t really expect to know the optimum way in which they should function – so make sure the supplier allows for a period of testing and adjustment.
Have you ever triple-checked some text before it went to print, only to have someone point out a typo on all 10,000 copies of the finished product? Any professional proofreader will tell you: you can’t proof your own text. The same applies to computer programs. A program that is not tested by two people other than the programmer will have bugs. Make sure there is someone who catches obvious problems before anything’s passed to you, and that you can test it on the real hardware, with as close to real data as possible. (It’s hard to tell whether the computer has retrieved the right information when half of it is “sdlkhjsdfjh”.)
A couple of weeks ago, one of my clients mentioned that he’d found a way to get a vital interface between two systems “knocked out for a grand” by “some bloke” he knew. I only hope that behind the deafening clang of alarm bells, I managed to explain calmly why this wasn’t a promising start.
As always, please feel free to email, call or write with your comments, questions and cries for help. And for those who are embarking on software projects, I wish you the best of luck.
© Joel Teague, 2015