High-profile technology projects are usually one of the most important elements of a tech leader’s responsibilities. These projects advance the broader organization’s strategic agenda, drive change, integrate acquisitions, or other critical tasks. They’re also usually subject to a significant amount of organizational scrutiny. Leaders and their teams are under constant pressure to meet the need to deliver on time, and within budgetary and scope constraints.
Historically, project and program management philosophies boiled down to variations of the “triple constraint” model, where leaders ultimately managed the interplay between project cost, timeline, and scope. Generally, leaders could control one or two of those factors. For example, if the scope were increased and timeline shortened, costs would presumably escalate. Similarly, if a fast timeline and limited budget were available, the scope would need to be carefully controlled to meet that objective.
This line of thinking worked well for delivering projects that were technical and budgetary successes, where the planned scope was delivered in an acceptable timeline and budget. However, a technical success doesn’t always mean a project is a true asset for the organization. Most IT leaders have experienced a “successful failure” at some point in their career, where they “checked the boxes” of the triple constraint model but delivered something that either didn’t meet the organization’s strategic goals or failed to gain end-user adoption.
Defining Successful Failure
Much like building a perfect house that the occupants hate due to the design or room layout, successful failures deliver a correctly-executed outcome 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 the adoption of the output of the project were not adequately considered, generally due to poor training or a variety of factors lumped into the “change management” bucket
- A compelling alternative to the project was found or already existed, which allowed the end-user to effectively ignore the outcomes of the project
- The project was too focused on a novel or “cool” technology and didn’t solve a useful business problem
- The project disrupts or jeopardizes someone’s livelihood, for example, by removing a key revenue stream, creating active opposition
These factors are complex and nuanced and require the majority of a leader’s focus and diligence. Assuming that no one actively objects to a Project Charter slide your junior analyst put together is not the same as thoroughly vetting the business problem your project is solving and ensuring that you’re building the right solution to that problem.
Avoiding the Project Management Morass
Arguably, too much focus in project management is about its technicalities, and the various project management certifications and organizations that advance different methodologies focus primarily on these details. Many IT leaders earned their stripes managing complex programs, and it’s 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 making tough calls if the environment changes and renders your otherwise-successful program moot.
IT projects have the added complexity of often dealing with new or novel technologies or vendors that have pitched their product as a “solution” without thoroughly vetting that the implementation is targeting the right problem.
Software development and project management models have largely become a “settled science,” and it’s easier than ever to find employees, partners, and vendors that will execute projects proficiently, cost-effectively, and on time. As leaders, we should spend our time digging into the “why” of any project that we agree to tackle, no matter how interesting the technology or how forthcoming the budget.
This diligence of understanding the problem often gets the short shrift, especially if the idea for the project was valid at some point. This becomes even more acute as your organization progresses from debating the problem to the exciting and energizing discussions of the “how” and “how we fund it.” While unstated, it’s frankly a lot of fun to be involved in a complex effort, with lots of people eagerly contributing to discussions on how to move forward. It can be difficult to pause the momentum and examine ground that’s already been tread. However, that’s why we have leaders.
Replace the Charter with a Problem Statement and Regular Review
An effective project charter can indeed help identify when a project is no longer meeting its objectives. Still, too often they’re vaguely worded documents done to check a box rather than serve a vital function. Rather than a charter, consider writing a problem statement that crisply articulates what business problem the project is meant to solve. To make this process effective, regular schedule reviews on a monthly basis, where stakeholders must defend whether the problem statement is still valid.
To make this process even more effective, consider articulating potential environmental or market changes that would render the problem statement invalid when the document is created. For example, a large technology consolidation project might become invalid if the company were acquired or cloud services reached a certain price point.
Evaluating your project against the problem statement and these “failure modes” will identify a potential “successful failure” early, while there is still time to redirect the project or redeploy the resources to a higher priority. This can require a great deal of maturity on the part of the leader since you are effectively questioning and potentially stopping an effort that seems to be meeting all outward criteria for success. If your problem statement was well-designed and shared however, it can serve as the “timeout indicator” rather than requiring you to expend leadership capital to pause and potentially shut down a project.
Having the management processes and leadership wherewithal to mitigate “successful failures” might seem defeatist, but it serves a dual purpose. Not only will you avoid spending money on an effort that’s ultimately not valuable, but you’ll also relieve your organization from supporting new systems or processes that aren’t delivering on their expected return.
No one wants to preside over a failure, let alone a successfully-executed project that ultimately fails in organizational slow motion post-implementation. However, with forethought and defining the problem statement you’re trying to solve, you can avoid “successful failures” and devote your energy and resources to where they’re most needed.
