During the first week of University of Phoenix’s Project Management Capstone course, students learn about three areas involved with properly initiating a project: project proposals, project selection methods and project chartering (University of Phoenix, 2009). Each organization develops strategic plans and many of the strategies are implemented through tactical projects. Departments within the organization develop proposals based on the strategies and the organization selects the proposals based on priority and potential benefit to the organization. Once a project is selected, the project sponsor creates and issues a project charter and the assigned project manager plans, executes and closes the project, successfully meeting the objectives outlined in the charter. At least that is how project initiation is supposed to work. But what would happen if the objectives were not clearly outlined? If the sponsor did not issue a charter, could that negatively affect the project? What if there was no sponsor? This paper examines the potential negative impact of improperly initiating an information technology (IT) project and provides recommendations for improving the project initiation process.
The Problem
A group within the IT department of a "company that shall remain nameless" was responsible for supporting the desktop computer environment. In the late 1990s the IT department was preparing to move the desktop environment to Windows 2000. However, the custom written software distribution system used by IT was not compatible with the new version of Windows. In addition, the developers who wrote the application were no longer with the company and the source code was unavailable.
IT management instructed the group to find and implement a replacement software distribution system so it would be in place in time for the Windows 2000 migration. The team worked to identify the industry leading Windows 2000 compatible software distribution systems and brought each in for a presentation. The team liked one of the presentations particularly well and recommended to management that they purchase the system. Management made the purchase and the team was instructed to deploy the new system.
Everything seemed fine until the team started working with the software. They quickly realized that the software was much more complicated than they had expected and that it did not function the way that they had anticipated. In addition, the team was not clear about what was expected from them. Management seemed to have a different idea of what the system was intended to do. The lack of clear direction and confusion within the team created a stressful environment. As time went on and the team was unable to show results from the software purchase, members within the team started blaming each other for the poor decision. What had started out as a simple request, to replace the software distribution system with one that was Windows 2000 compatible, had turned into a complicated, stressful and expensive mess.
The Opportunity
Management turned to one of its seasoned IT project managers to resolve the project. The project manager had a history within the organization of successfully rescuing projects. The project manager met with the team to learn as much as he could about the project’s history. He quickly identified four problems. First, management had not identified a project sponsor to support the project. Second, management had identified the problem they were trying to solve (Windows 2000 compatibility), but they did not provide any objectives or requirements for the solution. Third, the project did not have a formal project manager. And fourth, there was no formal documentation to launch the project officially.
The project manager decided to start the project from scratch. He worked with management to identify a project sponsor and worked with the sponsor and the IT team members to identify the business problem, the business and technical objectives and requirements and documented each within a formal project charter. The project sponsor signed the charter and distributed it to the affected teams within IT.
The project manager then worked with the IT team members to develop a Request for Proposal and an evaluation matrix to use to evaluate the proposal responses. The project team evaluated the responses against the matrix and selected a new solution that was a close fit to the business and technical objectives and requirements of the project. The project manager lead them through the rest of the planning, executing and closing phases to help the team successfully meet the project objectives.
Closing
Project managers should follow the project initiation best practices, like the IT project manager did at this company. By following a structured process during the initiation phase of the software distribution system replacement project, the IT project manager was able to establish a clear foundation from which the team could work. By working with a project sponsor to document the business and technology objectives and requirements within a project charter, the project manager was able to obtain the authority and clarity needed to effectively lead the project team to a successful implementation.
References
University of Phoenix. (2009, August 11). Week 1 Topic 1: Project Initiating Processes. Retrieved August 2009, from CPMGT/305 Project Management Capstone: https://ecampus.phoenix.edu/classroom/ic/classroom.aspx
No comments:
Post a Comment