Overview of project planning

• Basic steps in project planning.

• Overview of points which need to be considered while doing project planning.
• Different projects need different technical approaches.
• PRINCE2 is a set of project management standards sponsored by office of Govt. commerce
(OGC) for British ICT and business change products.
• PRINCE2 is the defacto standard for project management skills in UK.

1
There are two computing and information systems which are taken for case study to understand the concepts
of project planning, they are

BRIGHTMOUTH college payroll

Brigette wants to work in a small organization and set up information systems from scratch. One of the task
brigette confronts is implementation of independent payroll processing

AMANDA works for high technology international office equipment ( IOE), this office assembles, supplies ,
installs and services various items of IOE. Now they are taking maintenance of equipment for which they were
not suppliers.

2
Functionality :

• Existing ICT department allow sales staff to input and generate invoices of completed projects.
• Large organizations must call out IOE several times during a month to deal with problems with equipment.
• Each month a batch run of system generates monthly statements for customers that are one payment per
month needs to be made.
• Management of IOE wants to provide a service where a single annual payment customers would get free
servicing.
• And problem resolution for a predefined set of equipment.
• The enhanced applications need many of recording details of items of equipment to be covered by customers
annual maintenance contract.
• Even though jobs done under this contract work cannot be charged for, the work will be recorded to allow
analysis of costs and profitability of each customer and each of the equipment.
• This will allow IOE to set future contract prices at an optimally profitable level.
3
• Now job records are only recorded after job completion so that prices are generated.
• The new system will allow a central coordinator to allocate jobs to engineers and to notify engineers aof urgent jobs
automatically viva their mobile phones.

4
Stepwise planning of projects

5
Step 0: select project
• Some process must decide to initiate this project rather than some other.
• Feasibility study says there is a business case for the project under consideration.
• Evaluation of the project may the part of project portfolio.
Step 1:
Identify project scope and objectives
• This involves all parties of the project who must agree upon objectives and committed to the success of the
project.
//Anlayse with respect to case studies discussed earlier
1.1 identify project objectives and practical measures of effectiveness in meeting the objectives.
1.2 establish a project objective
A single project authority need to be established so that there is a unity of purpose among all the concerned.

1.3 stakeholder analysis- identify all the stakeholders in the project and their interest.
6
1.4 modify objectives in the light of stakeholder analysis.
• Adding new features to give benefit to some stakeholders.
• Sometimes this may obscure original objectives, so modifying objectives must be done
consciously in a controlled manner.

1.5 establish methods of communication with all parties

• It involves preparation of draft communication plan.

Step 2 : identify project infrastructure

2.1 identify relationship between project and strategic planning
• It involves identifying how program a management ensures that project contributes to
organizational strategy. 7
2.2 identify installation standards and procedures
• Software organizations must define development environment. [s/w process life cycle]
• Changes to the requirements must be applied through the policies of change control and configuration
management standards.[ IOE}
2.3 identify project team organization
• Project leaders must control project teams.
• Ex. s/w developers and business analysts will be in different groups [IOE}

Step 3. analyze project characteristics [IOE}

• This is to ensure appropriate methods are used for implementation.

3.1 distinguish project as either objective or product driven

• As development of the system advances it becomes product driven.
• Underlying objectives are respected. 8
3.2 analyze other projects characteristics
• Understand the nature of the project
• Ex. Information system or process control system

3.3 identify high level project risks.

• Focus on risks that threaten outcome of the project [ payroll +IOE}

3.4 take into account user requirements concerning implementation

• Client procedures and developing organization procedures may be different.

3.5 select development methodology and life cycle approach

• Methodology indicate a set of methods for implementation of the project.
• There are generic ways of structuring projects. E.g. waterfall model
9
• Questionnaire surveys may be conducted with experts to identify life cycle. [ machine learning].
3.6 review overall resource estimates
• After understanding potential risks, overall resource estimates can be done.

Step 4. identify project products and activities

• Long term planning is broad and in outline while more immediate tasks must be planned in detail.

4.1 identify and describe project products and deliverables

• There are no activities which not produce products.
• Activities must be accountable for the outcome.
• At the end of project, a product will be handed over which is the deliverable.
• In deliverables there will be intermediate products.
• Product may include training materials, operating instructions etc.
• Products related to management and quality of project.
• There could be main products and subproducts.
10
• The relationship between main products and subproducts may be depicted using PBS- product breakdown structures.
Product break down structures

11
4.2 document generic product flows

• Some products may need existence of other products before they are created. These relationships me be portrayed using
product flow diagrams- PDFs

