S3. Step 3 Develop Roadmap

Transcription

1 S3. Step 3 Develop Roadmap PART OF IT STRATEGY TOOLIKIT VERSION 0.5 MAY

2 TABLE OF CONTENTS S3-1. DETERMINE PRIORITIES... 3 S3-1.1 ASSESS DEPENDENCIES... 3 S3-1.2 PRIORITISE BUILDING BLOCKS... 3 S3-1.3 IDENTIFY QUICK WINS... 4 S3-1.4 CONDUCT THRESHOLD ANALYSIS... 4 S3-2. DETERMINE PROJECTS... 6 S3-2.1 DETERMINE PROJECTS & PORTFOLIO STRUCTURE... 6 S3-2.2 VALIDATE IT PROJECTS, PRIORITIES & TIMING... 7 S3-3. DEVELOP IT MASTER PLAN... 8 S3-3.1 DEVELOP MASTER STRATEGIC PLAN... 8 S3-3.2 ANALYSE, PRIORITISE & SEQUENCE PROJECTS S3-3.3 DEVELOP HIGH LEVEL GANTT CHART S3-3.4 DEVELOP PROJECT COST ESTIMATES, RISKS & BENEFITS S3-3.5 DEVELOP DETAILED ROADMAP S3-3.6 ASSESS IMPACT OF PLAN AND PREPAREDNESS OF CURRENT IT ORGANISATION S3-3.7 IDENTIFY PRELIMINARY BENEFITS & HIGH LEVEL COSTS S3-3.8 INCORPORATE OPERATING VIEW INTO FINANCIAL PLAN S3-4. DEFINE CONTINUOUS PLANNING FRAMEWORK S3-4.1 DEVELOP SENSING NETWORK TO KEEP TRACK OF PRESENT AND FUTURE OPPORTUNITIES S3-4.2 DEFINE CONTINUOUS PLANNING FRAMEWORK S3-5. ONGOING PROJECT MANAGEMENT S3-5.1 MANAGE PROJECT S3-5.2 PROJECT CLOSEOUT

3 S3-1. Determine Priorities Overview This activity ranks all current and planned projects to produce a prioritised list for use in the work plans developed in later activities. Priority 1 Initiatives Priority 1 Initiatives for 2007 PriorIT S3-1.1 Assess Dependencies 1. Review the application and technology portfolio. 2. Identify all projects to be initiated within the next financial year. 3. Review the potential IT projects and recommend and agree upon with the steering committee the number of these projects to be developed in further detail as part of this task. 1. Based on discussions during the proposal process and subsequent discussions with the client, a timeframe for the projects to be considered is determined and agreed upon. As the timeframe increases, it often becomes more difficult to accurately determine the detailed project requirements. Therefore, it is recommended that the timeframe should not exceed 2 years. 2. If it is determined that major changes to the high-level plan are required, these changes are presented to the steering committee for review and approval. This is especially true if it is determined that the changes will have a high impact on the overall cost of implementing the IT strategic plan. Dependencies Analysis S3-1.2 Prioritise Building Blocks 1. Review all high level initiatives and building blocks identified in previous tasks. 2. Identify and document all dependencies and update the list of high level initiatives with descriptions for pre-requisites not previously identified. 3. Establish criteria for prioritising initiatives and projects. Examples of evaluation criteria include: Supports organisational objectives. Supports organisational critical success factors. Has high-value related issues. Has financial impact as part of the value chain. Has broad impact across the organisation. Enhances revenue. Reduces or avoids cost. Easy to implement. 4. Prioritise the building blocks based on the agreed criteria. 3

