SPM 3.

Dr.Sushruta Mishra
Dr.Sushruta Mishra
 In project management, proceeding without a project plan leaves you in
danger of overrunning available resources and failing to achieve the client’s
goals.

 Project management plan, is the document that describes how the project
will be executed, monitored, and controlled, and closed. This outlines the
objectives and scope of the project.

 Project constraints such as time, scope, and costs are discussed in the
project planning process, and mitigation plans are developed after the
identification of potential risks.

 By comparing the actual progress with the project plan, you can also
monitor the performance of your team and take the necessary steps to
improve it.

Dr.Sushruta Mishra
Dr.Sushruta Mishra
 Step 1::: Establish project scope and objectives

 Identify objectives and measures of effectiveness

‘how do we know if we have succeeded?’

 Establish a project authority

‘who is the boss?’

 Identify all stakeholders in the project and their

interests
‘who will be affected/involved in the project?’

 Modify objectives in the light of stakeholder analysis

‘do we need to do things to win over stakeholders?’

 Establish methods of communication with all parties

‘how do we keep in contact?’

Dr.Sushruta Mishra
 Step 2::: Establish project infrastructure

 Establish link between project and any strategic plan

‘why did they want the project?’

 Identify installation standards and procedures

‘what standards do we have to follow?’

(change control and configuration management standards,

quality standards and procedure manuals, measurement)

 Identify project team organization

‘where do I fit in?’
(SW developers, business analyst, business-to-customer
web application group, database group)

Dr.Sushruta Mishra
 Step 3::: Analysis of project characteristics
 Distinguish the project as either objective or product-based.
Is there more than one way of achieving success?
(tends to be more product driven and the underlying
objectves always remain and must be respected)

 Analyze other project characteristics (including quality based ones)

what is different about this project?
(information system, process control system, safety critical)

 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?’

Dr.Sushruta Mishra
 Step 4::: Identify project products and activities
Products:::::::::
 Identify and describe project products - ‘what do we  The result of an activity could be (among other things)
have to produce?’  physical thing (‘installed pc’),
 a document (‘logical data structure’)
 Identifying all things the project is to create helps us
 a person (‘trained user’)
to ensure that all the activities we need to carry out  a new version of an old product (‘updated
are accounted for. Some of these products will be
software’)
handed over to the client at the end of the project –  The following are NOT normally products:
these are deliverables.  activities (e.g. ‘training’)
 events (e.g. ‘interviews completed’)
 Other products might not be in the final
 resources and actors (e.g. ‘software developer’)
configuration, but are needed as intermediate  Products CAN BE deliverable or intermediate
products used in the process of creating the
deliverables.
Product description (PD):::::::::
 Product identity
 The products will form a hierarchy. The main
 Description - what is it?
products will have sets of component products
 Derivation - what is it based on?
which in turn may have sub-component products,
 Composition - what does it contain?
and so on. These relationships can be documented in
 Relevant standards
a Product Breakdown Structure (PBS)
 Quality criteria whether the product is acceptable
Dr.Sushruta Mishra
Some products are created from scratch,
for example new software components.
A product could quite easily be a
document, such as a software design
document.

It might be a modified version of

something that already exists, such as an
amended piece of code. A product could
even be a person, such as a ‘trained
user’, a product of the process of
training.

Always remember that a product is the

result of an activity. A common error is
to identify as products things that are
really activities, such as ‘training’, A fragment of a Product Breakdown Structure for a system development task
‘design’ and ‘testing’.
 What would be the product breakdown structure of
the deliverables of the vendor who would develop the
Brightmouth College payroll software by customizing
one of its existing products?
  Document generic product flows
A program design must be created before the program
can be written and program specification must exist.
The relationships can be portrayed in a Product Flow
Diagram (PFD).
Flow on the diagram to be from top to bottom and left to
right.
User requirement is an oval.

Note that the ‘flow’ in the diagram is assumed to be from top

to bottom and left to right.

In the example, ‘user requirements’ is in an oval which means

that it is used by the project but is not created by it.

It is often convenient to identify an overall product at the

bottom of the diagram, in this case ‘integrated/tested
software’, into which all the other products feed.
PFD for a software development task

Dr.Sushruta Mishra
 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

 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
Draw up activity network
An example of an activity network

Dr.Sushruta Mishra
 Add check-points if needed
An activity will start as soon as the
preceding ones are completed.
Sometimes as per need, divide the
project into stages and introduce a
check point activities.
Check point ensures the preceding
activities together are complete and
compatible.
This may delay work on some
elements of the project.
There should be a trade-off between
efficiency and quality

Dr.Sushruta Mishra
 Step 5::: Estimate effort for each activity

 Carry out bottom-up estimates

At this point, estimates of the staff effort required, the probable elapsed time and the non-staff resources
needed for each activity will need to be produced.
Effort is the amount of work that needs to be done. If a task requires three members of staff to work for
two full days each, the effort expended is six days.
Elapsed time is the time between the start and end of a task. In our example above, if the three members
of staff start and finish at the same time then the elapsed time for the activity would be two days.
 Revise plan to create controllable activities
(If an activity involving system testing is to take 12 weeks, it is difficult after six weeks to judge whether
50% work is completed.)
Break up very long activities into a series of smaller ones
Bundle up very short activities (create check lists?)

Dr.Sushruta Mishra
 Step 6::: Identify activity risks

 Identify and quantify risks for activities

A project plan will be based on a huge number of assumptions, and so some way of
picking out the risks that are most important is needed. The damage that each risk
could cause and the likelihood of it occurring have to be gauged.
 Plan risk reduction and contingency measures
It may be possible to avoid or at least reduce some of the identified risks. On the
other hand, contingency plans specify action that is to be taken if a risk materializes.
For example, a contingency plan could be to use contract staff if a member of the
project team is unavailable at a key time because of serious illness.
 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

Dr.Sushruta Mishra
 Step 7::: Allocate resources

 Identify and allocate resources to activities

The type of staff needed for each activity is recorded. The staff available for
the project are identified and are provisionally allocated to tasks.

 Revise plans and estimates to take into account

Resource constraints e.g. staff not being available until a later date non-project
activities

Dr.Sushruta Mishra
Dr.Sushruta Mishra
 Step 8::: Review/publicize plan

 Review quality aspects of project plan

(ensure the quality criteria has been ensured before
completion of the project)

 Document plan and obtain agreement

It is important that the plans be carefully documented and
that all the parties to the project understand and
agree to the commitments required of them in the plan.

Dr.Sushruta Mishra
 Step 9 and 10:::::::: Execute plan and create lower level plans

Once the project is under way, plans will need to be drawn up in greater
detail for each activity as it becomes due.
Detailed planning of the later stages will need to be delayed because
more information will be available nearer the start of the stage.
 Key points
 Establish your objectives
 Think about the characteristics of the project
 Discover/set up the infrastructure to support the project (including standards)
 Identify products to be created and the activities that will create them
 Allocate resources
 Set up quality processes

Dr.Sushruta Mishra
END

Dr.Sushruta Mishra