Project planning

Marc Groenewegen (marcg@dinkum.nl)

October 9 2007

Document Information
Organisation Hogeschool voor de Kunsten Utrecht (HKU)
Version 0.3
Status draft
Abstract:
This document provides an introduction into planning and tracking of software projects

Table Of Contents

1 Introduction

2 List of definitions

3 How to manage a project

4 Making a project plan

5 Running the project

6 Gantt charts


1 Introduction

Why do planning ? We can start designing and programming because we have a gut feeling everything will fall into place by itself, but this is not going to happen when the project is bigger than one page of coding and involves more than one person and more than one piece of software.

The purpose of Project Planning is to make plans for building the software and for managing the project. We want to make sure that the work will be delivered in time, within budget, that it will do what was promised and will have the quality that was promised.

To do so we have to make estimates for the work to be done, find the necessary commitments, and make the plans for doing the work.

Project Planning consists of the following parts:

2 List of definitions

3 How to manage a project

3.1 What is a project?

In a project, resources are brought together for a specified period of time to do something like creating a software package or building a house. A project starts with a problem, a need, or an idea and proceeds through a number of stages towards the end product that solves the original problem.

3.2 Why do some projects fail ?

Projects may fail for various reasons: not enough manpower, lack of support, poor facilities, financial miscalculations or unrealistic goals, but very often it's just a matter of bad planning, lack of communication and mismanagement.

Problems can also arise when you promise more than you can deliver, fail to think through how long things are really going to take or are not realistic about the conditions you will operate in or the resources you need.

3.3 How to make a project succeed

There are always circumstances that can not be foreseen and pose a threat to your project. This makes it impossible to assure you your project is definitely going to succeed when you follow certain steps, but if you follow some simple rules your chances for success will increase a lot.

4 Making a project plan

Most important for every project is to make clear what the goals are and how these are to be met. These things should be settled before the project actually begins: who is going to be involved, what is going to be produced, where does the work take place etc...

4.1 Project teams

Projects generally bring together temporary teams of people with their own skills, line of work, points of view, availability and character. To keep a diverse group of people together and make them cooperate it's important that they are guided and the circumstances for them to do their work properly are created. For this we need a project manager.

4.2 The project manager

The project manager has responsibility for successful completion of the project. He (or she) relies on the cooperation of the team members and can make the difference between a successful team or a set of non-cooperating individuals.

This doesn't mean that the project manager does all the work. To the contrary: the project manager keeps a clear view of the goals that have to be realised, monitors the project's progress against the project plans and takes corrective measures if the progress deviates from the plans.

A project manager does not do the project alone but it is essential that all partners know their roles and understand and respect the role of the project manager. These responsibilities and commitment to them are vital for the success of a project.

Some tasks of the project manager:

4.3 Project planning

The planning begins with defining the work to be done, breaking down the work into manageable pieces and assigning people to the pieces. During this planning stage, constraints like manpower, budget and delivery time are constantly to be kept in mind while making time estimates for every deliverable. Some things to consider at the start of a project:

Making a software project plan is always based on estimates. Developing software is only partly predictable. It won't be a surprise that experience makes better estimates, so obviously it's important to learn from the past. Project plans and experience gained in previous projects help to make better estimates for a future project.

The project manager should be able to rely on estimates given by the team members, as these normally have the experience in their line of work to make those estimates.

4.4 Putting together a project plan

When making a project plan, consider questions like why, what, where, when, who, how ?

Why do we do this project ? What is the purpose of it ?

The objectives for a project have to have some generic characteristics, often described by the word SMART. What does SMART stand for ?

Where will the work be done?

What exactly are we going to make ?

What resources are needed and when must they be available ?

When does it start and when does it have to be finished ?

Who will run the project ?

How will the work be done ?

In software development things often take much longer to develop than you might think. Don't hesitate to give realistic estimates to the customer and signal possible risks.

4.5 Software lifecycle

