You have an I.T. Infrastructure in place. You’ve perhaps bought some out of the box solutions, but you’re left with the feeling that there are some simple changes that could be made to save you a lot of time. What if these different products could talk to each other? You could enter information in one product and have it automatically pushed through to another, or what if you could make a simple change in one product to allow you to do your job quicker? As Business Analyst and Developer for Fusion I.T. these are the sort of changes I assist firms with on a daily basis.
Here are my top 5 tips if you are thinking about making any custom changes to your software:
Making a Difference
It’s not always the easiest thing to quantify, but will your proposed development actually make a difference? How much time and/or money will the development save and, on balance, how long will the development take and cost. Here at Fusion we can assist by offering an objective viewpoint and working with you to put together a development proposal at no charge, just give us a call.
Get User Support
Once you know what you want to do, get the users behind the development as soon as possible. Discuss with them what you plan to do and most importantly what you hope to achieve and how it will benefit them. As a user, I find it can be very frustrating to have an application that I use daily upgraded and be in the dark as to why anything was changed (or where that button has gone!).
If it’s a major piece of development you may want to enlist one or more advocates from your super users (people who have used the system/process you are developing for a long time or have a lot of experience in it). Most people will enjoy this extra role and will welcome being involved in the development process.
Bite Sized Development
Don’t try to do too much development in one go, you wont benefit from the time and cost savings if it’s still in development! Prioritise the changes you would like to make; those which confer the most benefit should be higher up the list with things like aesthetic changes down the bottom.
Breaking development down into manageable chunks in this way assists everyone; particularly if you’re commissioning an outside developer to do the work. Working through a staged priority list you have a rolling assessment of how the work is coming along, rather than any issues only coming to light once everything has been completed and the development piece delivered to you.
Test, Test, Test and then Test Again
In an ideal world you would have a dedicated environment set up for testing; a true replica of your live environment dedicated to testing your new development. Whilst this is the best way to discover any problems, the cost of setting up this environment can be prohibitive. We can offer advice as to how best to test the new software without it impacting your users or the live environment; this could involve us hosting virtual servers and/or machines for this purpose.
Whichever way you go about testing, don’t rush this step. Spend some time actively trying to break the new development and then pass it on to some other users so they can try to do the same!
Once you have a working development piece in your hand it’s very tempting to unleash it across the firm so that everyone can get the benefit of it as soon as possible. But if something has been missed, even a small issue within the product can negatively affect users trust in it and could mean they don’t want or like to use it! So give it to a small subset of users first for as long a period as you feel necessary for them to actively put it to use and then extend that user group gradually to the whole firm. The slight delay caused by this will be well worth it!
Each piece of development is unique and the guidance above may not assist in every situation, but we’re here to offer the support you need in planning the development and, should you wish, do the work for you!
Gary Colclough, Business Analyst/Developer at Fusion IT Management Limited