4 1. Consider the following when assigning priorities and sequencing the initiatives: Logical priorities - dependencies will in many cases dictate a logical precedence. Benefits - what is most important to do? Resources - what is capable of being done? Risks - what is most likely to succeed? 2. In many mid-market organisations, assigning priorities to initiatives will be relatively straightforward, and may be accomplished by means of a meeting with the client that reviews each initiative and agrees on a high, medium or low priority. In more political environments, where there are a number of different constituencies, each with their own priorities, a more formal evaluation approach using agreed criteria may be necessary. Risk/Value Analysis Prioritisation of Building Blocks S3-1.3 Identify Quick Wins 1. Review the application and technology portfolio. 2. Develop a list of high priority projects from the work done in previous tasks. 3. Identify those projects that can quickly provide a significant benefit, with low cost and low risk, and without disrupting the IT strategy engagement. The goal of these projects is to achieve improvements as soon as possible, without waiting for the IT strategic plan to be finished. 1. Sometimes quick win improvements can be achieved without a formal project, just by implementing a new procedure. 2. A quick win project is a project that satisfies the following criteria: Short duration. High return. Minimal risk. Narrow scope. Minimal resource requirements. Minimal integration. Minimal complexity. S3-1.4 Conduct Threshold Analysis 1. Review the prioritised list of building blocks and the identified quick wins. 2. Perform a high level analysis of the costs associated with each initiative. 3. Review the annual budget of the organisation for IT. 4. Rank the initiatives to deliver those of the highest priority as soon as possible while remaining in line with the financial restraints of the organisation. 1. Remember to take into account those projects already categorised as quick wins. 2. New projects will be required by the business through the period covered by the IT strategy so there be must be room to cater for these in the budget. 4

5 3. Take into account those projects that are already running and any costs associated with stopping or delaying these projects. 4. Remember that the IT department must continue to provide service to the business out of the same budget. Threshold Analysis 5

6 S3-2. Determine Projects Overview This activity breaks down the high level initiatives into specific projects. These projects form the basis of the more detailed transition planning which takes place in later activities. 1. Although the methodology separately discusses the areas of application, technology and IT organisation, projects can cut across one or more of these areas. S3-2.1 Determine Projects & Portfolio Structure 1. Review the proposed initiatives. 2. Develop a list of high priority projects from the work done in previous tasks. 3. Classify the projects according to the following categories: Strategic, including competitive applications critical for future business success. Core operational, involving backbone applications critical to sustaining existing business. Support, involving traditional applications which improve management and performance but are not business critical. High potential, involving applications more speculative in nature, but which have the potential to be of strategic importance. Enabling, including projects to implement underlying platform technology or organisational infrastructure, enabling other projects to be implemented. Quick win, where projects have clear benefits and can be implemented rapidly. Interim, including those projects required as a stop-gap until a later project can be fully implemented. 4. Group together projects that logically belong together. 5. Develop a high-level description of each project including the following: Project scope. Project objectives, benefits and critical success factors. Key deliverables of the project. Recommended project sponsor. Recommended project-specific steering committee members. Organisation and business functions within the project scope to set boundaries for the organisational areas covered. Project structure/organisation. Preliminary strategy for approaching the project. Project risk assessment, including measures to contain/mitigate identified risks. Project implementation issues. 1. This task bridges the gaps identified in previous tasks through the identification of projects which include elements of application, technology and IT organisation. Typically projects are identified. 2. Consider the following in developing the project scope: boundary of functionality, functionality excluded from scope of project, number and type 6

7 of key inputs and outputs, number and location of users, number of key system interfaces, current systems impacted by enhancement, replacement, or new interfaces, general level of resources required. 3. If a software selection or implementation project is identified, consider if a process redesign project needs to occur first. 4. Consider the full range of services offered by Deloitte as guidance as to the types of projects that can help the client to achieve the desired future environment. 5. When identifying project objectives or benefits, focus on using clear measures and timeframes for achieving those measures. However, do not ignore other more qualitative objectives. 6. Critical success factors, in this context, are those key issues and requirements that need to be addressed to ensure that the objectives can be met. Develop Project Templates Prior IT S3-2.2 Validate IT Projects, Priorities & Timing 1. Review the linkages and dependencies between building blocks identified and prioritised in previous tasks. 2. Develop an IT tactical plan containing an executive summary and the assembled outputs from previous tasks for steering committee approval. 3. Schedule a review meeting with steering committee and distribute the IT tactical plan for review prior to meeting. 4. Prepare and deliver a short presentation of the major points of the IT tactical plan to the steering committee. 5. Put in place a sound management process to support the implementation of the IT tactical plan. 6. Gain steering committee approval and sign-off on the IT tactical plan. 1. The document developed is designed to both summarise what has been done and to serve as a reference guide to those who implement the results. 2. Prior to the presentation, informally meet with each member of the steering committee and other key client stakeholders to identify any concerns about the IT tactical plan. These concerns should be addressed, to the extent possible, prior to the presentation to all members. 3. Client sign-off is usually obtained during the meeting with the steering committee and is a verbal commitment and sign-off. Since each client relationship is different, determine if a signature sign-off from the client is required. 7

