PROJECT KICK-OFF MEETING PROJECT: PRISM VENUE: Meeting Room 4 START TIME: 10:30 DATE: 5 May 2003 FINISH TIME: 12:30 PURPOSE: Project Inception Meeting to establish relevant information f
Trang 1Starting up: ideas and opportunities for projects l 89
understanding of the task ahead A list of typical questions that should all
be answerable at this stage is given in Checklist 7
CHECKLIST 7: THE PROJECT KICK-OFF MEETING
Background
• Why is the project necessary?
• What is the overall problem or opportunity being addressed?
• Has the current situation been explored and understood?
• Has a statement of requirements been derived from the needs list?
PROJECT KICK-OFF MEETING
PROJECT: PRISM
VENUE: Meeting Room 4 START TIME: 10:30
DATE: 5 May 2003 FINISH TIME: 12:30
PURPOSE: Project Inception Meeting to establish relevant information
for project definition
John Foster Sponsor (Chair)
David Johnson Customer
Alison Williams Customer
Angela Kimball Customer
Alex Wimborne End user representative
Anthony Barrett Project manager
Jane Foxbury Team member
Jim Fawcett Team member
Alan Davidson Team member
Amanda Hunt Team member
Please confirm your attendance.
Figure 5.2 Typical agenda for the kick-off meeting
Trang 2• Is this an old problem?
• How long has it existed?
• Who wants to change things?
• Have previous attempts (projects) been made to address this problem?
• What information exists about past attempts to fix things?
• What assumptions have been made?
Context
• How does the project align with current organizational strategy?
• Does the project form part of a programme of projects?
• Will the project form part of a chain of linked projects or a programme?
• What is the timescale of the project?
• Is there a business-critical date by which it is necessary to get the results?
• Will the results be of value to another customer or another part of theorganization?
Approach
• Have all the needs been identified and analysed?
• Has a statement of requirements been agreed?
• Are there predetermined solutions?
• What are these solutions?
• Is there a best option and a least worst option?
• Is there enough time to explore more than one option?
• Are there known checkpoints for project review?
• What specialized skills are expected to be required for the project work?
Objectives
• Are the project’s primary deliverables known?
• What does the customer need, want and hope to get from the project?
• Can these deliverables be clearly defined and specified?
• Does the end user agree with these deliverables?
• What does the end user need, want and hope to get from the project?
• What are the project’s perceived benefits?
• Have these benefits been quantified?
• Has a project budget been fixed?
• Is capital investment necessary?
• Has a capital expenditure request been initiated?
• Is time used for project work to be measured and costed?
• How were the costs derived?
• Has a cost–benefit analysis been carried out?
• Has a financial appraisal been carried out to establish payback?
Trang 3Starting up: ideas and opportunities for projects l 91
Constraints
• Have the project’s constraints been identified?
• Is there a time constraint for all or part of the deliverables list?
• Are there any financial constraints (eg manufacturing cost, projectcost)?
• Is there a financial payback constraint?
• Are there any known technical constraints (eg new or untried technology)?
• Are there known resource constraints?
• Is the project team to be located together on one site?
• Is part of the work to be carried out at another site?
• Is part of the work to be carried out by sub-contractors or suppliers?
• Is there a preferred list of approved sub-contractors and suppliers?
• What existing specifications and standards are to be applied to theproject?
• Are there any legal constraints that might affect the project work?
• Are there any security implications?
• Are there any operational constraints (eg access to production areas/test equipment, etc)?
• Are there any health and safety constraints?
PROJECT DOCUMENTATIONYou are not alone – no one likes having to record information in a regularand organized manner Project work produces a large quantity of data and
it is important that you record essential material One of the greatest wasters in project work is repeating the recording of information in differ-ent formats and the problems created in its interpretation later
time-Start off your project by avoiding the ‘I’ll do it my way’ syndrome Insistthat the team members keep all essential project records on a standard set
of templates derived specifically for the purpose Throughout this book atthe appropriate time, you are given examples of standard templates Allthe templates suggested can be designed on a computer and networkedfor ease of completion from blank masters
Some are more important than others, and it is your decision which touse Whichever you use, having standard templates ensures that everyoneinvolved with the project records data in a consistent and disciplinedmanner without re-inventing forms every week In addition you get theright information recorded (and in the appropriate amount) for the projectfile to support your control system, which aids progress in reporting to thePST and project evaluation at completion Expect an adverse reaction from
Trang 4people when you suggest using standard templates It is viewed as ‘formfilling’ and a chore Stress the importance of keeping everyone informedabout what has happened in the project and that it is in their interests toget into the habit of keeping accurate records Nobody can carry all theplans and information in his or her head!
The first of the standard templates is the project organization chart, which
lists all those involved with the project, plus their line manager, locationand telephone number This is an important communication document forinformation, and records agreed commitments of individuals assigned tothe project team Review the document regularly and keep it up to date.Set up a distribution list now, identifying who gets which documents.Distribute copies to all those who need to know – both participants andnon-participants
The project file
Set up a project file for all the documentation related to the project Thisfile is the permanent record of the project and requires a disciplinedapproach to administration Even if you personally prefer to use a paper-based system, some of your team may like to keep all their records on acomputer-based file or folder This makes the distribution of informationeasier if you have a network It also makes access and retrieval relativelyeasy There is a potential difficulty with using the computer to store all theproject data If you cannot restrict access to your data, people can makechanges without informing you, and create confusion Take precautions toprevent unauthorized access, or modification of project documents, andinform the team of their limits on the system If you have concerns aboutreliability, always keep a hard copy of the project file
Organize your project file into sections for the different stages of theproject; for example:
• Business case and amendments by the PST
• Project definition:
– project organization;
– stakeholders;
– project brief
• Project plans and schedules:
– project risk management;
– responsibility charts;
– schedules;
– work plans
• Project execution and implementation:
– project status reports;
Trang 5Starting up: ideas and opportunities for projects l 93
Date Revision Initials
DECIDE WHO MUST RECEIVE COPIES
OF THIS AND ALL OTHER PROJECT DOCUMENTS, ie PROJECT PLANS AND PROGRESS REPORTS
MAINTAIN RECORD OF REVISIONS AND RE-ISSUES
8
9
10
LIST EACH MEMBER OF THE TEAM
AND HIS/HER SPECIFIC ROLE IF ANY
[IDENTIFY BY SKILL IF APPROPRIATE]
RECORD THE ORIGINAL LOCATION OF THE TEAM MEMBER AND HIS/HER CONTACT TEL NO
RECORD THE NAME OF THE DIRECT LINE MANAGER – REMEMBER
HE OR SHE IS A STAKEHOLDER
Figure 5.3 Project organization chart
Trang 6– changes to project plans;
– action plans for corrective action;
– cost control data;
– supplier and sub-contractor data;
– follow-on and post-project responsibilities;
– project evaluation data;
– completion report
Divide it into more detail if necessary You are responsible for updating thefile at regular intervals and it is a good habit to do this once a week Alwayslet others know where to find the file; it is most frustrating to search for afile that is hidden away!
The project logbook
It is a good discipline to open a project logbook at the start of your project.
The purpose is to provide you with somewhere to record all events,agreed actions and forward planning ideas The book is an A4 bound,
lined book and not a loose-leaf file or folder Record events with essential
relevant data such as:
• date;
• time;
• who is involved;
• key points or content
Events to record include:
• telephone calls – incoming and outgoing;
• faxes – incoming and outgoing;
• letters – sent and received;
• memos – sent and received;
• e-mails – sent and received;
• purchase instructions issued;
• contracts signed;
• action plans agreed;
• problems encountered;
• solutions derived;
Trang 7• decisions taken – and how implemented;
• reports issued;
• meetings – sponsor, team, third party, one to one
The logbook is not a personal document; it is an addendum to the project
file When using a logbook:
• Use every page and number them sequentially
• Never remove any pages.
• Start each day with a new page
• Always write in pen, ballpoint or felt tip, never pencil.
• Write on every line
• Rule out all unused lines at the end of each day and sign the page atthe bottom
• Do not allow anyone else to write in the logbook – not even theproject’s sponsor
The logbook is particularly valuable for recording events concerned withthird parties such as suppliers and contractors When conflict and differ-ences occur, the logbook provides a record of events that often takes theheat out of an argument The record can have a legal status if a disputeeventually ends up in the hands of the legal profession!
THE PROJECT BRIEF AND SPECIFICATION
The kick-off meeting you have just completed will have been the focalpoint of all the initial work associated with the project start-up Thepurpose of that meeting was to enable you and your team to understandthe expectations of your customer and agree the requirements derived in
the statement of requirements The data you collect are enough for you to
draw up a preliminary statement of the project objectives and the ated specifications
associ-This step is often the most difficult, because you must now formulate inrealistic terms just what the project is about and has to achieve This is thefoundation of project definition, which we will examine in more detail inChapter 6
The project brief is a document that summarizes all the relevant facts
about the project and is therefore a source of definitive information Thecontents include:
• the project’s origins – a need or opportunity statement;
• the project’s rationale – why is it necessary now?
Starting up: ideas and opportunities for projects l 95
Trang 8• the benefits of the project – to the customer and your organization;
• the project budget if known at this stage;
• the current timescale and deadlines – subject always to detailed ning later
plan-This document is ideally just one piece of paper, but for larger projects itoften takes the form of a report with many different sections If you have agood business case document, the project brief provides a convenientsummary of key data It forces you and the team to focus on real facts andnot hopes or wishes Unfortunately, during the start-up of most projectsthere is too much expression of hopes and the ‘wish list’ You have toresolve this conflict to sort out what you can achieve in practice withcurrent technology, experience and knowledge compatible with the state-ment of requirements
Project specification is a term applied to many different types of
docu-ments and can include almost anything Here the term ‘specification’describes any document that is an obligatory statement of procedures orprocesses that apply to the project It is a statement of policy for theproject
These specifications can range from technical descriptions to qualitystandards, or even organizational policy documents such as contractpurchasing guidelines When you come to define your project you will
collect all the relevant specifications together in the project scope of work
statement This document is often referred to as the SOW and directly
relates to your project brief to support the factual information included forapproval by your customer
All these documents can sometimes be combined into one, termed the
project charter.
Trang 9Starting up: ideas and opportunities for projects l 97
CHECKLIST 8: KEY LEADERSHIP ACTIONS
DURING PROJECT SELECTION
• Identify your project sponsor.
• Identify your customer.
• Confirm needs and expectations
• Identify the end users of the project’s outcomes
• Start to build a relationship with these people
• Determine the project’s constraints
• Agree a date for a kick-off meeting
• Select your core team
• Hold an initial team meeting
• Explain the project’s background and context
• Explain the overall objectives of the project as you know them atpresent
• Confirm the team’s understanding of the objectives
• Share your own enthusiasm for and commitment to the project
• Listen to what the team members have to say
• Answer their questions if you can
• Promise answers to questions you cannot answer now
• Explain the project phases and the process you intend to use
• Empathize with their concerns about other commitments
• Explain your intention to have separate one-to-one meetings witheach team member
• Agree dates for the first of these meetings
• Set up an initial programme of team meetings, say for the next fourweeks
• Explain the kick-off process and confirm their attendance at thismeeting
• Open the project file
• Prepare for the kick-off meeting with the team
• Hold the kick-off meeting and record outcomes in the file
SUMMARYThe key steps may be summarized in a flow diagram (Figure 5.4) Checklist
8 summarizes the key leadership actions during the project selectionphase
Trang 10IDENTIFY YOUR SPONSOR
IDENTIFY YOUR CUSTOMER
IDENTIFY END USERS
IDENTIFY THE CONSTRAINTS
PREPARE INITIAL PROPOSAL
SUBMIT TO PST
DERIVE PRELIMINARY SCHEDULE
ASSESS RESOURCE NEEDS
DERIVE BUDGET
PREPARE FINANCIAL CASE
PREPARE BUSINESS CASE
SUBMIT TO PST
‘NO GO’
DECISION
ASSIGN PROGRAMME/ PROJECT MANAGER
ASSIGN CORE TEAM
HOLD PROJECT KICK-OFF MEETING
PROJECT BRIEF
SET UP PROJECT DOCUMENTATION
RECORD ON PROGRAMME REGISTER
PROJECT
FILE PROJECT
LOG BOOK
PROJECT ORGANIZATION CHART
‘GO’ DECISION
0
1
Figure 5.4 Process flow diagram: opportunity selection through Phase Zero
Trang 116
Defining the project
Now that you have completed the start-up process to gather the dataneeded to define your project, you can start the real journey towardssuccess Definition is the process of turning the data into something morerealistic, not just a wish or a hope but creating the solid foundations ofyour project Compare it to a building – failure to provide well-definedfoundations will risk structural failure, serious consequences and evencollapse
The project brief is the summary document that contains the foundation
design for your project It is supported by numerous other documents.Failure to give adequate time to producing the project brief and derivingall the relevant data for its foundations will lead to a poorly defined projectwith considerably reduced chance of achieving a successful outcome Apoor definition leads to a project plan that is derived from incorrect oreven misleading information Your plan will soon start to fail and bediscarded as a useless document Your project goes out of control and youmay suffer further serious consequences and criticism
A clear definition of your project is critical to success: a large number ofprojects (more than 75 per cent) are perceived to fail as a consequence ofpoor or unclear definition
WHAT IS NECESSARY TO DEFINE A PROJECT?Apart from the business case, five essential documents are required todefine a project effectively:
Trang 12We have listened to you and understood what you need and require We have examined these requirements and concluded what we believe we can realistically deliver to satisfy these needs Now we are telling you what we understand we are going to provide for you with this project Please approve these definition documents as they are the basis on which we will derive a plan and schedule for you to approve later.
The approval or ‘sign-off ’ process is essential to maintain customer andsponsor commitment to your project
THE STAKEHOLDER LISTWhen you start the definition process, the first step is to return to thesimple question: ‘Who has an interest in this project, now or in the future?’
We identified these people in Part 1 as stakeholders, and some of these people you have already identified as key stakeholders:
• the customer;
• the end users;
• the sponsor;
• the line managers of your core team members
With your team you must now try to identify who has now or potentially
in the future will have an interest Refer to Checklist 2 in Chapter 4 forguidance on the questions to ask Consider that the list could include:
• the finance department;
• the sales and marketing department;