Software
development projects, especially bespoke solutions, are
notoriously high risk and can end up running over budget and way
past the project deadline which is why there is a need for a strong
process that works time and time again. Unfortunately the
Government's many IT projects are often an exemplar of what can go
wrong.
People, Process and Management.
The key ingredients to ensure that any project will be completed
on time and on budget are people, process and management.
People
The most valuable resource to any development project are the
actual people that carry out the work, and to ensure all the other
elements fall into place you need to obtain a team of developers,
programmers and project managers that show the following
characteristics:
- High quality, very talented
- Experienced and qualified
- Work quickly and precisely
- Very supportive, strength in depth, team work
- Excellent client service skills and the ability to
deliver.
Once these core strengths/traits are the backbone of a
development team then it is already halfway there to ensure
successful outcomes. But to obtain success then a precise and
quality process needs to be applied to enable milestone to be
achieved and the roll out of the various project phases before
general release.
Process
Behind a process there are varying methodologies that can be
adapted to fit a system that suit the particular development team,
or they can follow industry specific standards such as RAD (Rapid
Application Development), or RUP (Rational Unified Process).
Neither methodology is better than each other but they do outline
common pathways to follow.
The main principles to a successful process are that it always
firstly needs a set of "Requirements". These are "full breadth"
business needs, i.e. encompassing all areas, but not necessarily
"full depth". Requirements should cover both functional and non
functional (e.g. security, audit, accessibility, performance)
aspects.
The following points outline the characteristics that are sought
after:
- Easy to read and understand by categorising requirements into
meaningful/logical groups
- They are consistently at the right level, and not "spikey"
(some areas covered more thoroughly than others, or worse still
inappropriately technical in some areas)
- Each Requirement records important cross reference information:
the source, priority, and also whether it is a new/changed, or
existing requirement
- Uses nomenclature or annotation to differentiate between
Mandatory and Wish List requirements
- Coverage of Non-functional requirements - these should not be
underestimated, as they are often forgotten, or partially
represented, and can be often the downfall of a Project.
Non-functional requirements include issues such as the required
performance of the software, what screen resolution it should work
in and whether it needs to support multiple languages or character
sets.
The second principle to be included in the process is the
Specification which is absolutely necessary. Use Cases are one
widely adopted approach to capturing a detailed spec, and it is
strongly argued that you cannot develop effectively without them.
The Use Cases and Supplementary Specifications are written against
a Requirements document to capture much more depth on the
functional, and non-functional requirements respectively. Use Cases
are an excellent medium to capture and review specifications with
the business users/project team and development team. Once
signed-off the development team can proceed to design, and develop
the system. A good notion to work to when devising a specification
is "If it's not in the specification, then it can't be developed."
And if you're outsourcing a project, if it's not in the spec
then the supplier can justly not deliver that aspect of the
solution.
Investing significant amount of time into the design ensures
that solutions that are typically resilient, robust, scalable, more
supportable, and extensible. In common with any problem that has to
be project managed, risk management is key to ensure that software
investment works. Identify risks, develop mitigation strategies,
and monitor risks as all projects have risks that need managing. A
lot of process is geared around lowering the risks on projects,
enabling the team to proceed confidently, and with pace. Developing
in iterations, i.e. carry out cycles of development/technical
testing/user testing, offers the following advantages:
Prototyping
Breaking a project into iterations also allows the use of
prototyping which becomes a very important element to ensure
software investment is not wasted and the milestones are on track
to being reached. Without prototyping most projects would more than
likely end in failure, there are essentially 3 types of prototyping
which are:
- Pre-contract ("wow") - These are created to show the abilities
of the technical team, typically in website design/creative
thinking, and hopefully provide some "wow" factor.
- Requirements stage ("light") - Again an element of proving
abilities and competence, but more aligned to actual
requirements.
- Use Case stage ("full") - Most prototyping is done at the Use
Case stage, and complement the words with a picture. Incredibly
important to agree the system framework at the start of the
development project.
Typically the following aspects are demonstrated during
prototyping:
- Look and Feel (Aesthetics)
- Navigation
- Workflow
- Key screens, new screens, or types of screens (e.g. Search, and
List View)
- The early stabilisation of the system "framework" is key.
Data migration is generally carried out towards the end of the
project, but some project teams look to complete data migration
from the source/legacy system at the start of the development
stage. By developing a repeatable data migration routine which can
be re-run at any time the project gets the advantage of developing
and testing using real data - this makes testing a lot easier and
provides confidence for go-live. It also tends to help increase
acceptance and adoption of the new software by ordinary users as
they see data they recognise in the new system.
The whole approach from specification to go-live is geared
around making the implementation as smooth as possible, and can be
achieved by following a few key steps throughout the process. At
the start of a project agreement is required on how implementation
may look - this provides focus on the final delivery, plus enables
the management of expectations. Data migration is completed at the
start of the project; hence all testing is completed against real
data. This increases the accuracy of tests, and provides confidence
for go-live. Confidence in the system, and use of live data,
creates an air of familiarity with the deployment process, and
ultimately go-live is seen to be another deployment.
Evidently the requirements that are submitted and developed
against at the start may not necessarily be those that end up being
deployed due to changes in direction and needs of the business that
are discovered during the process. A common sense approach should
be adopted as it is inevitable that changes will occur during the
development, therefore communications should be open between
business and project team about changes (both + and -), and the
importance of having a strict change control regime to protect
project timescales and budget.
Summary
Making a software project work
needs a project manager to apply good governance, structure and
process from the start. The 3 key attributes of People, Process and
Project Management should be in place and are overall accountable
for success.