|
Managing
Complex Systems
1. Definition of a Complex System
The implementation of complex software intensive or systems
integration projects is a high risk activity for both supplier and
customer. There are many dependencies including relationships,
organisational culture and IT maturity. No two projects are
identical and a successful project must achieve both the expected
business benefits for the customer and reasonable profits for the
supplier.
Previous success rates, (in terms of systems being delivered on
time, within budget and operating correctly to the satisfaction of
the purchaser,) have not been high. This is because the management
of such high risk, high complexity projects is intrinsically
difficult.
A complex system is likely to be one where any of the following
is identified:
1.1 Fundamental Technology Risks
- there is an integration requirement to a legacy system
- there will be hardware/software changes to standard products
1.2 Management Risks
- your existing IT capability or maturity is currently less than
will be required
- there is poor quality assurance either within the supplier or
customer organisation
- project management/general resourcing is inadequate
- the cost of the project as a percentage of your business
turnover is 10% or greater
- there are a large number of subcontractors to manage (in
excess of 2)
- there are misunderstandings within the project team
- there are frequent changes to the specification
- BPR is involved
1.3 Expectation Risks
- the specification is incomplete or ambiguous
- the specification is over-ambitious
1.4 Timescale Risks
- implementation timescale is particularly tight
- product may be obsolete by the time it is delivered
- cost escalation
- changes to staff within either supplier or client organisation
due to length of project
1.5 Risk Reduction
A small investigation into five systems development projects
found that:
- 28% of errors were due to incorrect specification
- 13% were due to deviations from the specification
Therefore about one third of the errors were introduced early in
the project life-cycle. Any method or tool which makes them easier
to detect before coding starts should pay handsomely. Spending money
at the early stages of a project is generally worthwhile.
One method of reducing risk is to compartmentalise or modularise
the system. Rapid Application Development and Prototyping techniques
are discussed in associated papers.
A complex programme should be divided into a number of discrete
phases each having defined entry points and exit/completion
criteria. The way in which these phases are linked together to form
the project process must be clearly understood and decision
checkpoint reviews held to confirm completion and approve future
budgets. There is obviously a requirement that a single person or
body within both supplier and customer accepts overall
responsibility for management of the project (See WP2 Section 5.3)
2. Fundamental Assumptions
We assume that you already have your Business and IT Strategies
in place. (See Workpackage No. 1 for more information.) You have
assessed your requirements and capabilities and have reached the
decision to acquire a system(s).
3. Processes and Procedures (Methods and Tools)
The choice of a good methodology, the tools used and a structured
approach at the outset is vital. Whichever you choose, stick to
them, don't take short cuts without serious consideration of the
implications and ensure you employ the appropriate skills and
experienced staff to manage the project.
Remember that flexibility and the ability to respond quickly to
changing circumstances must be built into any process or procedure.
Formal methods should be seen as 'hand rails' supporting the
planning process and not 'hand cuffs' preventing innovation.
As a purchaser, two additional reasons why you should have an
interest in tools and procedures are:
- to understand the methods and tools your supplier intends to
use, and to assess these for suitability
- to ensure that they are compatible with your own existing or
planned methods
There are three types of method and tools
- those whose purpose is to assist the manager to control the
project through its life cycle
- those which relate to the generation, visibility and control
of technical products and are used at a specific point in the
life cycle
- integrated sets of methods and tools which lead to further
improvements in productivity, teamwork and communication.
(Integrated Project Support Environments (IPSEs))
All the potential benefits described so far can be achieved by
the use of appropriate in-house standards and procedures, but the
cost is likely to be high. The advantage of using proprietary or
other standard methods are:
- proprietary methods have been devised and developed over time
using the practical experience gained from many projects
- it may be possible to recruit staff who already have
experience of the methods (e.g. PRINCE, PROMPT, SSADM etc.)
- a wide range of tools are likely to be available because the
cost of developing them has been spread over many organisations.
However, the cost of introducing methods and tools should not be
underestimated. They include:
- staff training
- hardware/software necessary to support the tools (capital and
revenue)
- early stage loss of productivity
- possible consultancy to introduce the method/tools
- additional systems programming incurred in acquiring and
supporting the tools.
The greater the difference in procedures invoked by the new
method or tool - the greater the cost. Despite these often
substantial costs, the cost of not investing is likely to be much
greater because it will lead to a steady decline in the
competitiveness of the whole organisation.
We suggest that you refer to the STARTS Purchasers Handbook
produced by NCC - National Centre For Information Technology for
further information on Methods and Tools and the CCTA
"Intelligent Customer Guide".
4. Quality
Investment at the start of a project to create a detailed and
agreed Quality Plan or Project Definition Document will be well
rewarded. It is a fundamental part of the process - not an
after-thought or "add-on".
The Quality Plan defines the "who, what, when and how and
should include:
- procedures and processes to be applied, checkpoints and audits
- technical standards to be followed
- configuration management plan
- change management process and procedure
- key responsibilities
- monitoring and support process - steering group definition,
reporting procedures
- top level project plan with key dependencies
- acceptance criteria, responsibilities for producing test
specifications, scripts, data etc.
- outline skill and resource plan together with role definitions
- risk management procedures
5. Risk Management
Having a clearly defined project plan together with the
supporting management processes will certainly highlight potential
risks and can contribute to reducing them. A further, more detailed
paper has been produced on Risk Management which you are advised to
consult for guidance.
6. Summary
Every systems development project is subject to risk. Some risks
are more significant than others but all are manageable, (to a
greater or lesser degree). The only certainty is that without a
strategy and plan, good methods and tools, failure is more likely
than success.
To achieve a successful project you need to:
- produce an unambiguous specification of requirements (See WP1)
- continually monitor the planned deliverables to ensure that
projected benefits will be achieved and that the business
environment has not changed to such an extent that the project
is no longer valid
- select a supplier who is able to produce the required system
on time and to budget by the use of appropriate tools and
methods
- develop appropriate supplier/customer relationships (see WP2)
- ensure that effective quality control and assurance techniques
are used
- define and agree with the supplier, Acceptance Test
specifications early on in the project
- ensure that, long before the system is installed, plans and
facilities for maintenance are in place
Press
here to go to managing projects mainpage < |
MANAGING PROJECTS