Project Planning A Step by Step Guide

By Duncan Haughey
The key to a successful project is in the planning. Creating a project plan is t
he first thing you 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.
This article looks at a simple practical approach to project planning. On comple
tion of this guide you should have a sound project planning approach that you ca
n use for future projects.
Step 1 Project Goals
A project is successful when the needs of the stakeholders have been met. A stak
eholder is anybody directly or indirectly impacted by the project.
As a first step it is important to identify the stakeholders in your project. It
is not always easy to identify the stakeholders of a project, particularly thos
e 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 you understand who the stakeholders are, the next step is to establish thei
r needs. The best way to do this is by conducting stakeholder interviews. Take t
ime 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 you have conducted all the interviews and have a comprehensiv
e 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 b
een achieved.
Once you have established a clear set of goals they should be recorded in the pr
oject plan. It can be useful to also include the needs and expectations of your
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 you 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 mu
st be delivered.
Add the deliverables to the project plan with an estimated delivery date. More a
ccurate 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 identifi
ed 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 you have established the amount of effort for each task, you can workout th
e effort required for each deliverable and an accurate delivery date. Update you
r deliverables section with the more accurate delivery dates.
At this point in the planning you could choose to use a software package such as
Microsoft Project to create your 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 deliv
ery deadline from the sponsor that is not realistic based on your estimates. If
you discover that this is the case you must contact the sponsor immediately. The
options you 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 you should create as part of the planning process.
These can be included directly in the plan.
Human Resource Plan
Identify by name the individuals and organisations with a leading role in the pr
oject. 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 you will us
e 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 ho
w they will receive the information. The most common mechanism is a weekly/month
ly progress report, describing how the project is performing, milestones achieve
d and work planned for the next period.
Risk Management Plan
Risk management is an important part of project management. Although often overl
ooked, it is important to identify as many risks to your 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 you have identified
to your risk log and write down what you will do in the event it occurs and what
you will do to prevent it from occurring. Review your risk log on a regular bas
is adding new risks as they occur during the life of the project. Remember, when
risks are ignored they don't go away.
Congratulations. Having followed all the steps above you should have a good proj
ect plan. Remember to update your plan as the project progresses and measure pro
gress against the plan.
1

Developing the Project Plan

