MAY/JUNE 2013

1.1 A project is a planned activity. Tasks are determined before they are carried out. Projects are
distinguished by the following characteristics:
- non-routine tasks are carried out
- planning is required
- specific objectives are to be met or a specified product is to be created
- the project has a predetermined time span
- work is carried out by someone other than yourself
- work involves several specialisms
- people are formed into a temporary work group to carry out the task
- work is carried out in several phases
- the resources that are available for use on the project are constrained
- the project is large or complex

1.2 Planning is the outline plan that is formulated for the entire project and detailed plans for each
phase of the project as they are encountered. This may include, but are not limited to, work- and
product breakdown structures (for the entire project as well as per phase), quality standards,
risk management and change control procedures, resource allocation, time management and
costing calculations.

1.3 Net profit is the difference between the total costs and the total income over the life of a
project. Disadvantage of net profit is that it does not take into account the timing of the cash
flows.

1.4 The payback period is the time taken to break even or pay back the initial investment.
Advantage the payback period is that it is simple to calculate and is not particularly sensitive to
small forecasting errors. Disadvantage is that it ignores the overall profitability of a project.

1.5 Risk is those threats that could prevent the achievement of the objectives given to the project
manager and the project team. Risk relates to the future and involves cause and effect.
Software projects have the following characteristics that make them particularly difficult compared
to general project management (FRED BROOKS!)

Invisibility – when a physical artefact is constructed the progress can actually be seen. With
software, progress is not immediately visible.

Complexity – per dollar, euro or pound spent, software products contain more complexity than
other engineered artefacts.

Conformity – Software developers have to conform to the requirements of human clients who are
inconsistent or not organised.

Flexibility – Software systems are particularly subject to change. Software systems are expected to
change when it interfaces with other components within a physical or organisational system.

2.2.1 Feasibility study assesses whether a project is worth starting – that it has a valid business case.
Used to confirm that the benefits of the potential system will justify the costs. Information is
gathered about the requirements of the proposed application. Development and operational costs
and value of the benefits of the new system are estimated.

2.2.2. Planning is the outline plan that is formulated for the entire project and detailed plans for
each phase of the project as they are encountered. This may include, but are not limited to, work-
and product breakdown structures (for the entire project as well as per phase), quality standards,
risk management and change control procedures, resource allocation, time management and
costing calculations.

2.2.3. Execution of a project consists of design and implementation sub-phases. Design is about
making decisions about the product to be created and must not be confused with planning.
A project is deemed successful is it is delivered on time, within budget and with the required quality.

Project portfolio management provides an overview of all projects that an organisation is

undertaking or considering. It prioritises the allocation of resources to projects and decides which
projects should be accepted and which existing ones should be dropped. The concerns of project
portfolio management include:

- identifying which project proposals are worth implementation

- assessing the amount of risk of failure that a potential project has
- deciding how to share limited resources between projects
- being aware of dependencies between projects
- ensuring that projects do not duplicate work
- ensuring that necessary developments have not been missed

4.1.1 This is the so-called classical model for system development and is also referred to as the one-
shot approach. This life cycle fits comfortably with project management because it views
development as a series of processes that are expected to be completed and planned only once for
the project. This model would typically be used in a traditional development environment where
most of the methodologies and technologies are regarded as stable, where the scope is clearly
defined, where similar projects have been undertaken and the development team can specify and
design a solution to a high degree of certainty.

4.1.2 This model is a variation on the waterfall model. The spiral models is best used when most of
the requirements are clearly defined, but only a small number of unclear variables exist, for
example, it is not clear how the users see the finished end-product’s functionality. It is an iterative
approach whereby additional levels of detail are added at each stage. The system to be
implemented is considered in more detail in each sweep.
4.2.1 This prototype tests some ideas and is then discarded when the true development of the
operational system is commenced. The prototype could be developed using a different software or
hardware environment from the final system.

4.2.2 The prototype is developed and modified until it is finally in a state where it can become the
operational system. In this case the standards that are used to develop the software have to be
carefully considered.

5.1.1 Parkinson’s Law – Work expands to fill the time available that is given an easy target staff will
work less hard.

5.1.2 Brook’s Law – The effort of implementing a project will go up disproportionately with the
number of staff assigned to the project. As the project team grows in size so will the effort that has
to go into management, coordination and communication. Brooks Law also states that putting more
people on a late job makes it later.

7.1.1 Risk acceptance – This is the do-nothing option. Some risks are ignored in order to concentrate
on the more likely or damaging risks. Damage inflicted by some risks could be less than the costs fo
action to reduce the probability of the risk occurring.