12
4.3 recognize the product instances
• Where the same generic PFD fragment relates to more than one instance of a
particular type of product an attempt must be made to identify instances.
4.4 produce ideal activity network
• Identify activities and represent dependencies using activity networks.
4.5 modify the ideal to consider need for stages and checkpoints
• Sequencing of activities is very important to reduce duration of execution.
• There will be no need to modify the project stages and introduce checkpoint
activities.
• There cannot be delay in key activities or milestones. 13
5. Estimate effort for each activity
5.1 carry out bottom-up estimates
• Estimates of required staff effort.
• Resource estimates.
• Sum up the costs of individual activities which give
bottom-up estimate.
• Activity networks produce duration for completion of
every activity.
14
5.2 revise plan to create controllable activities
• Estimates for individual projects could reveal that some are going to take long time.
• Try make activities of length equal to reporting period used for monitoring and controlling the
project.
Step 6. identify activity risks
6.1 identify and quantify activity- based risks
• Estimation of risks may be addressed by providing a range of cost/effort estimation.
• Or specify most likely estimate
• The damage that each risk could cause and likelihood of occurring must be gauged
6.2 plan risk reduction and contingency measures where appropriate
• Avoid risks.
• Contingency plan specify actions to take when risk occurs. 15
6.3 adjust overall estimates and plan to take account of risks
• By adding new activities risks may be reduced.
E.g., for a new programming languages, training may be given.
Step 7. allocate resources
• Identify and allocate resources
• e.g., allocate tasks to staff on provisional basis.
• Revise plans and estimates to consider resource constraints.
• Some staff may be required for more than one task at a time.
• What is the effect on project delay by waiting for the staff?
• Gantt chart helps to show staff allocation on different activities with respect to
16
Gantt chart for staff allocation
17
Types of Schedules required for resource allocation
1. Activity schedule: This indicates planned start and competition dates for individual
activities.
2. Resource schedule: shows the dates on which resource is required and their level of
requirement.
3. Cost schedule: it shows the cumulative cost incurred by the use of resource over a
period of time.

Nature of resources
• Categorifies of resources-
• Labor
• Equipment
• Materials
• Space
• Services
• Time
• money 18
Identifying resource requirements
Steps in producing resource allocation plan-
• List the resources required with expected level of demand, to achieve this consider
activities involved and resources required.
• There are resources such as space, project infrastructure, deal with them separately.

19
20
21
Software Effort Estimation
“A successful project is delivered on time within budget and with required
quality”

Difficulties in software effort estimation

Software effort estimation is difficult due to the following factors
• Subjective nature of estimating
• Political implications
• Changing technology
• Lack of homogeneity of project experience

22
Where are the estimates done?
Estimates are done at various stages of software project-
• Strategic planning – project portfolio management involves estimation of costs and
benefits of new applications to set priority for resource allocation.
• Feasibility study – this study confirms the benefits of the project and will justify the
project
• System specification- estimation at this level confirms that argument in feasibility study
is still valid
• Evaluation of supplier's proposals – costs of bids are compared with in-house
development
• Project planning – the planning and and implementation of the project becomes more
detailed, so estimates of smaller tasks are available

23
Problems with over and underestimates
• Parkinson’s law: Work expands to fill the time available

• Brooks’s law – effort of implementing the project go up disproportionally with the number
of staff assigned to the project.
As the project team grows in size, more effort has to go into management, coordination and
communication.

• Underestimated project might not be completed on time or to cost.

• The danger with the underestimate is the effect on the quality. Staff with less experience in
pressing deadlines may produce substandard quality work.

24
Basis for software effort estimates
• The need for historical data
Experience on past projects help in better effort estimation for current
projects, programming language, project performance, experience of the staff
must be kept in mind.

• Measure of work
• Consider number of lines of source code (SLOC), KLOC(thousands of lines of
code)

25
Software effort estimation techniques:
• Algorithmic models
• Expert judgement
• Analogy
• Parkinson
• Price to win
• Top down
• Bottom up

26
Bottom-up estimating
• Bottom-up approach breaks the project into its component tasks
• The process of breaking down into tasks is an iterative process
• Top down is a precursor to bottom-up estimating, it is a work break down schedule
• Bottom-up approach the is best at later stage of project planning
• Bottom-up approach is more suitable when historical data is not available

A procedural oriented approach

