What does he do? The importance of top down Journal keeping to programme communication, coordination and team spirit

This is the first in a series of articles about Programme Management.  Many of the things I am going to say apply to project management and to management in general but Programme Management is my focus.  I need to start by setting the scene. 

My experience is enterprise IT infrastructure programmes, so that’s what I will be talking about.  By Programme I mean a collection of projects with many dependencies between them.  By IT Infrastructure I mean all the common IT services that a business needs, desktops, portables, file, print, directory services, communication, collaboration and coordination services, systems management etc, you get the idea.  On my biggest programme, we had approaching 90 different server types so I won’t list them all.

Anyway onto the first topic:

“What does he do? The importance of top down Journal keeping to programme communication, coordination and team spirit”.  

Why you may ask did I pick this topic first?

·        because almost no one does it

·        because it can make a huge difference for very little cost

·        because communication and collaboration and coordination are key to any programme and journals help with all three

·        because I happen to like blogs and think they make a great tool for journal keeping

Lets look at a some of the characteristics of programmes and leadership and how journals help:

• Programmes have lots of people on them, and many more people who will be impacted by the programme.  It’s difficult to know who to communicate to and what to communicate and when, to keep everyone happy.  Blog like journals are great for this.  The more senior the person the more important so as a minimum I recommend journals for Programme Managers and Solution Architects as these are the team members responsible for stitching the whole programme together.  However, the idea cascades down the hierarchy very well.  In my model I recommend that the doer’s blog what they are doing and link to the background material that has influenced what they do, and any decisions they have taken or are trying to take.  Project managers blog the changes, status and deliverables of the project as they are produced, architects blog like a doer, but also blog change and technical debates that the rest of the team contribute to.  They link to key issues that doer’s blog about, that may affect other people in other hierarchies.
• Programmes are constantly changing, and it’s difficult to keep track of the changes, the rationale behind them and the impact of them.  Formal change logs solve these problems in a dry way but they rarely capture the background and impact in the same way as a journal does.  For example they don’t talk about the impact on morale, resources and cascade changes – especially those that come to light after a change has been approved.
• Team members rarely understand what their leaders and peers are up to, the higher up you go in the hierarchy the more confusing it is for the people below.  Too often if you ask an engineer what’s drawing on his programme managers time the answer will be “lots of meetings”.  How would the answer change if the team read the programme managers blog: “he is focussing on locking down the release schedule with the customer and reviewing the overspend on project X, and preparing for the programme review next week.  It’s been a tough week because he has to do a Customer Care course for two days and his wife is ill so he had to get home by 5:00 to look after the kids this week.  The customer is however unhappy because the they want 2 releases rather than 3, but our current position is that this is too risky and he want’s input from the team on whether we could mitigate that risk in any other way”

So you get the idea, lets be more specific about the benefits of a journal, delivered as a blog:

• Writing helps you get your thoughts straight
• You control the message, this can be very important at all levels in the hierarchy.  Often guys at the bottom rarely get to communicate with guys at the top except in 20 minute “team meetings” which are often conference calls and very much one way channels for 5 minute sanitised summaries
• You can get feedback directly and interactively
• Your audience decides how much information they want, depending on which categories they subscribe to
• The team start to pull together because when implemented top down, everyone’s understanding of each others problems and successes, constraints, frustrations etc is greatly improved
• It provides a mechanism for everyone to demonstrate their contribution/value to the programme
• It helps with the management of and identification of dependencies and change
• It’s less likely that myths – my projects “green” – will propagate up to the top without someone questioning it
• It makes it much easier to add resources to the team, or replace existing resources – they just need to read the blogs for a day to get up to speed
• You can add system generated blogs for example document check-ins. changes log updates, risk log updates.