This article talks about why decision‐making needs to be conscious in large digital projects. In it, we look at what can go wrong if you don’t address it early. And also why your company’s objections are imaginary.
Before we get into this, it is important that you understand that redeveloping a website in a large corporation is not the comparatively simple thing that smaller businesses deal with. It’s a big deal because it introduces major culture shifts and new ways of doing things. In so doing, it is a thing to be challenged, an additional task for many people, and its importance is underestimated.
Often, there is a great excitement at the prospect of things like new websites. People get excited about the possibilities of greater engagement. Newer technologies allow for faster representation of information, greater responsiveness, and far better branding. They get so excited that they overlook an assessment about whether that tech is even possible.
The usual methodology is:
- Consultants are brought in
- Basic audits conducted
- Users quizzed
- Information architectures developed
- Wireframes done.
Have you noticed what’s missing?
While this is the common way forward, it is not a good way forward. There are key elements that get missed. One of them is governance of the end‐product; more worrying is governance of the project. So, too, is risk and decision‐making, or change management.
The development of other important things like workflows, taxonomy, envisioned content re‐use strategies, and much more are missing. People leap into wireframing after doing very basic architecture work — and they often don’t bring a strategist in to help them.
Problems start to emerge when work commences
As you get into projects like this, you find that:
- Change management is overlooked, resulting in resistance to proposed outcomes
- Executive support is given but not visible to the company as a whole, resulting in project team stress
- Knowledge management is behind (or, worse, not in place at all)… resulting in more time in research, conversation and definition.
Even worse is when the new architecture seems great, but because no content specialists worked on the architecture, it billows out like it is being filled with a gentle breath of wind. The ‘new’ architecture may seem lean and functional, but because of an absence of workflow mapping, business process mapping, and decision‐planning, it gets bigger… and bigger… and bigger.
Because subject matter experts understand the concept, but not the reality, as content is crafted they default to what they know. And what they know is the previous website. Most people don’t get it until they can see it, which is why they always want to work with things ‘on the website page’.
Then, because the project’s content side did not have a written governance structure to begin with, it gets delayed. Subject matter experts are not effectively briefed or worked with enough, and start to resist changing what — to them — worked so well in the past. ‘Change management’ becomes a topic but is not part of the process. Possibly those who are managing the input of other teams are not skilled in managing change.
They may also not be skilled enough to manage complex publishing workflows.
You need to understand the complexity of publishing workflow to deliver large‐scale projects on time.
This is partly why editors make excellent content strategists. They understand the workflow, how to get content and reviews from people on time, and how to work with knowledge and change. It is an extremely overlooked skill — which is why the job is often relegated to the rank and file administration teams.
Getting material out of the hands of other people is difficult. It’s why deciding how to make decisions at the start is so necessary.
It is important that decision‐making is conscious.
There are some things we do all the time and therefore tend to use ‘everyday’ logic to do them in projects. Decision‐making is one of them. Within a large corporation, it is critical that decision‐making and governance is documented. Not just for the project’s end result, but for the project itself.
We’re talking about things like:
- Whose version is used if reviews are not delivered on time?
- Whose decisions take precedence in difficult situations?
- What is the ideal pathway, and what is the necessary decision pathway if time gets tight?
- Who has authority to make decisions about which topics, and why?
- Who is responsible for which decisions?
- Who is accountable for which decisions?
- How do timelines affect decisions that are made, and how does the process change (if at all) in different situations?
This might all seem a little bit crazy to you if you haven’t worked on digital projects in large companies. But if you have, you will see the value of documenting this stuff.
The most critical decision to document is the one that says what happens to content if deadlines that other people or teams are responsible for is not met? It might seem brutal to you, but we advocate a one‐chance only accountability model. If you are responsible for it, and you don’t deliver, then the content goes in without your commentary.
We do the same thing for small companies as for large ones. For example, in managing the content creation for a small project, if you don’t deliver promised material by X date, whatever we create goes in its place.
Get agreement in the beginning… because it saves pain!
When you gain agreement on these things at the beginning of the project, it saves you a lot of stress, worry, and time. It also means that you have a protocol that enables you to hit deadlines and deliver projects on time, every single time.
If you leave it, then when you are in the final weeks of dealing with content review, project risks start to surface. It’s the wrong time to find these. If you are in the situation where elements are only just being discovered as project risk — and you’re within 10 days of a deadline — there is an extremely good chance that the foundation of the entire project is shaky.
More to the point, there’s a good chance that you will end up working like a maniac to deliver it, and will launch with an inferior product.
Define your risks in planning and analysis phase. Know what they are, intimately. Know what you can and will do to avoid them, and work smartly. Occasionally, take the time to think about how far you are from hitting one of those risks, and identify potential impediments before they turn into roadblocks.
But my company/organisation could never do that!
An extremely common objection is that this type of process is not possible because of culture/process/nature of the business/nature of the people/[insert other reason here].
It’s not true. All companies can do this — and when they do, positive change happens. The ones that can’t don’t value the project enough to invest the time to get it right.
The objection is most commonly raised because of one of the following:
- The project team is not supported at an executive level
- The project team is not given the right authority — or not backed up with support afterwards
- Change management is not on the table
- Governance discussions have not been held
- Initial planning, workshopping, and risk was incomplete
- People are scared (see the point about change management).
Very often, the lack of project governance and risk, and lack of change management are the key issues resulting in resistance. The only way around that is to get executive buy‐in. And real buy‐in! The provision of a budget is not the same as having real executive support. Real buy‐in is hands‐on, involved in decision‐making and risk, and overtly supportive.
People avoid the hard thinking in the start because it’s not sexy. It is also the only way to do the work right, with minimal pain, and to prevent both project delays and budget blow‐outs. When the latter happens, resistance to proper form next time is increased, and digital is put in the too‐hard basket: Something that you just can’t afford.