Software Project

Management
Program Management

 A group of projects managed in a coordinated way to gain benefits that

would not be possible were the projects to be managed independently.
 Programs may be
 Strategic
 Business cycle programs
 Infrastructure programs
 Research and development programs
 Innovative partnerships
 Program Management
 Strategic
Several projects together implement a single strategy. For example, merging two
organizations will involve many different activities e.g. physical re-organization of offices,
redesigning the corporate image, merging ICT systems etc. Each of these activities could
be projected within an overarching program.
 Business cycle programs
A portfolio of projects that are to take place within a certain time frame e.g. the next
financial year
 Infrastructure programs
In an organization, there may be many different ICT-based applications that share the
same hardware/software infrastructure
 Research and development programs
In a very innovative environment where new products are being developed, a range of
products could be developed some of which are very speculative and high-risk but
potentially very profitable and some will have a lower risk but will return a lower profit.
Getting the right balance would be key to the organization’s long-term success
 Innovative partnerships
e.g. pre-competitive cooperation to develop new technologies that could be exploited by a
whole range of companies
Program managers versus project
managers
 The program manager may well have a pool of staff upon which to call.
He/she will be concerned with ensuring the best use of staff e.g ensuring
that staff have regular work with no periods of enforced idleness between
project tasks.
Program managers versus project
managers
 Program manager:  Project manager:
 Many simultaneous projects  One project at a time
 Personal relationship with  Impersonal relationship with
skilled resources resources
 Optimization of resource use  Minimization of demand for
resources
 Projects tend to be seen as
similar  Projects tend to be seen as
unique
Managing the Allocation of Resources
within Programs
 Resources shared between concurrent projects
 Projects sharing resources:
During the resource allocation phase of project planning
– some project activities could be delayed while waiting for a resource to
become available.
 Strategic programs

 Based on OGC approach

 The initial planning document is the Program Mandate describing
 The new services/capabilities that the program should deliver
 How an organization will be improved
 Fit with existing organizational goals
 The program director should be someone who is in a prominent position in the
organization so that the seriousness and commitment of the organization to the
program are made clear.
Next stages/documents

 The program brief

 equivalent of a feasibility study, with emphasis on costs and benefits
 The vision statement
 explains the new capability that the organization will have
 The blueprint
 explains the changes to be made to obtain the new capability
 Aids to Program Management
 Dependency Diagram  Delivery Planning

B Corporate G Implement
image design corporate
interface

C Build
A System Common
F Data
study/ design System
Migration

D
Relocate E Training
Offices
Some Reservations about Program
Management

 Focus on structure – e.g. who reports to whom, at the expense of process

– e.g. the basis on which decisions are made.
Benefits management

 Providing an organization with a capability does not guarantee that this

will provide the benefits envisaged – the need for benefits management
 This has to be outside the project – the project will have been completed
 Therefore done at the program level
Benefits management
 Benefit profiles can be produced that document when and how it is planned
that the benefits will be experienced.
 As different components of the new capability are developed, a series of
tranches of projects (projects grouped in different steps of the program) may
be completed, each with a set of associated benefits.
 The achievement of benefits might be made the responsibility of staff who
are designated as business change managers. To carry this out, you must:
 Define expected benefits
 Analyze balance between costs and benefits
 Plan how benefits will be achieved
 Allocate responsibilities for their achievement
 Monitor achievement of benefits
Benefits
 These might include:
 Mandatory requirement
 Improved quality of service
 Increased productivity
 More motivated workforce
 Internal management benefits
 Risk reduction
 Economies
 Revenue enhancement/acceleration
 Strategic fit
Quantifying benefits

 Benefits can be:

 Quantified and valued e.g. a reduction of x staff saving salary
 Quantified but not valued e.g. a decrease in customer complaints by x%
 Identified but not easily quantified – e.g. public approval for an
organization in the locality where it is based
An approach to planning software projects
 Stepwise Project Planning
