Project planning


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


  • 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
  • Project scope statement
  • 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
  • High level schedule plan
  • 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
  • Detailed schedule plan
  • 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
  • Planning the resources
Input Activity Description Output
  • WBS, Estimation sheets
  • 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
  • Estimating the cost
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
  • Cost Estimation sheet
  • 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 Budget plan
  • 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
  • Communication 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.
  • Communication plan
  • Risk Management Plan
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
  • 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
  • Project risk register
  • 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
  • WBS,
  • Schedule plan
  • 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
  • Planning for Training
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

  • Training
  • 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
  • All Supplementary plans
  • 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
  • Project plan


  • –    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.



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.

© 2007, Vinuttha B M and M R Sriprasad
Originally published as a part of 2007 PMI Global Congress Proceedings – Budapest



Related Content

  • Project Management Journal

    Validation of a New Project Resilience Scale in the IT Sector member content locked

    By Rahi, Khalil | Bourgault, Mario This article aims to present the concept of project resilience and to validate, through quantitative analysis, to assess its two key dimensions: awareness and adaptive capacity.

  • Project Management Journal

    Getting Past the Editor's Desk member content locked

    By Klein, Gary | Müller, Ralf To reach acceptance, every research paper submitted to Project Management Journal® (PMJ) must pass several hurdles. This editorial aims to declare the editorial process and reveal major reasons for…

  • Project Management Journal

    Narratives of Project Risk Management member content locked

    By Green, Stuart D. | Dikmen, Irem The dominant narrative of project risk management pays homage to scientific rationality while conceptualizing risk as objective fact.

  • Project Management Journal

    Coordinating Lifesaving Product Development Projects with no Preestablished Organizational Governance Structure member content locked

    By Leme Barbosa, Ana Paula Paes | Figueiredo Facin, Ana Lucia | Sergio Salerno, Mario | Simões Freitas, Jonathan | Carelli Reis, Marina | Paz Lasmar, Tiago We employed a longitudinal, grounded theory approach to investigate the management of an innovative product developed in the context of a life-or-death global emergency.

  • Project Management Journal

    Investigating the Dynamics of Engineering Design Rework for a Complex Aircraft Development Project member content locked

    By Souza de Melo, Érika | Vieira, Darli | Bredillet, Christophe The purpose of this research is to evaluate the dynamics of EDR that negatively impacts the performance of complex PDPs and to suggest actions to overcome those problems.