The Terror of Project Failure Risk
While many children (and some adults) are looking forward to the sweet rewards of trick or treating on Halloween, this month’s question has to do with a terror more real than those created by the best haunted-house or scary movie. Hold on tight as we explore dealing with the terror of project failure risk!
Due to our current parking system’s technical limitations and the continuing impacts of our reduced staffing levels, our team is considering purchasing a new solution. Yet, with the significant project issues that occurred on the last technology project, several people on our leadership team are worried about the risks of making another change. Do you have any suggestions for how to deal with the risk of project failure?
Nervous in New York
Hello, Nervous in New York,
I can understand the concerns of your leadership team. Bringing on new technology is never an easy process. Many projects can end up taking more time and money than expected, while a surprisingly high number of technology projects are not successful. According to a 2017 Project Management Institute (PMI) report, 14 percent of all technology projects were determined to be “total failures,” while 43 percent exceeded their initial budgets, and 49 percent were delivered late. This data helps reinforce the idea that most projects result in some form of failure. Knowing this, developing and implementing a “failure management plan” can help deal with the risks, both operationally and professionally. Your plan should cover a few key areas, including political, operational, and the vendor.
Whether you are working for a public or private institution, you are dealing with a level of politics. On some level, everyone is balancing their interests against the larger organization’s goals. The changes caused by a more extensive project tend to bring out additional issues as not only are people worried about the project, but how the project affects them. While you can’t control others’ behavior, having a written and published project plan completed before the project starts helps with the post-failure finger-pointing. To help create this plan, I would recommend doing an honest postmortem on your last project. What went well, what could have been improved, and what lessons should we take into the next project? Then a few days later, have a pre-mortem for this new project that takes a hypothetical look back as if your future project has already been completed. The idea is to discuss what could go wrong, and then create plans for those situations ahead of time. Once the project begins, publicly share plan updates (at least, within your organization) and be honest about shortcomings and changes.
Next, work to obtain support from project champions all along the chain of command. Set clear expectations for the project and how you might need help. Often, projects are delayed due to issues outside of the parking department’s or vendor’s control (think IT or legal compliance). The ability to obtain help at higher levels increases the likelihood of cross-organizational cooperation.
Be honest about the likely issues that could occur due to operational changes or technology adoption. For example, when rolling out a new license plate reader (LPR) based enforcement system, the number of citations (and calls from parkers) will likely increase dramatically early on. But these will level out over time as compliance increases. If you prepare leaders for the worst, they are less likely to be surprised when it happens.
Many times, due to political concerns, project failures are kept quiet. It is an understandable decision in many situations. However, this choice can cause others to learn the hard-earned lessons themselves instead of from your project. If possible, be willing to share the lessons learned from both successful and less-than successful projects. It is a professional “pay it forward” moment that can help others in the same situation.
The move to a new parking system can be a challenging and time-consuming task. A crucial part of your plan should include dealing with the possibility of failure. A fallback plan allows failure to be dealt with in a way that does not cripple the overall operation. Have an agreement with your current provider that allows for continued use of the existing system beyond the new system’s expected go-live. This time helps avoid the need for “make or break” hard deadlines to move off your current system. While this approach will likely cost a bit more in the short term, it is an insurance plan for continued operational success.
Determine the goals of the project in clear operational terms and document what is driving those needs. For example, one goal could be to improve enforcement officers’ operational efficiency by reducing the amount of time it takes to patrol one city block by 25 percent, allowing for broader enforcement coverage of city streets. Clearly stating operational needs provides for the development of quantitative project success criteria, which can later be used to measure project progress and clearly define what constitutes success or failure. Create project stages built on these measurements to provide a realistic view of the project progress up to that point and enable the plan to be updated with additional information.
Expect to make operational changes as part of the implementation process. Many times, existing rules are the product of previous parking technology limitations more so than current operational needs. Taking the time to document and understand the current operational processes before the project begins allows changes to be made quickly and safely during system implementation. Process documentation should include not only the process completed, but specific items such as report names, file locations, and, if possible, the typical time to complete a function in the current system. These time estimates are beneficial while the staff is learning to use the system. There can be a “rose-colored glasses” period after go-live, where everything about the old system seems more straightforward and faster. The documented process benchmarks help to quantify a typically qualitative situation and can speed new system acceptance.
Selecting the correct vendor can be challenging. The typical RFP process is a complicated and inefficient way to choose technology. While contract piggybacking and sole sourcing can be faster, it limits options and can create complacency in the vendor. One approach is an RFQ process with a hands-on demo and information session followed by a more detailed RFP.
When it comes to the vendor stated functional performance of the system, trust but verify. The goal of many sales teams is to find ways to say yes to every requirement listed. To help avoid this, ask operationally descriptive questions such as “show me how we would do this in your system” or “what limitations would your system have in performing this task?” You can also ask, “what other customers are using this feature in the way described?” Interview those customers about how well the system is working. Require a list of all customers who terminated their contracts before or after go-live within the past three years. Talk to those customers and discuss specific reasons for cancellation or termination. Just because a customer ended their relationship doesn’t mean that vendor isn’t a good fit for your situation. But the way a vendor handles difficult situations is a good insight if you run into issues with your project.
Finally, configure the payment schedule that aligns with the project phases mentioned above. This step helps ensure that the vendor is paid as the system meets the stated goals while preserving the funds needed if a switch is required. The key is the goals have to be measurable and agreed upon ahead of time so that success is not based on a person’s perspective or feelings but on actual assessable performance.
I hope this was helpful and good luck with your project!