Project Implementation, Closure, and Evaluation PDF

**Project Implementation, Closure, and Evaluation** This week we will concentrate on project completion. This includes project implementation, closure, and evaluation. Project implementation focuses on installing or releasing the project's major deliverable in the organization---namely, the product...

**Project Implementation, Closure, and Evaluation** This week we will concentrate on project completion. This includes project implementation, closure, and evaluation. Project implementation focuses on installing or releasing the project's major deliverable in the organization---namely, the product or system that was built or installing the software package purchased. This release or implementation requires a tactical plan that allows the project team to move the project's product from a development and test environment to the day-to-day operations of the organization or in the hands of the customer. What would be the best strategy for project implementation? This is a question faced by every project team when it comes to IT solution production implementation (so called Go-Live). This week provides an insight into the final stages of project implementation and the required completion steps. It explains different the implementation strategies; benefits and short-comes of each of the options (Direct Cut-over, Parallel Run, and Phased Approach). The week also describes the processes associated with proper project closure as well as four project evaluation techniques. **Learning Outcomes** Upon successful completion of this unit, you will be able to: - Describe the three tactical approaches to information implementation and installation: (1) direct cutover, (2) parallel, and (3) phased. Compare the advantages and disadvantages of each approach. - Explain the processes associated with project closure to ensure that the project is closed in an orderly manner. - Identify the four different project evaluations or reviews: (1) individual performance review, (2) postmortem review, (3) project audit, and (4) evaluation of the project's MOV **Project Implementation, Closure, and Evaluation** The three approaches for installing or converting to the new system are described.  These approaches include direct cutover, parallel, and phased.  While each approach focuses on delivery of a technical solution, choosing a particular approach can have an impact on the organization and the various project stakeholders. The project methodology introduced in Chapter 2 provided a framework for initiating the project in an orderly manner.  Moreover, a set of plans and processes guide the project and the development of the IT solution.  While we have tried to provide structure for beginning the project, we must not lose control of the project at this late stage.  Therefore, a project should have an orderly beginning and an orderly end. The project and project team need evaluation.  This includes a number of reviews such as individual and team performance reviews, audits, and reviews by outside members, and the evaluation of project success -- a review of the project's MOV. **Project Implementation Approaches** Project Implementation focuses on installing or delivering the project's major deliverable -- the information system that was built or purchased. The implementation of the IT solution or the project's product is a technical undertaking. However, a number of human issues must still be addressed.  For example, choosing a particular conversion or installation strategy can place pressures on a particular group of project stakeholders such as the project team if a direct cutover approach is taken or the users of the current and new systems run in parallel.  While the organizational change management helps prepare many of the external project stakeholders for the impending change initiative, the implementation of an information system can create a number of non-technical challenges and issues for the project team. These issues may include a sense of panic to get things finished on time and within budget, the likelihood of project success or failure, or moving on to a new assignment after the project is completed.  The end of the project can be stressful and emotional and often brings out the best or the worst in people. There are three general tactical implementation plans explored further direct cutover, parallel, and phased. Post-mortem or close-out meeting following completion. 1. Product Release or System Implementation: **Direct Cutover** Fig. 12.1 Direct cutover illustration The direct cutover approach is an approach where the old system is shut down and the new system is turned on. In general, a target, or go live, date is agreed upon, and the new system simply replaces the old. This approach may be appropriate when quick delivery is critical, the old system is so poor it must be replaced ASAP or if the system not mission critical. There are also risks associated with this approach such as: - It is not always painless -- like walking a tightrope without a safety net - It may result in major delays, frustrated users, lost revenues, and missed deadlines - It places more pressure and stress on project tea Product Release or System Implementation: **Parallel** The parallel approach to implementation allows the old and the new systems to run concurrently for a time. At some point, the organization switches entirely from the old system to the new system. 12.2 Direct parallel illustration This approach may be appropriate when problems arise or the failure of the system can have a major impact on the organization. It provides a safety net or backup in case of problems, can increase confidence in the new system, however, takes longer and requires more resources than direct. Besides, it places more pressure on the users. Product Release or System Implementation: **Phased** The phased approach introduces the system in modules or in different parts of the organization incrementally. This allows for an organized and managed approach for implementing system modules or a system/upgrades in different departments or geographical locations. Experience with early implementation can guide and make later implementations go more smoothly. Notably, the approach takes longer and may cost more than the direct cutover approach and problems encountered during early phases can impact the overall implementation schedule. **Project Closure** Lets talk about project closure, completing the project. The project was undertaken to provide specific and measurable value to the organization as defined in the project's MOV.  The big question is: How close are we to meeting those expectations?  If we defined and controlled our project scope carefully, at this point, all we need to do is look at the approved Scope Definition Table or Chart to see whether the project sponsored signed off on the various deliverables as milestones.  If we have, then closing the project should be fairly straight-forward as expectations have been managed.  On the other hand, missing deliverables or unapproved milestones may lead to confusion, panic, and strained relationships. The rest of this unit will provide us the guidance on this process. Let's take a look at various scenarios for project termination: *Normal* - A project that ends normally is one that is completed as planned. The project scope is achieved within the cost, quality, and schedule objectives, although there probably was some variation and modification along the way. The project is transferred to the project sponsor, and the end of the project is marked with a celebration, awards, and recognition for a good job well done by those involve. *Premature* - Occasionally, a project team may be pushed to complete a project early even though the system may not include all of the envisioned features or functionality. *Perpetual* - Some projects seem to take on a "life of their own" and are known as runaway, or perpetual, projects. These projects never seem to end. Perpetual projects may result from delays or a scope or MOV that was never clearly defined or agreed upon. Then, the project sponsor (or even the team) may attempt to add on various features or functionality to the system, which results in added time and resources that increase the project schedule and drain the project budget. *Failed* - Sometimes projects are just unsuccessful. In general, an IT project fails if insufficient attention is paid to the people, processes, or technology. Even though the project's MOV may define the project's value to the organization, cost and schedule overruns may drain the project's value to a point where the costs of completing the project outweigh the benefits. *Changed Priority* - In some circumstances, a project may be terminated as a result of a change in priorities. Financial or economic reasons may dictate that resources are no longer available to the project. Or, management may decide to divert resources to higher priority projects. This change can happen when the original importance or value of the project was misjudged or misrepresented or when organizational needs or technology change over the course of a long-term project. Because of number of undesirable but possible realities, many project stakeholders find the end of a project stressful. **Project Implementation, Closure, and Evaluation** It is important to know the difference between a shortsighted and a knowledgeable project sponsors as making this distinction helps the project manager during project closure: Shortsighted sponsors tend to view the project as a short-term buyer-seller relationship in which getting the most for their money is the most important criteria for accepting the project. This view often leads to an adversarial relationship if the sponsor attempts to renegotiate the project scope or price at the end of the project. Knowledgeable sponsors realize that they have an important stake in the outcome of the project. As a result, they will be actively involved throughout the project in a constructive manner. A knowledgeable sponsor may ask tough questions during project reviews, but their objective is not to embarrass the project team or manager, but to ensure the success of the project. Instead of an adversary trying to get the most in a "win-lose" situation, the knowledgeable sponsor will negotiate intelligently and in good faith. The project manager and team can improve the likelihood that the project will be accepted if they (1) clearly define the acceptance criteria for the project at the early stages of the project, and (2) document the completion of all project deliverables and milestones. A clear definition of the project deliverables is an important concern for project scope management (discussed in an earlier chapter). Yet, defining and verifying that the project scope and system requirements are accurate and complete is only one component. Having scope change procedures in place that are understood by all the project stakeholders also ensures that everyone has the same expectations concerning what will and what won't be delivered at the end of the project. In general, the project manager and team should develop a final report and presentation for the project sponsor and other key stakeholders. The objective of the report and presentation should be to give the project sponsor confidence that the project has been completed as outlined in the business case, project charter, and project plan. By gaining this confidence, the sponsor or client will be more likely to formally accept the project that will allow for a smooth termination of the project. The report may be circulated to key stakeholders before the presentation in order to get feedback and to identify any open or unfinished items that need to be scheduled for completion. The Final Project Report includes the following main elements; Project Summary, Project Description and Project MOV. As well there is a comparison of planned vs. actual and the report includes scope, schedule, budget and quality objectives. There is a great value in conducting the final meeting and presentation in order to: - Communicate that the project is over - Transfer the information system from the project team to the organization - Acknowledge contributions - Get formal signoff Administrative closure requires the following activities to be completed: 1. Verifying that all deliverables and open items are complete 2. Verifying the project sponsor or customer's formal acceptance of the project 3. Organizing and archiving all project deliverables and documentation 4. Planning for the release of all project resources (i.e., project team members, technology, equipment, facilities, etc.) 5. Planning for the evaluations and reviews of the project team members and the project itself 6. Closing of all project accounts 7. Planning a celebration to mark the end of a (successful) project **Project Evaluations** Once the system is installed and working properly, the work of the project team is still not quite finished. All project documents need to be archived and the project and project team needs to be evaluated.  Reviews should focus on the individuals involved closely with the project as well as the project itself.  Experiences lead to lessons learned, and lessons learned can lead to new best practices.  Finally, the project's MOV must be evaluated to determine the project's value to the organization. *Individual Performance Review* The purpose of conducting a review or evaluation with each project team member is to provide constructive feedback for individuals. The meeting can serve to help prepare the individual to move on and accept the psychological fact that the project will end. And, in most cases, the project manager could use this meeting to discuss the project team member's next assignment. *Postmortem Review* A postmortem review should be conducted so that the project manager and team can identify what they did right and what they could have done better. These lessons learned should be documented so that they can be shared with others in the organization. Moreover, best practices should be identified and become part of the organization's IT project methodology. The postmortem reviews provide an important view of the internal workings of the project. To provide a more objective view of the project, an audit or review by an outside party may be beneficial for uncovering problems, issues, or opportunities for improvement. Similar to the postmortem review, the auditor or audit team should focus on how well the project was managed and executed. This may include the project plans and Project Management Body of Knowledge areas described in the previous section, as well as the underlying project management and systems development processes outlined in the organization's IT project methodology. In addition, the auditor or audit team should assess whether the project manager and team acted in a professional and ethical manner. Any lessons learned should be documented so that they can be shared with others in the organization. Moreover, best practices should be identified and become part of the organization's IT project methodology. Often, the MOV cannot be readily determined at the close of the project. Many of the benefits envisioned by the implemented system may require weeks or even months before they are realized. The evaluation of the project's MOV may be intimidating---it can be the moment of truth as to whether the project was really a success. However, a successful IT project that brings measurable value to an organization provides a foundation for organizational success.