8 S3-3. Develop IT Master Plan Overview This activity describes the development of a portfolio of projects, which completes the development of the IT strategic plan and begins its implementation. The resulting deliverable is the IT tactical plan. The IT tactical plan includes those projects that will be initiated in the first year. 1. The material assembled in this activity should previously have been reviewed, both within the project team and with senior management. For this reason, ensure that adjustments to the material being assembled are concerned with clarity and linkage, and not with matters of substance, which should have been discussed and agreed upon in principle previously. This does not, however, mean that the plan should not be changed to address new information that will ultimately affect the quality and effectiveness of the plan that is developed for the client. 2. The development of the IT tactical plan is important to the client. This document outlines the steps required by the client to begin to implement the projects identified in the IT strategic plan. It is a living document that can be used by the client to monitor the progress it has made towards accomplishing its IT strategic vision. 3. The value of creating an IT strategic plan is minimal if it is never implemented. Therefore, there is a high value in developing an IT tactical plan. 4. Use the budget and engagement letter for the IT strategy project as a guide to determine the number of IT tactical plan projects that should be developed in further detail as part of this activity. S3-3.1 Develop Master Strategic Plan 1. Review organisational initiatives and priorities and compare to the agreed implementation and resource plan. 2. Identify any major issues that may prevent the implementation plan from being achieved. 3. Identify other issues that need to be planned for (e.g. staff redundancies). 4. Resolve issues with senior management. 5. Develop executive summary and assemble outputs from earlier tasks. 6. A management or executive summary of the plan is also prepared and a presentation is made to the steering committee summarising the findings, conclusions and recommendations of the plan. 7. Assemble IT strategic plan to include the following major sections Executive Summary. IT Strategic Assessment and Direction. Future IS Organisation Model. Application Architecture. Technology Architecture. Projects / Resources (Project descriptions, resource plan, project costs and benefits, project priorities, project Gantt chart). 8. Identify key management personnel who need to be "sold" on the plan, in addition to the steering committee members. 9. Individually meet with each member of the steering committee to address issues prior to the overall meeting. 8

9 10. Present the IT strategic plan presentation to the steering committee members. 11. Gain steering committee approval and sign-off, as required, on IT strategic plan. 12. Modify the steering committee presentation, as required for other key management personnel. 13. Present the IT strategic plan presentation to other key management personnel. 1. The purpose of this task is to understand and communicate, at a high-level, the major impacts on the business of adopting the strategy, for four main reasons: To ensure that the plan is achievable, within the context of other organisational initiatives. To ensure that any major impacts on the workforce are identified well in advance and to appropriately plan work force issues. To mitigate any potential management resistance to the implementation of the IT strategic vision, due to unanticipated impacts on their business. To obtain buy-in and commitment. 2. The document developed is designed to both summarise what has been done and to serve as a reference guide to those who implement the results. This document is assembled from outputs in earlier tasks. The only new material developed should be introductions, summaries and transitions. 3. The following topics are suggested for the executive summary: IT strategy project scope and objectives. IT strategy project approach and deliverables. Assessment results. Key issues. Strategic direction and rationale. Project prioritisation method and criteria. High priority projects. Resource schedule. Business impact. Next steps. 4. Prior to the presentation, informally meet with each member of the steering committee and other key client stakeholders to identify any concerns about the IT strategic plan. These concerns should be addressed, to the extent possible, prior to the presentation to all members. 5. The additional key personnel to which the IT strategy needs to be presented could include managers in the IT department and managers in the business functional areas. 6. The presentation given to the key managers can be a variation of that given to the steering committee. It should cover the major points of the plan, the major implications and the rationale. The presentation should also indicate the level of top management support for the plan. 7. Client sign-off on the IT strategic plan is usually obtained during the meeting with the steering committee and is a verbal commitment and signoff. Since each client relationship is different, determine if a signature signoff from the client is required IT Master Plan Financial Tools Supplementary Tools: 9

10 Five Year Master Plan Executive View S3-3.2 Analyse, Prioritise & Sequence Projects 1. Review the project portfolio and assigned project categories established in previous tasks. 2. For each project within the project portfolio, identify prerequisite projects that are required to successfully implement the identified project. Use the application and technology architectures to assist in analysing this dependency. 3. Refine sequencing of projects, as required based on detailed project descriptions developed above. 4. Refine implementation schedule, as required based on a detailed definitions. 5. Document dependencies and update project portfolio with descriptions for pre-requisite projects not previously identified. 6. Confirm project sequence with practitioners within Deloitte that are experienced with implementing the type of project identified 7. Establish criteria for prioritising projects and prioritise projects based on agreed criteria. Consider the following: Logical priorities - project dependencies will in many cases dictate a logical precedence. Benefits - what is most important to do? Resources - what is capable of being done? Risks - what is most likely to succeed? 8. Starting with the highest ranked project, review its prerequisite projects and place these at the start of the project sequence. Repeat this process for the next highest ranked project and continue until all projects are sequenced. 9. Prepare a recommendation as to the project sequence, without timeframes and dates. 1. This step can prove useful in validating the project portfolio. Analysis of dependencies can reveal missing projects necessitating the refinement of the project portfolio. 2. When sequencing the projects, analyse the logical dependencies between the different types of projects and ensure that any logical constraints are documented. The projects that logically belong together should then be grouped. 3. In many mid-market organisations, assigning priorities to projects will be relatively straightforward, and may be accomplished by means of a project team meeting that reviews each project and agrees on a high, medium or low priority. In more political environments, where there are a number of different constituencies, each with their own priorities, a more formal evaluation approach may be necessary. In this case, consider asking the project team to score projects against weighted criteria, such as: Fit to application and technology vision. Support for client s critical success factors. Addresses significant issues. Generates revenue. Reduces or avoids costs. Process priority. User-assigned priority. Clarity of project scope and objectives. Likely level of cost magnitude. Level of organisational impact. 10

11 Strategic fit. Competitive advantage. Technical stability. Business risk. Ease of implementation. S3-3.3 Develop High Level Gantt Chart 1. Review and confirm senior management expectations, constraints and guidelines, including: Capital spending constraints. Staffing or hiring constraints. Maximum IT spending or investment limit as a percentage of sales. Project capital approval criteria. 2. On the basis of the project sequencing, develop a high-level project Gantt chart that takes into consideration the identified constraints. 3. Prepare a resource plan that identifies the impact of the implementation plan in terms of capital investment and expenses. 1. The project Gantt chart should cover the projects to be completed within a three to five year time period. 2. It is essential that senior management expectations are well understood if a realistic plan is to be prepared. Also, ensure that the client s requirements regarding investment appraisal are clearly understood so that the business case can be prepared to take account of these requirements. Other projects for example (in progress or sequenced) can place severe constraints on resource availability. The IT strategy project schedule may need adjustment accordingly. 3. Both the resource capital investment and expenses required for the defined projects and for ongoing operations, administration and maintenance should be considered. S3-3.4 Develop Project Cost estimates, Risks & Benefits 1. Conduct high-level research to establish a high-level cost range for the determined projects. 2. Estimate high-level costs and classify them according to the following categories: Package acquisition / application development. Technology acquisition. Configuration, testing and conversion. Technology deployment. External consultants / project management. On-going support and maintenance. Organisational restructuring. Training. Temporary support for client personnel assigned to the project. Travel and accommodation costs for projects involving travel to multiple sites. 3. Identify and classify high-level risks according to the following: By type (e.g. business risk, technical risk). By the impact on the organisation should the risk occur. 4. Identify proposed risk containment measures and contingency plans. 11

