What, it’s so late already? You should have said something! Sometimes I tend to ramble on. Would you like to finally get around to talking about the procedure for your project? Unfortunately, it’s much easier to say what you shouldn't do on an intranet project than to prescribe what’s absolutely necessary. Sure, there are a few trivial things. You need a software package and all your employees need access. You have to make sure the whole thing is secure. It should be easy to import information and content into the system. So far so good. 

Something you definitely don’t need to do is meticulously plan the project using extensive Gantt charts and a deterministic approach. I come across people doing this all the time – and it almost always contributes little or nothing to their project. Instead, you and your project team should become friends with the idea of an iterative process model. A customer once told my brother, “Now I know what you mean by “agile”: it means you muddle on through. That’s what we always do on our projects.”

What more can I say? This is the way kids naturally behave every day, and it’s often the best way to go about things later in life. Don’t let anyone tell you everything can be planned. That’s rubbish. Some things are so quick and easy to implement you don’t need a plan. Others are so complex that a plan will simply distract you from the fact that the next surprise is waiting just around the corner. You and your project team should be ready to implement and accept changes. That’s an important step. 

In contrast, something I always encounter in large companies is an overwhelming penchant for theory: concepts are recorded and goals and needs are continuously collected and prioritized. Requirements are structured and classified; specifications and project road maps are drawn up. 

External agencies are sometimes assigned to moderate and organize project planning. Except one thing almost always seems to get left out: actually trying out the system and assessing it from a user standpoint. 

The problem with the lack of practical relevance is so pronounced I’m tempted to recommend that you prioritize testing the software over planning it. It’s not uncommon for a panel of up to twenty people to jointly advise on the purchase of intranet software and ultimately make a decision. Of these twenty people, you’ll find that maybe two-thirds of them have not seriously examined the software systems they have to make a decision on. Most won’t even have logged in to any of them. 

Admittedly, most providers don’t make it easy to test their software. Some don’t even provide test environments that you as a prospective customer can use productively. Sometimes they’ll only grant access credentials once you’ve finished jumping through myriad administrative hoops. However, I don’t want to talk about what others do or want here, but what’s good for your intranet project. And if there’s one thing that’s critical, it’s using the software. I can explain this in a very simple, catchy way. 

By introducing a social intranet, most companies hope to bring about changes in employee behavior. The most important elements include creating a sense of corporate culture, togetherness, and transparency and ensuring that everyone really knows what’s going on, feels at home, and has the impression they’ve arrived. If all of these factors were already addressed in a company, there would be no need to invest energy into setting up an intranet. So, something needs to be different. What exactly is that something, though? Well, if it were clear what was missing, your organization would have gone ahead and implemented it long ago. Let’s not fool ourselves: no one on the team really knows what exactly needs to be changed. 

It always makes us happy when software helps us to understand how to do something differently in a gentle and subtle manner. However, you can’t really explain to anyone how video meetings can change the way you collaborate if you’ve only ever used the phone so far. 

So, if most of the people in your company have never worked with a successful modern social intranet – how do they know what one should look like? Their opinions may be meaningless.

Of course, there’s always a slight danger that some people will fall head over heels for a certain piece of software and not be able to break away from its spell. For example, you know Word, Excel, and PowerPoint like the back of your hand and want to use them for all your projects and work-related situations in the future. The advantage is that you don’t have to learn anything new. You just carry on looking at the world through the same pair of glasses. And this is exactly what happens when you design an intranet when you’re in a purely theoretical requirements gathering mode. 

If you send your intranet team off to search for the right platform and ask them to evaluate what an intranet can do for your company, make sure they’re actively trying out as many systems as possible. Not just one; as many as they can get their hands on. And, finally, you can put three to five really good, simple, convincing systems on your shortlist that you then continue to actively work on. 

Before your twenty-person panel makes a decision, all of them should have the chance to take a sneak peek at the software of choice for at least half an hour. Unfortunately, we hardly ever experience this happening, but I believe it’s the right and most sustainable way to go. 

Defining a fixed set of requirements and telling your testers and decision-makers that the software should fulfill all of these requirements is less important. Different systems set different priorities. In my view, just diving in and finding out how the various functions and available options could create added value for your company is significantly more useful, even if this approach may not sound systematic or intuitive at first. 

Most intranet teams place too much emphasis on requirement lists and their (theoretical) levels of fulfillment. Focus on the actual physical use of the software instead! 

If you can increase the practical relevance here, you’ll be ahead of the game. Try things out. “Muddle your way through.” Get some hands-on experience with the specifics of the software and try to find out whether there’s a common denominator between the solution you’re exploring and the needs of your company. 

Never test collaboration software on your own. The more people you get involved, the more realistic the test will be. 

From my perspective, the most sensible approach is to delegate the software testing to a team or a small department of 10-50 people. I can say with confidence that a test like this will take anywhere from two to six weeks. (Most providers should allow you enough time to do this free of charge.)

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