While so, the question most often asked is - should planning be on paper?
Not necessarily – for small short duration endeavor, mental planning can be adequate. In fact, none of us fail to plan, we do plan – however, we may not put it on the paper, all the time.
By putting the plan on paper, the advantages are -
- We can get it reviewed by someone knowledgeable or review it ourselves and see if we missed any important aspect and thereby improve the plan.
- A documented plan acts as point of reference for all the persons concerned / involved in the endeavor
- Facilitates control and performance evaluation during execution of the endeavor as well as validate the efficacy of the norms by contrasting the plan with the actual values obtained in execution
The granularity (required detail) of planning depends on –
- The duration of the endeavor
- The number of resources employed
- The complexity involved
- The relationship between the above three aspects
Now consider the sequel to the above statements –
- Longer the duration, greater the necessity for increased rigor
- If the duration available to complete the endeavor were adequate, the rigor of planning needed would be less. However, if the duration were less than adequate, then the rigor would increase.
- The rigor of planning is proportional to the number of resources employed. Higher the number of resources employed, the more is the rigor required in planning.
- If the complexity is higher – limitations are imposed or the expertise of the domain in which the endeavor is being attempted is lacking – then the rigor of planning would need to be higher
Consequently, the rigor of planning for execution of software projects also depends on the above three aspects, namely duration, number of resources employed and the complexity.
Before we proceed further, let us define Planning.
Definition of Planning
Planning is defined as the intelligent anticipation of resources required to perform a predefined endeavor successfully at a future date in a defined environment.
The key terms are
- Anticipation - this indicates that the Planning precedes performance as well as using the best guess – anticipation is basically estimation of resources
- Resources – the 4 M’s – Men (persons), Materials, Methods, and Machines (equipment) plus the time (duration).
- At a future date – the dates are decided or are to be decided during the course of planning
- In a defined environment – the environment where the work is going to be performed is known and is defined or is to be defined during the planning exercise. Any variation in the environment would have an effect on the plan. Environment refers to the working conditions including work & workstation design, processes and methods of management, prevailing morale at the workplace etc.
- Predefined endeavor – the endeavor is defined – the scope of work is known
Now we can move forward.
Planning for software development projects is also planning “per se” and is tailored to suit the specific attributes of software development.
What are the unique and specific attributes of software development projects?
- The output is not physical – in the sense that there are no physical components that are delivered – everything is inside the computer
- Process inspection doesn’t facilitate progress assessment – we need to wait till the program is finished and tested to get a feel of progress. In a manufacturing organization one can see semi-finished goods and the proof of working is in the noise made. In a software development organization, visual inspection is not enough to ensure that people are performing – one needs to walk-thru the code being developed to ensure that the person is working.
- While there is significant progress in the software engineering tools, they are no where near the precision of engineering drawings to get the predictability that we get in other engineering disciplines
- The professional associations in software development still are far from other professional associations in the matter of defining standards or bringing discipline in the process of developing software. True IEEE (Institute of Electrical and Electronic Engineers) is defining a number of standards but these standards are far from the other engineering standards in terms of level of granularity.
- While there is significant improvement in software development methodology, it is still largely dependent on human beings for productivity and quality. While tools are available to help development or testing they still need to go far to meet the standard of tools used in fabrication / inspection / testing in other engineering disciplines. In other engineering disciplines tools are available that shift the onus for productivity / quality from human beings to tools – true – still the human being can screw-up both quality and productivity, but an average skilled person can achieve higher productivity / quality that can come only from a super-skilled person – this is still a far cry in software development arena – an average programmer cannot achieve higher standard of productivity / quality with the assistance of tools – as yet.
Therefore, the rigor of planning becomes all the more important in software development than in other engineering projects. In other engineering projects, a simple schedule based on PERT/CPM would suffice, where as, in software development projects, increased rigor is required and more plans are required. The plans that are commonly required are described in subsequent sections.
Software project – here the focus is on software development projects. That is –
- The project has a definite beginning and a definite end
- The project deliverable is software and related artifacts
- The activities that may be included under this head are user & software requirements, software design, software construction, software testing, acceptance testing, delivery of software, deployment and hand-over.
- The activities of project selection / acquisition and post–handover activities are not included under this head.
Types of plans prepared by the project management
There is a misunderstanding among software development fraternity that a schedule based on PERT/CPM constitutes software project planning in its entirety. It is not so. Software project Planning needs to go beyond PERT/CPM based schedule. The following are the typical plans prepared for a large software development project
PMP – Project Management Plan – in other engineering projects this is covered in the operating procedures and policies of the organization (or the production facility, which more or less remains consistent) – it is understood how a project is managed. In software development projects, as the development environment changes in every project, we need to plan how to manage the project and we record the following in this plan -
- Project info
- The software estimate (software size, effort, cost and schedule
- The milestones, delivery schedules
- Acceptance Criteria for deliveries effected
- Human resources required along with the dates of their requirements
- Management methods – work allocation, information and code management, quality control, communication management etc
- Tools used in the project
- IEEE standard 1058 gives various aspects of preparing PMP as well as the suggested template.
CMP – Configuration Management Plan – we record the following info in this plan –
- Naming conventions to be followed for naming project artifacts including documents, code units, variables and constants used in programming, table names, field names and so on
- Procedure for change management
- Organization of project information management so that it would be easy for project team when a reference is needed
- Reference to organizational standards and processes for use in the project
- Code and code library organization along with check-in and check-out criteria and authorizations and procedure for state-change (from development to review / testing, to integration and delivery etc.) of programming artifacts
- IEEE standard 828 gives details of preparing CMP including the suggested template for preparing CMP.
QAP – Quality Assurance Plan – we record the following in this plan –
- Standards (coding guidelines, design guidelines, testing guidelines etc) slated to be used in the project
- Quality control activities proposed for the project – such as code walk thru, review of requirements and design, proposed tests like unit testing, integration testing, functional testing, negative testing, end-to-end testing, system testing, acceptance testing and so on
- Software metrics to be collected for the project
- Procedure and triggers for causal analysis – for failures / defects / successes
- Audits proposed for the project
- IEEE standard 730 gives details of preparing QAP including the suggested template for preparing QAP.
Schedule – this contains the work breakdown structure with start and end dates for the activities. This document is used to monitor progress of the project. Network analysis techniques, namely, PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) are very useful techniques in this activity. There are plenty of resources on these techniques on the World Wide Web and if you are not knowledgeable in them, my suggestion is to study these techniques. PERT handles uncertainty inherent to planning thru use of probability theory. CPM assists in locating the activities that are critical to the meeting of the over all schedule and assists in resource allocation in such a manner that the delayed activities do not affect the overall completion date of the project. Both the techniques are referred together as PERT/CPM now-a-days. Knowledge of PERT/CPM is necessary to arrive at a credible schedule for a project.
Induction Training Plan – this contains the list of training requirements to be undertaken by a new team member joining the project to bring him on par with other team members. Also, these courses are imparted to all the team members at the start of the project. Normally, the courses would include training on project plans, which specify how the project would be executed and controlled, quality assurance activities, communication, issue resolution and project specific tool / development platform training etc.
Build Plan – this would contain the number of builds, when they would be built, how they would be tested etc.
Deployment Plan – This document would contain the plan of deploying the software at the target location including deployment of hardware, system software, middleware, pilot runs etc.
User Training Plan – this document would contain the course outline for the user training, duration and schedule of user training etc.
Hand-over Plan – this document would contain the details of handing over the system, timelines, person to whom the handover would take place, what artifacts would be handed over and the signoffs thereof etc.
Software Maintenance Plan – this document would contain the mechanisms for raising maintenance work requests, service levels, turnaround times etc.
All these plans may not be required to be made as separate documents in all cases. For smaller projects, all the above could be included in the PMP itself. For medium sized projects, it is normal to prepare PMP, CMP, QMP and Schedule and include all others in PMP itself.
Project Management Planning
This is the top-level plan. This takes info (that is relevant to the project) from the Purchase Order received from the client and places it in the plan. Additionally, the methods of managing the project and tools used, project milestones, communication protocols, escalation mechanisms, issue resolution mechanisms etc also would be part of this plan.
Planning for resources
This forms part of the PMP. To achieve this we need to carry out effort estimation. We may carry out effort estimation using any of the popular techniques. For a detailed discussion on effort estimation, see “Software Estimation – Practitioner’s Perspective” by the same author. Then, work out a schedule for the execution of the project.
We have to estimate human resources with respect to
- The skill sets required for the project – this can be derived from the technical specs of the project
- The size of software that is to be developed using any accepted software size measure such as Function Points or Software Size Units etc.
- The amount of effort that has to be spent on the project – this can be arrived at by converting software size into effort required using the productivity norms of the organization
- The amount of duration that has to be spent on the project – this can be arrived at by allocating resources and assigning calendar days to the activities that have to be performed for executing the project. This is also called as Scheduling and is covered in greater detail in the book Software Estimation – a Practitioner’s Perspective referred to above.
- The likely dates on which the resources would be needed by the project – this can be derived thru the schedule
Types of skill sets needed in a software project
We may need different skill sets to play the following roles for the project team. The following is a typical list of roles – in addition to Project Leader / Project Manager - needed for a large project –
- Programmers - for each of the languages used in the project – to write the necessary programs
- Team Leaders – to lead and manage teams of programmers
- A DBA (Database Administrator) or a database specialist – for data modeling and to design the database initially and then to offer assistance to programmers in the efficient development of data handling routines
- Software Testers / testing specialists – to prepare test plans and test cases and guide the team to ensure that testing is properly carried out and all defects are uncovered and rectified
- Language Smiths – expert programmers for the languages used in the project to assist in troubleshooting programming issues
- Software (Solution) Architect – for process modeling, to develop application architecture and to integrate the developed solution
- Business (Systems) Analysts – who interact with the customer to understand client requirements and translate those needs/requirements into documents, which then, can be understood and used by software developers to produce the solution that meets the client needs. Business Analysts also act as the customer-representative within the project team.
- Configuration Controller – who would control the artifacts – information and software – such that right info is available to various team members and ensure that the deliveries to customer contain right versions
- Process Coordinator – to ensure that organization’s processes are implemented and the process related info is made available on time to concerned functionaries of the organization
Often, some of these roles are handled on a part time or as-needed basis. For example Project Leader or Project Manager often takes on the roles of Configuration Controller, Process Coordinator and Software Architect. Programmers may take on the role of testers too.
Once the required skill sets and the duration for which they are required, resource requests can be placed on the department that allocates person-power to the projects.
Planning for Types of machines
This would be a part of the PMP. The project team needs various hardware items for the project execution, depending on the nature of the project. The following are the typical hardware and system software requirement for a project.
- Special computers based on the project need
- PCs, if necessary, with appropriate terminal emulation software to connect to the development machine/server
- Networking hardware
- Connectivity to the customer machines, if the project is to be executed from a remote location
- Bandwidth – if communication with remote customer or testing of a web application is involved
- Special software – like databases, programming languages, testing tools, configuration management tools, documentation tools and so on
Methods for managing the project
These form part of PMP. The following are the typical methods that are included in the PMP –
- Work allocation methods – work allocation can be carried out using an Excel sheet or a scheduling tool like MS-Project or Primavera or a WBS (Work Breakdown Structure) collaboration tool like PMPal. Intimation of work allocation may be thru formal emails or collaboration tools like PMPal or over phone or in person. All these are used across software development organizations. Similarly reporting of completion by team members may be thru email or in person or over phone.
- Progress measurement & review methods – Some of the popular techniques for progress measurement and review are Earned Value technique and Line Of Balance technique. Weekly Status Report is the most common vehicle for reporting progress and for using as a base for progress review and deciding action points.
- Communication methods – meetings, emails and phone calls are the most frequently used mechanisms to achieve communication within and without the project team. The means of communication is stated in PMP for the following scenarios –
- Communication within the project team
- Communicating work allocation and completion
- Progress Reporting
- Communication with client
- Communication with project support group
Environment – tools, techniques, hardware, system software, database, IDE, testing tools, CM tools, Folder structures for artifacts in various states
Issue Resolution Mechanisms – whenever there is ambiguity or clarifications are needed, an issue arises. The mechanism used to record all issues of the project, communicating the issue to the concerned person and track the issue to resolution that is implemented for each of the issue are under the Issue Resolution Mechanism.
Escalation Mechanism – sometimes it becomes necessary to raise the issue to the next higher level. The levels which are above the normal level of communication and when to escalate an issue and the concerned executive for the issue – all these are planned and recorded under this head.
Configuration Management Planning
In a software development project, there are different configurations used –
- Development Configuration – the arrangement of hardware (development machines – PCs), and the software (the development platform including the programming language, the database, IDE, third-party software used in the project etc) for use by the programmers for developing the software. The data in the database undergoes frequent change and may contain junk data. The software does change very frequently during development. Programmers use this configuration. This would have two distinct portions –
- Code – this portion would have the source code being developed
- Information / documentation – this portion would have all the info received from client, or developed for use in the project (like requirement specs, design, test plans, test cases etc), and project generated info (like test logs, review logs, etc) and change requests received etc.
- Review/Testing Configuration – the arrangement of hardware and software for use by the reviewers/testers. Software does not change in this configuration. Programs enter this configuration and after testing are sent to either development configuration for rectification or to integration configuration for integration with other code units. Software is transient here. Data here is test data that is designed to unearth defects in the software. Data in this configuration stays consistent and does not undergo frequent change except as modified by the software being tested.
- Integration (Build) Configuration – the arrangement of hardware and software for use by product integrators to receive software components and integrate them to build the product. Software components enter this configuration only when they are reviewed and tested and all unearthed defects are rectified satisfactorily.
- Delivery configuration – the arrangement of software components for delivery to the client. Typically this configuration would contain –
- The Software Build
- The source code components
- Third-party software, if any.
- Software Libraries, if any
- Artifacts received from client, if any
- Images, if any
- User Documentation and training materials
- Installation guide, Operations Guide and Troubleshooting Manual
- Deployment (Target/Production) configuration – this is the arrangement of hardware and software components on the target system on which the developed software would be deployed and used.
In a software development project, the daily configuration management activities revolve around promoting software components from one configuration to another. And finally, ensuring that the “right” software components are assembled in the delivery configuration for delivery to the customer.
Another important aspect of Configuration management planning is about how to manage the obsolete artifacts and the artifacts that are being improved upon. To ensure that the concerned persons refer only the current set, we have to provide unambiguous reference to the current set. We do not destroy obsolete artifacts until the project is completed. So we must make provision to store the obsolete artifacts in such a way that it is not easily accessible but available when needed using a system of appropriate authorizations. Similarly, when an artifact is being modified or being improved upon, it is to be ensured that it is stored in a designated folder so that others would not be able to access it. We can achieve this by creating three folders, namely, Current – this folder would contain all artifacts that are to be referred when needed, Archive – this folder would contain previous version of artifacts and In-Process – this folder would contain artifacts that are being developed / revised.
This forms part of Configuration Management Plan. Earlier days, there was restriction on the number of characters that can be used for a name. Now, we can have long meaningful names. Then why do we need naming conventions? We need naming conventions –
- Prevent duplicate names or bring clarity when duplicate names are used
- Easily recognize the contents of the artifact
- Easily identify a group of artifacts, such as all artifacts of a specific module
- Achieve uniformity in naming artifacts
- In programming, naming conventions allow us to distinguish the one type of variable from the another type of variable – such as programming variables from table field names
Naming conventions normally use pre-fixes to distinguish between various categories. The prefixes can be one or more. Naming conventions are defined for the following –
- Document Names
- Program / Subprogram Names
- Screens, Reports
- Numeric Variable
- Alphanumeric Variables
- Database Table Names
- Database table field names
- Error Messages
- Information messages
- Controls like Combo Box, Text Box, Command Buttons etc
This forms part of configuration Management Plan. Change Management in software projects includes –
- Receiving Change Requests (CRs) – this involves designating a single point to receive change requests from all sources, consolidate them and maintain a Change Register
- Analyzing the CRs received – this involves specifying agencies responsible for analyzing the impact CRs received on schedule, effort, and cost and providing this data for taking a decision on implementing the CRS
- Implementing the CRs – this involves the mechanism for implementing the CRs, namely,
- Accept or reject decision
- If accepted, decision on when to implement the CR – as and when received or to retrofit all CRs at the end
- If accepted, the decision on how to absorb the impact or to pass it on to the customer
- Obtain / accord approval for CR implementation
- Implement the CR
- Quality control of the CR implementation
- Closure of the CR
- Progress Reporting of CRs this involves the mechanism to track all CRs received, and tracking all CRs to resolution – communicate the status of all CRs to all the concerned agencies on a periodic basis
- Closing the CRs
Quality Assurance Planning - QAP
This plan basically focuses on achieving the specified level of quality on the artifacts to be produced by the development team. This plan normally contains the following details –
- Standards to be used in the project – such as –
- Coding Standards
- Database Design Standards
- GUI Design Standards
- Test Case Design Standards
- Testing Standards
- Review Standards
- Organizational Process reference
- The specifications of quality levels for the project. These may be –
- Defect Injection rate
- Defect Density
- Productivity for various artifacts of the project
- Schedule variances
- Quality Control activities to be implemented in the project – such as –
- Code Walk-thru
- Peer Review
- Formal Review
- Various types of Tests that would be carried out during the project execution. At a minimum these are –
- Unit Testing
- Integration Testing
- System Testing
- Acceptance Testing
- Measurement for the defined quality levels, periodicity and reporting
- Causal Analysis for the variances – both positive and negative – and its schedule
- Schedules for various audits proposed for the projects –
- Periodic Conformance Audits
- Phase-end Audits
- Criteria for Investigative Audits
- Delivery Audits
- Process Improvement activities, if any
- Progress reporting to all concerned agencies of the status of quality assurance activities implemented in the project
This is best achieved using a scheduling-software such as MS-Project or Primavera. All the activities that are need to be performed to execute the project are enumerated; their predecessor relationships defined; resources allocated and dates are set for the activities.
Induction Training Plan
This plan contains the topics on which the project personnel need to undergo training – examples are –
- Project Plans
- Team Communication methods
- Quality control activities
- Issue resolution mechanisms
- Escalation procedures
- Development platform
- The methods of training
- Self study material availability
Build Plan contains the following info –
- Approach for integration – top down or bottoms up
- Configuration of integration environment
- Quality assurance activities before accepting components into build environment
- Quality assurance activities after integrating each component, each module and at the completion of the build
Deployment Plan consists of the following info –
- A schematic diagram of the deployment components including hard ware, software, networking etc
- Floor Plans, if necessary for deployment of hardware and networking
- A BOM (Bill of Material) listing all components being deployed along with technical specs of each of the components
- Quality assurance activities planned for deployment
- Technical methods, if necessary for deploying the configuration
User Training Plan
User Training plan consists of the following info –
- Details of courses on which users have to be trained, user-class-wise
- Course material for each course including training slides, teaching notes, lesson plans, session breakdown, participant handouts etc
- Schedule of courses to be conducted
- Details of facilities needed for conducting the training
The handover plan consists of the following info –
- A BOM (Bill of Material) of all components to be handed over
- The mode of handover / takeover
- Required sign-offs details
- Schedule of handover
Software Maintenance Plan
Software Maintenance Plan could cover only the software maintenance during warranty period or even later depending on the contractual requirements. This plan consists of the following info –
- Process of raising requests for software maintenance
- Formats, and templates for raising software maintenance requests
- Service Levels agreed – turnaround times for software maintenance requests
- Procedure for classifying software maintenance requests and prioritizing the same
- Issue Resolution mechanisms and escalation mechanisms
- Environment for software maintenance
Documenting the plan
Documenting the plan differs from normal writing. A Project Plan is a document that is used by many persons as a reference and is used in guiding human effort and causes expense. This document ought to be like an engineering drawing. Hallmarks of an engineering drawing are –
- Unambiguous representation – the same inference is drawn irrespective of the person interpreting it
- One fact is presented at one and only one location – never repeated. (Presentation of information at multiple locations may cause conflict – especially during revisions it may be updated at one place and ignored at another)
- Free-flowing language is not made use of – it is subject to guidelines
Taking a clue from engineering drawings, the project plan be better –
- Adhere to documentation guidelines of the organization in the matter of presenting information
- Avoid duplication of information at multiple locations
- Avoid ambiguity
Uniformity in plan documents can be achieved in an organization, keeping in mind that multiple persons are likely to prepare documents, by using templates. Each organization needs to define its own templates. One best source for guidance on templates would be the IEEE standards on software engineering.
Roles in Planning
Achieving effective project planning needs collaboration between various agencies in the organization. Basically there are two entities in the organization that impact project planning, namely, the organization that needs and infrastructure for project planning and the individual who carries out the project planning. Their roles are discussed below.
Organization needs project planning and provides infrastructure that facilitates and enables effective project planning. These include –
- Develop, establish, implement and continuously improve Project Planning Process in the organization – including procedures, templates, formats, quality assurance for plans
- Various guidelines and standards including documentation guidelines, checklists for preparation and review of plans, estimation guidelines and productivity figures for various technologies used
- Establish a nodal agency that takes charge of all project plans and assists concerned individuals preparing project plans in preparing project plans as well as receive feedback and ensures that it is analyzed and dovetailed back into the process, standards and guidelines
- Arrange for review of the plans vis-à-vis actual execution at the end of every project to capture best and worst practices and the efficacy of the project plans
- A Knowledge Repository on the subject of Project Planning
- A Corporate Memory (a Repository) of past estimates and project plans for reference by persons planning the projects
- Structured Training for individuals planning the projects
- Recognizing that Project Planning is a specialist activity and subjecting it to the rigors of Process Improvement as well as recognizing and rewarding individuals who excel at it
Individuals can make or mar the planning. Making best use of the available infrastructure for project planning, individuals vested with the responsibility of planning projects ought to excel at project planning. Individuals can –
- Assist the organization in the developing, establishing, implementing and continuously improving the project planning process
- Adhere to the organizational process, standards and guidelines in letter and spirit
- Give feedback to concerned agencies
- Participate in the process improvement activities wholeheartedly
- Carry out the project planning activity to the best of one’s ability as diligently as possible
- Recognizing that Project Planning is not preparing documents but that it is planning of the project and documenting plans is only for the purpose of review and reference by other concerned agencies
About the Author: