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
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:
- cost control
- time management
- resource management (people, goods, money)
- risk management
- quality assurance
2 List of definitions
- customer - person, board or group that gives the assignment
- deliverable - item or outlined part of the project that has
to be delivered
- milestone - important moment in the project's time scale
- project manager - person responsible for the project
- planning - setting out the way to reach the goal
- resource - people (labour), raw materials, external tools, money
- requirements - demands posed to the end product
- tracking - monitoring progress of a project
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:
- Make project plans
- Motivate people
- Keep track of expenses and budget (money management)
- Stimulate communication within the project team
- Track and correct project progress
- Facilitate equipment, housing etc.
- Deal with the customer about planning issues
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:
- availability and employability of team members
- holidays
- budget
- total available time
- commitment
- risks
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 ?
- Specific: no open-ended questions
- Measurable: progress can be objectively determined
- Agreed upon: commitment from all parties
- Realistic: feasible
- Trackable: output can be related to time
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:
- Reading
- Giving comments, preferably in a review meeting
- Reworking
- 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:
-
The critical path is recognised as the one without any slack time
-
Any task on the critical path lengthens the project schedule.
-
Tasks on a non-critical path can expand without threatening the project's
completion date.
-
If a non-critical path expands to fill the available slack time, it may
become the new critical path.