I recently sat down for a podcast interview with Sanchit Thakur, CEO of Illuminz and host of the Illuminz Insights podcast, on the topic of large website and software projects, the ways in which they’re always trying to fail, and what actions you can take to ensure they succeed.
The reported failure rate for such projects varies by source (1, 2, 3, 4) but it’s fair to say that more than 50 percent of such projects – by virtue of expanding timeframes and budgets, underdelivery, or failing to launch outright – can be said to be “missing expectations” on delivery. More often than not, these projects are sponsored, led, and staffed by sharp, well-intentioned people. So what’s going on?
What’s going on is that at a certain scale, large software projects – and I’d include any website or technology project that deploys code with a budget of $100,000 or higher in that definition – start to take on unique dynamics, many of them counterintuitive. It’s like different laws of physics take hold. For example, increasing the number of people working on a project as launch nears typically doesn’t speed it up, but instead slows it down. If you’ve been there, you know.
The good news is that most of the problems stem from a single cause, and the actions you can take to be part of a success story rather than a cautionary tale are very effective if consistently applied.
The single biggest cause of failure for large website projects = overloading launch scope
Not surprised? That’s because you’ve likely heard this before: The path to success for a large website or web application project is to abandon the outmoded “all or nothing” single launch approach (managed via a single serialized “waterfall” process) in favor of a more evolutionary approach that includes multiple launches over time (managed via an iterative “agile” process).
But like going to the gym, this is far easier said than done. Scope creeps into a project’s initial release (called the “minimum viable product” or “MVP”) like clutter into a closet or ants onto a discarded Twinkie. If that scope overwhelms the team and project, the project starts to tip – first slowly, then all at once – into becoming the next failed website project casualty.
So, how do you avoid this outcome? Our team offers five solutions to help set you and your large website project up for success:
Solution 1: A clear commitment to post-launch evolution
A clear commitment to post-launch evolution is the single biggest predictor of long-term website project success.
This commitment mitigates stakeholder anxiety that the only two options for a potential feature are “now” or “never,” relieving pressure to overload the initial release. Does this require more budget? No. What this does require is a willingness to amortize your existing budget across several releases rather than place all your bets (and budget) on the first release.
You can still advocate for the features that make that initial release truly “viable,” and the initial release often commands a larger share of budget than the ones to follow. That said, it’s essential that you reserve a meaningful budget to yield meaningful, regular progress after the initial release.
Solution 2: Single-list prioritization
At some point as the project approaches launch, all the items competing for resources must be ranked within a single list. “All” means all, including features, bug fixes, and optimizations, so the entire stakeholder and project team can transparently see what’s getting worked on, and what items will wait for a later release. Prioritizing these items from 1 to 5 will often result in a lot of “1s” trying to get through the door at once, in which case you may need to increase the fidelity of prioritization with a larger scale.
Solution 3: Guard against phantom requirements
One type of feature that should be rigorously interrogated before it’s allowed to claim precious project resources is anything that would risk becoming a “phantom requirement.” A “phantom requirement” is a feature that the stakeholder team is convinced it will need, but after the investment is made and the feature deployed, it doesn’t get used as expected, and sometimes isn’t used at all. A close cousin of this is building a section of the website for “phantom content,” such as a feature-rich blog that ultimately only serves up a minimum of posts.
The key to avoiding such “regerts” in production is to ensure you’re building for the content (or scenario) you have, not the one you might have. Want to build that blog? Great! Let’s see if we can get several initial posts together first to prove that the content side of the operation can deliver on its promise before we spend the resources to highlight that content on the website.
Solution 4: Set aside some early goodwill capital
Large website projects are hard. They always start with a wave of excitement and optimism (and we love that stage!) but challenges always arise, and we’ve been deliberate about setting aside some of the goodwill from the former to apply to the latter.
We’re typically quite direct about this, saying something along these lines at the kickoff meeting: “We love this initial energy, and we want to remind everyone that at some point between now and launch, there will be challenge and potential frustration. It may be because a feature didn’t make it into the MVP and will have to be added post-launch. It may be an unexpected technical challenge. It may be a miscommunication or misunderstanding along the way.”
When that moment comes (and it’s a rare project that doesn’t have the unexpected “thing” crop up at some point), we call back to that early reserve of goodwill, which is usually applied at just the right time to bridge us to our next surge of excitement and enthusiasm, post launch when the new site is live.
Solution 5: Plan for common challenges
Did we mention that large website projects are hard? Things may go perfectly, but if you go into the game expecting the ball to always bounce your way, you’re likely to be knocked quickly out of bounds. The key is to architect your project plan to provide ample resilience in the face of common challenges:
- Things take longer than expected.
- The need to match your learning curve to the pace of change in technology.
- When “life happens” and you have to adapt (e.g., a key project team member leaves or gets sick).
It’s our job to expect one or more of these things to happen and then be pleasantly surprised when they don’t. I call that patrolling the edges of the project for risk. Experience doesn’t buy you the ability to eliminate risk, but it does buy you the ability to see around corners and do a good job of anticipating which risks might manifest. Even on the best days, stay vigilant and be adaptable.
Be a success story, not a statistic
You can find the full Illuminz Insights podcast interview here:
My conversation with CEO Sanchit Thakur includes other topics, but the main thread holds: With some simple best practices, you can ensure that the large website or web application project you lead doesn’t end up a failure case, but instead proves to be a resounding success story.
Need a guide to help you map your large website project?
Our Wayfinding Workshops are a great way to define your needs, assess your resources, scope your project, and create your blueprint for execution. We’d love to hear more about what you want to accomplish and share how we can help get you there.
Complete the form below or drop us a line at hello@culturefoundry.com to put your next large website project on the path to success.