Project Planning

“Politehnica” University of Timisoara Faculty of Automation and Computer Science

Project Planning

Valentina MORAR 4th Year, Group 3.1 Coordinator: Carmen HOLOTESCU

10-04-2009

Table of contents: I.

II.

INTRODUCTION 1. Why do we need a project plan

3

2. Brief description of the project plan

4

THE PROJECT PLAN 1. Characteristics of the project plan

5

2. How to write a project plan

6

3. Structure of a project plan a. Overview b. Phase Plan c. Organization Plan d. Test Plan e. Change Control Plan f. Documentation Plan g. Training Plan h. Review and Reporting Plan i. Installation and Operation Plan

7 9

j. Resources and Deliverables Plan k. Index

9 9 10 10 10 10 11 11 11 13

4. Templates and tools for creating a project plan

13

III.

CONCLUSIONS

15

IV.

REFERENCES

16

2

I. INTRODUCTION

1. Why do we need a project plan A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody directly or indirectly impacted by the project. So, when undertaking a new project, one should consider first and foremost the satisfaction of the stakeholders. This means that a project manager should try to put both the customers and the developers on the first level. Often, project managers try to satisfy their customers first and make efforts to deliver the results as quickly as possible, due to the fact that time consumption is a highly appreciated characteristic. The shorter the period of time needed for completing the project, the better it is appreciated and the more the customers are willing to pay for it. But the key to a successful project is in the planning. Creating a project plan is the first thing a project manager should do when undertaking any kind of project. Although sometimes it might seem like a waste of time, a correct project plan can turn out to actually save time, money and often solve misunderstandings of requirements. Many times, the project planning is ignored or little time is allocated for it, in order to start the actual work on the project itself, but this may result in more time loss than it would have needed for structuring the plan and a lot of uncertainty about the tasks allocated to each developer. Therefore, any project manager, in order to best organize the tasks, the time spent on developing and maintaining, the structure of the project content, should first think of writing all the ideas down, then structure the ideas, so that he can keep track of what had been accomplished at any moment of time during developing.

3

2. Brief description of the project plan A Project Plan is part of the project and it highlights the phases, activities and tasks needed to deliver the project. The timeframes required to deliver the project, along with the resources and milestones are also shown in the Project Plan. It is like an agreement upon a written specification. Such an agreement has several benefits: •

the clarity will reveal misunderstandings

•

the completeness will remove contradictory assumptions

•

the rigor of the analysis will expose technical and practical details

•

the agreement forces all concerned to actually read and think about the details

The Project Plan is the most important document in the project, as it provides the project managers with a roadmap, and it tells them during the journey whether they are on-track. The main advantages the planning of a project puts forward are the following: •

Identify all of the phases, activities and tasks

•

Sum up the effort needed to complete those tasks

•

Document all of the project inter-dependencies

•

List the planning assumptions and constraints

•

Create a detailed project planning schedule

•

Define the project scope & milestones

•

Set and agree the target delivery dates

•

Monitor and control the allocation of resource

•

Report on the progress of the project, to the sponsor

4

II. THE PROJECT PLAN

1. Characteristics of the project plan A project plan has various characteristics that should be followed by the project manager when setting the goals for a new project. The project plan: •

Should be written – this gives the proof of the specifications agreed and helps the project manager keep track of the steps of the project

•

Describes the job to be accomplished, how to proceed in developing and what resources are needed for the accomplishment of the specified job

•

Must be written in such a way that at a later time it’s easy to follow the steps described

•

Allows for contingencies: it states actions to be taken in case something does not go as planned; There are two types of contingency planning to consider: a. The first involves specific, identifiable problems which may arise: for example, if a planned computer is not available on the date specified, where will test time be obtained, and at what added cost in time and money? b. The second specifies what actions will be taken in case unforeseen problems develop? Obviously, specific answers cannot be supplied because specific problems cannot be stated. But the manager can prepare for such events by being realistic in planning resources: - Should always assume people will get sick, leave the company, get pregnant, misunderstand a specification, make mistakes. - Should always assume machines will break down - Should always assume misunderstandings with the customer. - Should plan the best he/she can to make everything work perfectly, but understand that will never happen. 5

- Should allow extra resources to cover the unplanned obstacles. •

Should be modular: it should contain chapters, paragraphs, etc., to make them easily readable; it should be divided logically and should follow a continuous flow from one section to the other

