Every major enterprise, every significant venture, and almost every groundbreaking project is accompanied by them: the sticks in the mud, doubters, admonishers, and intransigeants. Everyone who works at a company with more than fifty employees will be familiar with them. And you’ll also encounter them on your intranet project. That’s because a successful intranet changes quite a few things in an organization. You can and should have respect for this — and sometimes also be afraid of it.

The role people play who actively address challenges like this is relevant and important for a project. It has value in itself when people dare to address risks and point out problematic situations. 

At the same time, however, we need to ensure that delicate plants (and these are the ideas and innovations at the beginning) have sufficient space to grow and thrive. And this includes iterations and errors. Nothing that is revolutionary and really new works right off the bat and fits perfectly. The majority of solutions need to be tweaked so that they fit your organization well. 

I find it pretty annoying when I try something out that I think will change the microcosm that makes up the world of our company and then find out that it doesn’t work in reality. That’s pretty frustrating. And it’s neither helpful nor constructive when someone from my team who’s been standing on the sidelines the whole time shouts, “You see, I told you right from the start it wouldn’t work. We should have left well enough alone!”. 

If you identify doubters on your team, make sure you get a (digital) discussion site up and running that the entire project team and external stakeholders in the project can see. 

This is a transparent gathering place, one where concerns, problems, and risks can be voiced. Without it, the doubters will feel entitled to run around the company telling everyone what a problem they think the whole thing is. And all that does is create a mood of disaster. 

The majority of teams won’t welcome this because it distracts from the actual project plan. However, what the discussion site does represent is an effective outlet for alleged problems and a valve for those who spread them. It’s also a way of showing the project team how fertile the ground is upon which problems can thrive in the organization. 

Let us assume that you and I are planning to implement an intranet project and enter the test phase. Your company is conservative and wants to see the intranet working inside a secure infrastructure first. The problem is, your IT department doesn’t have the resources to handle the hosting and operations. So, you plan to run the platform from our data center. That’s great, we can get started immediately! You would think so. But then the objections start flooding in. Is that okay from the legal side? GDPR and the like? Does it comply with our information security policy? Is it going to work on our devices? Do we have enough bandwidth? And so on and so forth. 

We want to gather all these concerns and questions in one place and publish them in a transparent form. At our company, we use a wiki page for this internally. But you can also use a table in Google Workspace or Office 365, or simply a page on your current intranet or a file on a network drive. 

You may even be able to solve several of these problems on the side, while others will not be resolvable. If dozens of people come to you over the next few weeks with increased concerns about outsourcing the data, for example, you know you’ll probably have to include it in the project. But if the chairperson and CIO come to you and pat you on the back and praise your cloud-first strategy, then it probably doesn’t present a major risk for the project. 

This approach is also a fair one for all of those with concerns because the amount of time and effort they invest in voicing the issue across the company is directly linked to the amount of personal energy they put into it. If there’s an escalation in the concerns voiced, you can respond accordingly. But if one of the doubters simply voices their concerns to you personally in passing, you don’t need to make a big thing out of it. 

Give the skeptics an outlet to voice their reservations and document them publicly using an existing channel. 

But only react to those topics that gather momentum and have the potential to impact the project from all sides. Do not allow doubters and skeptics to become active participants in the intranet project group. Those who don’t want to try out anything new and are afraid of failing or embarrassing themselves are bad at spearheading new things that can change your workflow.

Doubters should be listened to and their doubts should be taken into account if they’re justified. As a rule, however, doubters are not good drivers of innovation. They shouldn’t be allowed to become part of the core team working on a new intranet project.

Link to this page: https://seibert.biz/intranetbookdoubters