404 Error: How to Prevent Tech Project Failures

 
 

technology project management

Technology improvements are vital for meeting evolving business needs, but poor project management can lead
to unmet expectations and significant excess costs.

Adopting new technology products, overhauling existing IT systems, or pursuing new internet services are not easy. In fact, if there is one way an organization can lose a bundle of money quickly, it is in the failed implementation of a technology project. There are many embarrassing examples of such failures. For instance, Cover Oregon, the online health insurance marketplace set up for the state in 2011, was meant to encourage citizens and small businesses to take advantage of federally-subsidized health insurance rates as laid out under the Affordable Care Act.

While the intent was to facilitate online registration and selection of coverage, the reality proved out to be much more 19th-century. From the start, the site was plagued with problems and it was only possible to purchase insurance via paper registration (which the state was forced to hire or reassign nearly 500 people to process), and the project fast became an expensive “white elephant.” Three years and $200 million in, Cover Oregon’s board of directors decided to discontinue the exchange. The FBI began an investigation in March 2014 and the state officially ended the project a year later, permanently folding its functions into an existing state agency and the federal HealthCare.gov website.

In 2017, Pennsylvania filed a suit against IBM over a $110 million technology project to upgrade its unemployment compensation system that the state says was never completed. The lawsuit, which IBM is contesting, alleges that state residents ultimately paid $170 million—$60 million over budget—“for what was supposed to be a comprehensive, integrated, and modern system that it never got,” Governor Tom Wolf said. The project was shut down in 2013, some 45 months behind schedule. Since then, the state has continued to rely on its legacy systems.

Consultants say that major technology projects can often fail, and the more ambitious they are, the more damage they can cause to the company’s coffers. Last year, the U.S.-based Project Management Institute, an association for project management professionals, found that organizations wasted an average of $97 million for every $1 billion invested in tech projects and programs worldwide in 2016. And that was cause for celebration—the previous annual waste amount had been $122 million. The failure rate stands at 14%, meaning that one in seven projects fell flat. Other experts have found similarly dire results: McKinsey has long said that it is hit-or-miss if a large-scale technology project actually delivers, and researchers at The Standish Group found that only 29% of IT project implementations are successful, with one in five (19%) being considered utter failures.

Project Management Problems

Companies need to up-to-date technology and systems in order to survive, but that survival is not necessarily dependent on investing in cutting-edge solutions. Even if the technology platform or software performs relatively simple tasks, that does not mean it is easy to integrate these new systems and procedures across an organization’s entire operations (including cross-border). As with any initiative, problems frequently occur. Companies must consider the risks inherent in these projects, how they should be managed, and who should manage them.

Gavin Stead, head of program services at IT professional services firm Gibbs Hybrid, said that technology projects tend to fail because of a lack of leadership, particularly at senior management and board level. “The IT department tends to get left in charge of IT projects and management takes a back seat. But while IT departments understand the technology and the risks, they don’t necessarily have the right project management experience to pull major projects off,” he said. “Also, technology is not just an IT issue, it is a business issue, and major technology projects need executive input and leadership from the start.”

Kirit Patel, regional managing director (Europe) at EOH International, a global consulting company that specializes in IT implementation, said that in his experience, project success—or failure—is often impacted by the level of executive sponsorship and that IT project failure is rarely caused by technology.

“Change can be hard. Even the best-planned and best-run projects will hit roadblocks where tough decisions may need to be made,” he said. “Unless a project has the right level of executive involvement—not just a signature on some paperwork, but full visibility and input into the process—lack of executive sponsorship can at best introduce delays and allow scope creep, or at worst become a point of failure.”

Appointing the right people to implement the plan is not as easy as it sounds, however, and can be another source of potential failure. It is a common mistake to nominate people internally to lead the project in addition to letting them continue with their day job. Instead, organizations need to set up a dedicated full-time project management team that reports directly to the executive. “Too many organizations try to form internal project teams with people who already have very full roles,” Patel said. “Project teams are made up of professionals who, due to existing commitments, are very stretched.” Without adequate support, deadlines are often missed, and the implementation is not done properly.

Bringing in other people from within the business to help manage the project or contracting parts of the project out to different suppliers on short-term contracts can also lead to disaster. Even engaging a lead partner to take control can have its downside, especially if key project managers are rotated on and off the implementation.

In 2013, Pennsylvania released a study conducted by Carnegie Mellon University’s Software Engineering Institute into its failed IBM-led project. Among a number of problems, the study cited high workforce turnover as a key factor in efficient project planning and execution. Since the start of the project, the report noted that 638 different contractor staff members had worked on it, with the majority of the workforce having less than a year of involvement and 75% less than two years.

The relationship between technology contractors and the client can also be a source of tension and failure. Val Jonas, CEO of risk management consultancy Risk Decisions, said that one of the most common problems she has seen with large-scale technology projects is that customers and contractors have different views of what is meant by an “agile” plan. While boards understand that “agile” projects involve flexibility and addressing changing needs to deliver the desired outcomes, they often think that the project’s scope is at risk as contractors change priorities to achieve the objectives in a different way.