7.1.2 Risk avoidance – Some activities might be so prone to accident that it is best to avoid them
altogether.

7.1.3 Risk reduction and mitigation – risk reduction - This is if deciding to go ahead with the course of
action despite the risks, but take precautions that reduce the probability of the risk. Risk reduction –
attempts to reduce the likelihood of the risk occurring. Risk mitigation – is action taken to ensure
that the impact of the risk is lessened when it occurs.
7.1.4 Risk transfer – risk is transferred to another person or organisation for example outsourcing
development.

Staff costs – these include staff salaries was well as the other direct costs of employment such as the
employers contribution to social security funds, pension scheme contributions, holiday pay and
sickness benefit. These are commonly charged to projects at hourly rates based on weekly work
records completed by staff. Contract staff is usually charged by week or month even if they are idle.

Overhead costs – represent expenditure that an organisation incurs which cannot be directly related
to individual projects or jobs, including space rental, interest charges, and the costs of service
departments. Overhead costs can be recovered by making a fixed charge on development
departments or by an additional percentage charge on direct staff employment costs. These
additional charges or on-costs can easily equal or exceed the direct employment costs.

Usage charges – projects can be charged directly for use of resources such as computer time, instead
of being charged as an overhead. This will normally be on an ‘as-used’ basis.

The Gantt chart - This chart is used to indicate scheduled activity dates and durations frequently
associated with activity floats. The Gantt chart can visually indicate if a project is ahead or behind
schedule. One disadvantage is that this chart is very difficult to keep up to date.

The slip chart - The slip chart is a more striking visual indication of the progressing of activities than
the Gantt chart. The slip chart has a slip line that indicates the variation from the plan. The more the
slip line bends the greater the variation. The project manager can then decide to reschedule some
activities if the chart has a very jagged slip line.

The timeline chart illustrates the way in which targets have changed through-out the duration of a
project. Planned time is shown along the horizontal axis and actual time along the vertical axis. In
the ideal situation (no delays), the Planned Time and the Actual Time will correspond on the
diagonal. When one part of a project is delayed for a number of days, the completion time for the
whole project is delayed with the same number of days. On a timeline chart a delay in one part of
the project has an effect on all the other uncompleted parts of the project in that each of the
uncompleted parts shows the same delay. Keep in mind that a time line chart shows planned and
actual times of completion of parts of a project as well as of the whole project and not dependencies
of parts of a project on each other. On a timeline chart each part of a project’s time is measured
from the beginning of the project.
OCT/NOV 2012

The project manager should not

 add new resources
 compensate on quality
 skip steps in the SDLC
 give in on testing (quality)
 shorten critical path and then create another critical path

MAY/JUNE 2012

The project manager should

 Renegotiate due date / cost with client
 Revisit requirements (MOSCOW)
 Ensure effective resources are on critical path (re-allocation of resources)
 Schedule overtime
 Re-look tasks start dates to maybe start sooner
 Shorten critical path

OCT/NOV 2011

Software projects have the following characteristics that make them particularly difficult compared
to general project management (FRED BROOKS!)

Invisibility – when a physical artefact is constructed the progress can actually be seen. With
software, progress is not immediately visible.

Complexity – per dollar, euro or pound spent, software products contain more complexity than
other engineered artefacts.

Conformity – Software developers have to conform to the requirements of human clients who are
inconsistent or not organised.

Flexibility – Software systems are particularly subject to change. Software systems are expected to
change when it interfaces with other components within a physical or organisational system.
MAY/JUNE 2011

SEE 8.2 above.

JAN/FEB 2010

The following criteria can be used to assess and evaluate a project:

Net profit – It is the difference between the total costs and the total income over the life of a
project. Disadvantage of net profit is that it does not take into account the timing of the cash flows.
Having to wait for a return has the disadvantage that the investment must be funded for longer.
Longer term estimates are also less reliable than short term investments.

Payback Period - The payback period is the time taken to break even or pay back the initial
investment. Normally the project with the shortest payback period is chosen to minimise time that
the project is in debt. Advantage the payback period is that it is simple to calculate and is not
particularly sensitive to small forecasting errors. Disadvantage is that it ignores the overall
profitability of a project.

Return on Investment (ROI) – ROI provides a way of comparing net profitability to the investment
required. The advantage is that it provides a simple, easy-to-calculate measure of return on capital.
Disadvantage is that it does not take into account the timing of cash flows and also the rate of return
bears no relationship to the interest rate offered or charged by banks and is therefore potentially
misleading

