This essay offers a practical tip in the project management area within good governance. It is part of the monthly series on strengthening governance in private companies, non-profit organizations, and public institutions.
Organizations may need to work with outside firms to acquire a product or a service or to invest in a capital project. A training facility may need to be renovated. An interstate freeway may need to be constructed. A fighter aircraft may be needed. An information technology (IT) system may need to be installed. Any of these projects must be managed, if the organization wants to receive a product that meets its goals and requirements. Anything less than expected could cause frustration, friction, or other problems with the contracted provider.
Needed projects could be implemented internally without having to consult vendors, of course. This assumes the organization has the necessary expertise to complete the project.
Most organizations would not have the capacity to execute on their own. They will have to find an external partner to support them in implementing the project.
How does an organization effectively manage a project, especially one that costs tens of millions of dollars? What should funders and project managers be aware of to ensure they achieve project success? More importantly, how can a failing project be saved and turned around?
With millions or even billions of dollars at stake, what could go wrong?
The U.K. government had plans to upgrade its destroyer class of naval vessels. In this instance, Lombardi and Rudd explained how the production of warships was scaled down by the government’s “evolving perceptions of the strategic environment, disproportionate faith in technologies …, and, above all, faulty project management.”[1] Project managers had unrealistic expectations on available technologies and the costs and timing involved to produce the new ships.
Expending more than what was originally planned appears to be a feature and not a bug in government contracting. Johnson commented that cost overruns and project delays have become the new normal in the U.S. government, resulting in excess charges in the billions.[2]
A common problem made by contractors can be rectified before an award is made. The design of the request for proposal (RFP) sets the stage for how bidders will propose what they will do to complete a project. Potential partners consider their own interests and risks in whether an opportunity is worth pursuing. They may interpret the opportunity as too risky if the scope of work is vague or too controlling if the scope is very specific. “Over-specification of requirements may result in a loss of common sense … [emphasis mine].”[3] Jones recommended that defining the RFP’s scope of work requires balancing the level of specificity in what the government wants. Both the government agency and the contractor would want to deliver something innovative. But innovation is unlikely to happen when an RFP is overly restrictive. On the flip side, innovation could result in technology that’s not ready when an RFP describes technological aspirations that cannot be achieved within three to five years. Project managers must research what is needed and what is feasible and determine what is possible from the impossible. During my time in government, I drafted RFPs that set clear requirements and quality standards, providing broad contours for a project that were tight enough to control and yet flexible enough to adjust. A well-defined RFP communicates clearly what a buyer is seeking in relatively flexible terms that permit a seller to create something new and bold but in a way that remains grounded in reality. The scope of work matches what is possible with what is needed today.
The request for proposal is a key instrument in procurement. If it’s based on sound background research, the RFP could prevent bidders from overpromising deliverables and underestimating expenses in their proposals. Bidders will follow instructions provided in the RFP however they may be written—vague, specific, or fantastically ambitious—and will respond accordingly.
The trajectory of a project can be determined within the first few weeks of starting work. During project startup, leadership can make its presence known by demonstrating its commitment to the project. The executive leader who sponsors the project (the one who has funding authority over the project) could potentially make or break the project. Kloppenborg and his team found that project success is likely when the project sponsor takes an active role, during the startup phase, in defining the project’s performance levels, mentoring the project manager, and communicating the priority of the project.[4] These are three success factors in project management. If performance is ill-defined, the project is not understood in terms of priority, or the person in charge of managing the day-to-day activities is not adequately briefed, the project could start to unravel before activities commence.
Interestingly, the Kloppenborg study also found a factor that might have a negative impact on project outcomes. Establishing change control procedures by the project sponsor during project startup could inhibit success.[5] This is not to say that change management is not required. It’s that control procedures should not be communicated at the start of the project. That can be done later on when activities are underway.
The project life cycle moves through the phases. The contractor carries out activities. Staff salaries are paid. But issues emerge. Milestones are missed. Rate of spending is faster than usual—too fast even. Evidence of a troubled project increasingly mounts.
Within the realm of IT information system projects, four strategies may be deployed to deal with a failing project. The project can be broken up into smaller projects or modules (the reduce strategy); it can be ended outright through contract termination (the dissolve strategy); the team or the entire vendor can be replaced with a new one (the redirect strategy); staff and leadership can do nothing and instead let time play out to see if issues will resolve by themselves (the delay strategy), or a combination of these strategies can be utilized.[6] Guidry and her team noted that the delay strategy is often used as a tactic to hide mismanagement and potential fraud.[7]
Allowing a failing project to continue without any meaningful corrective action is problematic. Expenditures could have been better used on an alternative solution. The opportunity cost should not be ignored. Funds continuously used on a failing project might be questioned in an audit. If word leaks out to the press and media, reputation may be harmed either to the organization or to individuals involved.
Another term for the delay strategy used in the literature is project escalation. Like in the case of delay, the project manager may choose to continue (escalate) working on activities despite the fact that the project is failing. More on why the manager escalates is discussed below. Part of the reason can be attributed to information asymmetry and goal incongruence between the principal (the government or buyer) and the agent (the contractor or provider).[8] Two organizations may have dissimilar goals that aren’t aligned. They may also have imbalanced levels of information where one organization knows more than the other and doesn’t divulge all relevant details to the other. Ultimately, escalation can be stopped by deploying the dissolve strategy or the redirect strategy.
Stopping a failing project may not be simple or quick as it sounds. A swift turnaround could be prevented or thwarted for a variety of reasons. Politics may play a role. Stakeholders may have a vested interest. Resources may have been committed at significant levels. In their analysis of a failing automated baggage handling project at the Denver International Airport, Montealegre and Keil revealed that making corrections is a gradual process that first involves recognizing the problem, then reexamining the previous course of action, searching for alternative courses, and finally implementing an exit strategy.[9] The exit strategy would be the change or solution to address the failure. For a large complex project where multiple actors are involved, the project manager in consultation with leadership needs to review the situation carefully and make a deliberate decision that all parties can agree on. A capricious action might result in another failure, if not alienate partners.
On the reason why a failing project is continued points to how the project manager perceives progress. The manager may have a predilection toward seeing ongoing activities either too optimistically or too pessimistically. Motivations are at play where an optimistic manager exaggerates accomplishments or downplays problems while a pessimistic manager does the exact opposite (exaggerates problems or downplays accomplishments).[10] The result in either case leads to a distorted view of the project. And then senior management can be misled into thinking that the project is operating on schedule (or not) when in fact the opposite is true.
Two factors that may give rise to overly positive and negative reports, according to Iacovou and his team, involve the relative degree of trust in senior management. A project manager may lose trust in her executive leader, if the leader conveys information poorly or unreliably or lacks substantive knowledge in the project’s subject matter. While poor communication alone shows a strong direct relationship with biased reporting, it is inadequate knowledge coupled with lowered trust that influences the project manager’s behavior to submit biased reports.[11] In other words, the executive leader is likely to be misled when he demonstrates poor communication or is seen as untrustworthy with the little knowledge that he has about the project.
Lack of knowledge observed in leadership brings the discussion back to ensuring project success at the outset. Defining performance, mentoring staff, and prioritizing work all presuppose that the executive leader has adequate knowledge of the project. If the leader doesn’t understand the technical qualities of the work, his communication of goals and priorities would be faulty and laden with errors. Such a start on sending unreliable information could doom the project from the beginning. And then the situation would have a snowball effect with the project manager losing trust in leadership and progress reports not reflective of the truth.
Successful implementation of a project throughout the project life cycle requires senior management to have an adequate understanding of the project. Mitchell showed that Chief Information Officers (CIOs) who have access to trade periodicals and similar technical literature and who also have the ability to integrate knowledge from various internal sources across their organization are better able to complete projects on time.[12] These leaders keep themselves abreast of latest technologies, current trends, and known deficiencies to have the capacity to inform staff and advise on issues promptly and expeditiously. A leader who doesn’t have access to technical resources or doesn’t seek out such knowledge may have difficulty in communicating problems, which could then cause delays as the project manager must rely on other individuals for advice and problem resolution. The executive leader with inadequate knowledge could find himself losing control of the project.
While much of the discussion above on correcting failing projects has been studied in the information technology field, the same strategies and concepts can be applied in other sectors like construction and defense. Similar patterns that would warrant a reduce, redirect, or dissolve strategy may be observed, for example, in a failing bridge project or a failing missile defense project. Any project manager in any field may have a tendency to overstate achieved milestones or disregard encountered problems. Any leader who cannot communicate relevant information about his project would be seen as an embarrassment at best or incompetent at worst.
Of course, a project can fail on occasion. That is human. But failure shouldn’t happen often enough to create a pattern or establish a norm. Is it really normal to have most projects fail? Failed projects ought to be limited to few instances and occurring under peculiar circumstances.
Strategies exist to take corrective actions to turn around a failing project. Leadership should not do nothing, wasting time and money, in hope that the problem will resolve itself. The cause may not be corrected without an intervention. A knowledgeable leader understands this and will take decisive steps to stop the hemorrhaging, diagnose the predicament, and find an effective treatment. The repaired project may look different from what was originally planned. But the issues have been resolved. And just in time to save the project from abandonment or a complete loss. The saved project can continue—albeit in a new form.
Evidence for Practice
A project may degenerate into an untenable situation when its leader lacks an understanding of the project.
Progress reports may be biased depending on a project manager’s motivation to continue project activities that may not be merited.
Stalling a project for time by deflecting questions, relying on abstract talking points, or deploying delay tactics indicates more often than not that serious management problems exist in the project.
Next Steps for Leaders
Leaders and managers should have opportunities to read technical journals, access relevant literature, or visit trade conferences. This will ensure that they remain knowledgeable about their projects that they’ll oversee and steer. It will also allow them to maintain a high degree of trust with staff and partners.
The procurement team should review the process of designing their request for proposal (RFP) instrument. Are there far too many RFPs that convey vague requirements or unrealistic expectations? Do RFPs include stifling provisions that don’t allow potential contractors to be creative? Are the staff who prepare RFPs adequately trained in analyzing business needs and system feasibility?
Notes
1. Ben Lombardi, and David Rudd, (2013) “The Type 45 Daring-Class Destroyer: How Project Management Problems Led to Fewer Ships,” Naval War College Review 66(3): 114.
2. John C. Johnson, (2018) “Cost Overruns, Schedule Slips: The Norm, Not the Exception,” National Defense 102(774): 26.
3. Cullen A. Jones, (2016) “Becoming Better Partners with Industry,” The Military Engineer 108(702): 87.
4. Timothy J. Kloppenborg, Chris Manolis, and Debbie Tesch, (2009) “Successful Project Sponsor Behaviors During Project Initiation: An Empirical Investigation,” Journal of Managerial Issues 21(1): 156.
5. Kloppenborg et al.: 157.
6. Terri Lenora Guidry, Brittany Brown Halligan, and Cara Peters, (2018) “Strategies for Handling Failures in Development of Information Systems,” Journal of Managerial Issues 30(3): 367–374.
7. Guidry et al.: 367.
8. Mark Keil, Joan Mann, and Arun Rai, (2000) “Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models,” MIS Quarterly 24(4): 657.
9. Ramiro Montealegre, and Mark Keil, (2000) “De-escalating Information Technology Projects: Lessons from the Denver International Airport,” MIS Quarterly 24(3): 424–428.
10. Charalambos L. Iacovou, Ronald L. Thompson, and H. Jeff Smith, (2009) “Selective Status Reporting in Information Systems Projects: A Dyadic-Level Investigation,” MIS Quarterly 33(4): 787.
11. Iacovou et al.: 803–804.
12. Victoria L. Mitchell, (2006) “Knowledge Integration and Information Technology Project Performance,” MIS Quarterly 30(4): 933.