Early warning signs during big digital change

Digital projects are complex. That said, many teams are surprised by problems that were flashing warning lights for miles. We'll cover four aspects of early warning signs during big digital change (such as redesigns, consolidation projects, and replatforming):

• The best time to avoid train wrecks is early
• What are the warning signs
• Milestones at which to be on high alert for the warning signs
• How to avoid these problems in the first place

The best time to avoid train wrecks is early

We all want to leap to implementation. After all, an advantage of the web is how easy it is to make changes. That said, just implementing and adding stuff without making sure you can do so in a high quality manner can lead to more problems than benefits. Especially for larger web presences, it's essential to course correct (or, in many cases, set the course at all) as early as possible. There's a list of places to be on lookout for warning signs later, but in general catching and correcting problems early has many advantages:

• Sometimes the way a problem is initially framed is not really addressing the root issue or business needs. If this is not faced early on then you may be marching toward fixing the wrong problem, which people may not realize until almost launching.
• Teams may not understand what they think they are agreeing to. It's easier to get aligned early rather than when the project comes to a grinding halt later.
• The way a project is conceived may not be possible to execute. It's far better to realign early than to collide with mismatched expectations later. Or reframing may still reach the same goals but with a different approach.
• A project that appears to be technical may actually have a much larger non-technical component, which may mean allocating resources differently (for example, less money going to the technical implementors). This sort of reallocation is exceedingly difficult late in the game.
• Some change should be fast, and some should be slow. Starting to take shortcuts early leads to problems later.

The warning signs, to notice impending train wrecks

There are two types of warning signs:

• decision making / expectation setting
• project management warning signs

Warning signs during decision making and discussions that are setting expectations

Expectation setting is critically important, but usually expectations are wildly different between teams (even if they are using the same buzzwords), both internal and external. This leads to major issues. With each of the issues below, don't just consider times of formal decision making but also hallway conversations that are setting expectations:

• A high buzzword ratio. Of course your new website will be responsive and undoubtedly it will be developed with an agile approach. Obviously you want to connect with your audiences and have sites that are easier to use, and you might even want to pivot quicker :-). We need to dig deeper, and latching onto buzzwords is not the way to go. I'll take a goal of projecting an organization's uniqueness (along with defining what that is) far above any buzzwords.
• Broad decisions being pushed down to the web team. On the one hand, the web team should be making the bulk of website decisions. But the broader team needs to be behind key decisions that need broad participation (the web team can't do it all!). Sometimes it may be up to the web team to articulate a proposal for the broader team to decide together, but if other teams' participation is needed then they need to be truly involved in decision making.
• Saying "yes" (even if qualified with "eventually") to a request that cannot be implemented in the near term. Whether you are on the giving or receiving end of this, it's a situation that will run into issues over the long term (see "Table of possible responses to requests" starting page 83 of Website Product Management). Everyone needs to be thinking and operating in a way that is looking more broadly and long term at change, and locking in changes far into the future does not allow responsive change.
• Any time you are describing your goals in a way that every other organization might. This is highly related to the buzzword point above, but even without buzzwords make sure you aren't writing your RFP or requirements in a way that could be copied and pasted into another organization. If you are, this is a sure fire warning sign.
• Any plan or decision that only considers one discipline or one team. However attached we are to the discipline that we associate with, we all know that a lot goes into making a digital presence a success. Any plan or decision that is too narrow has a high probability of a problem later.
• Doing the same thing again but expecting different results.

Some of the above are difficult to track. Others, such as the buzzword trap, are ones that many organization fall into but it's fairly easy to notice. That said, another key issue is knowingly moving forward with decisions we know will lead to problems later. This one is almost laughable to state, but it happens too often. See the section below on how to avoid these problems, which includes some discussion of how to illustrate the impact of decisions.

Project management warning signs

Of course all the normal project management tracking techniques are essential, but be on high alert for the following two that can result in massive issues later on:

• Day-by-day slips. As Frederick Brooks said in the classic Mythical Man Month: "Question: How does a large software project get to be one year late? Answer: One day at a time!" In today's agile development, an equivalent is sprint projected vs. actual burn rates being out of whack, along with the "we'll catch up refrain."
• Putting off important complexity. When push comes to shove, don't do the easy stuff first. Whenever you are about to do this, think carefully. See Getting the bones right and Don't defer complexity. 

When to see problems

If we look at the lifecycle of a site (and keeping in mind that earlier is better throughout), here are times to watch for the warning signs:

1. Immediately after a new site has launched, and before anyone is even remotely thinking of a redesign (when in fact nothing could be further from everyone's minds)
2. When teams decide it's better to just create new things rather than fix the framework (see Cheer or jeer? Did that slick new website help?)
3. When there is some serious discussion about big changes (whether the focus is on the platform, functionality, inflexibility in the platform, or whatever)
4. When preparing an RFP or initiating discussions with implementation partners
5. During development

One of the reasons to highlight these steps is that there are lots of opportunities to a) see a warning sign and b) deal with it far before implementation. If you are already in implementation then by all means look out for the warning signs (you could still notice an issue earlier than might occur otherwise), but be on alert early. 

How to avoid this in the first place

Obviously, even though we must always remain vigilant to the warning signs, we want to avoid problems in the first place. I see three main ways to doing this:

• Early strategy and alignment. There's really little point in expecting great results without a focused strategy and ensuring key stakeholders are aligned, but people skip this step all the time. You need to answer 1) What is important to our business? 2) Big picture — do we know how to get there? 3) Does everyone know the implication of the decisions we are making? and 4) Are we setting ourselves up for long term success? (see more on these four questions in this CMS Wire article). 
• Product thinking. Many of the warning signs above arise because the organization isn't looking at their web presence broadly and long term. That's what product thinking does and this can also be used on a day-to-day basis (you can download this flowchart). 
• Illustrating the issues. Often people don't even understand what they are agreeing to, so look for ways to illustrate issues (and, specifically for migration planning, download this flowchart about communicating concerns)