By Talibah Adenouga
Whether you call it a project plan or a project timeline, it is absolutely imper
ative that you develop and maintain a document that clearly outlines the project
milestones and major activities required to implement your project.
This document needs to include the date each milestone or major activity is to b
e completed, and the owner of each. Your project plan also needs to be created a
t the beginning of the project, and a baseline version approved by the team as s
oon as possible.
Although you will probably not know all of the major activities required to impl
ement your project in the beginning, it is important that you create a draft of
the activities you think may need to be tracked via a formal document.
Take some time and really think through what you know about the objective of you
r project. Look at some historical data from similar projects. You can even have
a few informal meetings with knowledgeable individuals you can use as a soundin
g board to make sure you aren't completely off base. You'll be surprised how goo
d a draft you can develop if you put in a little effort.
With this draft you will be able to speak with subject matter experts (SMEs) and
stakeholders to flesh out the project plan. If you don't make some level of eff
ort to develop a rough draft, you may give a bad impression which will make it h
arder for you to obtain the support of the persons you need to implement the pro
ject.
After you have fleshed out your draft with your core team, and some other SMEs t
hat may not be a part of your team, you should give the document a baseline stat
us. Your timeline / project plan should not undergo many edits, if any, after it
achieves baseline status.
You should document the actual date your project activities are completed. If th
e actual completion date differs from your baseline date at anytime, you'll stil
l have documented the date it was supposed to be completed for historical purpos
es.
It is also a good idea to notate where things are deleted or added, and why. Tha
t way you aren't standing there looking crazy, trying to go through the crevices
of your memory, when someone asks you why something you deleted isn't in the do
cument...and trust me, someone will ask.
A few key items to include in your timeline are:
• A unique ID that your team can reference when giving an update
• The name of the task
• When the task should start
• When the task should finish
• The actual date the task was completed
• Any tasks that need to happen before other tasks can begin
• The owner of the task
• Percent complete of each task
You or the Project Sponsor you represent may decide to track or maintain more th
an what has been outlined above in your project plan. This is absolutely fine. T
hese are just the items I have found to be vital, and a good foundation to build
upon.
It is completely possible to run a project without a project plan or timeline; i
t's just not very smart. So, do yourself and your project team a favor... docume
nt milestones and important tasks, keep up with the status, and you'll be that m
uch closer to a well managed project.
Remember, it doesn't matter what you call it, it just matters that you develop i
t.
Demand a Strong Project Plan
What to look for to advance your consulting projects from contract to execution
By Michael Strange
You've engaged a reputable consulting firm to perform a large systems project. Y
ou've prepared an RFP, carefully reviewed the responses, scrutinised the consult
ancy's oral presentation, and ultimately negotiated and signed a well-written st
atement of work (SOW).
Don't stop there.
A clearly defined SOW may place you on the right path, but it doesn't ensure suc
cess. In reality, the project manager engaged to run your project may not even b
e the person who wrote the SOW.
As an IT leader, you can and should do more to help advance your consulting proj
ects from contract to execution. A careful review of the project plan is one way
to facilitate this transition, and it's an underused and surprisingly effective
method of finding early warning signs. So spend time reviewing the project plan
and asking questions. Here's what to look for:
1. Analysis, preparation and documentation tasks should be well defined.
Unless the requirements are 100 percent complete, most software projects require
extensive analysis and planning in advance of design. For example, make sure th
ere are tasks defined for process analysis, requirements definition and all rela
ted areas. Make sure there are tasks to discuss security, response times, user r
oles, data conversion, retention, reporting, preparation for testing (not just t
esting execution) and so on.
When evaluating the level of detail, many managers use the "40 hour" rule, which
states that all tasks must take less than 40 hours. But it's more useful to inc
lude preparatory and documentation tasks. For example, look at how this project
plan describes the steps for documenting requirements:
• Gather requirements, accounts payable (40 hours)
• Gather requirements, cash application (40 hours)
• Gather requirements, accounts receivable (40 hours)
• Finalise and get sign-off on requirements (40 hours)
The project team has two full-time people dedicated to documenting requirements,
so they should be able to complete this segment in two weeks.
But consider rewriting the plan as follows:
• Eight meetings, accounts payable, two hours each (16 hours)
• Preparation, one hour per meeting (eight hours)
• Document results, four hours per meeting (32 hours)
• Repeat the pattern for the other functional areas
The new plan shows 56 hours of effort, rather than the 40 in the original. If th
is pattern holds throughout, you may be starting your project 40 percent over bu
dget and not know it. With the rewritten plan, team members will see that the tw
o weeks that had been allocated is not enough, especially given the difficulty o
f scheduling meetings. And if they can't tell you this kind of detail, they have
n't thought the project through.
2. The allocation must make sense.
Check the high-level allocation of effort. If the project is "waterfall" style,
calculate the percentage of hours spent on each phase (analysis, design, constru
ction, testing and implementation). If the project is "prototype" style, calcula
te the percentage of hours spent getting to the first and subsequent milestones.
Take project management tasks out. The percentages should correspond to the mat
urity of your project. If the requirements are already defined, then don't accep
t the plan if 30 percent of the hours are allocated to analysis. If the project
is in early stages of definition (and may evolve as work progresses), then don't
accept a plan with 5 percent analysis.
3. Milestones should come every 30 days or less.
One of the easiest and most effective ways of managing multi-month systems proje
cts is to use well-defined milestones. Demand a formal presentation of the desig
n at one milestone. Schedule a review of the first iteration of prototyping at a
nother. For straightforward custom-development projects, the milestones should b
e self-evident, and with formal review, they can be early indicators of success
or failure. For newer, more complex projects (such as business intelligence or m
aster data management), make sure your consultants have the expertise to define
practical milestones.
4. Contingency must be quantified, not buried.
Contingency should provide a "relief valve" for unknown problems or unplanned wo
rk, and it should be included in virtually every project plan. If the project ma
nager tells you that no contingency is required, his inexperience with the unkno
wns of large projects is showing. In my experience, once a custom development pr
oject is designed and a plan is carefully prepared, a 10 percent to 15 percent c
ontingency is still warranted. More or less may be required, depending on the ma
turity of the project and the organisation.
5. Project management steps should be defined, not assumed.
Project management is a series of tasks, and those tasks should be included in t
he plan. Tasks such as documentation review and preparation of presentations and
status reports are easily quantified. Don't accept a plan that includes technic
al tasks only and then adds just one person to serve as the project manager.
If you follow these rules, the project should progress cleanly. And since the pl
an will clearly describe tasks to be performed, you'll be better able to spot pr
oblems before they get out of control.
Then follow through
Signing a consulting contract isn't enough. Follow these steps to help the consu
ltants spend more time on expertise-driven analysis and less time on logistics.
1. Hold a kick-off meeting. Explain the goals, objectives and roles to ever
yone involved.
2. Be honest with your team. Clearly explain why outside help is needed.
3. Facilitate scheduling. Don't let the consultants flounder trying to sche
dule meetings.
4. Hold intermediate discussions. Help them focus on what's practical for y
our environment.
5. Help with formats. If your organisation has standards for presenting bus
iness cases, recommendations and ROI calculations, give these to the consultants
in advance.
Work Breakdown Structure: Purpose, Process and Pitfalls
By Micah Mathis, PMP
In this article we are going to look at what many project managers and project m
anagement professionals refer to as the "foundation" of the project, or at least
the foundation of project planning. The Work Breakdown Structure (WBS) is defin
ed by A Guide to the Project Management Body of Knowledge 3rd Edition (PMBOK Gui
de) as:
"A deliverable-oriented hierarchical decomposition of the work to be executed by
the project team to accomplish the project objectives and create the required d
eliverables."
Wow! That is a lot of buzz words and jargon, but do not worry. It is not nearly
as daunting as it sounds. Creating a quality WBS will require a substantial amou
nt of energy, time, and people, but in the end is not rocket science. However, b
efore we get too deep into how to actually create a WBS let's first look at its
purpose.
Purpose
Why do we need to create a WBS for our projects? What purpose does it serve? Why
should I waste my time writing on post-it notes and drawing charts when I could
be getting my team started on the actual work of the project? Now, I know every
one reading this is a great project manager or team member, so I am sure none of
you have ever said comments such as these, but I am sure you have heard them fr
om those "other" project managers who will remain nameless.
So to answer these questions, let's take a look at what purpose the WBS serves t
o our project and our project team. There are three reasons to use a WBS in your
 projects. The first is that is helps more accurately and specifically define an
