Yesterday we looked at several reasons why IT is sometimes a highly costing failure- but today we're going to look at the other side of the coin and look at successful components. Most of these are pretty straightforward but some are quite specialised (and therefore) not well known.
The first major point is that users should be kept involved with the system from start to finish and their feedback should be valued as ways to improve, include more features in or make the system more efficient than it was before. Otherwise, were you not to include them, you would most likely end up with a really great system that is also...really useless.
If no-one can use it- it's a waste of money.
To be successful make sure that people who need to use it can and that their needs are met, as even a well-made and user friendly system can fall short on utility.
The next point kind of rolls over into the third point as well- but, in short, get the right people for the job.
You wouldn't ask a carpenter to bake you a cake and you wouldn't go into an industry that you knew nothing about without help. Thereby, make sure you have particular expertise (or you are connected with people that do) in an industry before developing software for it. If you go into it blind you might as well not go into it at all as you're not going to make the slightest bit of difference.
Be prepared, knowledgable and strong and you won't fail!
The third point is more a common sense point than anything else, but, really, you'd be surprised how often it comes up as a major stumbling block.
While you may need people with particular skills and experience, in any IT project you will also need to rely on a great deal of business orientated people. Your tech guys may have some idea of what they're doing, as may the users- but do you? Are you sure this meets your aims? Is it even attempting to meet your aims? There's so many questions that can only be answered by business orientated folk as there are so many that can only be answered by your tech guys.
See things from both sides and you'll notice that there's a greater deal of integration between the two sides of a very similar coin.
The fourth point is to use the correct method to approach your IT project. Again this could be considered a point of almost common sense- but, if you don't know/aren't too technology savvy- you could easily back the wrong horse and lose out for it.
If you don't know what you need then research it, ask your tech guys, see what other technology is available and even go so far as to ask other organisations what they use. Some things like Microsoft Office are so widely integrated it's almost painful to think that you might not be able to use it, but other things like databases and bespoke software is not. It's there if you need it but easily ignored if you don't.
Research, plan and look forward to the future.
The fifth is quite simply "Simplicity is the name of the game- so follow suit."
These days a lot of software packages are becoming insanely easy to use and so much so even the most novice users can work with them. Coding complex software that requires a whole host of features is a great way to go for utility...but for practicality, not so much. There are far more transferable skills in IT than there were ten years ago so take advantage of them!
Don't work yourself in a hole where the only way you're going to advance is by coding even more features into something if it could be done easier, more stream-lined and more familiarly for your staff.
The sixth being the need to always anticipate change.
Change (much like risk) is a staple element of the business workplace and there will always be a need to change something around. If you can see a large fundamental change coming- make sure you get there before it does. Nothing can cripple an IT system more than if it has to have several months of lead-on development to make up for something that could've been easily avoided.
Keep note of the trends that may affect your software and implement those changes early rather than late in the day.
Next we explore whether or not a project has a strong concept or not.
Technically speaking, a lot of things are a good idea. A new ordering system. An online reservation system. New technology in the offices. There's so many things you can easily say "Well, that would be useful" to and so little things that you could prove will be useful.
Good concepts are like buses- you wait around forever and when one comes along so do a number of them.
You have to be able to ascertain which concepts are actually going to prove to be not only worth the time, money, effort and resources but also all of the implementation and operation time.
But, if you've come this far then I dare say you're probably on the fast-track to a great idea- just make sure it's as solid as can be. And that proof can be given, somehow, somewhere, that it can actually either increase efficiency or generate returns.
Along the line from that, the next point is to keep decisions simple and concise.
Nothing is worse than when you start creating complex decisions that require a number of factors to actually come to fruition. Not only does it frustrate people- but it takes an incredibly long time to get all of these factors together in a balance, therefore, its practically goes down the chute and you're back to square one.
Thereby always try to make your decisions bite-sized so that people can understand what the next point is and why. This will improve efficiency, make the process more transparent and increase the possibilities of success.
The ninth point covers a great deal of the theory of implementation.
Always keep implementation and deployment in phases and incremental so that changes can be seen almost immediately for all concerned. While it can be a lot easier to explain a piece of software when it is nearly (or already is) finished- that's going to take time. Time you don't have. Every minute you're not proving that this software is going to make fantastic returns is another minute going towards the everso common "This is costing too much/taking too long/draining too many resources etc." speech.
Show progress in parts not only to show that something has actually been done but also to help introduce new users to complex procedures.
Our final, and tenth point, is to use your experiences wisely.
There's an old adage with coding "If it's logical it's going to happen again" which means- if something goes wrong with this database this time, it's like that the next (and the time after that) is going to fall victim to the same error. This is because almost all of the time software is logical. If there's a fundamental error it's going to be there for a while.
At the same time if you realise that you're pushing the software beyond a limit and it's always hanging up the process- don't do it. Or, on the positive side- if you are successfully implementing certain parts of a package, well, try to make it even more efficient!
The sky is the limit with success but there's only one place it's going if it fails.
And that's it!
Thank you for reading. If you have any comments (or maybe some really good recipes for success) let us know in a comment on any of our social media sites.
All information presented here is © copyright Carkean Solutions Ltd., 2010 - Not to be used without our permission - The views expressed here are the views of an individual not the corporation
No comments:
Post a Comment