Net present value (NPV) – This criterion takes into account the profitability of a project and the
timing of the cash flows that are produced. This is based on the view that receiving money now is
better than having to wait for it. The NPV for a project is obtained by discounting each cash flow and
summing the discounted values. Initial investment takes place immediately and is not discounted.
Later cash flows are assumed to take place at the end of each year and are discounted by the
appropriate amount. Disadvantage of NPV is that it might not be directly comparable to earnings
from other investments or the costs of borrowing capital.

Internal rate of return (IRR) – IRR attempts to provide a profitability measure as a percentage that is
directly comparable with interest rates. IRR is calculated as that percentage discount rate that will
produce a NPV of zero. Disadvantage is that it does not indicate the size of the return. Also, under
certain conditions it is possible to find more than one rate that will produce a zero NPV.
Boehm’s equation: effort = c* (size)*k
Variables in Boehm’s equation:
Effort: measured in person months consisting of 152 working hours
Size: measured in thousands of delivered source code instructions (kloc)
c and k are constants - The constants, c and k, depended on whether the system could be classified,
in Boehm’s terms, as “organic”, “semi-detached” or “embedded”. These relate to the technical
nature of the system and the development environment.

See Q5 – may/june 2013

Earliest Start Duration Earliest Finish

Activity label, activity, description

Latest Start Float Latest Finish

SEE Question 7 – MAY/JUNE 2013

RISK RISK REDUCTION TECHNIQUES

Personnel Shortfalls Staffing with top talent; job matching; teambuilding training and career
development; early scheduling of key personnel

Unrealistic time and cost Multiple estimation techniques; design to cost; incremental
estimates development; recording and analysis of past projects; standardisation of
methods
Developing the wrong Prototyping; task analysis; user involvement
user interface
Real-time performance Simulation; benchmarking; prototyping; tuning; technical analysis
shortfalls
Developing the wrong Improved software evaluations; formal specification methods; user
software functions surveys; prototyping; early user manuals
Gold Plating Requirements scrubbing; prototyping; cost-benefit analysis; design to
cost
Late changes to Stringent change control procedures; high change threshold;
requirements incremental development (deferring changes)
Shortfalls in externally Benchmarking; inspections; formal specifications; contractual
supplied components agreements; quality assurance procedures and certification
Shortfalls in externally Quality assurance procedures; competitive design or prototyping;
performed tasks contract incentives
Development technically Technical analysis; cost-benefit analysis; prototyping; staff training and
too difficult development

A project is deemed successful is it is delivered on time, within budget and with the required quality.
OCT/NOV 2009

SEE OCT/NOV 2011

2.2.1 PBS – Used to document the relationship between all products created in the project.

2.2.2 PFD – Some products will need one or more products to exist first before they can be created.
These relationships can be portrayed in a PFD.

2.2.3 Activity Network – shows the tasks that have to be carried out and the order in which they
have to be executed to generate one product from another.

What is prototyping: A prototype is a working model of one or more aspects of the projected
system. It is constructed and tested quickly and inexpensively in order to test out assumptions.

Two kinds of prototypes with a discussion of each: Prototypes can be classified as throw-away or
evolutionary.

Throw-away prototypes – The prototype tests out some ideas and is then discarded when the true
development of the operational system is commenced. The prototype could be developed using a
different software or hardware environment than that used for the final system.

Evolutionary prototypes – The prototype is developed and modified until it is finally in a state where
it can become the operational system. In this case the standards that are used to develop the
software has to be carefully considered.
How prototypes may eliminate risks and facilitate communication: (advantages of prototypes)

- learning by doing: can look back at a task and see where mistakes were made
- improved communication: users cannot get a feel for how the system is likely to work in practice
from a specification
- improved user involvement: the user can be more actively involved in design decisions
- clarification of partially known requirements: where there is no exisiting system to mimic, users get
a better idea of what might be useful by trying out prototypes
- Demonstration of the consistency and completeness of a specification: uncovers ambiguities and
omissions when implementing a specification on a computer
- reduced need for documentation: working prototype can be examined leading to less need for
documentation
- reduced maintenance costs: user can ask for modifications at the prototyping stage rather than on
the operational system
- feature constraint: if an application building tool is used then the prototype will tend to have
features that are easily implemented by that tool
- production of expected results: prototype helps produce accurate results to test input

Drawbacks and dangers of prototypes (disadvantages of prototypes)

- users can misunderstand the role of the prototype

- lack of project standards possible
- lack of control
- additional expense
- machine efficiency
- close proximity of developers

Pg 86

SEE QUESTION 8.2 – MAY/JUNE 2013.