d organise the scope of the total project. The most common way this is done is b
y using a hierarchical tree structure. Each level of this structure breaks the p
roject deliverables or objectives down to more specific and measurable chunks. T
he second reason for using a WBS in your projects is to help with assigning resp
onsibilities, resource allocation, monitoring the project, and controlling the p
roject. The WBS makes the deliverables more precise and concrete so that the pro
ject team knows exactly what has to be accomplished within each deliverable. Thi
s also allows for better estimating of cost, risk, and time because you can work
from the smaller tasks back up to the level of the entire project. Finally, it
allows you double check all the deliverables' specifics with the stakeholders an
d make sure there is nothing missing or overlapping.
Process
Now that we have agreed that creating a WBS will be help to our project's effici
ency and effectiveness, how do we go about it? First, let's look at what all we
need to get started. There are several inputs you will need to get you off on th
e right foot:
• The Project Scope Statement
• The Project Scope Management Plan
• Organisational Process Assets
• Approved Change Requests - (PMBOK Guide)
These inputs should give you all the information you and your team needs to crea
te your WBS. Along with these inputs, you will use certain tools as well:
• Work Breakdown Structure Templates
• Decomposition - (PMBOK Guide)
Finally, using these inputs and tools you will create the following outputs:
• Work Breakdown Structure
• WBS Dictionary
• Scope Baseline
• Project Scope Statement (updates)
• Project Scope Management Plan (updates)
• Requested Changes - (PMBOK Guide)
The first step to creating your WBS is to get all your team, and possibly key st
akeholders, together in one room. Although your team is not listed as an input o
r tool in the above sections, they are probably your most vital asset to this pr
ocess. Your team possesses all the expertise, experience, and creative thinking
that will be needed to get down to the specifics of each deliverable. Next, we h
ave to get the first two levels setup. The first level is the project title, and
the second level is made up of all the deliverables for the project. At this st
age it is important to function under the 100% Rule. This rule basically states
that the WBS (specifically the first two levels) includes 100% of all the work d
efined in the project scope statement and management plan. Also, it must capture
100% of all the deliverables for the project including internal, external, and
interim. In reality the WBS usually only captures between 90-95%, and 100% is ou
r goal.
Once we have gotten the first two levels set, it is time to launch into our de
composition. Decomposition is the act of breaking down deliverables in to succes
sively smaller chunks of work to be completed in order to achieve a level of wor
k that can be both realistically managed by the project manager and completed wi
thin a given time frame by one or more team members. This level of breakdown and
detail is called the work package. Work packages are the lowest level of the WB
S and are pieces of work that are specifically assigned to one person or one tea
m of people to be completed. This is also the level at which the project manager
has to monitor all project work. Now the million dollar question is how specifi
c and small does a chunk of work need to be to still be considered a work packag
e? Well PMBOK does not seem to give a definitive answer on that. Most project ma
nagers concur that this varies by project, but can usually be measured using the
8/80 Rule. The 8/80 Rule says that no work package should be less than 8 hours
or greater than 80 hours. Notice we said that the work package is the lowest lev
el of the WBS. Activities and tasks are not included in the WBS. They will be pl
anned from the work packages once they are assigned.
Now you are ready to start your team on the work of decomposition, but do not ge
t too far ahead of yourself quite yet. As grandpa always said "There is no reaso
n to reinvent the wheel." Occasionally, you will run into a project that is a "f
irst of its kind," but that is not usually the case. Most of the time, you, your
team, or your organisation has done a project like this one in the past. That m
eans that there should be a WBS from the previous project that you can use as a
template. This will save you a lot time and effort. Even if you have not done a
project like this one before, most Project Management Offices (PMOs) have basic
WBS templates that can get you started. Another great technique to make your lif
e easier is the Post-It Note Technique. I know it sounds a little cheesy, but it
actually works very well. In this technique you simply write each deliverable o
n a post-it note and stick them at the top of a wall. Then you and your team sta
rt to break down each deliverable into components and write each component on it
s own post-it note. This way, as you place them on the wall and start to create
your tree structure, everyone can easily see what has been accomplished and wher
e you are headed. Also this technique allows for easy movement of components aro
und within the WBS.
Now the conference room wall is covered in post-it notes and Sally is franticall
y wanting to write everything down before they start to fall, but wait one more
step before you put it into an official (or semi-official) document. You can use
your newly created WBS to look for missing or overlapping pieces of each delive
rable. This will help eliminate change requests and double work down the road. O
nce that is completed, put your WBS on paper and log it into your project.
Many projects will also find it necessary to create a WBS Dictionary to accompan
y their WBS. The WBS Dictionary is simply a document that describes each compone
nt in the WBS. This helps clarify any specifics later on when team members compl
eting the work or stakeholders viewing the deliverables have questions. Also, wh
en creating the WBS for very large, lengthy, or complex projects, all the delive
rables' specifics might not be known up front and, therefore, it is difficult to
create a full WBS. In cases such as these many people use what is called Rollin
g Wave Planning. This is when you plan down to the level of detail currently kno
wn and go back to plan deeper once more information is acquired. Usually rolling
wave planning needs to stay as least 2-3 months ahead of the actual work being
done, but of course this varies slightly by industry.
Pitfalls
Lastly let's look at five common pitfalls to creating a WBS. If you can keep the
se few possible issues in mind when you are creating your WBS, you and your team
will be much more successful at creating a useful and accurate Work Breakdown S
tructure.
1. Level of Work Package Detail
When deciding how specific and detailed to make your work packages, you must be
careful to not get too detailed. This will lead to the project manager to have t
o micromanage the project and eventually slow down project progress. On the othe
r hand, work packages whose details are too broad or large become impossible for
the project manager to manage as a whole.
2. Deliverables Not Activities or Tasks
The WBS should contain a list of broken down deliverables. In other words, what
the customer/stakeholder will get when the project is complete. It is NOT a list
of specific activities and tasks used to accomplish the deliverables. How the w
ork is completed (tasks and activities) can vary and change throughout the proje
ct, but deliverables cannot without a change request, so you do not want to list
activities and tasks in the WBS.
3. WBS is not a Plan or Schedule
The WBS cannot be used as a replacement for the project plan or schedule. A WBS
is not required to be created in any type of order or sequence. It is simply a v
isual breakdown of deliverables.
4. WBS Updates Require Change Control
The WBS is a formal project document, and any changes to it require the use of t
he project change control process. Any changes to the WBS change the deliverable
s and, therefore, the scope of the project. This is an important point to help c
ontrol scope creep.
5. WBS is not an Organisational Hierarchy
The WBS and Organisational Hierarchy chart are never the same thing. Although of
ten similar in appearance, these two documents are very different. The Organisat
ional Hierarchy shows things like chain of command and lines of communication, b
ut the WBS is restricted simply to a project and shows only the deliverables and
scope of that project.
We hope that this article has helped you better understand the Work Breakdown St
ructure's purpose, process, and common pitfalls. The WBS is an extremely valuabl
e tool to the project management methodology. It can make or break a project. It
sets the foundation for the rest of the project planning. A solid WBS helps ens
ure proper project baselines, estimating, resource use, scheduling, risk analysi
s, and procurement.

