PROJECT MANAGERS COMPANION
SECTION 12 - PLANNING PROJECTS
|
CONTENTS
|
1. Introduction
2. What Is A Project?
3. Step 1 - Agree Objectives And Scope
4. Step 2 - Identify Requirements
4.1 Step 2a - Management Products
4.1.1 Project Start-Up Products / Documents
4.1.2 Planning Products / Documents
4.1.3 Project Management Products / Documents
4.1.4 Project Quality Products / Documents
4.1.5 Project Closure Products / Documents
4.2 Step 2b - Specialist Products
5. Step 3 - Define Needs
6. Step 4 - Plan Activity
7. A Paper Based Approach
8. Step 5 - Review Products And Plans
9. Step 6 - Project Risks
10. Step 7 - Change Management
11. Step 8 - Project Initiation Documents
12. Step 9 - Start Project
This document is a designed as a support / procedures
document to assist developing project plans. It assumes that the reader is familiar
with the PRINCE method of project management and the project planning tool
Microsoft Project.
For those unfamiliar with PRINCE a summary is provided in
the Project Managers Companion file. If you have any training requirements for
PRINCE, project management or Microsoft Project please see the training
department.
If you have technical problems with the set-up of the
project planning tool Microsoft Project or using the templates that have been
developed for Jersey Post Office please see the IT Section.
Sometimes it is difficult to establish what is a project and
what is day-to-day work. The point here is to establish do we need a formal
project set-up, plans and organisation structure for this work or not? At all
times we should use project management at a level appropriate to the project
complexity, budget and risk. This is the general guideline which it is proposed
should be used by the Corporate Team and Business Planning Workshop to
categorise supporting objectives in the Business Plan.
|
|
FOCUS GROUP
|
SMALL PROJECT
|
MAJOR PROJECT
|
|
Is there a defined goal and end-date?
|
Generally No
|
Yes
|
Yes
|
|
How long will it take?
|
Generally undefined
|
< 6 months
|
> 6 months
|
|
How much will it cost?
|
< £5000
|
< £50,000
|
> £50,000
|
|
Resources
|
Resources do not require management.
|
Low resource demand over length of project
|
High resource demand over length of project
|
|
Departmental function
|
Recurring or routine activity.
NEW reports or strategies
|
One-off (requires change management plan)
|
One-off (requires change management plan)
|
|
Involvement
|
Generally internal to Jersey Post Office
|
|
Involves significant contractual (3rd Party) arrangements
/ penalties
|
|
Project Management
|
dedicated Project Manager not required
|
Part-time Project Manager
|
Project Manager using more than 50% of their time.
|
All projects should follow the basic steps outlined in this
document, however small project may have a Focus Group of 3 people and lots of meetings
and a summary plan. Major projects may require a Project Manager, Project
Board, a full organisation set-up with roles and responsibilities and sets of
plans with much more detail where there is a requirement to schedule resources
and control budgets. The principles remain the same for both, but a large
project may have more formality including the documentation of agreements,
progress etc.
Get whoever has told you to do the project to define exactly
what the outcome is supposed to be, and roughly by when you are supposed to
achieve this outcome. This will tell you what the goal is, and having
established what the goal is you have a much better chance of scoring! To
continue the analogy a little further get the agreed objective documented,
either in a sign-off document or minuted in a meeting. This will prevent people
moving the goal posts (as so often happens with projects!)
Identify everyone who is likely to be involved in the project,
either as people doing the work or end-users receiving the result. From this
group establish a “Focus Group” who will collectively meet and thrash out a
list of what needs to be done to achieve the end goal.
This should result in a “shopping list” of things to do. In
PRINCE terminology this is a Product List. The idea is to get every requirement
to culminate in a tangible “thing”. The end-product of an activity might be a
sign-off document, a set of minutes, an agreement, a contract, a committee act.
The point is that in project management terms it is easier to measure and
control the delivery of tangible products or “things”.
It is very useful if the Product List has Product ID numbers
so that they can be cross referenced with the plans which should also detail
Product ID numbers.
STEP 2A - MANAGEMENT PRODUCTS
The management products are likely to be similar for all
projects and therefore it is quite easy to anticipate what they are, how they
will be used and their contents…
|
PRODUCT
|
USAGE
|
|
|
PROJECT INITIATION DOCUMENT
|
A Project Initiation Document should answer the following
questions
Why are we doing this project, what is the business case?
How will this project be managed?
Controls & Budgets
Project Reporting
Meetings
The Products and Plans, when agreed, form part of the
Project Initiation Document
Agreed by Project Manager and Project Board
|
Date
Title
Introduction
Confirmed Project Brief
Business Case
Definition Of Organisation And Responsibilities
Quality Plan
Project Pre-Requisities
Project Risks
Management Of The Project
Project Tolerances
Project Reporting
Financial Control
|
|
PROJECT BRIEF
|
A Project Brief should answer the following questions
What is the purpose of the project, what are the aims and
goals?
What are the assumptions, constraints and risks?
What is the organisation structure, who reports to who,
who is in-charge?
What is everyone’s role / job description?
Agreed by Project Manager and Project Board
|
Date
Title
Background
Definition Of Business Goals
Project Aims
Specific Objectives
Constraints
Assumptions
Executive
Senior Users
Senior Technical
User Project Manager
Business Change Manager
User Stage Teams & Project Assurance Function
|
|
PRODUCT
|
USAGE
|
CONTENTS / HEADINGS
|
|
PRODUCT DESCRIPTIONS
|
To explain, in detail exactly what needs to be done /
delivered / produced and set the standard (quality) demanded.
Agreed by Project Manager and Stage Team(s)
|
Date
Title
Purpose
Composition
Derivation
Format And Presentation
Allocated To
Quality Criteria
Quality Check Required
Approving The Product.
|
|
PROJECT PLANS
|
To record at high level the schedule of activities and
stages through the project.
Agreed by Project Manager and Project Board
|
Date
Title
Activity
Cost
Start Date
End Date
Resources
|
|
STAGE PLANS
|
To record at detail level the schedule of activities for a
given stage, period, or activity.
Agreed by Project Manager and Stage Team(s)
|
Date
Title
Activity
Cost
Start Date
End Date
Resources
|
|
END OF STAGE REPORT
|
To record progress at the end of a stage, period, or
activity, comparing actual results against plans and putting forward the next
period plans. Used by stage managers to report to Project Manager.
|
Date
Title
Management Summary
Progress This Period - What Happened
Potential Problems
Suggested Next Period Activities
Budget Status
Resource Implications
|
|
PRODUCT
|
USAGE
|
CONTENTS / HEADINGS
|
|
PROJECT MANAGER’S PROGRESS REPORT
|
To record progress, report issues and agree next period
activities. Used monthly to communicate to Project Board.
|
Date
Title
Management Summary
Progress This Period - What Happened
Potential Problems
Suggested Next Period Activities
Budget Status
Resource Implications
|
|
PROJECT RISK REGISTER
|
To record risks, and possible contingencies / avoiding
action. Used by Project Manager to communicate risks and impact to Project
Board.
|
Date
Title
Risk Detail
Impact Notes
Likelihood
Impact
Risk
Action(S)
|
|
CHANGE CONTROL
|
To control changes to the project where they impact upon
the quality, scope, end-date or budget.
Agreed between Project Manager, relevant Stage Team(s) and
Project Board.
|
Date
Title
Problem / Reason For Change
Change Required
Impact (Budget / Time)
|
|
OFF SPEC REPORT
|
To report back where a product or deliverable fails to
meet the specified requirements.
Agreed between Project Manager, relevant Stage Team(s) and
Project Board.
|
Date
Title
Agreed Specification
How This Fails The Specification
Impact
Change Required
|
|
PROJECT ISSUE REPORT
|
To alert the Project Manager or Project Board to an issue
which can either require no further action, or might give rise to a Change
Control or Off Spec Report. (see above)
Agreed between Project Manager, relevant Stage Team(s) and
Project Board.
|
Date
Title
Problem / Issue
Factors / Impact
|
|
PRODUCT
|
USAGE
|
CONTENTS / HEADINGS
|
|
INVITATION TO QUALITY REVIEW
|
To notify relevant people that a product has been
submitted for acceptance and to give them the opportunity to review that
product before acceptance.
|
Date
Title
Fix Of Meeting (Time / Venue)
Enclosure Of Product
|
|
MINUTES OF QUALITY REVIEW
|
To record acceptance or otherwise of a product.
If a product is not acceptable to record actions / changes
required.
|
Date
Title
Comments From Meeting
Action Required
|
|
PRODUCT
|
USAGE
|
CONTENTS / HEADINGS
|
|
END OF PROJECT NOTIFICATION
|
For the Incorporation Programme Manager to report to the
Project Board / Corporate Team on how the project has performed against its
goals.
Created by Project Manager for the Project Board.
|
Date
Title
Achievement against objectives
Performance against plan and budget
Summary of outstanding issues
Fix of post implantation review date
|
|
LESSONS LEARNT REPORT
|
To pass on any lessons that have been learnt from this
project that may be used to benefit Project Managers, Jersey Post Office or
other projects.
Created by Project Manager for the Corporate Team.
|
Date
Title
What went well
What went badly
What improvements could be made
|
|
POST IMPLEMENTATION REVIEW
|
To find out whether the project has delivered expected
benefits and if the project has caused any problems.
Created by Project Manager for the Corporate Team.
|
Date
Title
Achievement of expected benefits
Unexpected benefits
Unexpected problems
User reaction
Follow-on work requirements
|
STEP 2B - SPECIALIST PRODUCTS
The specialist products are unique to each project.
Examples:
For an IT & Systems Project these are likely to include
hardware, software, test plans, training plans.
For an Incorporation Programme there may include work for
Accounting, Pensions, IT & Systems, Corporate Administration and Facilities
In each case the product descriptions should meet the
requirements (defined above) and repeated below.
|
PRODUCT DESCRIPTIONS
|
To explain, in detail exactly what needs to be done /
delivered / produced and set the standard (quality) demanded.
Agreed by Project Manager and Stage Team(s)
|
Date
Title
Purpose
Composition
Derivation
Format And Presentation
Allocated To
Quality Criteria
Quality Check Required
Approving The Product.
|
When you have a Product List the next thing to do is to
describe each item as if it were a specification or purchase order that could
be given to someone unfamiliar with your project. If you describe your exact
requirements in this level of detail it becomes very difficult for someone to
deliver or do the wrong thing.
When describing a product and the activities that lead up to
completion of the product consider who will be involved, what will they do, how
much will it cost. A product description should answer the 6 questions; who,
what, when, where, why, how.
A Product Description should answer the following questions
What is the purpose, goal and end-product?
Who will be involved, for how long and how much will it
cost?
What, if anything, is this dependant upon?
Who will receive, accept or be the end-user of this product?
What is the acceptance criteria?
What risks or contingencies need to be considered?
This is a critical point and it might be prudent at this
stage to get your boss or the person requesting the project to agree a sign-off
document which acknowledges that this is what they want and that you haven’t
misunderstood and they haven’t changed their minds.
The advantage in products and product descriptions are that each
separate sheet or document can be passed to individuals or used as the basis of
a sub-contract or tender. This is more difficult with a set of plans which will
contain all the activities of a project, rather than discrete elements.
When you have a list of requirements (Product List) and a
specification of each item (Product Description) then you have a list detailing
a series of things that must be completed on the way to your project goal. The
next stage is to schedule these things into a project plan.
Completing the project plan should be easy if you have
followed this route. Steps 1 to 3 will have ensured that everyone has
contributed to thinking about what needs to be done, you’ll have a list of what
needs to go into your plan and the product descriptions will have identified
who will be involved in what.
It is very useful that the plan indicates Product ID numbers
so that it can be cross referenced with the Product List and Product
Descriptions which should provide further detail to the activity being
scheduled. It may be useful to detail only the major deliverables in the Product
List (STEP 3) and minor sub-components are recorded only in the plans. Where
further detail is needed to explain these interim products notes are made which
are appended to the plans as part of a Plan Description. The benefit of this
approach is to limit the amount of product descriptions that are developed
without compromising the quality of planning which is enhanced by the
requirement to define resources and actions required to deliver products.
A paper based approach
In Jersey Post Office we use ms-project to plan and schedule
our projects, if we were not using a software tool, a paper approach might be
as follows….
|
TASK
|
RESPONSIBILITY
& INVOLVEMENT
|
START DATE
|
DURATION
|
END-PRODUCT
|
|
Work to be done
|
Who is in charge
|
When should it be done
|
How long should it take to complete task(s)
|
What should be the end-result
|
|
Focus Group meetings to agree and document requirements
for tender.
|
|
|
10 days
|
Terms of reference for tender (agreed by Corporate Team)
|
|
Issue tender to prospective companies
|
|
|
3 days
|
Tender invitation sent out by registered mail.
|
.. this meets all the planning requirements of identifying
who does what when, and the PRINCE principles of having a definable end-product
against which progress can be measured. It is detailed here because not all
project people will use ms-project and using a list of tasks, as above, is a
good alternative.
This could be scheduled using a simple table or spreadsheet,
as below, where each task number in the schedule refers to the detailed
information contained in the table above.
|
Task
|
Date
|
Duration
|
week 1
|
week 2
|
week 3
|
week 4
|
|
1. Focus Group
|
|
10
|
|
|
|
|
|
2. Tender
|
|
3
|
|
|
|
|
This scheduling technique can be used to indicate where one
task must follow another, either because they have to be done one after the
other (Example: painting walls before laying carpet) or because they are being
done by the same resources who cannot do 2 jobs at once.
This is a very simple planning technique and lacks the
reporting and calculating facilities that come from a software planner, however
this is a simple way to approach project planning without specific software for
the purpose.
By this stage you will have gone through the step by step
process of listing requirements, defining requirements and making plans. At
each stage you will go into the project in greater detail, adding resources and
identifying costs as well as planning the activities surrounding the delivery
of each of the requirements.
Now is the time to step back and check that the Product
Descriptions (see above) and the Plans fit together. A typical test would be to
ensure that the “Who will be involved, for how long and how much will it cost”
in the Product Description agrees with what is scheduled in the plans.
This is another critical point and, as before, it would be
wise to agree a sign-off document to double-check that things are still going
in the right direction.
By this point in the project planning it should be possible
to identify what might go wrong, what might be the consequences and what action
should either be taken to avoid problems, or taken if such problems arise. A
record of risks and contingencies should form a risk register or risk report
that should be put to the Project Board with the Project Initiation Document so
that everyone knows, and if necessary accepts, the inherit risks of the
project.
This can be detailed in a simple table, as below.
|
RISK DETAIL
|
IMPACT NOTES
|
LIKLIHOOD
SCORE
|
IMPACT
SCORE
|
RISK
SCORE
|
ACTION
|
|
|
Lack of resource time.
There is so much going on that people will not have the
time to meet their project commitments.
|
Products may be done late, or not at all. In some areas
quality may be compromised leading to omission or error with key products.
|
4
|
5
|
20
|
Jersey Post Office will need to outsource work where
possible, hire temps and be very sure of retaining key staff. Some work may
need to be totally sub-contracted.
|
|
STEP 7 - CHANGE MANAGEMENT
All projects deliver change and an assessment needs to be
undertaken to make sure that the change is managed efficiently and effectively
so that the benefits to staff, operations and customers are realised.
This may comprise the following..
Impact analysis - to identify the impact on staff,
procedures and operations
Communication plan - to ensure participation & feed-back
of all stakeholders
STEP 8 - PROJECT INITIATION DOCUMENTS
When you have completed step 4 the next thing to do, if
everyone agrees with your plans (or it has been revised and adjusted until
everyone does!) is to write up a Project Initiation Document and Brief. These
two documents are the main documents that detail what the goal is, what the
constraints and assumptions are and what other factors apply. These documents
are key because they will be the bench-mark against which the end of the
project will be assessed.
Whereas the Product Descriptions detail what must be done,
and the Plans when it must be done, the Project Initiation Document and Brief
take a broader view and detail the objectives and end-goal of the project and
how the project should be managed.
A Project Brief should answer the following questions
What is the purpose of the project, what are the aims and
goals?
What are the assumptions, constraints and risks?
What is the organisation structure, who reports to who, who
is in-charge?
What is everyone’s role / job description?
A Project Initiation Document should answer the following
questions
Why are we doing this project, what is the business case?
How will this project be managed?
Controls & Budgets
Project Reporting
Meetings
The Products and Plans, when agreed, form part of the
Project Initiation Document
The Project Initiation Document and Brief are crucial. They
form a ‘contract’ agreement of what should be done and neither party should
change or deviate from this without agreement with the other, and if necessary,
renegotiations on budgets, staff, time-scales etc.
Start your project. By now you should have a clear
understanding of who, what, where, when, how and why. The Project Initiation
Document and Brief should layout the framework of the project (including roles,
responsibilities etc) and the Product Descriptions detail what must be done,
and the Plans when it must be done. This is an excellent foundation from which
to start your project. Good luck!
