Successfully exploiting the power of Information Technology (IT) to secure a competitive advantage has proven difficult. The Chaos Report published in 1995 by the Standish Group, illustrates dismal IT project performance:
• 31.1% of projects would be canceled before they ever get completed.
• 52.7% of projects would cost 189% of their original estimates.
• Only 16.2% of software projects would be completed on time and on budget.
The proliferation of technology and its impact on the global economy suggests that IT project managers will be challenged to improve upon these statistics. As IT project managers try to balance scope, cost, and schedule, Moore's Law (Intel, 1999) constantly threatens to upset project equilibrium. According to the Chaos Report, for every 100 projects that start, there are 94 restarts.
This paper presents some of the factors that contribute to an IT project restart, the effect of a project restart on the project life cycle, and lessons learned from project restarts.
Causes of Project Restarts
IT projects are usually terminated prematurely because of cost and schedule overruns. In this scenario, the expenses associated with the project eventually exceeded the expected return and the project was terminated. There are circumstances, however, where an IT project cannot be terminated and must be resurrected. Several examples are: regulatory compliance, trading partner, or customer mandates such as Electronic Data Interchange (EDI) and de facto business practices such as methods of Product Data Interchange (PDI).
In addition, with .com startup companies changing the competitive landscape, whether or not to implement an Internet-based application that offers products and services to customers and suppliers may not be a choice. Failure to resurrect a project that creates a web presence may not be an option.
While difficult and sometimes impossible, it is imperative for an IT project manager to identify and prepare for situations in which a project may be restarted. Effectively suspending a project for later restart has a significant impact on the success of the restart effort. There are several key indicators that an IT project manager can use to determine if a project will be restarted.
• Strategic Intent—Whereas tactical projects serve near-term goals, strategic projects often serve as enablers for an enterprise to reach its long-term objectives. Examples of strategic IT projects may be the creation of a high-capacity network for trading partners or the development of a new scheduling algorithm that will allow lower cost and more flexible production runs. Project justification in financial terms of revenue generation over an extended time period is a clear signal to an IT project manager that an existing project has strategic intent.
• Executive Support—Typically, if the support for an IT project extends higher in the organization there is greater visibility for the project. Hence, more than just the project outcome is at stake. Executive reputation, shareholder expectations, and the ability to “get the job done” can motivate project stakeholders to resurrect fallen projects in order to maintain corporate status and standing within the organization.
• Undeniable Deadlines—Remediation of the Year 2000 software “bug” is a good example of an IT project that cannot exceed a given deadline. The consequences of failing to complete a project with an undeniable deadline such as the Year 2000 date change can prove disastrous to a company.
• Competitive Pressures—As stated before, the Internet is changing the competitive landscape; especially for traditional brick-and-mortar retailers. New entrants to established vertical markets are using the Internet to gain access to consumers once unavailable without significant investments in physical infrastructure. If they desire to compete in the retail space, some companies have no choice other than to complete their web application development projects.
In addition to the key indicators presented above, inherent problems associated with the use or lack of project management techniques may plague a project and eventually cause a restart. The authors recommend that if the techniques mentioned below are applied to a project, detailed analysis, and monitoring of their use be practiced. These techniques include:
• “Crashing”—Ineffective use of the “crashing” technique; that is to take action to decrease the total project duration after analyzing a number of alternatives to determine how to get the maximum duration compression for the least cost.
• Fast tracking—This technique may cause weaknesses in the documentation of issues/decisions, risk, and variance reporting. These weaknesses are a direct result of blurred or overlapping project phases.
• Ambiguous objectives—There is no agreement on exactly what are the project's objectives. The justification for the project can no longer be determined and therefore need to be suspended.
• Organizational changes—Accountability for the project is lost. A driving force to ensure the project's success does not exist without the support of stakeholders such as project sponsors, process owners, resource managers, and suppliers.
• Inadequate or poor communications—Status reporting that uses words such as task is almost complete. The true progress of the project is unknown.
• Inadequate effort during project initiation—The project team is ready to begin working before they know what needs to begin.
The Project Lifecycle
The lifecycle of a restarted IT project is different than the generic project lifecycle as represented by the Project Management Institute's (PMI®), A Guide to the Project Management Body of Knowledge (PMBOK® Guide). In a generic project lifecycle, the ability of project stakeholders to influence the outcome of the project is highest at a single point: project initiation. In a project restart, the ability of project stakeholders to influence the outcome of the project is highest at three separate points in the project lifecycle. These points are:
1. Project initiation—When either cost vs. benefit techniques or decision models determined that a new project should exist.
2. Suspension point—When the consumption of resources for the purpose of the project is suspended.
3. Restart point—When a management decision has been made to resume the consumption of resources for the purpose of the project.
Project Initiation
There have been numerous studies that indicate that the effectiveness of project initiation has a significant impact on the outcome of an IT project. From requirements determination to careful risk planning, project initiation sets the stage to successful execution of the project. However, with a project restart, the suspension point and the restart point cannot be ignored as opportunities to notably impact the outcome of the project.
Suspension Point
Depending on how a project has been suspended, there may be pressure to halt all project-based expenditures. While not obvious at the time of suspension, effort expended here will provide benefit in the future. The astute project manager should recognize if there are underlying factors that may induce the restart of a suspended project and encourage post-suspension activities in order to position the project for a successful re-launch.
There are several project-related actions that should be taken prior to project suspension that will enable a project to smoothly restart.
1. Develop a consensus and document the reasons for the project suspension. This activity establishes a shared understanding of the project by the stakeholders that will be used during restart. Establishing a consensus of project problems enables the project manager to plan to address these issues upon restart and generates expectations for potential expenditures in the future to eliminate or mitigate the problems. This technique also provides a set of “to dos” for the project manager upon restart.
2. Perform a project health check. While the obvious reason for project suspension may be cost or schedule overruns, the factors contributing to these issues may not have been identified. If the project is restarted with the same underlying problems that caused the suspension, the likelihood is the project will be unsuccessful again. Is there effective teamwork within the project team including project sponsors, team members, customers and suppliers? Was adequate training provided prior to project execution? Were critical success factors identified by the functional manager, project sponsor, and project team members? Was the schedule realistic? Were estimates modified to reflect the reality of the situation? Answers to these and other project health-related questions could provide insight into unseen causes of project problems.
The project health check also provides a forum where project participants can communicate individual issues related to the project. If the potential exists that the same project team will be used at restart, effectively listening to team issues can promote cooperation when the project is re-launched. This forum can also captures the “what went well” aspects of the project. It is important to attempt to continue with successful project practices after the project restarts.
3. Perform quality checks and updates of all work in progress to ensure that the latest information is accurate. This activity is critical, especially in the realm of software development. Unanticipated expenses can arise due to rework associated with project-related deliverables that were assumed to be correct when the project was suspended. Suspension point quality checks also provide input into the planning process necessary when the project is restarted.
4. Make sure that the configuration management process is being executed, especially for designs, software libraries, source code and executables. By packaging the project environment for later reuse, the restart team can build upon a reliable platform. A restarted project under tight deadlines can ill-afford to incur unnecessary expenses associated with rework due to executing a project with the wrong versions of software, especially source code.
Restart Point
When a project is restarted, the instinct will be to immediately pick up where the project left off. The mantra for a project restart should be to validate what was assumed to be true. This means reviewing the project plan as well as other project and project management outputs. Are the project's fundamental components: goals, objectives, scope, constraints, and high-level requirements still accurately defined?
The activities of the restart point are similar to what can be expected during project initiation. There is however, a subtle, yet important difference. Expectations of the restarted project have, in some respects, been set based on the results of the suspended project. The project manager must recognize these expectations and either manage to them or reset them based on the validation of what was assumed to be true.
Project Plan Review—The restart point provides an opportunity to take advantage of past learning. Corrective action can be performed so that the restarted project's performance can be realigned with the expectations of an updated project plan. Examples of project plan elements to review are:
• Integration Management: An assessment should be performed on any outstanding change requests and or project issues. The causes of issues and even change requests may have themselves changed during the project dynamic of suspension and then restart. Some of these change requests may still be valid and some could be deleted.
• Scope Management: The methods used for initiation to justify the project should be reviewed. The project team must understand how project success will be measured. Are the criteria used to initially justify the project still valid? Even a small change in interest rates can result in a negative return on investment.
• Time Management: A false assumption would be that a suspended project's schedule is valid and needs simple updates with respect to dates. A new activity from an updated Work Breakdown Structure (WBS), new constraints and simply the passage of time will most likely invalidate the previous schedule.
• Cost Management: A project restart allows a project team to adopt past learning. Work accomplished prior to suspension can be a critical input to validating past estimates for future work. Estimates may have to be regenerated, especially if new estimators will also be performing the work. The rapid pace of changing technology can also encourage new estimates, as methods for accomplishing certain activities in the WBS may now be different and can have both positive and negative impact on a project's budget.
• Quality Management: As with Cost Management, work performed prior to suspension can provide input to new change requests, which may be introduced to implement corrective actions. These corrective actions can be used in conjunction with input from the suspended projects health check to direct the restarted project on an appropriate path to success.
• Human Resource Management: In many technical projects, assumptions are made for resource assignments based on the skill sets of the project team. The same resources that were assigned to the suspended project may not be available to complete the effort for the restarted project. New training may need to be provided and different skills may be required to match changes in technology or business needs of the restarted project.
• Communication Management: With a restarted project, the authors cannot emphasize the importance of over communicating to project stakeholders. Through effective communications, the project manager of the restarted project can establish new expectations and mitigate a potentially negative outlook on the restarted project. It may be necessary to hold another kick-off meeting with project stakeholders to inform them that while the objectives of the project are the same, prior experiences have been incorporated into the restarted project. Restarted projects are often analyzed under greater scrutiny then prior to the suspension of the project. The level of reporting granularity may need to be increased.
• Risk Management: The project's risk handling plans must be reviewed. The same factors that contributed to the project's suspension may still exist. These factors may not have been identified during risk assessments when the project was originally initiated. Some previous risk events have already occurred and new risks may need to be identified.
• Procurement Management: The assumption cannot be made that supplier commitments are still valid. New quotes may be required even if the scope is the same.
The essence of a project plan is to provide the framework for executing a project to meet a business objective. If modifications to the existing project plan will not effectively guide project execution and control, a new project exists and should be executed as such.
Lessons Learned
Outside of the mechanics of suspending a project for later restart or reviewing the suspended project's plan at the restart point, the authors have discovered the following project restart issues that IT project managers should be aware of:
Change in Scope—New (and old) project stakeholders may try to expand the project scope by referencing the “old” project. If a suspended project is restarted given a new charter, project stakeholders must be educated to the new goals of the project and encouraged to maintain the scope with the project's change control processes to ensure successful completion.
Team Dynamics—There is a tendency to try to keep the same project team engaged in a project after it is restarted. If the team is still essentially available, the thought is that a shorter learning curve can be expected by applying “experienced” project personnel. However, keeping the same project team after restart may cause discontentment due to the manner in which the project was suspended. Many projects are suspended due to factors outside of the project team's control, yet the project team may feel a sense of responsibility for the project suspension and even failure. It is at the suspension point where the project manager can mitigate future discontentment and create a level of understanding with the project team and other project stakeholders that will help avoid conflict when the project is restarted.
Past Paradigms—Project stakeholders may still operate on the paradigm of the suspended project. These paradigms may even have contributed to the actual suspension of the project! Examples include failure to adhere to change control processes resulting in scope creep, failure to fully contribute to project requirements and the lack of active participation in project-related decision-making. The project manager must identify past project paradigms and take active steps to reset the project's expectations for project stakeholders.
Instant Results—Similar to the attitude of project suspension, where there is pressure to immediately cease project expenditures, there may be pressure for the restarted project to demonstrate instant results. The project manager must avoid the “get-to-work” syndrome that may have been prevented during project initiation. The same business reasons that validated careful planning of the project during initiation still apply to the restarted project.
Productivity—If the project team is essentially the same after restart, the productivity of the project team will most likely be less. This may be due to the perception that “this is the same thing all over again.” Or, the project team may believe that nothing has changed and that the outcome of the restarted project may be another suspension or even cancellation of the project. The foundation built through careful review of the suspended project's plan and effective communication can aid to alleviate this issue. However, the project manager must assume an initial loss in productivity until the project team realizes that something “has changed this time.”
Project Variances—The suspension and restart of a project will ultimately place the project under closer scrutiny by the project's sponsors. Project sponsors will want to avoid the impact of suspending the project again. Project sponsors will have higher expectations for the restarted project and may accept only small project variances. The project manager may have to enact tighter controls for schedule and budget to prove to project sponsors that the project is really under control.
Conclusion
Project restarts pose unique challenges to project managers and research indicates that project restarts will continue to occur. By realizing that there are three points in the project lifecycle (Initiation, Suspension, and Restart) where project stakeholders can influence the outcome of a restarted project, project managers can focus their attention where most appropriate. With this awareness project managers are forced to refine their project management tools and techniques and focus on a preventative method of project management.
By realizing the potential causes of a project restart a project manager can take appropriate steps to correctly suspend a project and position the project for restart. At the restart point, a project manager can perform an educated review of the suspended project's plan from the restart perspective to ensure the plan will effectively guide project execution and control.
And finally, by understanding certain lessons learned from project restarts such a productivity loss and past paradigms, a project manager can be prepared to proactively influence a positive project culture. Project managers are forced to manage human resource issues by straddling the chasm that exists between functional managers and traditional project managers. Project restarts require a certain amount of soft skills in order to nurture a productive, safe, successful project environment.
Useful Web Sites
Sample Research on The Standish Group WWW server [electronic bulletin board]. 2 October 1999. [Cited 22 November 1999]. Available from http://standishgroup.com/visitor/chaos.htm.
What is Moore's Law? on The Intel Processor Hall of Fame WWW server [electronic bulletin board]. [Cited 22 November 1999]. Available from http://www.intel.com/intel/museum.