An Overview of project planning

Chapter three

1
Project Planning
• it is a task, which is performed before the production of software actually starts.
• It is there for the software production but involves no concrete activity that has
any direction connection with software production; rather it is a set of multiple
processes, which facilitates software production.
• It is a discipline addressing how to complete a project in a certain timeframe,
usually with defined stages and designated resources. One view of project
planning divides the activity into these steps:
• setting measurable objectives
• identifying deliverables
• scheduling
• planning tasks
• Supporting plans may encompass human resources, communication methods and
risk management.
• Enterprises often have an it project planning guide that identifies the processes
used.
2
Why is project planning important
• It is important at every phase of a project. It lays out the basics of a project, including
Scope, Objectives, Goals, Schedule
• Planning enables project managers to turn an intangible idea into reality. Key purposes of
planning includes
• Guides the execution of the project, coordinating the activities
• Facilitate better communication between the project stakeholders
• Provides a means of tracking and monitoring the progress
• Provide a detailed documentation regarding planning decisions
• Project planning is of significant importance for the success of the project
• Careful planning helps prevents costly mistakes
• Good planning is the key to meet the project objectives within defined time and
budget
• Many different techniques can be used such as step wise and PRINCE2
• PRINCE2 is a set of project management standards that were originally sponsored by
what is now the Office of Government Commerce (OGC) for use on British government
ICT and business change projects. The standards are now also widely used on non-
government projects in the United Kingdom. 3
An outline of Step Wise planning activities

4
Step wise project planning
• Step Wise covers only the planning stages of a project and not
monitoring and control
• A major principle of project planning is to plan in outline first and
then in more detail as the time to carry out an activity approaches
• Hence the lists of products and activities that are the result of a given
step will be reviewed when the tasks connected with a particular
phase of a project are considered in more detail. This will be followed
by a more detailed iteration of next steps for the phase under
consideration.

5
Step 0: Select project
• Called Step 0 because it is actually outside the main project planning
steps
• While feasibility study suggest that there is a business case for the
project, it would still need to be established that it should have
priority over other projects
• This evaluation can be part of project portfolio management.

6
Step 1: Identify project scope and objectives
• The activities here ensure that all the parties to the project agree on the objectives and are
committed to the success of the project.
• A danger to be avoided is overlooking people who are affected by the project.
Step 1.1: Identify objectives and practical measures of the effectiveness in meeting those objectives
• How do we know we are successful
Step 1.2: Establish a project authority
• Who is the boss?
Step 1.3: stakeholder analysis-Identify all stakeholders in the project and their interests
• Who does what?
Step 1.4: Modify objectives in the light of stakeholder analysis
• What shall we do for the commitment of stakeholders to the project?
Step 1.5: Establish methods of communication with all parties
• How do we stay in touch and informed?

7
Step 2: identify project infrastructure
• Projects are never carried out in a vacuum. There is usually some kind of existing
infrastructure into which the project must fit
• Where project managers are new to the organization, they must find the precise
nature of this infrastructure. This could be the case where the project manager
works for an outside organization carrying out the work for a client
Step 2.1: identify relationship between the project and strategic planning
• Identify projects to be carried out
• Order of projects
• Identify and prioritize the projects
• Establish framework for projects
• Why did they want the project?
• What hardware and software part needed?

8
Step 2: identify project infrastructure
Step 2.2: identify installation standards and procedures
• What are the development procedures?
• Any organization that develops software should define their development procedures.
The normal stages in the software life cycle to be carried out along with the products
created at each stage should be documented as a minimum.
• What standards do we have to follow?
• Change control and management
• Change control and configuration management standards should be in place to
ensure that changes to requirements are implemented in a safe and orderly way.
• Quality standards
• The procedural standards may lay down the quality checks that need to be done at
each point of the project life cycle or these may be documented in a separate
quality standards and procedures manual.

9
Step 2: identify project infrastructure
Step 2.3: identify project team organization
• Project leaders, especially in the case of large projects, will often have some control over the
organizational structure of the project team. More often, though, the organizational structure will
be dictated to them
• Identify your requirement of team
• Choose best people
• Where do I fit in?
• Divide the activities
• Create groups
• There should be a project leader
• Restrict some groups to be combined
• It will help at resource allocation stage
• For example, there might have been a high level managerial decision that code developers and
systems analysts will be in different groups, or that the development of PC applications will not be
done within the same group as that responsible for 'legacy' main-frame applications.

10
Step 3: Analyze project characteristics
• The general purpose of this part of the planning operation is to ensure that
the appropriate methods are used for the project
Step 3.1: Distinguish the project as either objective- or product-driven
• Object v/s product
• Project can be distinguished by their aim whether it is to produce a
product or to meet certain objective
• Is there more than one way of achieving success?
• Mostly in earlier stage projects are objective and in later stage it
become product driven
• As development of a system advances it tends to become more product-
driven, although the underlying objectives always remain and must be
respected

11
Step 3: Analyze project characteristics
Step 3.2: Analyze other project characteristics (including quality based
ones)
• What is different about this project?
• Whether it is a information system or embedded system?
• What are the critical issues?
• Malfunctioning threatened human life?
• For example, is an information system to be developed or a process
control system, or will there be elements of both? Will the system be
safety critical, where human life could be threatened by a
malfunction?