12 5. Reprioritise projects based on identified risks, as required. 6. Analyse costs against benefits according to an agreed approach with the client. 7. Review results and refine as necessary. 8. Carry out any sensitivity analysis required. 9. Describe key non-quantifiable, intangible benefits of adopting the strategy. 10. Document findings. Even though costs were estimated by category, the sum total cost for all projects should be documented. 1. Ensure that projected costs are realistic, and include some contingency. Always give a range of costs (e.g. best case, worst case, most likely case). When performing this task, discuss the projects with experienced Deloitte practitioners who have performed the project. 2. Even though costs were estimated by category, the sum total cost for all projects should be communicated and documented. 3. Understand the risks associated with each project and establish measures to manage the risk. 4. The level of effort applied to costing should not be equal for all projects. A larger effort should be applied to the definition and evaluation of those projects that have one or more of the following characteristics: high priority, high cost, high benefits, high risk or high impact. 5. Identify an approach for determining the method(s) by which investments are going to be justified. 6. Include in the analysis any speculative savings, such as savings in staff time which will not lead to headcount reduction (making clear when presenting the results that you have done so). 7. Consider also whether some degree of sensitivity analysis should be undertaken. For instance, it may be appropriate to present a best case, worst case and most likely scenario. 8. Potentially, the major point to consider here is what to do if the strategy does not appear to be financially justified. In some cases, there will still be a strong business case for adopting the strategy, in order to achieve the nonquantifiable benefits. But clearly the way must be left open to review the project portfolio and drop high cost, low priority projects from the plan, or should the strategy still be unjustified, to revisit and modify the application and technology direction. 9. If the benefits identified in this task do not outweigh the cost of implementing these projects, the application and/or technology directions and architecture may need to be revisited. S3-3.5 Develop Detailed Roadmap 1. Review the high-level IT project implementation schedule. 2. Produce high-level workplans for each project. 3. Consolidate project workplans, taking into account resource requirements and constraints. 1. The high-level project Gantt chart developed in previous tasks is a highlevel IT strategic plan workplan. Within that chart, each project is represented by one line, which indicates the overall duration of the project. The workplan developed within this task contains more information, but is still at a high-level. Each project is broken down into more detailed steps to indicate the major phases of each project. 12

13 2. Prior to the further development of project workplans and the assignment of required resources, it is important to finalise the definition of the transition approach by defining project sequences and priorities. When appropriate, experts within Deloitte are contacted and consulted with to confirm that the project resource assignments and project timing is appropriate. As a result, ensure that the basis of the developed workplans, including any key assumptions made, are well documented. 3. Develop the application and technology projects in a consistent way. The client should be possible to trace back through the process and the assumptions made in defining the tasks and estimates. If this is done, then it will be relatively easy to re-plan to adjust for variances against plan in one project and reflect the impact on all related projects. It will also be easier to adjust the plans in light of revisions to estimating assumptions, which will inevitably occur. Detailed Roadmap S3-3.6 Assess Impact of Plan and preparedness of current IT Organisation 1. Review the proposed changes to the IT organisation. 2. Review the change readiness assessment carried out in previous tasks. 3. Discuss the feasibility of the proposed changes with senior management and ensure that they are on board with the proposed changes. S3-3.7 Identify Preliminary Benefits & High Level Costs 1. For each project in the roadmap, review the project costs and assigned cost classifications identified in previous tasks. 2. Classify the previously defined cost as one time or recurring costs. As required, divide the costs within the categories in previous tasks to properly classify them here. For example, within the category "configuration, testing and conversion", a portion of the testing may be one-time, for the initial implementation, but a portion may also be relevant to recurring costs, for the testing of upgrades, enhanced functionality, etc., after the initial implementation. 3. Revise the project cost estimates as required, based on this further breakdown. 4. For each project, review the project benefits identified in earlier tasks. 5. Refine project benefits as required. 1. The entire life cycle of the project is considered, including testing and implementation, where applicable. 2. The cost of the time of the personnel involved in the development and implementation of the project as well as all resources, such as personnel, funding, equipment, etc., is considered in these estimates. 3. When estimating the cost of a project, be certain to consider the following: Planned investment costs. Hardware and software purchases. Recurring costs (leases, maintenance, communications, human resources and supplies). 13

