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.
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:
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.
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.
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.
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.
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. In the mean-time, contact us for a free consultation.