12
Step 3: Analyze project characteristics
Step 3.3: identify high-level project risks
• What could go wrong?
• What can we do to stop it?
• Consideration must be given to the risks that threaten the successful
outcome of the project. Generally speaking, most risks can be attributed to
the operational or development environment, the technical nature of the
project or the type of product being created.
Step 3.4: Take into account user requirements concerning implementation
• The clients may have their own procedural requirements.
• For example, an organization might mandate the use of a particular
development method or customer may want product in java
13
Step 3: Analyze project characteristics
Step 3.5: Select development methodology and life-cycle approach
• waterfall? Increments? Prototypes?
• For many software developers, the choice of methods will seem obvious:
Generally company use the same method or SDLC as they were using in past
• It also depends on project need
• we recommend caution in assuming that the current project is really similar to
previous ones
Step 3.6: Review overall resource estimates
• once the major risks have been identified and the broad project approach has
been decided upon, this would be a good point at which to re-estimate the effort
and other resources required to implement the project
• Where enough information is available an estimate based on function points
might be appropriate
• Does all this increase the cost?
14
Step 4: identify project products and activities
• The more detailed planning of the individual activities now takes place.
• The longer-term planning is broad and in outline, while the more immediate tasks are
planned in some detail.
Step 4.1: identify and describe project products (or deliverables)
• in general, there can be no project products that do not have activities that create them.
• There are no activities that do not produce a tangible product.
• Identifying all the things the project is to create helps us to ensure that all the activities
we need to carry out are accounted for
• Some of these products will be handed over to the client at the end of the project - these
are deliverables.
• Other products might not be in the final configuration, but are needed as intermediate
products used in the process of creating the deliverables. These products will include a
large number of technical products, such as training material and operating instructions.

15
Step 4.1: identify and describe project
products (or deliverables)…
• A product could quite easily be a document, such as a software
design document, an amended piece of code, a person such as a
'trained user’

16
Step 4: identify project products and activities
Step 4.2: Document generic product flows
• Some of the products will need some other product to exist first
before they can be created. For example, a program design must be
created before the program can be written and the program
specification must exist before the design can be commenced.
product Flow Diagram (PFD)

17
Step 4: identify project products and activities
Step 4.3: Recognize product instances
• The PBS and PFD will probably have identified generic products .For
example software modules
• It might be possible to identify specific instances for example ‘Module A’,
‘Module B’
• But in many cases this will have to be left to later, more detailed planning
Step 4.4: Produce ideal activity network
• In order to generate one product from another there must be one or more
activities that carry out the transformation. By identifying these activities
we can create an activity network which shows the tasks that have to be
carried out and the order in which they have to be executed.

18
An example of an activity network

19
Step 4: identify project products and activities
Step 4.5: Modify the ideal to take into account need for stages and
checkpoints
• Assumption of ideal activity network:
• An activity will start as soon as the preceding ones upon which it
depends have been completed
• But we need to divide the project into stages and introducing check point
activities
• To check that products of preceding activities are compatible
• Milestones represent the completion of important stages of the project of
which managers would want to take particular note
• Checkpoint activities are often useful milestones

20
Step 5: Estimate effort for each activity
Step 5.1: Carry out bottom-up estimates
• estimates of the staff effort required, the probable elapsed time and the
non-staff resources needed for each activity will need to be produced. the
method of arriving at each of these estimates will vary depending, on the
type of activity.
• 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.
• The individual activity estimates of effort should be summed to get an
overall bottom-up estimate.

21
Step 5: Estimate effort for each activity
Step 5.2: Revise plan to create controllable activities
• It is very difficult to judge the progress of a long activity
• With long activity it is difficult to monitor and control the activity
• Break up very long activities into a series of smaller ones
• Bundle up very short activities(create check lists)

22
Step 6: Identify activity risks
Step 6.1: identify and quantify activity-based risks
• Damage if risk occurs( measure in time lost or money)
• Likelihood if risk occurring
• Any plan is always based on certain assumptions. Say the design
of a component is planned to take five days. This is based on the
assumption that the client's requirement is clear an
unambiguous. lf it is not then additional effort to clarify the
requirement would be needed. The possibility that an
assumption upon which a plan is based is incorrect constitutes a
risk.

23
Step 6: Identify activity risks
Step 6.2: Plan risk reduction and contingency measures where appropriate
• 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.
Step 6.3: Adjust overall plans and estimates to take account of risks
• Adjust the plans according to their risk involved with it
• Example add new activities which reduce risks associated with other
activities e.g. training , information gathering…

24
Step 7: Allocate resources
Step 7.1: Identify and allocate resources
• Type of staff needed
• Number of staff needed
• Staff availability
Step 7.2: Revise plans and estimates to take into account resource
Constraints
• Some staff may be needed for more than one task at same time so
priority should be given to the critical activity
• e.g. staff not being available until a later date
• Non project activities
• Gantt chart can be used for example

25
Step 8: Review/publicize plan
Step 8.1: Review quality aspects of the project plan
• When task is reported complete it is important to review its quality
• There should be some quality criteria
Step 8.2: Document plans 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.

26
Steps 9 and 10: Execute plan/lower levels of
planning
• 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.
• It is necessary to make provisional plans for the more distant tasks

27
Thank you

28