How to prevent your digital experience project from becoming a stumbling block

Author: Boris Kraft, Magnolia

Success is something to be proud of. But not everything always goes according to plan.

I have been involved in many DX (Digital Experience) projects. What I noticed was that when mistakes were made, they were always the same. I'm using a chaotic project that is still fresh in my mind as an opportunity to point out the pitfalls. But I also reveal how these can be avoided.

Four DX project stumbling blocks (and how to avoid them)

1. ignore the project management triangle

It's amazing that project managers (or their superiors) think that they can make the impossible possible, even though they should know best. The project management triangle, known as the "triple constraint" or "iron triangle", contains three factors that determine the success of a project: Scope (features and quality), time and cost. If one parameter is changed, this has an impact on the other two.

Ambitious goals, a small budget and little time mean little room for maneuver. In principle, a project cannot optimize all three factors, but at best two. If the budget is reduced or the delivery date is brought forward, this is not possible without also reducing the scope of the project.

Too many DX projects ignore these dependencies. A good project manager knows that the increase in project scope must be accompanied by an increase in time and budget. Otherwise, factors such as overtime or burnout will drive up costs and time.

I know of a case where the entire project team of a service provider quit immediately after the site was delivered. The costs for the service provider to rebuild this team were far higher than the profits for the project.

Stay realistic. To better estimate the scope of the project, you should first define the essential components and then see if there is time and budget left for more later. Start small and build a prototype or a basic product using agile development practices. Remember, however, that agile does not mean: "Just like before, only without a project plan". Agile means that you don't know exactly what will actually be delivered. However, you know that you will have a working product after each sprint and that the most important requirements will be processed first.

2. give developers a free ride

Developers are important. Modern tools help them to be creative in the frontend and backend. However, make sure that the developers do not realize themselves, but work towards the defined goals.

I was recently called in when the management made exactly this mistake. The developers wasted a month's worth of resources on something that could have been resolved within two days with the help of manufacturer support.

Your DX project needs the right project manager. Many a DX project falls to a person who is not really qualified for it. Projects should not belong to the IT department just because they have something to do with computers, systems and infrastructure.

Important stakeholders include web and UX designers, who create the site structure, and advertisers and authors, who are responsible for content and campaigns. Don't forget the end users and the user experience you are creating for them - what are their goals, desires, frustrations and pain points. The ideal DX project owner has a clear vision from start to finish. They know exactly what kind of experience they want to create, how and why.

3. overlook critical requirements

Large DX projects challenge conventional business processes. There can be power struggles between departments. Often these are carried out as part of a large-scale digital transformation. They have two roles, reflecting the corporate strategy while maintaining the link between 'old' and 'new'.

As with any interdisciplinary project, it is important to put all requirements on the table. How big is the traffic? If you expect a big rush, then do a load test before the site goes live. This is common sense, but I know of at least one project where this step was skipped, much to the detriment of everyone involved. Also, make sure your system can handle the number of authors and editors working with it. Can the functions and processes keep up with the volume of work?

Remember that every implementation is different and your provider will give you successful projects as references, not failed ones. Your system may have been set up so badly that it is unusable. Then you need to investigate, do your own testing and enlist the vendor's expertise to set up your system correctly or optimize it for your specific needs.

Next question: how will your data structure be migrated from the old to the new system? It's not just about training your Markom team on the new CMS after using the old one for 10 years. It's also about translating hundreds of thousands of articles and images from the old system into the logic of the new one.

Harmonize your digital platforms with one another. Take the opportunity to find out which systems are really important. Unnecessary software should be phased out, existing business-critical systems should have the right support. Test the most important functions.

4. overestimate functions and specifications

DX projects often start with a long list of features and specs. Highlighting these details is ok, but keep in mind that they are not necessarily always adapted to the user's needs. There is a risk of focusing on functions that are rarely used or too complicated. Simple but necessary innovations can quickly be overlooked.

Stay in constant contact with providers and implementation partners. You may have opted for a product based on its functions, but also check whether the product is flexible enough to integrate other tools and expand functions. In the digital world, things change very quickly. Prepare your system for these changes.

When the going gets tough...

Some DX projects make you want to throw your arms up in the air in resignation and run away. The project I would most like to forget was a high-profile one. It was a test for new functions and was supposed to be the trump card up our sleeve to beat the competition. Unconventional solutions had to be found: additional budget was found, cutbacks were made and partnerships were entered into.

Many things went wrong but "all's well that ends well": all parties met the deadline, the site is alive and well and it survived traffic peaks without any problems. Yes, you can bring a chaotic project to a successful conclusion. However, it is better to prevent mistakes from the outset and thus increase the chances of a successful project!