icenet logo
 • Who We Are  • Who We Work With  • Want a Job?  • Contact Us
 • What We Do  • Latest News  • Handy Links  • Home
articles
think, create, inspire, learn, grow, share, discover, succeed, trust, work
 • News releases
 • Articles
 • Events
 • Newsletter
 • Case studies
Understanding the drivers

Welcome to the first in a short series of articles, which shall endeavour to provide guidance through the process of acquiring and implementing new IT solutions. The series will follow the path from start to finish and begins today with the all-important question – why are we doing this?

The need – or perceived need - for a new IT system can arise in many ways,
• a change in legislation making existing systems non-compliant;
• a significant change in the shape of the business – M&A activity, new product direction, geographic expansion or entity spin-off;
• technological redundancy; or,
• a move to reduce costs over the forthcoming years
Whatever your drivers you must be clear that the resultant benefits will outweigh, not only the direct costs, but the indirect costs and the risks to your business. The indirect costs associated with the time at least some of your staff will necessarily need to spend away from the task of delivering your business plan, whilst occupied with the project, become greater the longer it takes. Risks abound and if the system is mission critical, failure of the project could mean the end of your business. A formal risk analysis will include a reflection of those risks in financial terms, which can be added to a cost/benefit analysis.

The key steps at this point are:
Build, document and agree a cost benefit argument to support the decision. You will need to return to elements of this, not only with the supplier, when chosen, but also with senior management, to establish the ultimate success or failure of the initiative;

Document the requirements of the business the solution will need to satisfy. Do cover the ground but be pragmatic – an exercise, which allows the user free reign to define the ultimate solution will usually fail. The requirements documentation will form a key component of your Invitation to Tender – a document to be sent to potential suppliers to respond to. More of this subject in the next article.

Internally or externally hosted - your decisions on this subject may be influenced by proposals from suppliers, at least from a cost and security perspective, however, where you have existing infrastructure you might look to leverage in order to save costs or mitigate risks. Integration with other systems is also something to consider and, if so, then document the technological requirements too. These will need to take into account interoperability, scalability and fit to existing resource skill sets.

Build the core project team at this point, by assigning a project sponsor and a project director and/or manager. It may sound early, but these people will need to be involved throughout and their drive and focus will be essential to success. Make sure the project director is experienced, as they will establish the structure of the team required and take responsibility for delivery. If you don’t have a suitable candidate within the organisation, then acquire one on contract.

Next month’s article will examine the critical process of selection, in more detail, ensuring your requirements can be met and the supplier can deliver!

< back to articles




Corporate Responsibility Privacy Statement Copyright + Legal
site by face