What is a good IT development project?
This might seem like a dumb question, but our experience tells us that many IT departments focus purely on the delivery dates and neglect some of the other important aspects of a system. Delivery to time and budget is very important but it is not enough! What about what happens after you go live?
A new system go-live should not result in a surge in support activity. A new system should be robust and reliable; it should delight its users and the team who support it. A new system should be amenable to changing requirements. A well designed system and good documentation go hand-in-hand; and both are a consequence of a sound development process. Documenting the code after it has been written is not the same as producing high quality specifications before hand, and gives a very different outcome. Can your project control all this? If not, why not?
What is a good IT process?
To be of any use to a hard pressed project team, a process has to be both effective and comprehensible. Teams are always under pressure, so every step in the process must count. A mountain of manuals is just a big turn-off, so the process must have a clear structure which is easy to navigate.
An IT project is a team effort. All roles need to be understood - who is needed and when, and the essential skills. Everyone in the project should understand what deliverables they are expected to produce, and be able to explain all the bits that their deliverables depend on.
A good development process must also facilitate good project governance and assist resource planning and portfolio planning.
Systems maintenance is a major part of the cost of running most IT operations. A good development process must help with the maintenance and support of the new system once the initial development stage is over and the system is in use.
What are the basic characteristics of our approach?
Our approach is a collection of good practices and structure drawn from a number of established sources and methods. Because the structure is coherent, it is possible to "mix and match", using some aspects of the process and not others but without losing all sense of where you are.
The main elements of our process are:
- use of UML models to get a firm grasp of the business problem
- use of UML to produce a robust and unambiguous specification of the system solution
- an outline, up-front analysis to establish scope, priorities, development options, costs, system architecture
- robust requirements analysis before design
- incremental development of the working system
- robust design before code
- clear deliverables with a clear purpose
- clear role responsibilities