The Worst Kind of Project: Successful Failure

High-level technology projects are often one of the most important elements of a technology leader's responsibilities. These projects advance the organization's broader strategic agenda, drive change, integrate acquisitions, or other critical tasks. They are also often subject to significant organizational scrutiny. Leaders and their teams are under constant pressure to meet the need to deliver results on time and within budgetary and scope constraints.

Historically, project and program management philosophies boiled down to variations of the “triple constraint” model, in which leaders ultimately managed the interplay between cost, schedule, and project scope. Typically, leaders could control one or two of these factors. For example, if the scope were increased and the deadline shortened, costs would likely increase. Likewise, if a quick schedule and limited budget were available, the scope would need to be carefully controlled to achieve this objective.

This line of thinking worked well to deliver projects that were technical and budgetary successes, where the planned scope was delivered within an acceptable schedule and budget. However, technical success does not always mean that a project is a true asset to the organization. Most IT leaders have experienced a “successful failure” at some point in their careers where they “checked the boxes” of the triple constraint model but delivered something that did not meet the organization's strategic objectives or failed to gain adoption. by the end user. .

Defining Successful Failure

Just like building a perfect house that the occupants hate because of the design or layout of the room, successful failures yield a correctly executed result that ultimately doesn't solve the right problem.

This breakdown usually occurs due to some combination of the following factors:

• The business problem was poorly defined or incorrectly defined, resulting in the project solving the wrong problem
• The environment and market changed during project implementation, causing the project to deliver an answer to yesterday's business problem, but not today's business problem.
• Difficulties with adopting the project outcome were not adequately considered, usually due to poor training or a variety of factors grouped under the “change management” group.
• An attractive alternative to the project was found or already existed, which allowed the end user to effectively ignore the project results
• The project was too focused on a new or “cool” technology and did not solve a useful business problem
• The project disrupts or endangers someone's livelihood, for example, by removing an important revenue stream, creating active opposition

These factors are complex and nuanced and require the majority of a leader’s focus and diligence. Assuming no one actively objects to a project charter slide crafted by your junior analyst is not the same as scrutinizing the business problem your project is solving and ensuring you are building the right solution to that problem.

Avoiding the project management quagmire

Arguably, much focus on project management is on its technical aspects, and the various project management certifications and organizations that develop different methodologies focus primarily on these details. Many IT leaders have excelled at managing complex programs, and it is easy to fall back on concerns about WBS elements, scrum masters, and issue logs rather than tackling more difficult challenges around understanding the true nature of a business problem and make difficult decisions if the environment changes and makes your otherwise successful program moot.

IT projects have the added complexity of often dealing with new or innovative technologies or vendors who present their products as a “solution” without thoroughly checking whether the implementation is targeting the right problem.

Software development and project management models have largely become a “settled science,” and it is easier than ever to find employees, partners, and vendors who execute projects proficiently, cost-effectively, and on time. As leaders, we should dedicate our time to investigating the “why” of any project we agree to tackle, regardless of how interesting the technology is or how close the budget is.

This diligence in understanding the problem is often ignored, especially if the project idea was valid at some point. This becomes even more acute as your organization moves from debating the problem to exciting and energizing discussions about “how” and “how we fund it.” Although it hasn't been stated, it's frankly a lot of fun to be involved in a complex effort, with many people eagerly contributing to discussions about how to move forward. It can be difficult to pause the momentum and examine the ground that has already been trodden. However, this is why we have leaders.

Replace the Charter with a Problem Statement and Regular Review

An effective project charter can, in fact, help identify when a project no longer meets its objectives. Still, they are often vaguely worded documents designed to check a box rather than serve a vital function. Instead of a charter, consider writing a problem statement that clearly articulates what business problem the project aims to solve. To make this process effective, regular reviews are carried out on a monthly basis, where stakeholders must advocate whether the problem statement is still valid.

To make this process even more effective, consider articulating potential environmental or market changes that would make the problem statement invalid when the document is created. For example, a large technology consolidation project could become invalid if the company is acquired or if cloud services reach a certain price point.

Assessing your project against the problem statement and these “failure modes” will identify potential “successful failure” early, while there is still time to refocus the project or reallocate resources to a higher priority. This can require a lot of maturity on the part of the leader, since you are effectively questioning and potentially stopping an effort that appears to meet all external criteria for success. However, if your problem statement is well-crafted and shared, it can serve as a “timeout indicator” rather than requiring you to spend leadership capital to pause and potentially terminate a project.

Having the management processes and leadership necessary to mitigate “successful failures” may seem defeatist, but it serves a dual purpose. Not only will you avoid spending money on an effort that is ultimately worthless, but you will also relieve your organization of supporting new systems or processes that are not delivering the expected return.

No one wants to preside over a failure, much less a successfully executed project that ends up failing in post-implementation organizational sluggishness. However, with forethought and defining the problem statement you are trying to solve, you can avoid “successful failures” and dedicate your energy and resources where they are needed most.