14 4. Create multiple scenarios for each project (e.g. best-case, expected and worse-case scenarios). This helps to show the effects of estimating and cost errors due to the large amount of unknowns at this point in the project life cycle. Include a large contingency for each project by quoting a wide range of possible costs. 5. Include the incremental hardware requirements related to each project (e.g. cost of additional processing capability, disk storage, networks, telecommunications or additional terminals, etc.). 6. Include the incremental software requirements related to each project (e.g. cost of database management systems, operating systems, specific development / support tools, etc.). 7. Recommend to the client that a more detailed business case be developed for individual projects prior to their initiation, in order to validate costs and benefits in more detail and with more certainty. Benefit Master Plan S3-3.8 Incorporate Operating View into Financial Plan 1. Using the approved IT tactical workplan, create a three year business case detailing the financial impact based on: Resource changes. Quantifiable business and IT benefits. IT budget costs. Outsourced/in-sourced model. 2. Present business case to the client management team for approval. 3. Gain consensus from the Business and IT on Business Case(s). 1. Access to client data and cooperation of key client budget and finance resources is critical. Five-year Operating Plan 14

15 S3-4. Define Continuous Planning Framework Overview This activity sets in place the framework for regular reviews of the IT Strategy to cater for ongoing changes to the business. This framework provides the basis for the review and maintenance of the IT strategy to ensure that it is kept up to date, relevant and remains aligned with the business objectives. Continuous Planning Components S3-4.1 Develop sensing network to keep track of present and future opportunities 1. Determine with the client the business and technology indicators that will be monitored and assessed during the next planning cycle. 1. Business indicators include: Number of customers. Value Drivers. Business Model evolution. 2. Technology indicators include: New technologies. Obsolescence. S3-4.2 Define Continuous Planning Framework 1. Put in place a process for the client to periodically update its IT strategic plan, including The frequency of review. The client staff responsible for the review 2. Put in place a similar process to assess business changes against the IT strategic plan, setting thresholds for change to prompt a review of the four rolling plans. 1. Ensure that the process regularly assesses the key indicators determined above and assess whether these indicators are still applicable. 15

16 S3-5. Ongoing Project Management Overview This activity covers standard project monitoring and control activities and suggests approaches for publishing project deliverables and maintaining project documentation. There are additional tasks in this activity to facilitate the management and control of the project during this last phase of the project, including tasks focused on closing out the project and facilitating the transition to future add-on opportunities with the client. 1. IT strategy projects often lead to other projects to assist the client in implementing the defined IT strategic plan. Although this makes the transition from the IT strategy project to the start-up of another project smoother, it presents a challenge for the IT strategy project manager. The project manager must therefore make certain that there is a clear understanding and communication to the client as to what deliverables can be expected as part of developing the IT tactical plan and what deliverables would be part of the start-up phase of a follow-on project. QRM Templates Project Management Methodology (PMM4) 0.html S3-5.1 Manage Project Ongoing project management should be carried out as a continuation of the activities described in the Anticipate & Assess step. S3-5.2 Project Closeout 1. Update the project workplan to include all project closeout activities. 2. Review workplan tasks and deliverables and ensure that all tasks have been executed and all deliverables have been completed, reviewed and approved by the client. 3. Meet with the steering committee to review the overall project and obtain agreement that all required work has been completed and that the project has met the client s expectations. 4. Verify that all project deliverables have been signed-off, if appropriate. 5. Obtain references from key client stakeholders to be used in future marketing efforts. 6. Deliver the final invoice and reconcile and close the project budget. 7. Track the final payment. 8. Schedule and conduct the post-project review with key client stakeholders. This can be done through a written or telephone survey and should be conducted with the client by a senior practitioner from Deloitte that has not been involved in the project. The survey should address effectiveness across consulting in the following performance areas: 16

