Many of our customers find it almost magical when they first discover that the project management module in Confluence not only helps in coordinating the project itself but that the resulting pages also form an excellent basis for documenting the project. Alone, the option to search for all the concepts, documents, files, meeting agendas, minutes, and any other key interim reports and discussions in one central location represents an enormous advantage for most companies. 

Of course, something that’s merely a “throw-away product” from project management on the wiki-based intranet certainly doesn’t represent a perfect documentation system yet. However, when a project team sits down and decides to prepare a short, readable, and detailed set of documents that contains knowledge and learning potential for the future, this “throw-away product” represents an invaluable asset for reviewing the course of the project and the relevant steps for discussion. And it goes without saying that the logs, intermediate statuses, and documents can also be linked. In fact, I can hardly emphasize this point enough. 

Now, answer truthfully: you don’t produce any documentation in your projects, do you? That’s because your projects are already a success once you’ve achieved the project goals. But don’t worry, you’re not alone in this. Many of our customers only ask for documentation if the project went badly wrong or if it’s going to be audited and the auditor is already on the doorstep. 

I don’t want to pretend otherwise. It’s the same with us too. A set of properly prepared documents that contains knowledge and lessons for the future is a rarity. And there’s no question about it: this is something we need to become better at and more disciplined in. 

Well, at least with our wiki, we have the basis for it. 

Personally, I’m more of a “jack of all trades, and master of none” at our company. This means that I often think about and study other people’s projects if someone asks me something about it or I can find enough energy to provide some assistance. Then I mostly rummage around in the wiki documents for the meetings and concepts. Also, when it comes to chat messages, there are usually too many of them and they’re too detailed for me. In Jira, there are usually too few tasks for me and they don’t have enough context. So, I only take a brief look inside. I don’t really understand most of the source code for our software. And the orientation phases for this frequently take place outside of the team members’ regular working hours, which means I can’t ask anyone. However, it still works amazingly well. 

What I like, of course, is for someone to prepare the documents for me in bite-sized chunks. There are teams who document everything extremely meticulously, and some teams are more lax in their work, but I usually get there in the end and have a rough overview of the project, its challenges, and its current status. This means that I’m really well prepared for any face-to-face discussions with the team. 

Which is What I Do When a Project Runs into Problems

Another example: if the project comes to a standstill and there’s no way forward or backward, the problem is sometimes escalated to me or other partners in the company. Usually, I receive a page that details the problem, the reasons for it, and people’s various positions on it. And often the page comes packaged with additional and very interesting and helpful information on the problem. With a little time and concentration, lots of details start to emerge that promise to be of tangible help. That said, however, I don’t know how we would manage if we didn’t have a wiki on board that people actively use. 

The almost natural reaction of managers in a situation like this in which there is no information or documentation is to rule with an iron fist. It saves them having to search for lots of boring details. In a perfect world, you should actually have all the information at hand and then ask probing questions so that the members of the project team can solve the problem themselves. Then, if there’s any doubt, you can follow up on it with questions and comments on the phone over the next few days. This doesn’t cost much in terms of energy, so there are still lots of reserves. However, you may end up using valuable meeting time during your main working hours that you'd prefer to use for important strategic tasks.

We’ve already examined the role that asynchrony plays in communication (see “When Does Synchronous Communication Make Sense?”). 

 and I’ll make it clear here once again. If I can do something on the go in passing, I might be able to complete it in addition to my other work. In general, however, I just can’t cram anything else into my main working hours, and I’m not very willing to set time aside without a damn good reason. 

This is why the iron fist rules in many places where there’s no digital support. And that’s not out of malice, but simply because there’s no other way to do it. When you don’t have time, you have to make quick decisions. And when you have to make quick decisions, you can’t take the context of that decision into account. And if you aren’t able to assess the situation and you lack the details for making a decision, that decision will often be bad. 

Of course, there may be some talented and experienced managers out there who can hit a target at a gallop without having to aim. A bit like Lucky Luke, who can shoot faster than his own shadow. In reality, though, the staff in most organizations shoot better. They have the time to aim. They draw a bead on the target and adjust and straighten their aim. They make wind calculations and a computer program validates the pre-settings. What I’m trying to say is this: in most situations, employees who have all the information and details and who are well prepared, are better suited than their bosses to making decisions, because their bosses don’t think for very long and make quick decisions based on gut feeling. To put it in a nutshell: forget Lucky Luke. He only exists in comics.

Clearly Separating Project Management and Tasks from Concepts, Reports, and Documentation 

In this context, I would like to refer to my experience with Atlassian Confluence and Jira as a whole, but I also believe that my thoughts may interest your colleagues who don’t use both systems.

Confluence is a wiki platform primarily used by teams for collaborating on all forms of text as well as for documentation and reference purposes. For example, teams can prepare meetings in Confluence and then document them afterward. Meetings of this sort almost always result in tasks that someone then has to complete. 

Let’s talk in more detail about the types of tasks that arise more or less spontaneously in this context. The completion of unplanned activities of this type plays an enormously important role in the successful completion of projects. Whether in waterfall (sequential, deterministically planned) or agile (step by step, adaptive) form, we all want to make sure we’re prepared for the future and think through the tasks we might need to face during the project. 

As part of the initial general planning, some of our customers still prepare Gantt charts to analyze how long a project will take and what major tasks need to be completed. The thing is, we all know that this type of planning will go wrong. Most people in the company are aware of that. In my view, what’s more decisive for the success of the project is how you react to new information that emerges over its course. 

The supplier we’re relying on cancels because their order books are full. The next one goes out of business in the middle of the project, so it has to be rescheduled. New requirements and detailed information crop up that result in even more tasks during the project. 

A modern intranet has to be able to grasp this world of complexities and help the people working on the project deal with them. A key requirement for me in these situations is to separate text from tasks so that there’s information in one place and context in another, i.e. knowledge about the project as well as what has happened, so to speak. And then there’s the list of tasks. 

We’ve already talked briefly about how we use WSJF for prioritization after presenting the SAFe process model. Internally, you have to think about what’s really important at this point in the project. There’s no point in blindly following a Gantt chart, which has long since become out of date anyway, if the entire project threatens to blow up in your face in a completely different place. This applies (or should I say particularly applies) when the board of directors is only interested in the Gantt chart instead of the details. 

“Dear Executive Board, would you prefer me to spare you the details and just give you regular status updates? Then I suggest that you give me the freedom to decide how to handle things myself and when to reschedule. I’ll submit the results of our status reports regularly. And, of course, we’ll also report on the likelihood of everything going wrong and how to prevent it.” 

That would be a good approach to communication that makes sense for everyone concerned. 

Let’s not get distracted, though, by the politics of the hierarchy in large corporations. Your autonomous and talented project team just wants to get on with their tasks. They analyze them. They discuss them. They comment on them. They prioritize them. They schedule them into sprints. They get evaluated with regard to their complexity and maybe even in terms of effort. Then they’re posted with the actual work steps or working times. A report is submitted on their status. The data is aggregated and summarized at the team level (or even at higher levels in the SAFe framework). In a nutshell: we manage the project, whereby some are more and others less agile. 

This is where Confluence and Jira demonstrate the great strength in their interplay: these systems support us very nicely in presenting and sharing the respective work results and interim results. On a Confluence page, you can embed what are referred to as Jira gadgets (i.e. graphical overviews at different levels of aggregation) and present them together with the content. You also have the option of embedding individual tasks or task lists from the project or its sub-projects. This information always remains dynamic, which means that it changes automatically when the source data changes. This lets you prepare project reports and overviews, for example, which are then constantly updated automatically.

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