Introduction
Project planning is an important aspect of any project. This presentation brings out the entry criteria, inputs and tasks involved in project planning, and the key points to be considered while putting up a plan. To ensure that the project is executed successfully there needs to be a foresight on the various phases and have enough armour to address the known and unknown challenges encountered during the project life cycle. To ensure that the project is successfully executed and accepted, there needs to be a well structured project planning. This paper addresses how a step by step approach to project planning can be done using a simple checklist and helps you to prepare a template to address planning in small and medium IT projects.
Project Planning in small and medium IT projects
Project Planning Objectives
The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost and schedule. These estimates are made within a limited timeframe at the beginning of a software project and should be updated regularly as the project progresses.
Project planning is a process of determining various requirements for executing, tracking, monitoring and controlling projects for its successful completion. Based on the scope of the project it encompasses the following sub-processes.
- Defining the project specific process
- Effort planning
- Resource planning
- Schedule planning
- Communication planning
- Risk Management planning
- Configuration Management planning
- Quality Assurance planning
- Training planning
The planning objective is achieved through a process of information discovery that leads to reasonable estimates. The objective of preparing and using the project plan template is to ensure
- Software project planning activities are documented
- Actual results are tracked against the plans
- To get feedback from customer on all completed projects about the project team's quality and services delivered and use the information to improve quality of deliverables and services.
The structure of the project plan template for a typical IT project shall have the sections as discussed below:
The “ETVX” Model
The template architecture that the template follows is the “ETVX” Model.
“E” – Entry criteria
“T” – Tasks
“V” – Verification
“X” – Exit criteria
Entry criteria for Project planning template
- Project charter handed over to the project manager
- Project scope and high level effort is available
- A Project kick-off meeting is conducted
Tasks
- Defining the project specific process.
| Input | Activity Description | Output |
- Project charter,
- Project scope statement
| - Analyzing characteristics of the project
- Identifying the life cycle for the project along with the activities specific to the project
- Tailoring the organizational processes to arrive at project specific processes
- Documenting waivers and deviations with a rationale and getting approvals
| - Project defined software process (PDSP)
|
- Preparing a schedule plan
| Input | Activity Description | Output |
| - Identifying the major milestones with planned start and completion dates
- The milestones could either be client specified or internally worked out for effective management of the project
| |
- Detailed Effort estimation sheets,
- WBS,
- High level schedule plan, Resource plan,
- Constraints
| - Determining start and finish dates for project activities and number of calendar days required to complete the project
- Has several iterations as more and more information becomes available at different points of time
- Various tools are available to assist project managers for this activity
| |
- Preparing detailed effort estimates
| Input | Activity Description | Output |
- Project scope,
- High level Estimates, Historical Information
| - Arriving at a detailed and accurate estimation of size, effort and cost after a thorough analysis of the requirements
- Identify the specific deliverables for each activity. (The output of first and second steps is a Work Break-down Structure (WBS). A WBS organizes and defines the total scope of the project)
| - Work breakdown structure (WBS), size and effort estimation documents
|
| Input | Activity Description | Output |
| - Determining what and how many resources are required
- (The resources mainly include human resources, hardware equipments, software environments, licensed software
- Human resource planning is based on the skill requirements for the project.
- It is satisfied either from available pool of skilled resources or recruitment
- Hardware and Software resources are allocated (if existing) or procured based on project specific requirements)
| - Resource plan
- Resource requests
|
| Input | Activity Description | Output |
- WBS, Resource plan,
- Resource rates,
- Historical Information
| - Arriving at an approximation of the costs of all the resources and other costs like training, travel specific to the project
| |
- Preparing the Cost Budgeting
| Input | Activity Description | Output |
- Cost Estimates,
- WBS,
- Project schedule plan,
- Risk management plan
| - Allocating the total project cost to individual activities or phases or milestones or timeframes depending on the organizational policies
- (Example: If the total project cost of a project is 80 lacs and the project duration is one year, then
- the management may allocate 10 lacs in first quarter, 25 lacs for next two quarters and 20 lacs in the last quarter
- Or
| |
- Cost Estimates,
- WBS,
- Project schedule plan,
- Risk management plan
| - The management may allocate 15 lacs till completion of requirements phase, 40 lacs for design and code development and 20 lacs for testing and release
- The budget is requested once the cost estimates and project schedule plan are ready
- The budget is approved by senior management
| - Cost Estimates,
- WBS,
- Project schedule plan,
- Risk management plan
|
| Input | Activity Description | Output |
- Stakeholder plan,
- Communication requirements
| - Determining the information and communications needs of all the stakeholders in the project in terms of
- who needs what information
- when will they need it
- How will it be passed to them.
| |
| Input | Activity Description | Output |
- WBS, Organizational risk management policies
| - Managing the risks through
- – Risk management planning
- – Risk Identification
- – Risk Analysis
- – Risk response planning
- – Risk monitoring and control
| - Risk Management Artefacts
|
- Stakeholder's input and risk tolerances
| - Deciding how to approach and plan the risk management activities
- (Important to get visibility on risks’ status throughout the project)
- A typical risk management plan will address the following
- Methodology / Tool and Technique for each activity
- Roles and responsibilities
- Cost implication
- Budgeting
- Thresholds involving both the sponsor and customer
- Risk Tracking mechanism
- Frequency of plan updation
- Reporting mechanism
| |
- Risk Management plan, Organization risk database
| - Determining which risks are likely to affect the project and in what way by documenting their characteristics
- Categorizing the risks on the basis of their characteristics
| |
- Risk management Plan,
- Project risk register updated with risk rating
| Mitigation - Reducing the probability or consequences of risk or both to an acceptable level
Acceptance - Accepting to absorb the risk if it turns into an event
This is the only response when no alternatives are available to change the course of risk.
Active acceptance involves contingency planning that describes the possible actions to reduce the impact of risk if it turns into an event
Passive acceptance requires no action leaving the project team to deal with consequences of a risk | - Risk Response plan,
- Contingency plans,
- Project risk register updated for risk rating
|
- Configuration Management Planning
| Input | Activity Description | Output |
| - Determining what, who and when with regard to the following configuration management activities
- Identifying Configuration Items (CIs)
- Creating and Maintaining software configuration management library
- Baselining Configuration Items
- Managing changes
- Generating Configuration Status Accounting reports
- Conducting Configuration management Audits
| - Configuration Management plan
|
- Software Quality Assurance Planning
| Input | Activity Description | Output |
- WBS, Standards and regulations, Organization goals
| - Identifying relevant quality standards for the project
- Planning formal SQA audits and data audits
| - Software Quality Assurance plan
|
| Input | Activity Description | Output |
- WBS, Project plan, schedule plan
| - Identifying training areas specific to the project and raising training requests
- Documents details like when the training has to happen, who is the target audience
The training request is raised indicating the details of the training schedule, topic of training, rationale behind such training, skill requirements and expectations from the trainer Evaluating the trainers for their competence, track record, cost and availability | |
- Development of Integrated Project Plan
- – The output of other supplementary planning processes will be used to document a consistent and coherent project plan
- – The project plan captures the project overview, scope, project organization structure, project life cycle, list of waivers and deviations and when and how to conduct causal analysis meetings for significant deviations and other details
- – The supplementary plans may be either separate documents with their reference mentioned in the project plan Or Part of the project plan itself
| Input | Activity Description | Output |
| - Integrating all the supplementary plans into project plan to arrive at a comprehensive project plan
- The supplementary plans may be either separate documents with their reference mentioned in the project plan
| |
Verification
- – The output of this process is verified and approved by an authority higher than the project manager
- – Any changes recommended to the output will be incorporated before proceeding to the next phase
Exit Criteria
- – A workable project plan approved by an authority higher than the project manager
A Sample TOC of a Project Plan template of a typical software project: A sample template can be shared at the end of the seminar if requested.
References
Pressman, Roger S (2001) Software Engineering A Practitioner's Approach McGraw Hill International Edition
Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK® Guide) (2004 ed.). Newtown Square, PA: Project Management Institute.
Project Planning Template THBS Quality Management System.
This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.
