From the archive – first published 27/09/2013
We’ve been putting in business changing computer systems since the year 2000 and have picked up a few nuggets about how to make sure a potentially revolutionary computer system is accepted, works well and is loved by its users. So here I’ve tried to put together a top ten list of things to bear in mind.
It’s important to maintain a can-do approach to development. For developers and their clients to remember that generally most things are possible, though not necessarily within the established budget for now. New features should always be welcome to the developer remember that often it means more work, and that’s what we’re here for. It’s easy, particularly in the world of programmers for some reason, for a negative attitude to grow whereby the developers start to have the attitude of “can’t do this” and “can’t do that” because they focus on the extra work that’s required. But having a wish-list in place where new features can be thought about and put into a future phase makes a welcome discussion of the future exciting possibilities.
9. Adjustment and tuning
The things that make most difference to end users are very often very small programming changes, such as the rewording of messages, changes in terminology or a slight difference in navigation. Developers, and their clients really benefit from keeping focus and tenacity right through the later stages of the software, when people might be forgiven for thinking the development is complete. But taking into account the end-user feedback and treating it as an important phase of the development makes the difference between great software, and software which is truly a joy to use.
8. Expect the long tail
Similar to point 9 above, but just to re-iterate the point that the later stages of the development are very important and should be expected to last for years even though it might not involve very much work in terms of actual development time.
The client should be able to feel the presence of the developers in terms of easy access to communications and rapid responses so they never feel alone or not-listened-to. Emails should be responded to immediately, with phone calls whenever something is a little tricky to explain in the written word. Absolute priority should be placed on getting back to a customer to deal with misunderstandings or a lack-of-understanding as quickly as possible.
The software should fulfil a clear need and make things easier than they were before, not just applying a new technology to a system that worked perfectly well before.
Similar to presence but it’s all about choosing the right form of communication for the right situation, whether that’s email, sms, a phone call, instant messaging or physical presence. All communications are necessary and should be chosen at the right time. Also, bizarrely, it’s easy for the client, or the developer to get a little scared and avoid communication and procrastinate. This should be spotted and challenged as soon as possible.
If a software project starts to run out of resources, on either side (both developer and client) then it can quickly run into trouble. If there is a shortfall in the budget this should be identified as soon as possible so that the development can be focussed on the main areas of value. Once a suitable relationship of trust has been established then the resources can be more forthcoming as the client understands everything is being done as efficiently as possible to produce the end result.
There must be trust between the client and the developer. The developer must do all they can to maintain a professional approach regardless of how that affects the bottom-line. The client needs to be able to expect honest answers about the best and cheapest way of doing things as a matter of professional honour (for want of a better word) for the developer. This is a wise long-term strategy for the developer as well as a duty for the reputation of the industry as a whole.
Fixes must be forthcoming as soon as is reasonably possible even if it is a workaround until the actual fix comes out. The client needs to know that the developer understands how frustrating a problem can be, particular if problems start to build up and are not addressed. The worse thing is if the client’s staff start to reject the system because they feel problems are not being resolved. Resolving problems quickly makes the difference between repeat business and one-off developments and the developer is only as good, in the client’s mind, as their last job for them, so putting a fix in quickly limits the length of time a customer has a negative opinion of the developer.
Above all, both parties should not give up. There are going to be times when putting in a new piece of software can be very frustrating and all software needs to take some time to mature. But that period of maturing does not last for ever, in fact it’s only usually a few weeks and very soon the software becomes something the staff really take ownership of and take into their own hearts. Keep working towards this goal and do not give up until it is achieved.
I hope this list gives you some interesting thoughts on the success of software development projects. We all know of infamous examples of failed developments but with this strategy in place we know from long experience a great solution can be created with a rapid return on investment.