•

Should be brief – for example it can be as small as one page per section; for a medium size project, the approximate value is fifty pages

•

Should be appealing for reading – it shouldn’t include too much bulk, because it will go unread

•

Should have an index – its inclusion will greatly enhance the usefulness of the document.

In order to fulfill all the above requirements, it is recommended to begin with a model plan and that would lead to a good start toward continuity.

2. How to write a project plan When preparing a project plan, it’s best to start with a model, then further develop the details. Of course, a plan should be written after a contract with the customer has been signed, because this means the details of the project were already established. Also, there is no point in wasting time in writing a complete detailed plan for a project it’s not sure that it will be developed. However, often the project manager designs the sketch for the plan as the specifications are set forward. When writing a plan, it must be taken into account that the plan will change as the project develops, so it must be structured in a flexible way, allowing it to change during the life of the project, but still provide all the necessary means for keeping the track of the steps followed. For the project plan, one should consider involving everyone responsible for the project: analysts, programmers, managers, customer etc. Each of them has their own 6

impact on the input or on the change of the plan. Also, any feedback received from them during the development of the project should be confronted with the plan and, if necessary, the plan should be changed in order to include the significant feedback. The project manager has to overview and to approve all the input and changes of the plan. One important characteristic should be taken into account when writing the project plan: its length. The project plan should be as small as possible in order to reduce interactions and produce a plan that hangs together. Also, the plan should have a cohesive structure. A good way to start the writing of a plan is to get a template/ model and then adapt it to the specifications of the project and to the ideas a project manager has. For this, one must consider the necessary how much time one can afford to spend writing the plan. Of course, one can assign tasks of writing sections of the plan to different people (for example managers of subprojects) after discussing the project’s objectives with them. The project manager should think of all the constraints, like fixed deadlines, customerimposed milestones, funding, and work location and include them all in the plan. During the project’s evolution, the plan will also evolve. Therefore, the project manager must consult with programmers and analysts and record the progress, and then compare it with the original specifications. If necessary, he/she must consult with the planners to establish if the plan needs to be adapted.

3. Structure of a project plan

Once the project manager has a clear understanding of the project, then he/she can describe it as a set of simpler separate activities. If any of these are still too complex for him/her to easily organize, they can be broke down into another level of simpler descriptions, and so on until the manager can manage everything. In this way, one complex project can be organized as a set of simple tasks which together achieve the desired result.

7

The reasoning behind this is that the human brain can only take in and process so much information at one time. To get a real grasp of the project, one has to think about it in pieces rather than trying to process the complexity of its entire details all at once. Thus each level of the project can be understood as the amalgamation of a few simply described smaller units. In planning any project, there are the same simple steps to be followed: if an item is too complicated to manage, it becomes a list of simpler items. People call this producing a work breakdown structure. Without following this formal approach the project manager is unlikely to remember all the little details; with this procedure, the details are simply displayed on the final lists. One common mistake is to produce too much detail at the initial planning stage. A description of the activity is sufficient to provide a clear instruction for the person who will actually do the work. Also, a reasonable estimate for the total time/effort involved is needed. The Project Plan is divided into the following sections: •

Overview

•

Phase Plan

•

Organization Plan

•

Test Plan

•

Change Control Plan

•

Documentation Plan

•

Training Plan

•

Review and Reporting Plan

•

Installation and Operation Plan

•

Resources and Deliverables Plan

•

Index

8

a. Overview In this section, a general description of the organization of the plan is given, assuming the reader doesn’t have knowledge of the project yet. It’s like a summary of the entire plan, giving only brief (gross) estimations regarding the timing and the specifications. It might also contain a brief analysis (including technical terms) of the project and the risks taken.

b. Phase Plan This section gives a description of the development of the project. For each phase of the life cycle, some primary and secondary objectives are stated. This section will be the reference for future details. This means the terms used should be clearly described, as should also be the specifications.

c. Organization Plan This section describes the organization during project phases and specifies the responsibilities for different groups within the organization. These can be presented first as general responsibilities and then more details can be provided. As mentioned earlier, the project plan is prone to change during development. This section is often changed as the project evolves from one phase to another. One important aspect to be taken into consideration is the people available for work at each phase and organize the work to best suite the human resources. Another important aspect is that if the planned organization turns out to be wrong, the project manager should change it.

