The Project
Plan
Writing the project plan provides a structured framework for thinking
about how the project will be conducted, and
for considering the project risks. Ultimately you cannot write a plan
until you have a plan. Having a comprehensive plan may require the involvement
of a range of functional experts, and it often requires the involvement of
decision-makers.
A significant value of writing a project plan is the process rather than
the outcome. It forces the players to think through their approach and make
decisions about how to proceed. A project plan may require making commitments,
and so it can be both a difficult and important part of establishing the project.
The project plan provides a vehicle to facilitate executive and customer
review. It should make major assumptions explicit and provide a forum for
communicating the planned approach and for obtaining appropriate approvals.
If the project team includes diverse organisations or ambiguous lines of
authority and communication, it may be useful to write a Project Management Plan to describe the roles and
responsibilities of the various organisational entities. It can also be used to
communicate management systems and procedures to be used throughout the project.
The requirements definition and specifications tell us what the project
needs to accomplish. The Project Plan should tell us how, when, by whom, and
for how much.
If the project will be challenging, it is important to
define and control the scope, schedule and cost so they can be used as
baselines for tracking progress and managing change. Defining the project
management triangle is the essence of a useful project plan.
There
should be some version of the project plan written with wide scope, at a level
of detail appropriate for executive review. There should be top-level
discussion of all the aspects of the project
that one would want to communicate to the senior customer or sponsor managers.
The project plan should address implementation, training,
and support plans as well as plans for future growth and expandability.
The
project plan should demonstrate that all aspects of the project
have received careful thought and that clearly defined plans for project
execution and control have been formulated. The generation of plans at the beginning
of a project
can be useful if they are concise and are used to set policy and procedures for
the conduct of different aspects of the project.
A
large complex project
may have many separate plans such as: Business Plan, Project Plan, Test Plan,
Acquisition Plan, Quality Assurance Plan, Integrated Logistics Support Plan,
Public Relations Plan, Training Plan, Software Development Plan, Project
Management Plan, Marketing Plan, Risk Management Plan, Process Development
Plan, Systems Engineering Management Plan, Staffing Plan, Communications Plan,
Configuration Management Plan, Data Management Plan, Implementation
Plan, Customer Service Plan, and so on.
Of
course, many small or straightforward projects will have very little formal
planning documentation, and developing a plan with extensive narrative would be
pointless. The challenge is always to assess project risks and apply project management practices only as
needed to the risks of your specific project environment. The Scalable
Methodology Guide provides practical assistance in tailoring best practices
project management techniques for the specific needs of smaller projects.
The
key to a successful project
is in the planning. Creating a project plan is the first thing we should do
when undertaking any kind of project.
Often
project planning is ignored in favour of getting on with the work. However,
many people fail to realise the value of a project plan in saving time, money
and many problems.
Here
I am describing a looks at a simple practical approach to project planning. On
completion of this we should have a sound project planning approach that we can
use for future projects.
Step
1 Project
Goals
A
project
is successful when the needs of the stakeholders have been met. A stakeholder
is anybody directly or indirectly impacted by the project.
As
a first step it is important to identify the stakeholders in our project. It is
not always easy to identify the stakeholders of a project,
particularly those impacted indirectly. Examples of stakeholders are:
·
The project
sponsor
·
The customer who receives the deliverables
·
The users of the project outputs
·
The project manager and project team
Once
we understand who the stakeholders are, the next step is to establish their
needs. The best way to do this is by conducting stakeholder interviews. Take
time during the interviews to draw out the true needs that create real
benefits. Often stakeholders will talk about needs that aren't relevant and
don't deliver benefits. These can be recorded and set as a low priority.
The
next step once we have conducted all the interviews and have a comprehensive
list of needs is to prioritise them. From the prioritised list create a set of
goals that can be easily measured. A technique for doing this is to review them
against the SMART
principle. This way it will be easy to know when a goal has been achieved.
Once
we have established a clear set of goals they should be recorded in the project
plan. It can be useful to also include the needs and expectations of our
stakeholders.
This
is the most difficult part of the planning process completed. It's time to move
on and look at the project
deliverables.
Step
2 Project
Deliverables
Using
the goals we have defined in step 1, create a list of things the project needs
to deliver in order to meet those goals. Specify when and how each item must be
delivered.
Add
the deliverables to the project plan with an estimated delivery date. More
accurate delivery dates will be established during the scheduling phase, which
is next.
Step
3 Project Schedule
Create
a list of tasks that need to be carried out for each deliverable identified in
step 2. For each task identify the following:
·
The amount of effort (hours or days) required to complete the task
·
The resource who will carryout the task
Once
we have established the amount of effort for each task, we can workout the
effort required for each deliverable and an accurate delivery date. Update our
deliverables section with the more accurate delivery dates.
At
this point in the planning we could choose to use a software package such as
Microsoft Project
to create our project schedule. Alternatively use one of the many free
templates available. Input all of the deliverables, tasks, durations and the
resources who will complete each task.
A
common problem discovered at this point is when a project
has an imposed delivery deadline from the sponsor that is not realistic based
on our estimates. If we discover that this is the case we must contact the
sponsor immediately. The options we have in this situation are:
·
Renegotiate the deadline (project
delay)
·
Employ additional resources (increased cost)
·
Reduce the scope of the project
(less delivered)
Use
the project schedule to justify pursuing one of these options.
Step
4 Supporting
Plans
This
section deals with plans we should create as part of the planning process.
These can be included directly in the plan.
Identify
by name the individuals and organisations with a leading role in the project.
For each describe their roles and responsibilities on the project.
Next,
describe the number and type of people needed to carryout the project.
For each resource detail start dates, estimated duration and the method we will
use for obtaining them.
Create
a single sheet containing this information.
Communications
Plan
Create
a document showing who needs to be kept informed about the project
and how they will receive the information. The most common mechanism is a
weekly / monthly progress report, describing how the project is performing,
milestones achieved and work planned for the next period.
Risk management
is an important part of project
management. Although often overlooked, it is important to identify as many
risks to our project
as possible and be prepared if something bad happens.
·
Here are some examples of common project risks:
·
Time and cost estimates too optimistic
·
Customer review and feedback cycle too slow
·
Unexpected budget cuts
·
Unclear roles and responsibilities
·
Stakeholder input is not sought or their needs are not properly understood
·
Stakeholders changing requirements after the project
has started
·
Stakeholders adding new requirements after the project
has started
·
Poor communication resulting in misunderstandings, quality problems and rework
·
Lack of resource commitment
Risks
can be tracked using a simple risk log. Add each risk we have identified to our
risk log and write down what we will do in the event it occurs and what we will
do to prevent it from occurring. Review our risk log on a regular basis adding
new risks as they occur during the life of the project.
Remember, when risks are ignored they don't go away.
Having
followed all the steps above, we should have a good project plan. Remember to update
our plan as the project progresses and measure progress against the plan.Project Management
No comments:
Post a Comment