A very important aspect when making a project plan is the expected life cycle of the product. In general the lifecycle of a software product is shown clearly in the diagram taken from Tansley and Hayball:

For every stage in the software lifecycle a number of deliverables are to be defined. These deliverables are incorporated into the project plan, together with their due-dates, also known as milestones.

4.6 Project requirements

A requirements document describes all demands to the system. For example, it states what the system will do, under what circumstances it must operate without failing, how it reacts to external stimuli and how it works together with other subsystems. In some cases it can also be important to specify what the system will not do !

Apart from being a useful resource that explains what will be made, a requirements document also serves as a negotiation guideline for the parties involved: when the system is delivered, the person or department that ordered the system can check whether the system lives up to its expectations and the programmer can prove he/she did a good job.

Requirements Management involves establishing and maintaining an agreement with the customer on the requirements for the software project.

That agreement forms the basis for estimating, planning, performing, and tracking the software project's activities throughout the software life cycle.

5 Running the project

5.1 Project Tracking

The purpose of project tracking is to provide insight into the project's progress so that the program manager can take actions when the project's performance deviates significantly from the plans.

NB: Not only the actual product is monitored but also all documents necessary during the development are to be delivered and reviewed in time.

When it is determined that the software project's plans are not being met, corrective actions are taken. These actions may include revising the software development plan to reflect the actual accomplishments and replanning the remaining work or taking actions to improve the performance.

5.2 Quality Assurance

Throughout the project's lifecycle, adherence to applicable quality standards must be verified objectively.

5.3 Configuration management

The purpose of configuration management is to establish and maintain the integrity of the products of the project throughout the project's life cycle. Configuration management involves identifying the configuration of the software and systematically controlling changes to the configuration.

5.3.1 Archiving and version control

Archiving is a way to store your knowledge and be able to retrieve it. This requires an archiving system that helps you store all relevant information in such a way that you can retrieve it from the system much later. In general we have to define the structure for our archive ourselves.

5.4 Reviews

Reviews are one of the most useful mechanisms in finding design flaws. The idea is that several people read and judge a document or a design and their comments help improve the design or even point out errors. Reviews are usually done for documents but can also prove useful for code.

In general, a review is done by three or four people, preferably from different projects and with different backgrounds. Reviewing consists of several steps:

  1. Reading
  2. Giving comments, preferably in a review meeting
  3. Reworking
  4. Approving

In step 1, the author distributes the document that has to be reviewed amongst the reviewers. This can be done by e-mail or in hard copy. It is important that everyone gets the exact same copy and that this copy is also used in the review meeting. The reviewers read through the document and write down all errors (even spelling errors !), things they consider unclear, omissions etc.

In step 2, all comments are collected. The preferred way is to organise a 'review meeting' in which all reviewers and the author get together. Page after page, every reviewer gets the opportunity to mention his/her findings and the author makes notes about these. Normally, a session of no more than 2 hours should be sufficient. Discussing all details can better be done in a different meeting because of the nature of a typical review group: not everything is relevant for everyone.

Step 3, reworking, implies that the author makes a new version of the document with all findings from the review.

After reworking the document, the author sends it to the reviewers again. When all reviewers agree with the new version, the document is approved and the document status is updated.

6 Gantt charts

The Gantt chart is a visual display chart used for scheduling based on time. It was developed by Henry Gantt (1861-1919) in 1917. A Gantt chart basically is a bar graph with time on the horizontal axis and project activities and resources listed on the vertical axis. It is used to schedule activities that follow and depend upon each other.

The following picture demonstrates a simple Gantt chart:

6.1 Critical path

The critical path is the most important chain of tasks in the project. If any task on the critical path is late, the overall project cannot be completed on time. On the other hand, if any task on the critical path is completed ahead of schedule, there is an opportunity to complete the overall project ahead of schedule, unless another path then becomes the critical path. There are some things to remember about critical paths: