BACKGROUND:
A project, in a
business environment, is:
·
a finite piece of work (it has a beginning and
an end);
·
undertaken within defined cost and time
constraints;
·
directed
at achieving a stated business benefit.
Key project roles
are:
·
The project
sponsor who is the person who wants the benefits the project will
provide. The person is “benefits
focused”. Answers the question is the
project viable? Do the benefits the
project provides fit our strategy?
·
The project
manager is the person who manages the project on a day-to-day basis,
ensuring that its deliverables are presented on time, at the right quality and
to budget. The person is “action and
delivery focused”. He/she is the key
player in creating and fostering a team spirit and enrolling the commitment of
those associated with the project. The project manager ensures clear reporting
lines, good information flow, realistic work plans and well defined project
roles for team members.
·
The project
review team is the cross-functional group which assesses the “doability”
and integrity of the project portfolio (MES-WB Quality Component) as a whole.
·
The project
team is that group of individuals in
the organization or brought to it for the term of the project to accomplish the
work to be done. The team may be
dispersed geographically; have other duties to attend to; and may not be the
most appropriate people.
Projects are viewed in stages. Stages are specific periods during which work
on the project takes place. These are
when information is collected and outputs created. For each stage of the project one should
carry out the full range of work covering the entire scope of functional inputs
required. These functions should not
work on the project in isolation but in a continuous dialogue with each other,
thus enabling the best overall solution to be developed. In this way ones knowledge develops and
increases on all fronts at a similar pace and solutions are designed, built and
tested in an integrated way. (Functional inputs in the business
setting are marketing, commercial, operational, and technical. In the MES they are its departments,
divisions, centres, etc.)
Gates (or milestones)
are decision points which precede every stage.
Unless specific criteria have been met, as evidenced by certain approved
deliverables, the subsequent stage should not be started. Gates serve as points to:
·
check that the project is still required and the
risks are acceptable;
·
confirm its priority relative to other projects;
·
agree to the plans for the remainder of the
project;
·
make a go/no go decision regarding continuing
the project.
At each gate, the following three questions are answered:
·
Is this project, in its own right, viable?
·
What is its priority relative to other projects
to be started?
·
Is the funding available to undertake the
project?
In other words, the key elements of benefit, scope, time and
cost are all present. The business plan is the document where all
of this is recorded. It serves as the
key review document for the approving and authorizing the project (MES and
World Bank).
In any project, the project manager delegates accountability
for parts of the work to members of the core team. This is done by breaking the project into work packages, usually centered around
deliverables. Each work package has a
person accountable for it. The work
package can be broken into smaller parcels again and again until you reach
activity or task level. This is called
“work breakdown structure (WBS) ”and is a fundamental control framework for a
project.
Cross-functional
teams are those made up of people from different parts of the
organizational hierarchy. They bring
different perspectives together, make it easier to negotiate the
all-encompassing, cross-functional processes result in planned change. During each stage is essential for the
project manager to continuously forecast and reforecast the benefits, resources
and costs needed to complete the project.
He/she should always keep the relevant functions informed and check on
behalf of the sponsor that the project still makes sound business (and in our
case, educational) sense.
Projects draw on resources from a wide range of functions
within an organization. Ensuring these
are focused on achieving specific, identified benefits for the organization is
the key management challenge. The
likelihood of success of projects is enhanced by following a project framework which:
·
is benefit driven;
·
is user and customer focused;
·
capitalizes on the skills and resources in the
organization;
·
builds “quality” into the project deliverables;
·
helps manage risk;
·
allows many activities to proceed in paralleled
(hence greater velocity); and
·
is used by people across the whole organization.
The project framework
includes the following seven stages:
·
Have an
idea – Proposal: an idea is first formally recognized by
describing, in a concise form, what one wants to do and why.
(MES-WB
initial discussions.)
·
Have a
quick look – Initial investigation
stage: a quick study of the
proposal, to outline the scope and make a rough estimate of the benefits,
resources and costs needed to complete it.
At the end of this you should be sure of why you are doing it and what
you are doing; you will know how to go about at least the next stage, if not
the full project. One should know
roughly how much it will cost, the resources likely to be needed and the order
of magnitude of the benefit expected. (Work done leading to MES-World Bank agreement
to proceed to plan the project.)
·
Have a
closer look – Detailed investigation stage:
a detailed investigation and a full investment appraisal culminating in
a decision to proceed with development work.
At the end of this stage one will have high confidence in all aspects of
the project and “What you want to do
”becomes “What you are going to
do!” Another name for this stage is the
“Business Plan. (What
the project planning team is doing now to prepare for WB appraisal and MES
approval and support.)
·
Do it! –-
Develop and test stage: the actual
development and implementation work. (For the implementators once the loan is
approved.)
·
Try it –
Trial stage: a trial of all aspects
of the development in the users’ or customer’s operational and working
environment. What has been created may
work very well under “test conditions, ”but does it work under normal
operational conditions? (Implementation pilots.)
·
Use it –
Release stage: when one unleashes
the creation on the world! This is when
products are launched, new computer systems used, new manufacturing plant goes
into production, new organization units start operating to the ”new rules,” new
processes are invoked, acquisitions sealed and disposals shed. The ongoing operational aspects are embedded
in the organization and the project is formally recognized as complete. (Pilots
expanded…standards shared with all of Latvia, etc.)
·
About three to six months after completion, a
check, known as a post-implementation
review, is done to see if the project is achieving its business objectives
and its outputs are performing to the standards expected. (Internal MES consideration of next steps based upon results.)
The Business Plan
(The Planning Team’s Job Now!)
There are three parts (and an appendix) to most business
plans:
·
Part
1: Finance, which is primarily aimed
at the finance function. Of interest to
the organization‘s finance department.
The project sponsor will also be interested in this as it sets out the
financial criteria to be met.
·
·
Part
2: Project Definition is of interest
to the project sponsor, stakeholders and project team. It is the meat of the document.
·
·
Part
3: Project Organization is of most
interest to the project manager and team as it sets out how they have organized
themselves.
The Business Plan Outline by Headings:
Section Section Heading Question Answered
1 FINANCE
1.1 Financial
appraisal HOW
MUCH?
1.2 Financial commentary HOW
MUCH?
2 PROJECT DEFINITION (WB Plan of
Action)
2.1 Background WHY?
2.2 Business Objectives Why?
2.3 Benefits Why?
2.4 Output definition WHAT?
2.5 Scope, impacts and
interdependencies WHAT?
2.6 Deliverables WHAT?
2.7 Timescale WHEN?
2.8 Risks and opportunities CONTEXT
2.9 Prerequisites, assumption
and
constraints CONTEXT
2.10 Project and implementation
approach HOW?
2.11 Analysis of options HOW?
3 PROJECT ORGANIZATION
(WB organization of PCU and decision-making.)
3.1 Review and appraisal points HOW?
3.2 Change control HOW?
3.3 Progress reporting HOW?
3.4 Project
team and stakeholders WHO?
4 APPENDICES
A. Business
Commitment
(WB identification of conditions required for implementation)
B. Schedule
plan (WB
sequence of activities over 4 years)
C. Resource
plan (WB
estimated resources needed for implementation)
D. Financial
plan (WB
estimated costs for implementation)
E. Terms
of Reference for Consultants for 1st year
F. Financial
sensitivity (WB
sustainability of investments)
G. Output
definition document (See section 2.4)
The Project
Definition: This section of the
business plan document defines the project – why one is doing it, what will be
produced, and how one will go about it.
Until this project definition section is completed, one cannot develop
fully either the financial or project organization sections of the business
plan.
2. PROJECT DEFINITION
2.1 Background
Describe, briefly, the background to the project:
·
Explain why the project has come about (eg, as a
result of a strategy study, as a result of findings from another project).
·
Refer to any other associated projects or
initiatives, business plans, or conclusions from previous studies.
2.2 Business Objectives
You should describe why you are doing the project:
·
Explain the business objectives the project will
satisfy;
·
Explain how the project supports the business
strategy.
Answering the question of “Why” is very important. There are four basic reasons why one should
want a project:
·
to earn more revenue;
·
to save costs;
·
to reduce working capital;
·
to enable one to remain in business.
All programs (related projects) will ultimately be aiming
for one or more of these. However, in a
program, individual projects may focus on other benefits, for example,
improving performance and service quality.
Other projects are created as vehicles to learn about new markets,
technologies, or approaches.
Relate these
objectives to the overall goals of the MES-WB Project.
2.3 Benefits
Describe the benefits to be achieved from the project. Benefits may be in two forms:
·
Financial – these should be stated in “money”
terms (eg, increased revenue, cost savings, etc.);
·
Nonfinancial – changes in operational and key
performance indicators should be quantified.
If you are unable to quantify a particular benefit describe it as best
you can – just because you can’t count it, doesn’t mean to say it does not
count (eg, changing attitudes about learning).
Include a statement on what else the project will
accomplish; for example, say what new possibilities will be created eg,
operationally, commercially, or for new projects.
In addition, outline:
·
the minimum conditions of satisfaction required
in order to declare the project a success (eg, achievement of a specific market
share, revenue, cost saving);
·
the method for measuring and confirming the
achievement of each benefit;
·
any possible events which, if they occur, will
lead you to consider terminating the project.
2.4 Output Definition
Describe, in one paragraph, what the project is going to
produce overall. This may be a new
product, a new culture, process, manufacturing line, computer system. Section 2.6 will list the key deliverables
and these need not be stated here. The output definition document will contain
the detail.
2.5 Scope, Impacts and Interdependencies
Define the work
necessary to meet the business objectives outlined in Section 2.2 and to create
the output described in Section 2.4. Include:
·
the work needed to be undertaken;
·
the boundaries of the project;
·
any aspects which are specifically excluded from
the project;
·
key interdependencies with other projects
You should also state, in broad terms:
·
the impact the project will have on current
operations and existing projects;
·
the functions or departments in the organization
which will be affected.
Scope: The project scope must comprise everything
which is needed to ensure that the benefits can be delivered. There should be no assumptions that others
are providing a key part. If other
projects are providing deliverables, this must be stated explicitly and not
assumed.
Interdependency: If Project B requires a deliverable from
Project A in order to achieve its objective, project B is dependent on project
A, ie, a deliverable is passed from one project to another.
(For example, Project A builds a computer platform as one of
its deliverables. Project B uses this
platform to run software it has built as one of its deliverables. If project A failed, project B will fail as
it is dependent on it.
A deliverable can be created by one project only. It may, however, be used by many subsequent
projects.
2.6 Deliverables
List the major deliverables from the project and which are
needed to create the output described in Section 2.4. Deliverables may take two forms:
·
Final deliverables – which are to be handed over
by the project team to the users at the end of the project (eg, hardware, software systems, brochures,
product specifications, tariffs, business processes, advertising campaigns);
·
Temporary deliverables – which are to be
produced during the course of the project for review and sign-off (eg, detailed
investigation report, business plan).
For each deliverable, specify:
·
the format and content in which it is to be
produced (eg, a written report, TV advertisement);
·
the named individual accountable for its
production and the target date for its completion;
·
the named individual(s) accountable for
reviewing and / or signing it off.
If the list is extensive, you should detail them in an
appendix and only list the very key ones in the main body of the document. (May use deliverable report form. Listed in Appendix in Business Plan
Template.)
2.7 Timescales
Outline the overall project timescales by stating the target
completion dates for key milestones.
Include all the staged framework milestones; development gate, trial
gate, RFS gate, launch, project complete.
Add any other significant milestones or events such as the letting
(tendering) of a major contract. (WB plan over four year period.)
2.8 Risks and Opportunities
This section should contain:
·
a list of the significant risks and
opportunities that may potentially jeopardize or enhance the success of the
project;
·
actions that will be taken at the outset to
reduce the likelihood of each risk identified;
·
actions or contingency plans that may be
implemented, should any risk or opportunity happen.
2.9 Prerequisites, Assumptions, and Constraints
Include:
·
any circumstances outside your control which must
be in place if your project is to be successful;
·
all assumptions that have been made about the
environment (eg, economic factors, competitors, systems, people) in which the
project is to be conducted;
·
any constraints which have been imposed on the
project which may affect the outcome.
It is important that all assumptions and constraints are
listed, even if they appear obvious to you; they may not be so obvious to
others associated with the project.
2.10 Project and Implementation Approach
Describe how the project will be undertaken and explain why
you have chosen this particular approach.
Include:
·
a work breakdown structure (eg, phases, stages,
subprojects, work packages) with justification;
·
key interfaces between subproject elements and
with suppliers.
Where subprojects are complex, each one should be formally
using sections 2 (project definition) and 3 (project organization) of this
document.
2.11 Analysis of Options
Summarize the key points from the investigative studies,
stating which options have been rejected and which have been carried forward
for further analysis. Give your reasons
for any choices made.
3. PROJECT ORGANIZATION
Once the project is defined and has been planned out, once
should make sure that other organizational aspects of the project are
addressed, including defining:
·
project administration needs (filing);
·
who can authorize changes to the project;
·
what formal review points are required.
Project Filing:
Projects can generate a considerable volume of information,
correspondence and reports, most of which needs to be accessible and some of
which needs to be archived. It is
essential that the project manager sets up the administ-ration of the project
as soon as practical and that he/she makes sure that all team members and
support staff understand what is required and available. The format or media for storing such
documentation can vary from being paper based to a full electronic group-ware
platform.
In many cases, different sections will be held in different
formats thus harnessing the capabilities of any support tools and avoiding any
duplication. Regardless of how you
choose to store the information, its content will be similar. The following comprises a structure on which
to base your own project filing requirements.
Benchmarking showed that many companies had a prescribed framework, such
as the one which follows, to ensure that records are kept in a consistent way
thus enabling newcomers to the project to know where to start looking for the
information they require. See Appendix
for more detailed descriptions:
·
Project summary details
·
Contact list
·
Project log
·
Business plan and change log
·
Progress reports
·
Project logs
·
Schedule
·
Finances
·
Meetings
·
Key control deliverables
·
Correspondence
·
Reviews
3.1 Review and Approval Points
Review Points
The management framework comprises a staged approach to
projects with the ”gates” defining the
key points when a formal project review is undertaken. However, the time lapse in some stages can be
very long, particularly in the develop and test stage. It is, therefore, essential that a sufficient
number of additional review points are built into the plan to check that:
·
the project still meets the real business need
and is achievable;
·
the quality of the deliverables is adequate;
·
the plans are in place;
·
the project is working.
As a guide, a project should have a formal review every
three months or when a major commitment is to be made. The occurrence of such reviews should be
formally documented as they comprise an essential part in managing the risks on
a organizational-wide basis.
Review are often seen to take up valuable time and hamper
progress on the project. However, it is
in the project sponsors interest that reviews take place with accountability to
make sure they happen.
3.2 Change Control
Once the project has been authorized its scope, cost,
benefits and timescale are baselined and are used as the basis on which to
monitor progress. Under certain
circumstances, it is however, legitimate (and often desirable and/or
unavoidable) to change these baselines.
Who authorizes such changes very much depends on the impact. It is, therefore, essential that the extend
of the authority given to the project manager and project sponsor is defined.
3.3 Progress Reporting
The project manager, is accountable for controlling the
project and taking the necessary actions to ensure that it delivers the
expected outputs. He/she should gather
the team together on a regular basis (preferably physically) and check what
progress has been made and what progress is forecast to be made. He/she should assess the issues which have
arisen and the risks which are looming on the horizon.
For the business plan, decide which types of reports will be
kept for purposes of reporting.
Progress should be recorded by updating the project schedule
and cost forecasts to show:
·
activities completed and milestones achieved;
·
forecasts of completion dates for activities in
progress (not yet started) where these are known to differ from the agreed plan
(eg, slippage);
·
costs spent to date;
·
forecasts of costs to complete the current stage
of the project and for the completion of the project in full.
Additionally, the project leader should prepare for the
project sponsor and other key stakeholders, a concise written progress report
which includes the following information:
1. Business
objectives;
2. Progress
summary and outlook’
3. Financials;
4. Milestones:
5. Issues;
6. Risks
and opportunities; and
7. Changes.
Progress reporting should be active, with you telling the
stakeholders what they need to know in as concise a form as possible. It helps that the reports are full and
complete and aids the reader by providing a familiar, consistent format. Make sure that the reports are:
·
honest and open, without undermining confidence;
·
focused on key issues
·
balance the good and the bad news;
·
acknowledge the achievements of the team.
Contents of Progress
Report
1. Business Objectives
As many stakeholders will not be familiar with your project
from its number or title, you should summarize:
·
the business objectives the project will
satisfy;
·
how the project supports the business
strategy.
2. Progress Summary and Outlook
Briefly describe the progress of the project both in terms
of achievements to date and expected future performance. For any significant schedule slippage or cost
variance give the:
·
reason
·
impact;
·
corrective action being taken.
3. Financials
Provide a summary of the project finances in terms of
expected benefits, spending to date and total expected spending compared to
that planned.
4. Milestones
List the major milestones.
These should at least be the gate milestones defined earlier. For each give:
·
original and current baseline data;
·
forecast date or actual date achieved.
5. Key Issues
Describe the key issues which require escalating beyond the
project manager for resolution. For each
give the:
·
natures and impact of the issue;
·
action being taken to resolve the issue and who
is accountable.
6. Key Risks and Opportunities
Summarize the high risks and major opportunities which have
arisen. For each give:
·
nature and impact of the risk or opportunity;
·
action being taken to manage the risk or
opportunity and who is accountable.
7. Changes
List all outstanding changes which are beyond the project
manager’s authority to authorize. For
each give:
·
reason for the change;
·
impact of the change;
·
who is accountable for Authorizing the change;
8. Attachments
It may be convenient to attach, for detailed reference:
·
Cost report;
·
Progress bar chart;
·
Issues log;
·
Risks log;
·
Opportunities log;
·
Change log.
3.4 Project
team and stakeholders
Stakeholders are those who are affected by the project. All those involved in the project are,
therefore, stakeholders. However, there
are also those who take no direct part in the project as team members, but
whose activities will in some way be changed as a result. These could be users of new systems, people
in new departments resulting from reorganizations (or those made redundant), those
taking roles in new processes as managers, supervisors, and workers. Often the project is of little importance to
them but they are of great consequence to the project if their consent is
critical to success. It is essential to
identify them because it is critical to enroll them at an early stage in the
project to ensure their power does not cause the project to fail later. Never underestimate stakeholders’ ability to
ruin your best laid plans!
It is both the project manager’s and project sponsor’s role
to ensure that all stakeholders are adequately briefed on the project. Too much communication will drown them—they
won’t read it. Not enough, will mean
your project will be lower down their priority list than you want it to be.
Enrolling stakeholders and keeping them enrolled is a taxing
but essential task. It is accomplished
both by a formal communication plan and by enrolling behavior on behalf of all
the project team on both a planned and opportunistic basis. In this section answer the following:
·
Identify the stakeholders and the influence they
have;
·
Identify the communications strategy that will
be used to keep the stakeholders informed and supportive.
·
Explain how will you t rack the results of the
strategy.
1. FINANCE
After managing time, management of the finances is the next
most important and fundamental aspect of project management. Without a good schedule plan it is impossible
to have a reliable financial plan.
However, while the schedule is the most visible aspect of a project to
outsiders, cost is often the most visible to insiders, such as your management
team.
At a simple level, a financial plan will tell you:
·
what each stage and work package in the project
costs;
·
who is accountable for those costs;
·
the financial benefits deriving from the
project;
·
financial commitments made;
·
cash flow;
·
financial authorization given.
In addition, some companies also derive the net effect of
the project on the balance sheet and profit and loss account.
Just as the schedule plan is used as the baseline for
measuring progress in terms of “time,” the financial plan is the basis for
measuring costs and financial benefits.
Many of the principles regarding schedule management are also applicable
to the management of finances. Schedule
and cost plans should share the same work breakdown structure (see earlier
section on work packages).
By doing this you will ensure:
·
accountability for both the schedule and cost
resides with the same person;
·
there is no overlap, hence double counting of
costs;
·
there is no “gap,” ie, missing costs.
In practice, you will develop the financial plan to a lesser
level of work breakdown that you would a schedule plan.
The financial plan, like the schedule plan, is developed in
summary for the full project and in detail for the next stage. There is little point in developing an
accurate and detailed financial plan on the back of an unstable schedule
plan. No matter to what level of
granularity you take the calculations, they will be fundamentally
inaccurate. You should take the level of
accuracy and confidence forward with the schedule and related costs matching.
The costs are influenced by the following which you must
take into account when drawing up the plan:
·
the scope of the project;
·
the approach you take to the project;
·
the timescale to complete the project;
·
the risks associated with the project.
The cost estimate should be made up of:
·
the cost of using your own employees;
·
the cost of using consultants, local and foreign
·
the cost of external purchases made as a result
of the project:
·
hardware
·
software
·
equipment (other than computer)
1.1 Financial appraisal
Define:
·
what each stage and work package in the project
costs;
·
who is accountable for those costs;
·
the financial benefits deriving from the
project;
·
financial commitments made;
·
cash flow;
·
financial authorization given.
The overall cost of the plan is
built on three elements in most situations (In the MES-WB project we have
guidelines to be followed):
1. Base
estimate: total costs for all the activities you have identified, including
the cost of the employees time and all external purchases
2. Scope reserve: estimate of what else your experience and
common sense tells you needs to be done, but has not yet been explicitly
identified.
3. Contingency: included in the estimate to take account of
the unexpected, ie, risks. It is not
there to compensate for poor estimating.
(See Appendix D. This is where the detailed information is
included.
1.1 Financial commentary
·
Explain how hard/soft the cost estimates are;
·
List any concerns regarding the financing of the
project.
The Business Plan Template
1 FINANCE
1.1 Financial
appraisal
1.2 Financial commentary
2 PROJECT DEFINITION (WB Plan of
Action)
2.1 Background
2.2 Business Objectives
2.3 Benefits
2.4 Output definition
2.5 Scope, impacts and
interdependencies
2.6 Deliverables
2.7 Timescale
2.8 Risks and opportunities
2.9 Prerequisites, assumption
and
constraints
2.10 Project and implementation
approach
2.11 Analysis of options
3 PROJECT ORGANIZATION
3.1 Review and approval points (WB organization of PCU and
decision-making)
3.2 Change control
3.3 Progress reporting
3.4 Project
team and stakeholders
4 APPENDICES
A. Business
Commitment
(WB identification of conditions required for implementation)
B. Schedule
plan (WB
sequence of activities over 4 years)
C. Resource
plan (WB
estimated resources needed for implementation)
D. Financial
plan (WB
estimated costs for implementation)
E. Terms
of Reference for Consultants for 1st year
F. Financial
sensitivity (WB
sustainability of investments)
G. Output
definition document (See section 2.4)
H. Subcomponent activity flow chart (WB plan of
action)
PROJECT FILING FORMATS
1. Project summary details
This should comprise a short description of the project and
the names of those holding the key accountabilities. The summary as held on a project tracking
system should fulfill the needs of this section.
2. Contact List
A list of all the team members, their roles, and how they
can be contacted.
3. Project log
A chronological record, owned by the project manager, of
significant meetings, events and commitments.
This should refer to detail in other sections of the file where
appropriate.
4. Business plan and change log
This section contains the fundamental definition of and plan
for the project. The change log is an
amendment record, listing any changes to the business case which are under
consideration or which have already been approved or authorized. By having a change log as a supplement to the
business plan, you avoid the need for updating the main document for every
change. You need only reissue it when
the number of changes become unwieldy to keep in separate documents.
5. Progress reports
All regular and special progress reports should be retained.
If a number of different reports are to
be prepared for particular audiences, this section should be sub-divided
accordingly.
6. Project logs:
·
issues
log;
·
risk log;
·
opportunity
log.
7. Schedule
This section contains a copy of the most recent schedule
showing achievement and forecast against the agreed plan.
8. Finances
This section contains a copy of the most recent cost and
benefit position showing achievement and forecast against the agreed plan.
9. Meetings
All meetings should either be minuted or notes produced to
promote clear communication. This should
include:
·
agreements:
record any agreements made (even agreements to disagree!)
·
actions: be
clear who has the accountability for any actions, when they have to be done by
and who are the recipients for outputs from those actions.
10. Key control deliverables
This section comprises a listing of the key control
deliverables (with account-abilities for preparation, review, and
sign-off). Copies of the documents themselves
must be held for team use and archive purposes.
For gate decisions:
·
proposal;
·
ready for trial report;
·
ready for service report;
·
closure report;
·
post-implementation report.
Other deliverables:
·
project description;
·
detailed investigation report;
·
test plan;
·
test results;
·
trial plan;
·
trial results.
PLUS any other that are required, as defined in the project
definition section of the business plan, such as detailed specifications,
requirements, document, tender documents, etc.
11. Correspondence
Record of all incoming and outgoing correspondence.
12. Review
Copies of any additional project reviews, other than the
mandatory gate reviews should be kept.
For complex projects, individual sub-projects and work
packages should follow a similar structure to that held for the overall
project.
PROJECT DEFINITION CHECKLIST
Use this checklist to review any project definition section
that you have written to ensure that it meets all of these criteria:
Criteria:
¨ Has a project definition been written,
reviewed by the stakeholders, and approved by the project sponsor?
¨ Do
the scope and objectives of the project meet the needs of the business?
¨ Have
the benefits been fully assessed and quantified wherever possible?
¨ Do
the benefits match the needs?
¨ Have
all the risks been identified and categorized?
¨ Has
a comprehensive and satisfactory work breakdown been developed?
¨ Does
the work breakdown reflect the deliverables to be produced?
¨ Are
all key logical relationships between projects and activities clear?
¨ Has
the plan been developed to minimize or offset the risks?
The only way a project can be delivered is by its
deliverables. For each deliverable check:
¨ Are
the project deliverables relevant and are they feasible both to produce and implement?
¨ Have
quality criteria been established?
¨ Is
it clear who is accountable for preparing each deliverable?
¨ Is
it clear who will review the deliverable prior to signing off acceptance of
each deliverable?
¨ Is
it clear who will sign off each deliverable?
¨ Has sufficient time been allowed for
reviewing/amending each deliverable?
Table of Contents
Background information and definitions pp. 1-3
The Business Plan Outline pp. 4-5
Explanation of Section 2:
Project Definition pp.
5-8
Explanation of Section 3:
Project Organization pp.
8-13
Explanation of Section 1:
Finance pp.
13-14
Appendix:
The Business Plan Template p.
15
Project Filing Formats pp. 16-17
Project Definition Checklist p. 18
Section 4: Appendices
Templates pp. 19-
A. Business
Commitment
(WB identification of conditions required
for implementation)
B. Schedule
plan (WB sequence of activities over 4
years)
C. Resource
plan (WB estimated resources needed for
implementation)
D. Financial
plan (WB estimated costs for
implementation)
E. Terms
of Reference for Consultants for 1st year
F. Financial
sensitivity (WB sustainability of
investments)
G. Output
definition document (See section 2.4)
H. Subcomponent activity flow chart (WB plan of action)
Nav komentāru:
Ierakstīt komentāru