Complexity is not a problem

It should be expected if the system is to replicate your business processes

But ensure that it is well defined before coding starts

Your developer will only deliver what he is told to deliver
A detailed Requirements Document is an essential starting point

Get it agreed and signed off by all users and managers

Decide What You Want Before You Start Coding

The key to developing any new system is to be completely clear on the objectives of the system, what it should and shouldn't achieve, before starting on any kind of development.

If your Marketing and Operations Teams cannot agree what the system will do or won't do, then it will be impossible to satisfy the users or achieve your objectives.

Gather And Refine The User Requirements

After gaining agreement from the holders of the purse strings, the gathering of the User Requirements is probably the most important part of the development. Normally this is completed in a document with screen designs and detailed descriptions of what the system should do and how it will function.

Even if the decision about hardware or development technology has yet to be made (which is sensible given that the functionality is undecided) a document which describes what should happen when each of the commands is executed is a vital first step.

Project Management Methodology

The use of a widely accepted Project Management methodology (such as PRINCE2 or similar) is recommended as it is easier and quicker to have a standard method for repeatable project elements. Methodologies are normally built on experience, are proactive and ensure that everyone knows what to expect – where, how and when.

It is also quite normal to adapt the project management methodology to circumstances, but to stay within the control structures, thus making it quite usable for diverse projects, not just computer or systems projects.

Resolve Complexity

Most computer systems in recent times have been extremely complex as the technology has allowed huge improvements in development techniques.

Systems now have to interface with a variety of other systems, especially MIS, and functionality which new systems replace tends to be complex and organisation specific. A formal System Specification must be built from the User Requirements to address this complexity.

Don't Let Suppliers Control The Development

It is vital that you do not decide on software before the System Specification and Requirements are clearly agreed. There are thousands of suppliers of packages, bespoke software houses and database bureaux most of whom could do the job, but resolving them down to a few who are most closely matched to the Requirements should not be rushed.

Don't let yourself be “sold” a system. The selection process should focus on your requirements and systems strategy. A good Project Manager will be able to help with this process and improve the quality of the decision as a result.


The cost of failure is high!

A dynamic systems development methodology may be one solution

Prototyping modules for users to test before the final solution is decided

This will also reduce the development risk

The Cost Of Failure Is High

If the project is not tightly controlled it will result in wasted resources, time, money and a system which does not meet the objectives set out when the project was initiated. A system that needs immediate re-development because it doesn’t deliver is probably not what was asked for or promised.

It matters little to a packaged solution supplier if your implementation isn’t optimal, they have already sold you the package. Or a bespoke package supplier who has delivered what you asked for, but it isn’t what you wanted or is hugely over budget.

Prototyping may be the way forward for your system, but this has to be assessed before a supplier is contracted as it will be more expensive than a "turn-key" solution.

A good project manager will assess these issues and recommend a solution and then work damned hard to ensure that it does achieve its objectives.

A successful outcome then invest for success

Bring In An Expert

It is unlikely that most organisations (even large organisations) have the available resources to carry out a project like this without a stretch. Project Management for this type of system is complex and the learning curve for internal Project Managers can be an extremely time-consuming process.

It is often better by far to bring in an expert who will get the job done quicker, has no learning curve because they have done this many times before and can provide outside experience of what does and doesn’t work for similar organisations.

An "interim" or temporary Project Manager is all you need. There are no fixed costs for the organisation to absorb and you only pay for the time spent on the project. It is more expensive if you equate the daily rate to a salary, but it is considerably cheaper in terms of speed of delivery and total time spent on the project. Reduced risk, no learning curve and much higher chance of a successful outcome which meets your financial and marketing objectives.

Future Proofing

Your project manager will be able to input to the choice of software solution and the development process chosen and so manage to "future-proof" the development to a much greater extent.

It has been known for such old development technology to be used, that a complete re-development had to be kicked-off soon after the system is completed. "Upgrading the software" is not as easy as it sounds!

Telephone 01733 246474 for more information