Strategies for successful software system implementation
This article was written because we were being referred a number of businesses that were having show-stopping problems when trying to implement software systems either ones they had bought off the shelf or bespoke software solutions (often where the developer had become invisible!). This article will hopefully outline some strategies for successfully implementing a system and help your project get delivered on time and without too many problems – or at least minimise the number of problems you might have.
This seems like such an obvious thing, but it’s amazing how often people don’t spend enough time working out what they need from the system before starting the implementation. You should absolutely not start writing code until you know exactly what you want to achieve. If there is any doubt then ask yourself if it needs to be part of the solution, or whether it could be done in a different which isn’t part of your system.
A good way to work out what you want from the system is to put together a use case document. This document should be about 1-5 pages per use case and says who will use it, what they need from it and then outlines what needs to happen when that person uses the system – along with any other notes such as required data or how frequently something may occur. It’s also worth reading up on Use Cases if you aren’t familiar with them already.
Once you know exactly what you need (and there shouldn’t be much at this point) then it’s time to think about designing the system. I like doing this in Microsoft Word – using bullet points for each section of code. I can even have a separate paragraph for each function if it helps. It will probably only take you about an hour to do this – really! This is your opportunity to consider options and try out different ideas before you start writing any code – so use it well. What I’ve found as well (and what seems obvious now I think about it) is that functions which are used less frequently should be the ones with the most comments. This makes them easier for new people to join your team later on because they can read through those functions and get up to speed quickly.
From here you’re ready to write some code and implement it. You don’t need me to tell you that at this point though, right? Go forth and deliver some software!
No, not the testing that you will do yourself. I mean making sure that other people try it out. This is really important because if you’ve missed anything important no-one else will find the problem until you release it to them – at which point they can be very angry with you for wasting their time. To run your system past others here are some great tips; Ask questions in advance of when you want feedback so that they know what to look for – this helps ensure they actually look at what you need them to rather than just emailing back “looks fine”. Make the tests clear and concise . Don’t waffle on about everything just give a simple description of what’s required. Don’t make the tests too difficult or else you won’t get useful feedback. You can always add more complex test scenarios once your system is in production – but for now it’s best to keep them simple so that people will actually do them with little prompting.
Ask your testers what they think of the new version before you ask for any critical feedback . Having someone give you positive feedback about something that’s not quite finished yet feels great, but unfortunately if someone does this you can be sure there are some problems at this point with the system. If possible go back and fix these things before trying to get critical feedback on it. Make sure everyone gets an equal chance to test against all parts of your system so that no-one person is doing more work than anyone else. Get everyone to sign off on the testing so that you have a written record of what was tested and what feedback they gave – it will be invaluable when someone remembers something wasn’t working 6 months after you’ve fixed it. This is also great for making sure specific people are aware of their responsibilities in getting things back up if the system breaks .
Monitor what’s happening
It’s easy enough to implement software, but unless you know how it’s being used then you could be missing out on real business benefits or wasting time fixing problems with parts of your system which aren’t actually important. The solution to this is monitoring ! By using carefully chosen tools (eg some combination of database metrics, application logs, application performance data, monitoring information from the operating system) you can get to the bottom of problems much faster – and even discover new opportunities for your software to help your company.
I hope that these tips prove to be useful to you, if you want to discuss other ways to improve the chances of success of any bespoke software development projects or systems integration projects you are planning then feel free to contact us.