Why Some Projects Succeed, And Why Some Fail

Distinguished Analyst and Research Fellow, Info-Tech Research Group. Insights and recommendations for projects, portfolios and change.

The Project Management Institute and The Agile Alliance spent over 20 years competing for project funding, certifications, training dollars and credibility. Their agreement to form The PMI Agile Alliance was announced on December 31, 2024, to the surprise of, hopefully, nobody. This move follows a long period of tension between opposing sides that had often declared at the grassroots level that they couldn’t coexist.

This seems like the right time to pause and reflect. So, let’s look back at how both the conventional Project Manager and the Agile practitioner were previously set up to fail. Let’s re-examine the absurdity of combining empowerment, matrix management and IT projects in the 1990s. Most of all, let’s look at how easy it is to compete in this new climate with virtually any project management approach.

The Pre-Project Management Software Era

The biggest oversight in this conversation, if you ask me, is to ignore how things worked in the 1980s. Simply put, workers were supervised and told what to do. We had lots of input, but at the end of the day, our supervisors decided what we did. In my case, I got work orders in my very own plastic tray, stacked deliberately so I could simply pick the next one on the pile.

How to build mainframe software? That was up to me. What to build? That was up to my boss and the SVP who owned the product we supported.

Sadly, IT wasn’t all that popular with the business, which viewed us as a bottleneck to their success.

The Perfect Storm That Sunk Projects

Looking back, it’s difficult to process that this all happened in one move in the mid-1990s:

1. Project management software went mainstream with products like Harvard Project Manager and Primavera. Scientific processes were introduced for forecasting resource capacity, allocating personnel to projects, assigning tasks with estimated effort and balancing the workload amongst multiple people. The waste in 1980s projects was to be eliminated through careful planning, improved design specificity and managing the humans to stay on task while avoiding interruptions.

2. Knowledge workers were empowered to transform into self-directed professionals and set their own priorities. Supervisory positions were eliminated.

3. Matrix management became the dominant driver of organizational structure, as the IT worker floated between assignments from potentially anywhere in the company.

We added project management science, gave the worker too much to do and told them to self-manage. Is it any surprise that our efforts were misaligned? The resultant leadership vacuum was filled with 30 years of software tools, training and methodologies attempting to overcome the fact that real project work had become inherently optional.

I’ve asked hundreds of IT leaders, “Who gets in trouble if you approve too much work?” It’s been decades of the same answer: Nobody.

Before empowerment, executives were accountable for reconciling supply and demand for project workers—they could add people or decline projects. By the mid-1990s the worker was empowered—they could either work more hours for free or underperform. So, I’m over-stepping the false dichotomy baked into the Agile-Waterfall debate because both sides succeed and fail based on the same drivers.

Sponsorship And Resourcing

A lot of IT departments are struggling with today’s reality of having too much work and not enough people. They’ve had PMO’s, they’ve gone Agile and many are trying to get back to a product-driven paradigm. They’ve tried inspiring the worker to focus on certain assignments and avoid distractions. But at the end of the day, most modern IT departments are struggling with their inability to deliver on projects.

Underneath the impassioned debate between the old school project model and the new age Agile model lies the reality that both approaches failed for the same reason: insufficient sponsorship and resourcing.

The resourcing part of the argument is easy to see when projects are approved without a design, business case or staffing. If we don’t know what we’re building, I doubt we know who should build it.

And the sponsorship part of the argument is even more self-evident when projects are approved without a business case. Somebody senior enough approved the project without forecasted costs or benefits. Sponsors are clearly not accountable for ROI they’ve never articulated.

These portfolios are filled with approved-but-unstarted projects, yet the central focus of leadership is getting even more projects approved.

The Silent Success Of Resolving Ambiguity

Behind the scenes, we see a silent minority enjoying the peaceful delivery of successful projects, while their competitors fail. These organizations did not invent a new methodology, and they aren’t working their people to death. Some are Agile, and some do more traditional planning—it doesn’t seem to matter. They succeed because they have real sponsors and enough of the right people.

Real sponsors don’t just approve projects and cheer for success. They take ownership of the forecasted spend, accountability for the predicted outcomes and personal responsibility for the experience of the personnel doing the work. Genuine project sponsors are terrified of project failure because it is a genuine career threat—they do everything in their power to succeed.

A properly sponsored project has costs, outcomes and timelines that are seen as realistic. Therefore, a properly sponsored project has the people needed to get the work done on time. This works with deterministically planned projects, and it works just as well with Agile.

This should seem like an oddly simplified argument—sponsorship and resourcing make the project succeed. But you can prove it to yourself by looking at the contra argument: How are your projects that were approved without requirements, designs, costs, benefits and resourcing?

Conclusion

Make sponsors genuinely accountable, and they’ll ensure they have the right people to deliver on what they promised. Don’t embrace ambiguity—resolve it.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?