sinking quicksand sign
We've all experienced them: the digital experience project from hell. Here are some tips to avoid going down that path again PHOTO: Lee Haywood

Everyone loves success stories, but we’ve probably all had to manage tough digital experience projects at some point or other — projects we’d rather have said goodbye to. 

I’ve seen through many DX projects over the years, some more memorable than others, but they tend to run into the same mistakes over and over again. Fresh from wrangling through a DX project from hell, I thought I’d recap some common pitfalls and how to avoid them.

4 Common DX Project Pitfalls (and How to Avoid Them)

1. Defying the Project Management Triangle

For something so fundamental, it’s amazing how project managers (or more likely their bosses) think that they can make the impossible possible. The project management triangle, also called the triple constraint or the iron triangle, involves three factors that work in tension to determine the success of a project: scope (commonly defined as features and quality), time and cost. Changing one side of the triangle affects the others.

An ambitious scope coupled with a tight budget and tight deadline leaves you no room to maneuver. Conventional wisdom says you can only address two of the three constraints: something has to give. Budget and deadline are very real constraints, so you would typically reduce the scope of the project.

Too many DX projects suffer from ignoring the interdependency of these constraints. A strong project manager would counter any demand to increase the scope without being granted more time and/or more budget. She knows that struggling with overtime or just pushing harder has hidden costs that surface eventually, like burnout or talent drain. 

A couple of years ago, I saw a project for a large organization where the complete team walked out after the site was delivered. The cost of that easily dwarfed the project’s revenue.

Be realistic. A good way to scope the project is to start with the essentials and see if any time or budget remains for a next iteration. Start small and build a prototype or minimum viable product using agile development practices. Just keep in mind that agile doesn’t mean “do everything as before just without a project plan.” Being agile means you don’t know exactly what the project will deliver, but you do know it will work and that it will provide the most important things first.

2. Giving Developers a Free Pass

Developers are vital and state-of-the-art tools empower them to be creative on both the front-end and back-end. But don’t let the devs run off with the project. 

I know a case where management made that mistake. The devs wasted one month’s resources trying to work out something that two days of vendor support would have solved.

Make sure your DX project has a rightful owner. Many DX projects fall on people wearing the wrong hat. These projects should not be controlled by IT departments simply because they involve computers, systems and infrastructure. 

Stakeholder roles span the full canvas from specialist web and UX designers who create site structure and navigation, to marketers and writers who agonize over content and calls-to-action. And don’t forget the users of the experience you’re creating — their goals, needs, wants, frustrations, pain points. Your ideal DX project owner has a clear vision and an end-to-end view of what experience they are creating, how and why.

3. Glossing Over Critical Requirements

Large DX projects challenge conventional business processes and can generate struggles between company departments. Very often, they are undertaken as part of a wider process of digital transformation. They have a dual role to reflect and reinforce your organization’s strategy, while at the same time maintaining the connections between the “old” and the “new.”

As with any interdisciplinary project, it’s vital to get all the critical requirements on the table. What volume of traffic are you dealing with? If you’re expecting massive traffic on your DX site, do a load test long before you go live. That sounds like common sense, but I know of at least one project where this was ignored. Do the same from inside. Consider if the system will adequately support the number of authors and editors working on it. Will the features and processes scale to the level needed?

Understand that every implementation is different, and the numbers your vendor provides you with are best-case, not worst-case assumptions. In the worst case, your system is set up so poorly that you can’t work with it at all. You have to do your own testing, and utilize the expertise of the vendor to optimize the system.

How will the data structure map with the move from the old to the new system? It isn’t just about weaning your marketing communications team away from a CMS that they’ve used for over 10 years. You have to think about importing hundreds of thousands of articles and images from the old system and fitting that data into the logic of the new system.

Harmonize your digital platforms and take the opportunity to figure out the essential systems you need. You want to move away from outdated software, but also consider if there are mission-critical legacy systems you need to support. Commission a proof of concept with test implementations of the most essential functions.

4. Getting Lost in Features and Specifications

DX projects tend to start with a long wish list of features and specifications. It’s fine to get into details, but remember that specs are not necessarily based on user needs nor research. You risk having a store of redundant and over-engineered functions, and thereby miss the simple but cool innovations that make the difference.

Never stop talking to your vendors and implementation partners. You might have been attracted to their features, but more importantly, ask yourself if they give you the flexibility to integrate other tools and extend functionality. The digital space evolves very quickly and the best thing you can do is to make your systems future-ready.

Vendors might be able to shed light on and solve similar problems you’re facing that they’ve solved elsewhere. Don’t make the mistake of saying: I want the system to do this. Good vendors would answer: We understand why you want to do that, here’s how it works better. If you’re lucky, they’re thick in the process of building features that meet your needs, your feedback is taken on board and they even fast-forward the pipeline to give you what you want.

When the Going Gets Tough ...

Some DX projects you just want to walk away from and bury forever. In moments of despair, remind yourself: all things shall end. In that project I’d rather forget, the stakes were huge. It was a high-profile DX project that had the potential to expand to a whole set of digital properties. This would be a live test case for new features. It would be a calling card on competitor turf.

Unconventional problems call for unconventional solutions. Sometimes you just have to grind your teeth and do whatever it takes to get the project going: write off extra costs if they don’t hurt too much, negotiate concessions, foster partnerships in other related areas.

This story had an unhappy beginning yet a happy end — All parties managed to deliver on time and the site is alive and kicking, handling peak loads each day. So yes, it is possible to save a DX project from hell and turn it into a smashing success. But it is much easier to avoid the big mistakes from the start, and much more likely to result in a successful project!