Bottom-up approach can be used at coding level activity. To apply bottom-up
approach at coding level, following steps to be followed.
1. Envisage the number of and type of software modules in the final system.
[ ex. Modules like add, delete, display etc.]
2. Estimate the SLOC of each module.
3. Estimate the work content, taking into account complexity and technical
difficulty.
4. Calculate the workdays effort 27
The top-down approach and parametric models
• Top-down approach is associated with parametric( or algorithmic ) models
• Project effort relates mainly to variables associated with the characteristics
of final system.
• A parametric model will be of the form;
• Effort =( system size) X ( productivity rate)
• System size is in KLOC
• Productivity rate40 days per KLOC, these values will often be the matters
of judgement.
Two key components of this algorithm are;
1. Assess the amount of work needed.
2. Assess the rate of work at which tasks can be done.
Ex. Amount of work needed = 2KLOC
No. of days required are say 55 days,
Therefore, total time = 2*55 days=110 days 28
The productivity is,
Productivity =effort/size
Statistical technique such as regression is used to derive the equation
below.
Effort= constant1 + ( size* constant2)

• COCOMO model is the form of parametric model is the form of

parametric model which focuses on productivity factors
• Once total project effort is estimated, next step is to allocate the efforts
activity wise.
• The top down and bottom-up approaches are not mutually exclusive.
For some parts of the projects top down is applied and for some parts of
the project bottom up approach is applied.

29
Expert judgement
• This is asking someone who is knowledgeable about the
application or the development environment.
• This method is suitable when an effort estimation is required
to change the existing piece of software.

• The estimator has to analyse and find out which all parts of
the software need to changed and then estimate the total
effort.
• Some person who is familiar with the code is the best
• Experts judge the effort required through informal approach

30
Step 8. review/publicize plan
8.1 review quality aspects of the project plan.
• On completed tasks which are completed quality checks are important to ensure that tasks
match standards.
• If it is revealed that an activity is not implemented properly when we have to start next activity
is very bad state of the plan.
8.2 document plans and obtain agreement
• All plan should be understandable by all parties of the project.
Therefore, proper communication plans must be used.
Step 9 & 10. execute plans/lower levels of planning
• It is necessary to make provisional plan for the more distant tasks.
31
Activity planning
Planning is essential
• To ensure the required resources are required when needed.
• To avoid different activities competing for the same resources.
• Produce a schedule for staff allocation.
• To produce time cash flows forecast.
• Replan during project life to avoid drift from the target.

32
Objectives of activity planning
• Feasibility assessment
• Resource allocation.
• Detailed planning.
• Motivation.
• Coordination.

What to plan?
• Planning is an ongoing process of refinement.
• It helps through tout the project, until the final deliverables have reached customer.

33
Project schedules

• A project schedule must show when an activity starts and ends, other details are
represented after refinement.
• Planning involves decisions about what activities to be carried out and in what order.
• This initial planning is then subjected to the analysis to identify potential risks in the
implementation.
• Detailed planning is required to accommodate resource constraints if any.
• Once the resources are identified and dates of activities are fixed, the schedule must be
produced.

34
Projects and activities
Identify activities that make up project
1. A project is composed of number of interrelated activities.
2. A project can start when at least one activity is ready to start.
3. A project will be completed when all the activities are completed.
4. An activity must clearly have start and end dates.
5. A resource required for the activity must be forecastable.
6. The duration of the activity must be forecastable.
7. Precedence activities must be known.

35
Identifying activities
• Conduct brainstorming sessions and identify activities of the project.
• Use past experience.
• For large projects analyze each stage separately.
• To avoid missing any activity, identify activities based on WBS- work breakdown structure [ refer fig]/
• .

36
PBS
• Tasks at each level of PBA are required to complete that activity.
• Consideration must be given to final level detail or depth of structure.
• Depth of PBS must help project control.
• PBS gives list of non overlapping activities.
• PBS may be refined when project proceeds.
• Activities identified by PBS must be sequenced.

37
The product- based
approach
• It needs PFD product flow
diagram which is
converted into a set of
activities.
• This methodology is
suitable if the method is
based on SSADM or USDP.

38
Hybrid approach

• WBS is suitable for any project size.

• Number of levels are recommended by IBM for WBS are,
• Level 1- project
• Level 2- deliverables such as software , manuals or training courses.
• Level 3- components which are the key work items that are needed to produce
deliverables
• Level 4- work packages, collection of related tasks.
• Level 5- tasks which are the responsibility of one person.
39
Sequencing and scheduling activities
• It is required to create schedule which clearly indicates when each project
activity is planned for and what resources are required. [ref. fig]
• Project plan a bar chart,
• A chart shows nature of development and resources required.
• To draw a bar chart, sequence the activities based on the availability
• For smaller projects sequencing and scheduling can be done together.
• For larger projects identify the sequence of projects based on their logical
relationships. This can be done using network models. of staff and resources.
40
41