An intranet makes it so much easier to plan, drive forward, and document projects. It makes information, data, and results more easily accessible and allows them to be updated constantly.

An intranet is ideal for internal project management. This includes creating an overview and providing transparency about things planned in the project and the current processing status. What’s more, on a wiki-based intranet, the complete history of developments in the project can be thoroughly documented and made available as a co-product.

Let’s start with transparency. You may have projects that need to be kept secret or that have restricted access permissions. This applies, particularly to human resources-related or secret research and development topics. For example, customers sometimes force us to guarantee that only those employees who are actually involved in the project are allowed to access the relevant information for a customer project.

What’s important here is that an intranet system offers an option for assigning access rights for individual areas or virtual project rooms to only those who meet the actual project requirements. However, this is actually a basic requirement that all established systems meet. 

One advantage of this granular system for configuring permissions is that (unlike Wikipedia) you can document both generally accessible and sensitive information. 

We don’t actually use the wiki or our intranet for “highly sensitive” information. This runs counter to the intranet’s current goal of increasing transparency for as many employees as possible.

The wiki or intranet should only be used if the number of people who share the knowledge published there is greater than five or if you need the information to be persistent and easy to find. 

For example, we don’t upload payroll information to the intranet. On the other hand, however, the intranet does support our personnel files. This has worked much better than our supposedly practical personnel management system for a long time. In the future, I imagine we’ll use our ERP system to populate the digital personnel files in a structured manner, and that the intranet will only be used for conception, reconciliation and coordination texts, and individual applications. 

The vagueness and changeability of how these systems are used become particularly clear when it comes to project management. If, for example, you operate a portfolio board at your company to organize the distribution of resources in innovation projects of a certain size, you need structured data to be able to assess and compare the projects. This data includes: 

• How much time has gone into the project? 
• How high is the estimated total effort? 
• What income do you expect to receive in the future from the project result? 
• What monetary risks can arise if we don’t implement the project successfully (fines, collapsing sales...)? 

You don’t just want to estimate and record all these figures, you actually want to process them in a structured manner as well. They’re meant to be used as a basis for sorting, filtering, and ultimately allocating decisions regarding budgets and resources. 

Of course, a wiki-like Confluence can also record figures like these using meta-information. That said, structured systems like ERP tools or Jira are more suited to this. Perhaps you have a SAFe solution like Agile Hive or project portfolio planning software up and running. You can enter metadata like this into applications like that. 

If we want to better understand the role of a wiki-based intranet in the corporate context, just imagine that all the available software solutions are placed together like large, thick stones in a bucket (the company). The stones play a really important role when it comes to the volume of the bucket. They represent the leading systems for different applications. For financial accounting, SAP is one of the stones. (by the way, we use ERPNext, an open-source application). Salesforce might be used as a CRM system, Jira is often used for task management, etc. These thick stones play an important role. They make up a large part of the bucket’s weight. 

However, cavities also exist between the individual stones. The software systems don’t fit together seamlessly. Maybe there’s an interface here and there, but the systems still don’t intermesh 100 percent. The bucket contains air in the gaps. This is where your wiki or intranet comes into play. We can picture the wiki or intranet as sand. We can still fill the bucket with sand even when it already contains the stones. It fills the gaps. 

This is exactly how a wiki works as a basis for an intranet at our company and for many of our customers as well. It’s so versatile and easy to use that you can use it for things that your project management software can’t do very well. For example, a wiki in the area of project management can be very powerful when it comes to preparing meetings and their agendas, drawing up the minutes, and then staging the information afterward for documentation and reference purposes. It’s also just as suitable for developing concepts, sharing them, coordinating them asynchronously, and gradually adding to them. 

We usually use links as the integration between a wiki page and a structured special software application, which works quite well. Proper interfaces over APIs should certainly be used between systems containing structured data so that you don’t have to input customer master data twice, for example, and so evaluations can be carried out cleanly without any confusion or duplication. 

The task of the intranet in the area of project management is to connect the different systems and to define a specification for processes and the locations for the documentation. 

Every major project is processed and reconciled using a variety of solutions: rapid exchanges in a group chat environment, short updates to the project in the microblog, concepts, documentation, and references in the wiki, time recording, and task planning in the project management software, and controlling and budget planning in an ERP or BI system. On top of this, analog channels or channels with little or no software support exist, such as in-person meetings, telephony, video conference, or even email software. The task of the intranet is to keep all of this together and transparent. 

Of course, the people working on the projects have to learn behaviors and routines that are meaningful and desired for specific situations. For example, when is it best to use the chat software on the project? Or the microblog? What should you be documenting on the intranet? And what comes along with the task management system? This is much the same as it is in set theory. All these circles overlap, and it’s important to understand that it may make more sense to use one tool in one situation and another in a different situation. 

And yes, you’re absolutely right! It’s important to have all the information in a digital system before anything else. This is the overriding requirement for achieving transparency. And I’m like you, I’d rather have the information in the wrong place than not have it at all, or not be able to find it. That said, of course, though some blurring is allowed, even from specialists who know the systems and processes inside out, you still need to slowly but surely make sure that your employees are putting all the information in the right places. 

As I write this, the market for mobile apps and support for mobile data entry is unfortunately still pretty underdeveloped. For example, entering information in Confluence is worse than in Jira. And if there’s any doubt, a chat is the quickest solution anyway. If someone writes a message in Telegram because they just don’t have enough time or it’s too difficult to pass in Confluence or Jira, it’s no big deal for me as the person responsible for the intranet, because it doesn’t change any of the basic project processes. 

If someone constantly fails to adhere to the procedures, I’ll talk to them about it, of course. In some rare cases, we offer data transfer to other systems as a project service. However, we really only do this for very important people (board members, divisional heads, etc.) in corporate groups. In our company, which has less than 200 employees, nobody can afford to do that if they don’t want me knocking on their door very soon thereafter.

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