9

d. Test Plan No plan is complete without explicit provision for testing and quality. In this section, the methods of testing are described. If there are tools used for testing, they should be mentioned, as well as the persons responsible for them. The people overviewing the results of the test should be mentioned. Also, any other means or details of testing used should be stated in this section.

e. Change Control Plan This part specifies the types of changes to be controlled and the mechanisms involved in controlling the changes. Also, the effects of the changes must be stated. This section should provide a description of the method through which a change in the project is requested by a developer or analyst (including, of course, the reason for the change).

f. Documentation Plan Most of the developers consider documentation to be a tedious work, therefore there are a lot of cases in which the documentation is missing or is incomplete. The idea for a documentation plan is that everybody should write the documentation using the same style, so it can be understandable and readable for all. This section of the project plan describes precisely the documents needed in the project and the style that should be followed. This section changes a lot, as the manager realizes that a new document is needed at a certain moment during development.

g. Training Plan This section specifies the necessary training on the project. This can involve the developers of the project (internal training) or the customer (external training). For complex applications, external training is usually paid very well. 10

h. Review and Reporting Plan During the project’s evolution, its status must be recorded. The review upon the project can be done orally or written. This part is viewed usually as quality assurance phase. The reviews can be external or internal. All these details are specified in this section, as well as the people in charge of them, the people responsible for communicating or writing the reports, etc.

i. Installation and Operation Plan This section describes the procedure of installing the application in its desired environment and the procedure of testing the functional operation of the application. This is usually referred as functional quality assurance of a project.

j. Resources and Deliverables Plan This is a key section in the plan, as it describes the resources allocated for developing, installing, testing the application (see Figure 1): • • • •

Manpower Computer time Other resources Budget

Also, the milestones and deliverables are stated: • Delivery schedules • Milestone chart - a summary of project milestones

11

12

k. Index It’s one of the most effective ways to make the Project Plan much more attractive and usable to the reader.

4. Templates and tools for creating a project plan It is wise to start with a template when trying to create a project plan. A project manager can take a standard outline for the project plan and adapt it to the specific project and to his/her needs. The template is like a guide to help create a good structured project plan. Of course, if the template doesn’t suite the project manager’s ideas, it’s not compulsory to follow the structure outlined in the template. Moreover, each plan depends on the project to which it corresponds. This means that, for example, for a more complex project, a more detailed plan is needed. All these issues, as well as opting for the use of a template and the level of detail provided by the plan are decided by the planners and eventually approved by the project manager. There are also tools for creating a project plan. Such a tool is SpiraPlan – an essential tool for planning and managing today's highly complex projects in a collaborative environment. Designed specifically to support agile methodologies such as XP, Scrum, DSDM and AgileUP it allows teams to manage their requirements, releases, iterations and tasks. It presents charts, reports, project summary dashboards, etc. – with the intent of helping project managers and easing their work (see Figure 2 and Figure 3).

13

Figure 2 - Printable Reports Library

Figure 3 - Graphical Charts Library

14

III. CONCLUSIONS There is, no question, a must for writing a project plan before staring the work on a project. This doesn’t happen often, but the project manager should at least make sure there is a plan, even if it is incomplete before going on with the work. A project manager must be flexible and understand that the project plan will change along with the progress of the project. He must make sure that the plan is adapted and it is always in correspondence with the status of the application. When writing the plan, he/she should respect all the characteristics of a good project plan and also make sure that everybody understands the importance of having a plan. The plan’s existence is crucial for the project, as it provides the specifications needed and eliminates possible misunderstandings. Also, it saves time and money, it establishes the schedule and the milestones for the development of the project. Most important, when writing a plan, the project manager should focus both on the importance of the customer for the specific project, but also on the importance of developers, analysts, testers, etc. and should consider all the resources available before proceeding to the organization of the project.

15

IV. REFERENCES

1. Duncan Haughey: Project Planning A Step by Step Guide, © Project Smart 2000-2008

2. Gerard M Blair: Planning a Project, Starting to Manage: The Essential Skills, ChartwellBratt (UK) and the Institute of Electrical and Electronics Engineers (USA), 1996

3. http://www.inflectra.com/SpiraPlan/Highlights.aspx

4. Vladimir Cretu: Software Projects Management, “Politehnica” University of Timisoara, 2009

16