Software Development
Risk Management
 The first thing to accept is that software
development is unpredictable. No matter what new fangled software is implemented
and how many function points are estimated, experience has shown that making the
target date (let alone achieving the desired quality outcomes), is a hit and miss
affair.
Risk may arise due to loosely defined requirements, difficulties in estimating the
time and/or resources needed for the software development, dependence on individual
skills and rapidly changing requirements due to changing needs.
Here are some thoughts on how to make the unpredictable a little bit more predictable.
Spend more time setting objectives
Project objectives are important. A project should not be initiated without well
thought out objectives. Spend time analysing what the project is trying to achieve.
The project objectives need to provide guidance to the programmer for every programming
task. Pin up the objectives for each programmer to see.
Here is an example of setting an objective. I was asked to analyse the requirements
of a busy manager. His manual filing system was constantly in use, and never in
order. A system was needed that would maintain the current details, and ensure that
records could always be found. That was easy enough. However, during the interview,
the phone rang constantly, with requests for information. The objective finally
agreed on was "Eliminate the phone requests". This led to a very successful solution,
but completely different to that originally envisaged.
Having set the objectives of the project, do an exhaustive analysis of how the objectives
can be achieved. This should eliminate unrealistic objectives – like "The best and
nicest and cheapest and quickest".
Do not spend too much time gathering requirements
Rigid analysis stifles programmer and user creativity. It is also no guarantee against
a software disaster. Where the documentation of the requirements runs into several
volumes, it usually guarantees a software disaster.
Users frequently do not know what they want, but they will recognise it when they
see it! What was the original requirement may not be what was wanted at all. Rather
spend time on creating a solid project framework that will enable you to achieve
the major objectives.
Break a project into multiple tasks
Wherever possible, a large project should be broken into smaller tasks. Each task
will then be more predictable with less to do and less that can go wrong.
The initial programming task should be to create a framework with minimal functionality.
Create dummy procedures to show the style and the intent – it is important for the
users to see the "look and feel" of the project early in the development cycle.
It is equally important for the users to get involved right from the start. What
you want is users to start "owning" the project.
With the project objectives soundly set, the basic functionality should be subject
to little change. The dummy procedures can be completed once the project concepts
and design have been approved. Later tasks can then add the "bells and whistles".
The project must be "infinitely modifiable"
The project must be designed so that it can handle major changes to requirements.
With a soundly defined framework and infinitely modifiable design, the effect of
users changing their minds will be minimal. As will the consequences of new or better
ideas as the project evolves.
There needs to extensive thought on how an "infinitely modifiable" system can be
created. This must be done before any programming is initiated. "Top down", modular
design standards will help.
The consequences of having a rigid system are unpleasant. When change occurs, and
it will, you will have very unhappy management when the target date needs to be
extended. Equally unpleasant is to send the programmers on a "death march" to get
the project finished on time.
Do not use new or complex technology
Using straightforward, tried and trusted Software provides a head start. There is
always some advantage in using the latest version of software – but there can also
be a heavy cost. If new technology is essential for the project, then an independent
trial of the software is needed to ensure adequate technical knowledge and that
all the software bugs have been ironed out (are they ever?).
Relying on immature software with limited programmer exposure to the software is
a recipe for disaster.
Hire only the best and brightest
The success of a software project is mainly dependent upon the abilities of the
developers. They determine, more than any other factor, the viability of a project
and have a tremendous influence on productivity.
A few tips: The successful applicant should have a keen sense of humour (see De
Bono and Lateral Thinking) and a good grasp of idiomatic English. Excellent communication
is all important.
Do not proceed with a large project where the best and brightest have recently left
the company. The company will be suffering from the "skim milk" syndrome – and you
need the cream of the crop for successful development.
Reusable code
It is always productive to collect a large library of reusable code. The procedures
should be used to standardise: error handling, database access, edit routines, grid
handling, etc. The reusable code will reduce debugging times, as each procedure
will be called multiple times. It also lessens the amount of coding needed. See
the page
Reusable Code – A Management Issue
|