Child pages
  • Intranet Book: Linking Project Management and Documentation
Skip to end of metadata
Go to start of metadata

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

Of course, what’s nothing more than a “throw-away product” from project management on the wiki-based intranet certainly does not 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 hand on your heart: you don’t produce any documentation in your projects, do you? Most of 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 is going to be audited and the auditor is due on the doorstep soon. 

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 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. When it also comes to chat messages, there are usually too many of them and they are 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 there are teams who are more lax in their work. However, I usually get there in the end and have a rough overview of the project, its challenges, and its current status. It means that I am 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 is 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. And 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 where there is no information or documentation is to rule with an iron fist. It saves them having to find out 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 is any doubt, you can follow up on it with questions and comments over 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 which you would 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 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 doing my other work. However, I can’t normally cram anything else into my main working hours, and I am not very willing to set time aside without a damn good reason. This is why the iron fist rules in many places where there is no digital support. And not out of malice, but simply because there is 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 that decision, it will often be bad. 

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. However, in reality, 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 want 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. Or 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. However, 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 and 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, more decisive for the success of the project is how you react to new information that emerges over its course. 

The supplier who we are 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. Lots of 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 here is to separate text from tasks so that there is information in one place and context in another, i.e. knowledge about the project and about what has happened, so to speak. And then there is 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 is really important right now 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. And that also applies when the board of directors are only interested in the Gantt chart and not the details. Or should I say: that doesn’t apply also, but in particular. “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 submit the results of our status reports regularly. And, of course, we will also report on the likelihood of everything going wrong and what we can do to prevent it.” That would be a good approach to communication that makes sense for everyone concerned. 

However, let’s not get distracted 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 are 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). Or put in a nutshell: we manage the project, whereby some are more and others less agile. 

This is where Confluence and Jira demonstrate their great strength in their interplay: the 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. This means that they change 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:

  • No labels