… we’ve been here before. But this time it’s about something else: knowledge management in IT projects.
Recently I started a new project that has been running for a while and in which some structures and workflows have already been set and are observed more or less successfully. Fortunately, I was explicitly asked to question these structures and processes and to suggest improvements.
The first step for me, however, was to familiarise myself, understand and connect. Well, there is always a lack of time in projects, so there was no initiation – er – briefing; access to the documentation was very scattered (Sharepoint, Teams, source code management, other people’s heads, …). Accordingly, it took a little longer to get started, and I thought to myself: I could write something about that. So what would I do differently? Well, in any case, the technical and organisational parts of the project structure should be explained by an experienced team member in person. After all, a well-documented and practised structural and procedural organisation is the project’s operating system and thus an important prerequisite for the team’s performance ultimately is better than the sum of the activities of the individual team members. If this were to be communicated verbally, in the best case not only would the newcomer gain knowledge, but critical questioning would also lead to a the person explaining gaining insight.
The second major aspect and my recommendation for change is to give greater importance to the documentation of project processes and results. This works for Wikipedia after all: comparatively few people write for many. The benefits far outweigh the effort required to document. Unfortunately, this often doesn’t work so well in IT projects, and it’s rarely the fault of the tool. Yes, I know, tight budget, no time, working software over comprehensive documentation. But good documentation is also a value in itself. Namely, when you realise that an important IT competence is learning itself – and good material supports that and thus reduces the time and costs for newbies’ familiarisation.
Here you can learn a lot from open source projects: if you don’t make it easy to get started, you get less attention (in the new currency Github stars) and ultimately have a harder time. So: simplify access as much as possible and thus increase the usefulness of the documentation. Examples: make the documentation accessible at a central location, avoid binary formats if possible and use simpler tools (Asciidoc or Markdown instead of Word!). Reduce every possible obstacle that makes writing difficult, because only then will the documentation be kept up to date and users will take the time to read it – who wants to invest time in documents that are incomplete and not up to date? Professional documentation is also a characteristic of an intelligent team.
There is a lot more to say about this. But that’s it from me for today.
Just this as a conclusion for reluctant writers: “If it hurts, do it more often!“ (Wisdom probably from Martin Fowler)
Original text: MHA
English translation: BCO
Bildquellen
- archive: Pexels / Pixabay
