As the final individual assignment for a Project Management class at University of Phoenix, I have decided to write about the affects of crashing or eliminating tasks on project closure. Why did I choose this topic? The topic of project closure has not been adequately addressed during this class. In addition, the company I work for does not do a very good job of closing IT Infrastructure-related projects. Through researching articles and writing this paper, I have identified some key problems with project closure. I will elaborate on the affects of those problems at my company, then make recommendations for project managers to follow to overcome the problems.
Project Closure Failures
In the article “Not So Fast,” author Mary Brandel outlines observations regarding project closure. Brandel claims that the majority of companies do not perform proper project closure (2006). As a result, they do not achieve the return on investment that the project was originally set out to achieve. Brandel identifies three main reasons for project closure failures: 1) failing to plan project closure, 2) neglecting to complete all project closure tasks, and 3) ignoring actual return on investment.
Failing to plan project closure. Brandel claims that “companies do not do closures well because they do not plan for them” (Brandel, 2006, p. 37). Instead, project planning is focused on building or creating the deliverables of the project. This problem exists within the information technology department at my company as well. Many of the projects are managed by people within the IT operations group. They know how to install and upgrade systems, but they have not been formally trained on project management best practices. As a result, any planning that is done is focused on installing or upgrading the system. Little planning is done in relation to closing projects.
When my company built a new technical support center, they engaged development resources to modify the help desk software to align with internal process. The requirements for development were clear and the programmers executed flawlessly. However, the developers received an endless list of new enhancement requests for the system which delayed the production release by almost a year beyond the date that the original requirements were met. If the project manager had planned to close the project after the initial requirements were met, the system could have gone into production much sooner than it did.
Neglecting to complete all closing tasks. Even with companies that plan for project closure, some have a tendency to “neglect important steps at the project’s close that can make or break your ability to achieve a full return on investment” (Brandel, 2006, p. 37). The article gives an example from a project that was intended to reduce headcount; however, at the end of the project, they neglected to execute the layoffs. Like many companies, my company has more projects than resources to execute them. As a result, once the core deliverables for a project are created, resources are quickly shifted to work on other projects. At times, some tasks are left incomplete.
This happened with a project to replace a software distribution system at my company. After the new system was in place, the project team disbanded to work on other projects. However, they did not complete a key part of the project closure—shutting down the old system. As a result, the servers from the old system were maintained by the operations team for just over a year before someone realized that the maintenance activities were no longer required. If the closure tasks were completed as originally planned, the equipment could have been retired much sooner saving the company valuable time and resources.
Ignoring actual return on investment. Many companies that plan for closure and execute the closure tasks still fail to “evaluate whether ROI was actually achieved” (Brandel, 2006, p. 37). Once the project is approved, they focus all efforts on meeting the project schedule and budget. If the schedule and budget is met, the project is deemed successful. However, it is possible to meet the schedule and budget but fail to generate the return on investment that the project set out to achieve. This is probably the weakest area of information technology project management at my company.
With a recent upgrade to my company’s anti-virus and firewall client software, the upgrade cost was justified through an estimate that the new system would take 50% less time to manage. Successful implementation would result in valuable resources freed to work on other priorities. The project was implemented on time and within budget and was considered successful. However, no measures were performed after completion to determine if the time reduction was realized. In reality, administrators spend more time with the system today—not because the project failed to achieve its objective, but because the new system has additional capabilities that consume administrative resources. If the project were evaluated upon close, management may have seen the problem and taken steps to correct it.
Recommendations
Once one understands the cause of problems, creating solutions can be an easy task. In many cases, simply doing the opposite of the actions that caused the problem will eliminate them. In order to counter the problems discussed, project managers should follow three basic steps to improve project closure processes. First, plan for closures. Use a standard project template that includes the default steps needed to properly close projects. For each project, add to the template any additional items needed to address unique requirements of the specific project. Next, hold the project team accountable to completing the project tasks as identified in the project plan. Ultimately, the project manager must keep the team focused until the last task is completed. And finally, measure the deliverables. Include in the closing process steps to “verifying that the original assumptions were met” (Brandel, 2006, p. 37). By following these three simple recommendations, project managers will counter the problems identified and bring projects to a more successful completion.
References
Brandel, M. (2006, January 16). Not So Fast! Computerworld.
No comments:
Post a Comment