Page 50 - DCAP307_PLANNING_AND_MANAGING_IT_INFRASTRUCTURE

Planning and Managing IT Infrastructure

Notes Some risks can be mitigated, some eliminated entirely, and others cannot be addressed by
you. In any case once prioritised in terms of likelihood and potential damage, they can be
mitigated or communicated to your business sponsor accordingly.
 People: Adding more people to a project can make it faster to a point. However in software
adding people very rarely tends to result in a linear increase in productivity. Hiring the
right people can be more efficient, but is far from easy.
Some organisations take the ‘lots of dumb people being told what to do by one or two
smart people’ route, others the ‘a few smart people all knowing what to do’.

Example: In the consultancy world, an organisation with a lower charge rate but
lots of people ends up costing much more deliver than a small number of people with
higher charge rates.

 Process: Reworking one’s process in order to be more efficient is an obvious thing to do,
but hard to achieve. Depending on the flexibility of your organisation changing your
process might not be easy, even if you know what it is to change.

Example: In order to deliver faster, changes mid-project tend to be limited and
small changes.
Retrospectives can be a good tool for identifying what the team thinks is required, but
don’t discount seeking outside help – someone from another team might have a different
take on things.
A far more common type of process change occurs when people make what is often claimed to
be short-term sacrifices in terms of software quality to deliver on time. Changes could involve
writing less developer tests, spending less time performing manual tests, stop pairing, or spend
less time ensuring consistent technical vision. When these changes really are short-term, and
time is set aside afterwards to repair the damage done, this may be a viable technique. However
those organisations which tend to drop quality in order to deliver faster tend to use this technique
more than any other, and frequently never spend time playing catch up – leading to a team
spending most of their time running from one disaster to another.
To keep control over the project from the beginning of the project all the way to its natural
conclusion, a project manager uses a number of techniques: project planning, earned value, risk
management, scheduling and process improvement.

3.2.2 Project Characterisations

In this section, different project phases and project life cycle are discussed.

Project Phases

Each project phase is marked by completion of one or more deliverables. A deliverable is a
tangible, verifiable work product such as a feasibility study, a detail design, or a working
prototype. The deliverables, and hence the phases, are part of a generally sequential logic
designed to ensure proper definition of the product of the project. The conclusion of a project
phase is generally marked by a review of both key deliverables and project performance to date,
to (a) determine if the project should continue into its next phase and (b) detect and correct errors
cost effectively. These phase-end reviews are often called phase exits, stage gates, or kill points.

Each project phase normally includes a set of defined deliverables designed to establish the
desired level of management control. The majority of these items are related to the primary

44 LOVELY PROFESSIONAL UNIVERSITY