17 Project management. Technical expertise. Industry knowledge. Consulting process. Effectiveness of approach. Overall satisfaction. 9. Findings should be analysed and incorporated into a report highlighting strengths and areas for improvement. Discuss concerns that will be addressed and the method by which they will be addressed. Create and send an engagement closing letter to the client, which formalises the completion of the project. Complete and document the final team debriefings, including lessons learned and opportunities for improvement. Verify that the project library contains all final project deliverables (no interim drafts) and significant correspondence. Archive electronic and paper files. Verify that all knowledge transfer activities have been completed. Design and implement a plan for ongoing contact and communication relationships with key stakeholders. Schedule follow-up client visit to review the progress in implementing the IT strategy. This meeting should be scheduled for a date 3 to 6 months after the end of the project. Copy the project library and quality files for internal reference. Update the Knowledge Exchange with project deliverables. Provide feedback on the Express IT strategy methodology. Complete performance evaluations of Deloitte project team members and discuss the evaluations with the individuals and their counsellors. Document any remaining action items. 1. Closing a project refers to the administrative closure and the storing and disposing of project information, completing project management deliverables, reviewing the project to verify a satisfactory completion, planning for any ongoing client support, planning for resource roll-offs and reviewing the project to provide feedback on the IT strategy methodology. 2. Closing out the project workplan is performed during the last weeks of the project. The updated project workplan serves as the close project checklist, so it must be updated to include those activities before closeout begins. 3. When reviewing and obtaining agreement from the steering committee that all required work has been completed, it is a good practice to have the final invoice for the project available so it can be given to the client for payment. 4. The project library will be useful as a historical record of the project and may be necessary for later legal or technical verification and documentation of project completion. It is vital that the project library contains a complete project record that is indexed for later access. Individual office requirements should be identified and applied as well. Proposal, signed engagement letter, documented modifications to engagement letter, final project deliverables (not interim copies) and copies significant correspondence in both hard copy and soft copy. Purge hard copy files of duplicate information. Verify that all team members have transferred project files from laptops or desktop computers to the server, and have deleted all personal files and directories from the server. Purge duplicate files and resolve version conflicts. Verify that there are physical (hard) and electronic copies of all published deliverables, and hard copies of all sign-off documents. 17

18 Box and label the paper files. Make an index of all project documents, both hard copy and electronic. Copy project files to backup media. Send the backup media of project files to the designated person within the individual office. 5. Update the Knowledge base with cleansed sample deliverables, the project workplan, the engagement summary update and lessons learned. 6. As practitioners roll-off, collect any client property, e.g. keycards. 7. Specific project budget closeout considerations include: Close out project administration. Review the project actual expenditures against the budget and submit the actual variance report to the engagement partner to approve and sign-off for any final adjustments. Make any adjustments to the final invoice. Submit the final invoice to the client. Complete final project reconciliations. Archive a copy of all closeout documentation in the project library. Document lessons learned for estimating future jobs, and archive in the project library. 8. Specific client references considerations include: Evaluate the client organisation from a QA/risk perspective, in terms of whether it should be used as a reference. If the client is not suitable, from a QA/risk perspective, to use as a reference, determine if any action is needed to address any potential negative publicity that may arise. If this is a suitable client to use as a reference, obtain the client s permission to be contacted as a reference by other potential clients, with specific contact person(s) and contact point(s). Obtain a signed agreement and testimonial, if possible. Archive the agreement in the project library. 9. Specific ongoing client contact management considerations include: Ongoing contact with the client is not just to resolve project-related issues after the close of the project. It should be considered a mechanism to build a foundation for future projects. Plan continued contact with the client, both for continued success of the current project and for new business on other projects. Consider writing to or meeting with the client to recommend specific projects where Deloitte can provide guidance and project management. Determine who the key client decision makers will be on future projects. Determine who will be responsible for following up with key client decision makers on an ongoing basis. Document who within the client will be contacted, who within Deloitte will make the contact, how often contact will be made, and what issues will be discussed, in the ongoing relationship plan. Schedule periodic reunions of key project leaders with the client. Send relevant articles and holiday cards to key client stakeholders. 10. Specific post-project review considerations include: A post-project review should be held with key client stakeholders, to review the project performance and results, and to verify client satisfaction with the project outcome. Contact the stakeholders at the end of the project to schedule a review session for about two weeks after the end of the project. The project partner and QA partner, and any other team leadership members as appropriate, should conduct the client stakeholder interview. Before the meeting, verify that all deliverables met specifications, were approved and signed-off. 11. Completing performance evaluations of Deloitte project team members is often delayed until after the end of the project. This makes it difficult to 18

19 meet in person with the individual being evaluated. Therefore, consider starting this process a few weeks before the conclusion of the project and schedule a meeting to discuss the evaluation. 19