Starting up: ideas and opportunities for projectsl89understanding of the task ahead. A list of typical questions that should allbe answerable at this stage is given in Checklist 7.CHECKLIST 7: THE PROJECT KICK-OFF MEETINGBackground• 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 MEETINGPROJECT: PRISMVENUE: Meeting Room 4 START TIME: 10:30DATE: 5 May 2003 FINISH TIME: 12:30PURPOSE: Project Inception Meeting to establish relevant informationfor project definitionAGENDAI. Introduction2. Project background and assumptions3. Project context

4. Project approach and strategy5. Project objectives6. Identification of constraints7. Business case8. Communication9. ACTION POINTSATTENDEES:John Foster Sponsor (Chair)David Johnson CustomerAlison Williams CustomerAngela Kimball CustomerAlex Wimborne End user representativeAnthony Barrett Project managerJane Foxbury Team memberJim Fawcett Team memberAlan Davidson Team memberAmanda Hunt Team memberPlease confirm your attendance.Figure 5.2 Typical agenda for the kick-off meeting• 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?90lThe programme and project processes and techniquesStarting up: ideas and opportunities for projectsl91Constraints• 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 andit is important that you record essential material. One of the greatest time-wasters in project work is repeating the recording of information in differ-ent formats and the problems created in its interpretation later.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 setof 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 from92lThe programme and project processes and techniquespeople 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, whichlists 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 fileSet 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;Starting up: ideas and opportunities for projectsl93Notes:Distribution:PROJECT ORGANIZATION CHARTTITLE OF PROJECT:PROJECT SPONSOR:LineNoNAMEPROJECTROLEDEPARTMENTLINEMANAGERTELNOLeaderIssue:012345671112131415161718PROJECT SPONSOR:ACCEPTANCE/RECORDSDATE:DATE:DATE:PROJECT MANAGER:PROJECT MANAGER:PROJECT CUSTOMER:PREPARED BY:DATE:Date Revision InitialsDECIDE WHO MUST RECEIVE COPIESOF THIS AND ALL OTHER PROJECTDOCUMENTS, ie PROJECT PLANSAND PROGRESS REPORTSMAINTAINRECORD OFREVISIONS ANDRE-ISSUES8910LIST EACH MEMBER OF THE TEAMAND HIS/HER SPECIFIC ROLE IF ANY[IDENTIFY BY SKILL IF APPROPRIATE]RECORD THE ORIGINALLOCATION OF THE TEAMMEMBER AND HIS/HERCONTACT TEL NORECORD THE NAME OFTHE DIRECT LINEMANAGER – REMEMBERHE OR SHE IS ASTAKEHOLDERFigure 5.3 Project organization chart– changes to project plans;– action plans for corrective action;– cost control data;– supplier and sub-contractor data;– records of meetings.• Project closure:– closure checklist;– handover checklist;– acceptance process;– 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 logbookIt 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 essentialrelevant 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;94lThe programme and project processes and techniques• 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 projectfile. 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 SPECIFICATIONThe 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 inthe statement of requirements. The data you collect are enough for you todraw up a preliminary statement of the project objectives and the associ-ated specifications.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 factsabout 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 projectsl95• 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 plan-ning later.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 willcollect all the relevant specifications together in the project scope of workstatement. This document is often referred to as the SOW and directlyrelates to your project brief to support the factual information included forapproval by your customer.All these documents can sometimes be combined into one, termed theproject charter.96lThe programme and project processes and techniquesStarting up: ideas and opportunities for projectsl97CHECKLIST 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). Checklist8 summarizes the key leadership actions during the project selectionphase.98lThe programme and project processes and techniquesIDEA/OPPORTUNITYIDENTIFY YOURSPONSORIDENTIFY YOURCUSTOMERIDENTIFY ENDUSERSIDENTIFY THECONSTRAINTSPREPARE INITIALPROPOSALSUBMIT TOPST‘NO GO’DECISION•REJECTED•RESUBMIT•ASSIGN TO WAIT LIST‘GO’DECISIONTO GATE ZEROTO GATE ONEIDENTIFY CUSTOMERNEEDS & EXPECTATIONSDERIVE PRELIMINARYSCHEDULEASSESSRESOURCE NEEDSDERIVEBUDGETPREPAREFINANCIAL CASEPREPAREBUSINESS CASESUBMIT TOPST‘NO GO’DECISIONASSIGN PROGRAMME/PROJECT MANAGERASSIGNCORE TEAMHOLD PROJECTKICK-OFF MEETINGAGENDADATA FORPROJECT BRIEFSET UPPROJECTDOCUMENTATIONRECORD ONPROGRAMME REGISTERPROJECTFILEPROJECTLOG BOOKPROJECTORGANIZATIONCHART‘GO’DECISION0011Figure 5.4 Process flow diagram: opportunity selection through Phase Zero996Defining the projectNow 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 foundationdesign 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:100lThe programme and project processes and techniques• a statement of requirements;• a stakeholder list;• a project brief;• a scope of work statement;• a risk assessment.All these documents must be approved before you start the planningprocess. You are effectively returning the project definition to yourcustomer, saying:We have listened to you and understood what you need and require. Wehave examined these requirements and concluded what we believe we canrealistically deliver to satisfy these needs. Now we are telling you what weunderstand we are going to provide for you with this project. Pleaseapprove these definition documents as they are the basis on which we willderive 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 thesepeople 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 potentiallyin 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;• consultants;• contractors;• suppliers;• other divisions or sites;• the public;• other agencies or statutory bodies.In some projects where your customer is internal, there may be anotherparty in the supply chain such as an end client with users.All these people have an interest, which means they have an agenda oftheir own for the project. Although the controlling interest may beperceived as that of your customer, you cannot afford to ignore all otherswith an interest. They may consider that their level of interest is enough tojustify their having a voice to which you must listen. Failure to do so at thisstage may lead to conflict, disruption and interference later. This group ofpeople are the stakeholders; all have strong feelings about their stake inthe project and will make these feelings known to you probably when youleast expect it!Derive a complete list of the stakeholders as you now see them andrecord them on the project stakeholder list, a typical template for which isshown in Figure 6.1. Making this list is not a single activity; regularlyupdate and reissue it. This is a communication document to keepinformed everyone who has an interest in the project. The list is also yourdatabase for further analysis as discussed earlier. But why, you ask, is thisreally so important? So far, you have concentrated on the customer andthe sponsor for inputs to the project definition. As we saw in Chapter 4, allstakeholders need to be consulted for their inputs to give a wider perspec-tive of, first, the project’s real needs and requirements, and second, what isrealistically achievable in the timescale demanded. You use these addi-tional data inputs in your work of defining the project. At this stage of theproject you may fail to identify all the stakeholders, so review the list ateach team meeting or project progress meeting, adding any newcomers asidentified.THE PROJECT BRIEFFrom the business case and the kick-off meeting you held earlier you havederived most of the data for this document. Now you must ensure there isno amendment necessary as a result of consulting with any other stake-holders you have identified. A suggested template for a typical one-pagedocument is shown in Figure 6.2. This contains a number of sub-headings:Project titleGive your project a relevant title for identification purposes. If appropri-ate, also identify the project number recorded in the programme register forfinancial budgetary control purposes. Indicate whether the project is partof a programme and identify the programme number.Defining the projectl101102lThe programme and project processes and techniquesTITLE OF PROJECT:PROJECT NUMBER:PROJECT MANAGER:PROJECT STAKEHOLDER LISTLineNoPREPARED BYDATE:Date Revision InitialsSTAKEHOLDER NAME INTEXT123456789101112131415161718192021222324HIGHMEDIUMLOWTELNOIssue: 0LIST ALL IDENTIFIEDSTAKEHOLDERS BY NAME.ASSIGN CODE NO IF REQUIREDRECORDLOCATIONTEL NOTICK APPROPRIATECOLUMN TO INDICATEWHETHER INTERNAL OREXTERNAL TOORGANIZATIONUSE THESE COLUMNS TOINDICATE RESPECTIVEIMPORTANCE TO THE PROJECT.INSERT INITIALS OF TEAMMEMBER ASSIGNEDRESPONSIBILITY FORMANAGING IN RELEVANTCOLUMNMAINTAINRECORD OFREVISIONS AND:CODE:1LIST ALL IDENTIFIEDSTAKEHOLDERS BY NAME.ASSIGN CODE NO IF REQUIRED.MAINTAINRECORD OFREVISIONS ANDREISSUESFigure 6.1 Example of a project stakeholder listOverall objective of the projectIt is appropriate to write an overall objective statement of about 25–30words that describes the desired results of the project.Project manager and project sponsorIdentify yourself as the project manager and identify the sponsor.Planned start date for the projectThe planned start date is the date when the real work of definition startedafter PST approval of Phase Gate One. This may not be the day ofapproval, depending on the availability of the team and yourself. In someorganizations the planned start date may be set as the date when youexpect to start planning if the project definition is accepted and the projectapproved to continue after Phase Gate Two.Required finish dateState the date when the project is required to end with handover to thecustomer. This should be clear to you from the kick-off meeting, particu-larly if it is a business-critical date for strategic reasons. The date may besubject to change after planning is completed.Project deliverablesIdentify the primary deliverables that will be seen from the projectthrough its life cycle. These are tangible outputs from the project that mustbe capable of being measured.Apply the SMART test to ensure that each deliverable is:• Specific – it is clearly defined, with completion criteria;• Measurable – understood metrics are available to identify delivery;• Achievable – within the current environment and skills available;• Realistic – you are not trying to get the impossible with manyunknowns;• Timebound – is limited by a delivery date based on real need.At this stage only five key deliverables are required, although after plan-ning many more intermediate deliverables may be apparent.Project benefitsList the benefits you have identified for your organization from the earlierinvestigative work you have completed in preparing the business case. AllDefining the projectl103benefits should be quantified; preferably they should be measurable infinancial terms: cost savings, increased turnover, contribution or profitabil-ity in a specific timescale. If in doubt, apply the SMART test to benefits.Project strategyState whether you intend to examine more than one route to success:explore alternatives, carry out a further feasibility study, set up a cross-siteteam, involve the customer in the team or anything else relevant to yourapproach to the project. These data may have been recorded in theapproved business case.Project skills requiredIdentify the skills required for the project work, particularly highlightingspecial experience and technical skills you expect to need. Indicate if certainskills and expertise will be purchased from outside the organization.Relationship with other active projectsMost organizations have many projects active simultaneously. Does yourproject interface at some point with another, either depending on it forinputs or providing outputs to another project? Is this project part of aprogramme? There are certain to be some critical interface dates that aremandatory for your project. Failure to recognize these interfaces can leadto both projects failing to meet completion on time.Project costIf the cost is known from the business case or a budget exists from earlierstudies or feasibility work then state the cost. If not, either give an esti-mated cost or leave blank until planning is complete. The relevance of costdepends on whether time is measured and costed or whether only capitalexpenditure is to be recorded here.Risk managementYou are asked to indicate whether the project risk log and risk managementforms are attached to the document for approval. (See later in this chapter.)In this document you have collected together all the known relevant factsupon which to base a decision to proceed. It may be supported by anotherkey document that contains the detailed specifications.104lThe programme and project processes and techniquesDefining the projectl105THE SCOPE OF WORK STATEMENTAs the name implies, the scope of work statement (SOW) is a narrativedescription of the project objectives in more detail, giving more informa-tion about each deliverable and benefit identified. What is more impor-tant, the document must identify the boundary limits of the project,clearly stating what is not going to be done as part of the project.The SOW is also a very convenient place for you to record all theconstraints identified earlier and any assumptions made, whether before,during or after the kick-off meeting. These assumptions may haveprofound implications later during the project work.The SOW is where the applicable specification list is recorded:• internal product specifications;• external product specifications;• mandatory standards imposed by legislation;• process specifications;• customer specifications;• standard operating procedures;• purchasing procedures;• quality standards;• testing specifications and procedures;• sub-contract terms and conditions imposed on third parties.Your purpose is to make sure that everyone knows from the outset whatstandards and specifications apply to your project. The document also iden-tifies, first, where the actual documents can be found for reference, andsecond, what exceptions, if any, apply to any specification for your project.If necessary, you can also use the SOW to record for reference purposesany other relevant documents that have been issued previously relating tothe project; for example:• the business case;• cost–benefit analysis studies;• feasibility reports;• studies carried out by consultants;• project evaluation reports from previous projects.In practice, similar projects often generate similar SOW statements, so thisis an opportunity for you to create a standard template. This is not a form;it is a detailed document that is kept as a master document. For each subse-quent project the master need only then be edited and amended as appro-priate for any project.106lThe programme and project processes and techniquesPROJECT BRIEFTITLE OF PROJECT:BACKGROUND:OVERALL OBJECTIVE:PROJECT MANAGER:RESOURCE SKILLS REQUIRED:Relationship to other active projects:COST (if known)Risk Management Formsattached?YES NOPLANNED START DATE:REQUIRED FINISH DATE:DELIVERABLES:12345BENEFITS:12345STRATEGY/APPROACH:EXPECTED DATE:EXPECTED DATE:(Indicate time, output, cost, space, etc)AMOUNTPROJECT SPONSOR:PROJECT MANAGER:ACCEPTANCE/RECORDSDATE:DATE:DATE:Issue: 0PROJECT SPONSOR:YES NOProject Risk Logattached?PROJECT CUSTOMER:PREPARED BY:DATE:DateRevisionInitialsCOMPLETE INFORMATIONREQUESTEDGIVE CONCISE SUMMARY OF BACKGROUNDTO YOUR PROJECT – INCLUDE A STATEMENTOF NEED/OPPORTUNITYWRITE AN OVERALLOBJECTIVE STATEMENT(POS)STATE THE EXPECTEDSTART DATE AND ANYIMPOSED COMPLETIONDATE REQUIREDIDENTIFY THE PRIMARY PROJECTDELIVERABLES AND THEIREXPECTED/REQUIRED DELIVERYDATELIST THE PROJECT BENEFITS,PREFERABLY QUANTIFIEDFINANCIALLY, AND THEEXPECTED YIELD DATESINDICATE ANY KEYELEMENTS OF YOURAPPROACH RELEVANT TOTHE APPROVAL DECISIONIF COST KNOWN –AN APPROVEDBUDGET EXISTS –GIVE TOTAL HERECONFIRM THESEDOCUMENTS AREATTACHED– if not, why not?LIST OUT ANYSPECIAL SKILLSREQUIRED FOR YOURPROJECT – HIGHLIGHTANY SHORTAGESIF KNOWN AT THIS STAGEIDENTIFY INTERFACE POINTS BYOUTPUTS OR DATES WITH OTHERACTIVE PROJECTSRECORD ANY CHANGES TOTHE PROJECT BRIEF WITHDATE AND REISSUE TO THEKEY STAKEHOLDERS ANDTHE PROJECT FILEENSURE THESE ARESIGNED WHEN APPROVALTO PROCEED IS GIVENTITLE OF PROJECT:BACKGROUND:OVERALL OBJECTIVE:PROJECT MANAGER:EXPECTED DATE:PROJECT SPONSOR:AIDENTIFY THE PRIMARY PROJECTDELIVERABLES AND THEIREXPECTED/REQUIRED DELIVERYDATEYIF KNOWN AT THIS STAGEIDENTIFY INTERFACE POINTS BYOUTPUTS OR DATES WITH OTHERACTIVE PROJECTSALFigure 6.2 Example of a project brief documentRISK MANAGEMENTThere is uncertainty in all projects, and risk management is the means bywhich this is systematically managed to increase the probability ofmeeting the project’s objectives. Every procedure in this book is really arisk management technique. Some are designed to reduce the chances ofdelay and late delivery. Others are designed to avoid cost over-run andavoid unavailability of resources. The purpose of this disciplined approachis to identify and contain the risks and minimize the impact on the project.So what is a risk?A risk is any uncertain event that, if it occurs, could prevent the projectrealizing the expectations of the stakeholders as stated in the agreed busi-ness case, project brief or agreed definition. A risk that becomes a reality istreated as an issue.A risk always has a cause and, if it occurs, a consequence. Risks can havepositive or negative consequences. Success is dependent on maintaining ahigh commitment to risk management procedures throughout the project.At the definition phase of a project it is valid for an initial risk assessmentto be conducted. It will save you much wasted effort chasing an impossi-bly risky outcome and divert effort towards more beneficial projects withlower risks. Two fundamental types of risks are always present: 1) projectrisks – associated with the technical aspects of the work to achieve therequired outcomes; and 2) process risks – associated with the projectprocess, procedures, tools and techniques employed, controls, communi-cation, stakeholders and team performance.As project manager you have the obligation, working with your team,to:• identify and evaluate potential risks;• derive a response strategy and action plans to contain the risks;• implement the actions and monitor the results;• promptly resolve any issues arising from risks that happen.There are two primary components of the process: assessment and moni-toring. Some risks should have been identified in the business case and,if appropriate, response strategies for these may have been derived. Ifyou are only conducting a feasibility study at this stage, then each optionmust be examined for risk, as the results could influence subsequentdecisions.Defining the projectl107108lThe programme and project processes and techniquesWhy is risk management necessary?The project schedule is your road map to success but things can and willgo wrong from time to time. When this happens and has impact on theschedule you are forced into recovery planning to overcome the problemand also to recover time used in the problem-solving process. Many prob-lems can be anticipated. Use hindsight to question your predictions insuch situations and always ask if you could have anticipated the problem.This is why it is necessary to carry out risk assessment – to try to anticipatewhat might go wrong and take appropriate action to avoid the problem.The risks that happen become the issues that you must promptly resolveto maintain the integrity of the project schedule. It is good practice toprepare risk mitigation plans for known major risks, taking early action toavoid the risk occurring.There is always the possibility of unforeseen risks leading to unexpectedissues. Provided you are prepared to react promptly, you can still take thenecessary actions to hold on to schedule dates. Identify the signals or trig-gers that suggest a risk is likely to happen and keep the team always alertto the possibility of any risk becoming a reality.What are the benefits?Some people regard risk management as being negative. In fact, it hasmany benefits:PROJECT SCHEDULERISKS ISSUESContainsinherent unknownsOccur to becomeIfunresolved,impact the scheduleFigure 6.3 Risks and issues: impact on the project schedule• The serious threats to your project can be predicted before theyhappen.• Mitigation plans can be derived and implemented immediately.• Contingency plans can be derived in advance.• Valuable data for negotiating with suppliers are obtained.• The process creates clearly defined ‘ownership’ for risks to ensure theyare monitored.• It helps to create a ‘no surprises’ environment.• It encourages decisive leadership rather then crisis management.Risk management does have a cost, but in most situations this is signifi-cantly less than the cost of correcting the subsequent issues when a riskoccurs.When is it necessary?Risk management is a continuous process throughout the life cycle of theproject and you must maintain awareness of risk in the minds of all themembers of your project team:• It should be started at the definition phase, or earlier if possible.• It is essential to establishing the project brief.• Compile a complete list and record it on the project risk log.• Review and add to the list at regular intervals as the project movesforward.Review the project risk log at regular intervals, normally monthly atproject progress meetings unless decided otherwise by the sponsor at thestart of the project. You need to focus this review on the following aspects:• Identify any change in the potential impact or probability of identifiedrisks.• Identify any new high risks that have changed from being previouslyregarded as lower-ranking ones and subject them to closer examina-tion and risk mitigation plans.• Derive contingency action plans for damage limitation.• Add any new risks identified to the list and assess these for impact andprobability.Any risk entered on the list is never removed, even if the time when itcould occur seems to have passed. It could occur again later!The list of risks from any project is a source of valuable learning data forfuture projects and is a useful data source for deriving checklists. Datafrom past projects of similar work content are useful sources of riskmanagement information.Defining the projectl109RISK ASSESSMENTAny project has risks at the outset because of the many unknown factors,some of which you will remove during the planning stage. The risk couldbe due to external or internal factors. In practice, risks disappear and newrisks appear as the project progresses, so regularly review potential risks.Adopt the view that ‘anything that can go wrong will go wrong’.Risk assessment requires answers to some key questions:• What exactly is the risk and what are its parameters?• How serious is it as a threat to the project?• What could be done to minimize or avoid its impact on success?Call your team together and hold a brainstorming session to identify asmany potential risks as possible. Think of anything that could go wrongand hinder the project’s progress. Include all perspectives by involving thesponsor, customer and other stakeholders in the process. You may find that others may perceive some of the risks identified as soinsignificant they can be ignored. Test the validity of any risk by askingsome simple questions about its possible impact on the project:• Cost – does the risk have a cost impact?• Schedule – does the risk have an impact on the preliminary schedule?• Scope – does the risk have an impact on the project deliverables andquality?If the answer to all these questions is ‘no’ then ask if it is really a risk toyour project. However, take care: apparently insignificant risks can growinto significance later and become ‘project killers’.Checklist number 9 gives you some typical questions to ask in riskassessment. Some of these are applicable only after the planning phase.CHECKLIST 9: Questions for risk assessmentYES NOអអHas the project manager’s authority been established?អអIs the core team appointed?អអDoes the core team understand the project’s purpose?អអHave the project’s stakeholders been identified?អអHave stakeholder management responsibilities been allocated?110lThe programme and project processes and techniquesអអHave the project’s objectives been established?អអHave the project’s benefits been identified and quantified?អអAre there clear deadlines and a project timescale?អអIs there a known business-critical date for completion?អអIs there a scope of work statement?អអAre the project’s boundary limits clearly established?អអIs there an impact if the project fails?អអAre the right skills available in the team/organization?អអCan the project brief be accurately derived?អអHave all the project constraints been identified?អអAre there identifiable consequences of late completion?អអHas the project brief been approved?អអHave all key stages been clearly identified?អអHave key stage dependencies been established and agreed?អអAre the key stage durations agreed and accepted?អអIs the project schedule realistic and achievable?អអHave key stage responsibilities been allocated and accepted?អអAre the resources realistically available?អអHave workload priorities been clearly established?អអHave line managers accepted and committed their staff involvement?អអHave all resources required given commitment to their responsibilities?អអHas the plan been developed to a low enough level for effective control?អអHave key stakeholders signed off the project plans?អអAre project procedures established and understood?អអHas a milestone schedule been established?អអHave performance measures been derived?Any questions to which the answer is NO must be examined further toestablish the consequences and, if they are significant, contingency actionplans must be derived.YES NOអអIs there an impact of doing nothing?អអAre staff or organizational changes possible/expected during the project?អអAre business requirements likely to change during the project?អអIs new technology involved?អអAre new techniques to be employed?Defining the projectl111112lThe programme and project processes and techniquesអអAre new suppliers/contractors to be used?អអIs the project dependent on another project?អអAre there possible constraints on third parties?អអCan third parties impose constraints on the project work?Any questions to which the answer is YES must be examined further toestablish the consequences and, if they are significant, contingency actionplans must be derived.Having identified all the risks, you need to decide a risk response strategy.This involves separating the identified risks into three types. The key stepsin the process are shown in Figure 6.4.Review the risks, making sure none are repeated, and then separatethem into three lists:D1IDENTIFYRISKS3RISKANALYSIS &QUANTIFICATION2aAVOIDANCERISKS2cTRANSFERRISKS2bRESIDUALRISKSREVISE PLANS& STRATEGYTO AVOITRANSFER TOTHIRD PARTYRECORD ONRISK LOG4RECORD ONRISK LOGRISKMANAGEMENTFORMSRISKMITIGATIONPLANSFigure 6.4 Steps in a risk response strategy