Why Your Project’s Success Depends on a Champion, Part I

The traits of a Champion and why your project needs one. We’ve seen a lot of enterprise software projects fail and we’ve seen a lot succeed. And there’s one big difference we’ve observed between the two: The projects that succeed have a software project champion. The ones that don’t? They have a former developer, the Original Author (OA), often in an executive role, who can’t seem to let their baby grow with the times.

What exactly do we mean by “champion”?

• A Champion is also an OA, and while both can be proud that their software was responsible for driving business success, the Champion is excited that his/her software will be leveled-up into a modern technology solution, whereas the OA seems resistant to change.
• The Champion is happy to delegate every major change or software update, while the OA insists on being involved at every stage.
• The Champion is delighted that their software is being modernized, whereas the OA feels defensive that this evolution is an admission that the legacy software wasn’t so great after all.
• During meetings, the Champion provides essential domain knowledge, but the OA, often with best intentions, provides a mix of detailed expertise and subjective interpretation. A new team will struggle to separate what is essential from what is opinion. And while the Champion is excited to hear new ideas from new developers; the OA…not so much. Innovation is delicate and with an OA, it can be quickly (even unintentionally) squelched.

The OA, like most people, is programmed against change. On top of that, this individual can feel as if the new app dev team is calling the original software (their baby) ugly—and by association, the proposed, modernized solution can make the OA feel out-of-date and irrelevant.

Intellectually, the OA may indeed want a more modern software solution, but it can often create several paradoxical scenarios, including:

1. The new project is much better than the legacy software

The new solution can drive more revenue from a software vendors’ customers, but it also exposes the holes in the earlier project, including how much money was spent in keeping it up and running. The OA may resist promoting how great the new solution is. The Champion is excited that the new project will provide more business value.

2. The new project is slightly better than the legacy software

This can beg the question from the OA: Why did we rewrite the software for so little advantage? However, the Champion will advocate that even slight improvement can pave the way for a better solution in the future.

3. The new project is a failure compared to the legacy software.

Despite a bigger budget and armies of developers, the OA ends up feeling validated and can promote the project’s failure. The Champion only sees success – failure is not an option.


As a result of any of these scenarios, the OA can force the new development team to rerun their modeling process, spoiling all the fun and creativity and further inhibiting potential innovation. In some cases, the OA can end up repeating their own mistakes and diminish the quality of the project. In contrast, a project Champion supports the app dev team, stays out of their way when needed, and is their biggest fan.

Developer beware: Common obstacles from the OA

The process of creating an original software product often begins with a “discovery” mindset but from there after, it’s about conforming to that original model. The unspoken message from the OA can be to just “do it the way we’ve always done it,” which can deprive developers of the possibility of new, “out-of-the-box” thinking, learning and innovation. The Champion is ready for a fresh, new approach and actively encourages it.

Another obstacle developers can encounter is when the OA claims their technology is obsolete. He or she may feel that newer technologies, like microservices, could be the easy way to enhance the software. Another option the OA may offer is to propose an extensive rewrite of the existing code, which often creates frustration. The Champion understands that newer technology constrained by legacy software limitations creates frustration with developers and a cascade of expensive, piece-meal solutions that most of the time don’t work.

Stay tuned for more good stuff

Have you and your team ever run into these challenges? Have you encountered the OA on one of your projects? Maybe you’ve been lucky enough to have a Champion. Let us know in the comments section your experience.

In the next part of this series, we’ll share our tips (based on decades of experience) on how to get buy-in for new, out-of-the-box thinking for your software modernization projects.