“IT contractors have a more sophisticated and mature understanding of what ‘agile’ entails because they have worked on a lot more projects,” she said. “Boards and management teams, however, do not always fully appreciate what ‘agile’ actually looks like as the project develops, which can lead to a lot of disruption, confusion and mistrust, especially if they think that any changes will lead to delays, cost overspends and failure to meet the stated goals.”

Milestones and Expectations

Project planning and establishing expectations up front are also important. “Set clear goals and realistic expectations,” said Paul Whitelam, senior vice president of marketing at ClickSoftware. “Talk through worst-case scenarios, likely and unlikely obstacles, and potential risks in order to develop a plan that can accommodate any disruptions and help prevent a disaster before one occurs.”

Organizations should set meaningful milestones to ensure that the project is properly scoped out and that those in charge of managing and implementing it properly know their roles and responsibilities. “By proactively communicating at every stage of the process, you will allow your team time to get used to the idea and feel comfortable providing input, making the transformation process inclusive and open,” he said. The plan should also be flexible enough to allow for changes to priorities if necessary without having to restart the process.

To iron out any initial kinks, organizations should run a pilot program as early as possible. “Any problems found will be more manageable early on than when encountered at a later stage,” Whitelam said. “By ensuring every member of your team knows what is happening and is working alongside one another during the pilot, you can generate a more efficient and comprehensive plan, which will provide a better offering and higher chance of success.”

Lukasz Lacniak, business solutions architect at IT integration specialist Comarch, advises organizations to plan for a degree of flexibility, whether in time, budget or scope. They should also revisit plans frequently to make sure they are still on track and that they can make adjustments as necessary before it is too late.

technology project risk management

“Statistically, any big IT change project has a worryingly high probability of failure,” Lacniak said. “Technology projects are particularly risky because of the number of variables, and there is often pressure to push them through quickly, even when resources like budget, staff and time are scarce.”

He added that it is important to make someone accountable for monitoring the plan in order to identify risks sooner so that there is a better chance of mitigating them before they spiral out of control. Risk managers should expect the unexpected, and mitigate the risk of delays by involving all relevant teams in this process.

Project managers also need to be honest about the project’s progress. “State what has gone well and what hasn’t,” said Drew Markham, a change management specialist at IT integrator Fordway. “Bad news up front is much better than when people are surprised by it. There may be a simple solution or a way around the problem that the team hasn’t considered.”

Markham also cautioned risk managers that finding errors is normal, and that they should be suspicious of 100% perfection rates. He said that if a company is planning to migrate multiple sites, it should plan to focus on one large site a week, with small ones around it, and avoid major migrations on Fridays when—if problems do occur—it will be more difficult to pull the necessary people in to fix them (see sidebar).

Lisa Heneghan, global head of technology, management consulting at professional services firm KPMG, said that a key factor to identifying problems early is ensuring at the outset that there is an effective governance mechanism in place.  This allows issues to be escalated and decisions to be made quickly (such as using accepted methods like the Scaled Agile Framework or “agile at scale”), while also ensuring that the project stays on track and that risk information is reported to management in real-time.

“The majority of major IT projects today are digital transformation programs and getting them right is harder than it sounds,” Heneghan said. “Our latest Harvey Nash/KPMG CIO survey found that fewer than a third of organizations have an enterprise-wide digital strategy and less than a quarter of IT leaders believe digital is being used effectively to support business strategy. Spotting the early signs that things are not working is therefore critical so that interventions and improvements can be made.”

Choosing the right product is often a bone of contention as well. Companies sometimes abdicate the responsibility for choosing the technology products that are most appropriate for their needs to “experts” that are more familiar with the technology and the associated benefits and risks. This causes two key problems, Patel said. First, if the project scope or delivery expectations are lost in translation between the implementation team and the business, the risk of failure will likely increase. Second, experience shows that bespoke solutions are often more suited to meeting the needs of the business rather than off-the-shelf solutions, which means that companies risk making a huge investment in a product that will not deliver the expected benefits.

“There is no cookie-cutter method of selecting the right solution,” he said. “In fact, there is an increased chance of failure if the selection process ignores new developments or risks over engineering a solution. For example, we sometimes see businesses being advised against cloud solutions as those advising them are unfamiliar with this option.”

End-User Understanding

Besides the technology-related risks, ignoring “soft” issues can also derail such projects. Stead said that organizations need to realize that technology projects “don’t just concern the IT department and management—other stakeholders in the company need to be informed and have a say in what is happening as the changes are going to affect them and the way they work.”

Organizations should design the solution around how people actually work to get the most out of the investment. This means involving users at every stage, from choosing equipment to testing training guides. “Users know how things actually work, what applications are crucial to daily operations, and which issues are likely to create roadblocks,” Markham said. “Without this, potential problems may not be identified until much later where they will have a greater impact.”

Employee training—ideally before the systems go live—is also a must, as is ongoing instruction and support. Whitelam said that organizations should plan for periodic post-launch training to make sure everyone is using the system in the manner intended, as new processes or policies are added, and as new employees or contractors join the company.

“Even with all the time and resources invested in training,” he said, “employees are still likely to fall back into old habits and will need ongoing support to change how they operate.”

 

More articles by »

About the Author

Neil Hodge is a U.K.-based freelance journalist and photographer.

 
 
 

Leave a reply

required

required

optional