Project Planning: The First Line of Defence for Preventing Failed Projects
By Matthew Sheaff
Every year thousands of projects are completed over budget, out of scope and pas
t deadline. Still, with each passing year, project managers continue to rush int
o projects without due diligence in defining the project and creating a plan for
project execution. By lightly addressing these critical components they are, in
essence, failing their projects before any work has even commenced. So how can
project managers efficiently execute a project plan while at the same time meeti
ng the deadlines and expectations of senior management? Here are three simple bu
t critical tips for any project manager to improve project results.
1. Ensure all stakeholders are identified
When beginning any project it is important to meet with all potential stakeholde
rs and understand their interests with respect to the project. Many projects fai
l when the project manager doesn't realise how a special interest group (ex., un
ions, environmental groups, etc.) can delay or stop a project. The project manag
er must represent all such interests in defining the project. In many cases proj
ect managers only have a general understanding of the project definition as per
the project sponsor (i.e., customer) and do not adequately understand the needs
of the target audience/end-users of the project deliverables. Remember that a st
akeholder is defined as a person or organisation that is either actively involve
d in the project, or whose interests may be positively or negatively affected by
the execution or completion of the project. A stakeholder may also exert influe
nce over the project and its deliverables.
2. Define, describe and validate the project definition
Most projects fail due to poor definition. This is the leading cause of scope cr
eep, which leads to unavailable resources and more time and budget necessary to
completely satisfy scope. Since the plan reflects the work, resources, budget, a
nd time necessary to satisfy the scope it is easy to see the critical importance
of understanding the project definition and description. It is also necessary t
o ensure agreement from all stakeholders before planning. Let stakeholders revie
w the draft of the project definition document, and get their sign-off, before m
oving to the planning phase of the project. Also, ensure stakeholders understand
that agreement with the project definition only means we all agree with the def
inition, not that we can satisfy scope, schedule and budget targets. In order to
commit to achieving the project's objectives, detailed bottoms-up planning need
s to be completed by the subject matter experts who will be performing the proje
ct work. It is only through this detailed planning that we can confirm that the
project definition is realistic and achievable.
In translating the project scope statement, it is necessary to identify the majo
r deliverables that will satisfy the scope. In addition the team should identify
what is in scope and out of scope for each of the major deliverables. It is oft
en a challenge to ensure implicit expectations are surfaced and are made explici
t by documenting them in the project definition document.
There are seven essential elements that need to be included in the project defin
ition:
• A clear description of the business problem and the solution to that problem
• A description of the benefits of completing the project (the business case)
• A concise (25-30 word) definition of the project schedule, scope and budget)
• A list of the major deliverables (which, when delivered, completely satisfy the
scope of the project), including what is in scope and out of scope for each
• A priority matrix which summarises the sponsor's priorities for the schedule, sc
ope and budget parameters that define the project
• Target customers for the project deliverables
• Project dependencies (committed dates and commitments to/from other projects)
The above project definition components do not exclude other possibilities that
can enhance understanding of the projects, for example:
• A milestone schedule that can document interim deliverables requested by the spo
nsor
• An impact statement that identifies what can or will be impacted by the project
• Strategic risks
• Constraints (ex., schedule, environmental, political, cultural, technological)
3. Create a Work Breakdown Structure (WBS)
The WBS is the foundation of the project plan. The WBS is a hierarchical logical
structure that represents all the work necessary to produce all the project del
iverables. By doing so it organises and defines the total scope of the project.
Work that is not in the WBS is outside the scope of the project. The WBS must be
broken down to a sufficient level of detail so that one owner can be assigned r
esponsibility for planning and managing each activity at the lowest level. By un
derstanding the deliverables for assigned activities, by having clear completion
criteria, each activity owner can successfully develop realistic and defensible
time and budget estimates.
Summary
In order to get the right resources at the right time project managers must have
a clear definition and a good project plan. Best practice project management is
n't an impediment to the project, it is critical to project success. As the sayi
ng goes, "Pain me now… or pain me later."
Planning a Project using a Work Breakdown Structure and Logic Network
Projects don't just happen they are planned. The whole project team should devel
op the plan not just the project manager. This ensures that the teams' experienc
es are taken into account and that everyone is fully committed and has ownership
of the plan. A good project plan will provide the following:
• A roadmap everyone in the team can follow with clear milestones
• A realistic project timescale
• Details of resource requirements
• Validation of the estimated cost
• Identification of task slippage
• Early warning of problems
It pays to use previous experience (historical data) from similar projects.
• How long did it take?
• How much did it cost?
• What were the problem areas?
• What were the successful areas?
Running a project without a plan is foolish. Working without knowing where you a
re going is likely to lead to problems and possible failure. Running a project w
ithout a plan is like trying to find your way in a strange city without a map. A
s the saying has it, "If you fail to plan, you are planning to fail."
Work Breakdown Structure (WBS)
In order to identify the individual tasks in a project it is useful to create a
Work Breakdown Structure. The WBS is the foundation for the detailed project pla
n. Get the team together and brainstorm all of the tasks and sub-tasks in the pr
oject, in no particular order. Write them down on sticky notes and put them on a
whiteboard. Once everyone has thought of as many tasks as they can, arrange the
sticky notes into groups under the major areas of activity. Add, modify, remove
and shuffle the sticky notes until the WBS is accurate, complete and logical. T
he purpose of a WBS is to decompose the project into steps and sub-steps.
Logic Network (time chart)
A Logic Network shows the sequence of activities in a project across time. It sh
ows which activity logically precedes or follows another activity. Create a star
t (left) and end (right) sticky note and put them on the board. Arrange the WBS
sticky notes in the logical sequence of activities from left to right. Join the
notes with an arrow in and out; some may have more than one arrow. All connectin
g lines on a network enter at the left (beginning) of the activity box (sticky n
ote) and exit at the right (ending). Lines do not enter the top or exit the bott
om of the activity box. No unconnected lines are allowed. All activities must co
nnect to another activity or the start or end of the project. Add the amount of
time every activity will take on each sticky note to calculate the project durat
ion. You have created a Logic Network that will help you understand the dependen
cies in your project, timescale and its workflow. This technique can reveal impo
rtant information that could otherwise be overlooked.
Milestones
Look for milestones in your Logic Network. A natural milestone may occur any tim
e a series of parallel activities come together in a point. Control the project
by defining a concrete deliverable for each milestone. A concrete deliverable is
something you can see or touch such as a design specification, prototype, repor
t, software module etc.
Using Project Management Software
The information from your WBS and Logic Network can be input into a software pac
kage such as Microsoft Project to provide a detailed plan. Enter the tasks, pred
ecessors, resources and time estimates into the software. Once entered the softw
are will create the charts and graphs automatically. Don't expect the software t
o plan or management the project; it's just a tool.
Checklist
Here is a checklist to help you create a well thought out, detailed project plan
 while building a committed high performing team.
1. Define what needs to be done using a Work Breakdown Structure
2. Determine the best approach to get everything done by developing a Logic
Network
3. Establish responsibilities and develop work and duration estimates of ho
w long each team member requires for each task
4. Calculate how long the project will take to complete, its critical path
and milestone schedule using the Logic Network
5. Calculate and chart how many people will be needed and the percentage of
each team member's time for each phase of the project
6. Adjust and refine the project plan to level individual workloads and smo
oth the number of people needed during the project
7. Creatively optimise trade-offs to deliver the best results in the shorte
st time
8. Use the joint planning process to intensify team members' commitment and
ownership