Definitions

• Initial Requirement: This is the first stage in the project lifecycle and is the precursor to the IT development stages.
• Analysis: Analysis involves gaining a full understand of the requirement, identifying all implications, and breaking down complexities into a more easily understandable form. Above all, it is the job of the Analyst to add clarity.
• Design: Design involves planning a system to meet the requirement. Issues often arise during the design phase requiring further analysis to be performed.

The Importance of Good Design and Analysis

A good design results in a more rigorous system and more integrity in the data; a poor design is a work creation scheme for Support staff.

In addition to the support implications, a poor design impacts future development work. When a poorly designed database table sits at the heart of a complicated system, it is highly unlikely that this flaw will ever get corrected due to the high cost of re-development.

Thus for every subsequent change, the developer has to work-around the original flaws. The cumulative effect of every change being less than a 100% solution can prove very expensive not only in terms of providing a poor service to customers, but also in terms of time taken to investigate the often very complex scenarios and then to implement data patches to get around the problems.

As we are only human, it is inevitable that, with highly complex requirements, we are unlikely to get the design 100% right first time. Thus we are resigned to releasing software that is flawed from day one! It therefore follows that we should strive to produce a 'change process' that allows the heart of the system to be altered with ease. If correcting the core database tables and relationships were to involve equal or less effort than a corresponding inelegant work-around, then we would be well on the way to producing systems which improve with age rather than ones that become more cumbersome, more quirky and less maintainable.

Furthermore, working in teams that have complete responsibility for specific applications is more likely to encourage people to have a strong will to deliver 100% solutions based on the highest quality 'no holes' designs. The driving force behind this is the fact that the same team that develops an application will also support it. Thus the developers will be more inclined to aim for a 100% solution rather than settle for a poor design, and more inclined to include extensive error reporting rather than next to nothing, and more inclined to do thorough testing rather than just being happy that it compiles.

Never Underestimate the Hidden Risks of Interfaces!

Regardless of whether we are talking about human interfaces (e.g. between a 'Developer' and a 'Tester') or system interfaces (where systems exchange data), experience has shown that all interfaces are high-risk areas in terms of their likelihood of being the source of problems. When something goes wrong there is often a debate about on which side of the interface the fault lies; other issues include who owns the interface, who is allowed to change the interface, and so on.

By having different resources for roles such as 'Business Analysis', 'Technical Analysis', 'Development', 'Testing' and so on, responsibilities get blurred, details get missed and the management of changes identified at different stages is arduous to say the least. It is not difficult to identify problems with this approach; for example, unless the 'Tester' is aware of every line of code that has changed he could easily fail to test one or more branches of updated code.

Therefore, to minimize interfaces, we recommend that the development process should be undertaken by a single resource. This resource would either be an individual or a team of people with shared responsibility, depending on the scale of the project. This single resource should talk to users to clarify requirements, implement the change and perform pre-production testing. It should run the test results past the users for reassurance that the change delivers the requirements before releasing into LIVE and it should continue to own the project by providing support and enhancement services thereafter.

Preventing IT Disasters

How often have we heard that "procedures will be put in place" to prevent a particular IT disaster from reoccurring? Probably not as often as IT disasters have actually reoccurred after preventative measures have been put in place!

Although these procedures have the right intent, trusting people to follow them is a basic mistake. Whether the problem relates to security, software releases, data changes, handovers or whatever, every critical procedure must be supported by a system that forces people to adhere to that procedure. That is to say, it should not be possible to complete an activity where critical procedures have not been followed.