1. Select project: There must be some process by which the project to be executed
was selected. Chapter 3 on project evaluation looks at this in more detail.
2. Identify project objectives: It is important that, at the outset, the main
stakeholders are all aware of the precise objectives of the project.
3. Identify project infrastructure: This may not be a significant step where you
are working on an in-house project in a very familiar environment. However, where
the project is being carried out for external clients, you may need to investigate the
characteristics of the environment in which the project is to be carried out.
4. Analyse project characteristics: Different types of projects will need different
technical and management approaches. For example, a project implementing
control software embedded in industrial equipment will need a different set of
methods than a project implementing a business information system. A multimedia
application would again need a different set of activities.
5. Identify products and activities: With software projects, it is best to start by
listing the products, both deliverable and intermediate, to be created. The activities
needed to create the products can then be identified the outset,
 Stepwise Project Planning

6. Estimate effort for activity.

7. Identify activity risks: Having assessed the amount of effort and the elapsed
time for a project, the reasons why these might vary during the actual execution
of the project need to be considered. Where there is a very high risk of additional
effort/time being needed then actions to reduce this risk may be formulated.
8. Allocate resources: With software projects, these resources will mainly
be staff, but could be equipment, etc.
9. Review/publicize: It is no good having a plan if no one knows about it
10. Execute Plan.
11. Lower level planning: Not all of a project, especially when it is large, can
be planned in detail at the outset. Not all the information needed to plan
the later stages will be available at the beginning: for example, software
development cannot be broken down into precise sub-tasks with realistic
target times until more is known about the overall design of the system
is known.
Step 1: establish project scope and objectives:
1.1 Identify objectives and measures of effectiveness – ‘how do we
know if we have succeeded?’
1.2 Establish a project authority – ‘who is the boss?’
1.3 Identify all stakeholders in the project and their interests –
‘who will be affected/involved in the project?’
1.4 Modify objectives in the light of stakeholder analysis – ‘do we
need to do things to win over stakeholders?’
1.5 Establish methods of communication with all parties
Step 2 Establish project infrastructure:
At the same time as establishing exactly what the project objectives are,
the person responsible may know little about the organizational
environment in which the application is to be developed and
implemented. The actions in Step 2 address this problem.

2.1 Establish a link between the project and any strategic plan
‘why did they want the project?’
2.2 Identify installation standards and procedures
‘what standards do we have to follow?’
2.3. Identify project team organization
‘where do I fit in?’
Step 3 Analysis of project characteristics:
Step 3 is about examining the nature of the application to be built and
the environment in which it is to be built and implemented and
identifying the most appropriate technical approach.
3.1 Distinguish the project as either objective or product-based. ‘Is
there more than one way of achieving success?’
3.2 Analyze other project characteristics (including quality based
ones) ‘what is different about this project?’
3.1 Objective-based versus product-based projects. With a
product-based project the developers have to create a product, the
specification of which is often (but not always) clearly defined. In an
objective-based project, a problem is defined that needs to be solved
but there could be more than one solution. For example, if an
organization needed a payroll application they might consider (a)
writing the system themselves (b) using a service company to do the
payroll for them (c) acquire an off- the-shelf package.
3.2 Analyse other project characteristics – such as is it an
information system or an embedded real time or a multimedia
application? Is it safety-critical? etc.
Identifying high level risks could influence the general approach to the
project. For example, if the users appeared to be uncertain about the
precise nature of the requirement then a more iterative approach,
including the use of prototypes to refine user needs, might be selected.If the
application is very large and complex then breaking it down into
increments might be the way to proceed.
• Identify high-level project risks ‘what could go wrong?’ ‘what can we do to
stop it?’
• Take into account user requirements concerning implementation
• Select general life cycle approach ‘waterfall? Increments? Prototypes?’
• Review overall resource estimates ‘does all this increase the cost?’
Step 4 Identify project products and activities:
Firstly we identify the products to be created. These products could be
deliverables that will eventually be handed over to the customer, or
intermediate products such as specifications and design documents, that are
produced along the way.

4.1 Identify and describe project products - ‘what do we have to

produce?’
Product Breakdown structure is the way of listing these products
Products:
•The result of an activity
•Could be (among other things)
–physical thing (‘installed pc’),
–a document (‘logical data structure’)
–a person (‘trained user’)
–a new version of an old product (‘updated software’)
•The following are NOT normally products:
–activities (e.g. ‘training’)
–events (e.g. ‘interviews completed’)
–resources and actors (e.g. ‘software developer’) - may be
exceptions tothis
•Products CAN BE deliverable or intermediate
4.2 document generic product flows:
The product flow diagram shows the order in which the products have to be completed.
Effectively it defines a method of working. The flow of the PFD is generally from top
to bottom and left to right. We do no put in lines which loop back. This is not
because iterative and back-tracking is not accepted. Rather it is that you can in theory
jump back to any preceding product.
Step 4.3 Recognize product instances:
•The PBS and PFD will probably have identified generic products e.g.
‘software modules’
•It might be possible to identify specific instances e.g. ‘module A’, ‘module B’ …
•But in many cases this will have to be left to later, more detailed, planning

4.4 Produce ideal activity network:

•Identify the activities needed to create each product in the PFD
•More than one activity might be needed to create a single product
•Hint: Identify activities by verb + noun but avoid ‘produce…’ (too vague)
•Draw up activity network
Step 4.5 Add check-points if needed:
These are points in the project when we want to check that the quality of what we
have done so far is a sound basis for further work.
Step 5: Estimate effort for each activity:
Effort is the total number of staff-hours (or days etc) needed to
complete a task. Elapsed time is the calendar time between the time
task starts and when it ends. If 2 people work on the same task for 5
days without any interruption, then the effort is 10 staff-days and the
elapsed time is 5 days.
•5.1 Carry out bottom-up estimates
–distinguish carefully between effort and elapsed time
•5.2. Revise plan to create controllable activities
–break up very long activities into a series of smaller ones
–bundle up very short activities (create check lists?)
Step 6: Identify activity risks:
6.1.Identify and quantify risks for activities
–damage if risk occurs (measure in time lost or money)
–likelihood if risk occurring
6.2. Plan risk reduction and contingency measures
- risk reduction: activity to stop risk occurring
– contingency: action if risk does occur
6.3 Adjust overall plans and estimates to take account of risks
–e.g. add new activities which reduce risks associated with other
activities e.g. training, pilot trials, information gathering
Step 7: Allocate resources:
You now need to allocate resources (in particular, staff) to the
activities in the plan. Where there is a resource constraint, that
is there are not enough staff (or other
resource) of the right type to start all the activities that run in
parallel at the planned time, then the start of some activities may
need to be delayed until the appropriate resources are available.

• 7.1 Identify and allocate resources to activities

• 7.2 Revise plans and estimates to take into account resource
constraints
– e.g. staff not being available until a later date
– non-project activities
Gantt charts:
A Gantt chart, commonly used in project management, is one of
the most popular and useful ways of showing activities (tasks or
events) displayed against time. On the left of the chart is a list
of the activities and along the top is a suitable time scale. Each
activity is represented by a bar; the position and length of the
bar reflects the start date, duration and end date of the activity.
We now have the basic information needed to produce a plan.
One way of presenting the plan is by means of a Gantt chart
(named after Henry Gantt).
Step 8: Review/publicize plan:
We have noted already that it is not feasible to produce a
detailed plan for all stages of the project right at the beginning of
the project planning process and not all the information needed
for the detailed planning of the later stages is available at the
outset. Initially an outline plan for the whole project would be
produced, plus a detailed plan for the first stage.
• 8.1 Review quality aspects of project plan
• 8.2 Document plan and obtain agreement