Communication Principles in a Project

The first hours or at least days within a project do shape most of the ongoing communication in a project or program. In other words: if you do not or too late define communication principles in a project you will need to cope with issues in a later stage.

All soft topics like usage of mobile phones or laptops during meetings, respect between each other, listening to colleagues, confirm understanding, participation by all in meetings, avoid mails but call instead, and so on and so forth are topics which are often more easy to follow than the individual behavior in following topics. Therefore guidance should be given.

A set of my standard communication set up in projects from day 1 onwards as an example below.

 

I would like to ask you to follow these communication principles:

To minimize our mail traffic and an easier organization of our mailboxes we should agree on the following rules:

  • Only send mails towards the team members who need the information!
  • Sounds funny, meant is: avoid big distribution list without need! (same with copy!)
  • As long as we are working on drafts or on finalization of templates the drafts are only send around the nominated team
  • Often big copy distribution lists in mails are used for escalation just to be sure in case this could be needed: Please contact and inform the Program Manager respectively the needed team member before. The Stream Leads are asked to design a workaround for internal escalation handling in their streams.
  • We agree that the work of all of us is very important for this program! For that reason only mails with a critical timeline are marked as urgent.
  • Mails with a critical impact for the program content have to be marked with URG at the beginning of the subject.
  • To avoid overload the capacity of our mail server we send links where ever it is possible
  • Last but not least: Don’t bury the needed information’s in mail chains …

 

Mail naming convention

  1. All Mails have to be marked with the kind of information is given with the e-mail
  • INF: Information; an information is given to the addressees, no action required
  • ACT: Date, Action; and action is required by the addressee
  • DEL: Delivery; a required action is delivered
  • URG: urgent information’s start with this prefix
    e. g. URG: DREAM: SP01: … – see also file naming convention
  1. Mail subjects needs to include a short and clear description of the content
  2. Addressees on copy have in general no action !
  3. Escalations
    In general the escalations come up as followed:
    1. Team Members to Subproject Managers
    2. Subproject Managers to Project Management
    3. Project Management to Program Sponsor / SteercoE.G.: INF: DREAM: SP01: Mail Convention

 

Document naming convention

All documents in the program are named as followed:

  1. Date (yyyymmdd)
  2. Project Name (DREAM) and sub project number (e. g. SP01)
  3. Document name
  4. Version (drafts V 0.1 ff; finalized versions V 1.0 ff)

E.g.: 20170220_DREAM_WP01_name convention_V 0-1.doc

The four elements are separated by an underscore.

 

All documents which have been reviewed follow this naming convention:

  1. <Name of Original Document>
  2. Rev<Initials of Reviewer>
  3. Date (yyyymmdd)

z. B.: 20170220_DREAM_WP01_name convention_V 0-1_RevMW_20170307.doc

 

Steering committees and project boards – understand, shape and use

Why does the topic of committees move us as project managers? We need clear decisions for our projects in cases where our empowerment is not sufficient. Why is it often difficult to obtain these necessary decisions promptly, clearly and precisely?

For this we have to understand that there are countless terms for one and the same … and many terms are used several times in practice.

I will come to the typical problems with the committees that result from this later.

Where can we find a solution? PMI braces role descriptions and organizational structure. So we cannot be helped here. Prince2 defines the mentioned committees in detail and harmoniously with IPMA or GPM.

DIN 69901-5 defines the project board as a “superordinate body to which the project manager reports and which is available to him as a decision-making and escalation body”.
This does not really help much.

Then let’s see how the PM3 of the GPM supports us.

What are steering committees? They can align the ship’s rudder in all directions on all seas.

These steering committees are … internal and … cross-project. Patzak/Rattay defines steering committee, steering group and project advisory boards as synonyms. The task of this committee is to analyse, observe and control the selection of projects and the interrelationships between projects.

The project board is also very well defined in the Duden … in my opinion ….. Namely as the “Committee for Economic Steering”. In contrast to the steering committee, this is not about defining the general meaning of a project, but about economic observation and influence. The project board is therefore represented at the steering wheel in the car on specified roads and can decide which direction to take at which intersections.

This committee, the steering committee, can also include external partners such as important suppliers or the end customer.

The PM3 states that there are no uniform rules in the organizations how control boards should work. It therefore differs from company to company. However, a typical responsibility can be worked out. The steering committee

  • appoints the Project Manager
  • selects projects
  • stops projects
  • initiates projects and shapes the
  • sets high level targets.

The PM3 also describes typical areas of responsibility for the project board. These are

  • project progress tracking
  • to clarify conflicts and powers between line and projects
  • accept milestones and project results
  • escalation in corporate management or portfolio management and
  • possibly, if there is no separate change board, the decision of amendments.

What do we as project and program managers have to do to be successfully supported by committees? Based on my experience I will explain the most important points.

  • we need to shape these bodies by
  • integrate necessary external partners
  • attract members to the committees who are highly placed in the hierarchy
  • demand that a spokesperson for the panel be appointed
  • escalation instances and solution durations at the respective escalation stages and also to
  • agree change management process.

What prerequisites and knowledge are required in the steering committees? According to Patzak / Rattay, they must have transparency and knowledge about the corporate strategy and knowledge about the project portfolio. Otherwise, the steering committee or portfolio board cannot act sensibly.

In order to be able to use the committees properly, we must observe a few basic rules.

Children and managers have at least one thing in common. They can only remember 3 things.

In your remarks as project manager in the project board, I therefore recommend that you address

  • the most important status information
  • a decision request and
  • a wish to cooperate

to the management.

Always pay attention to formulate these core messages concisely and precisely, because since the year 2000 until today, the attention span with us humans has fallen from 12 to 8 seconds. Thanks to the new technology and the new lifestyle.

Now I come to the typical problems that have already been announced. Experiences from my projects.

Berlin. Public project. In public projects, it is often very difficult to separate the project client and the shareholders. Especially the governance organization becomes complex. Defining the requirements in such a construct is particularly difficult, as is managing changes. A “reinstatement” – this verb sounds already governmental or public – is preprogrammed here.

South Africa. A project at an energy company with several divisions, which is to standardize central processes and IT systems. Due to the sheer size of the project, several external parties are required. In large-scale projects, the project offices are often staffed by external consulting companies to underline the challenging and neutral character.

Even as the largest contractor, it can be difficult to formulate uniform committee definitions and appointments. Agreeing on maximum solution times for escalated problems at the respective escalation levels is often an impossibility, but critical to success.

Israel. Again an energy company with several subsidiaries to harmonize their procurement organizations and processes. A further problem with the committee use is the decision fixation and above all the enforcement of decisions. In the run-up to committee meetings, pre-socialised decision alternatives and decisions are often questioned or not enforced again after the meeting has taken place. Here the cultural influence is formative and steering out. Decision making can take many times longer.

Bonn. Escalation levels are not mirrored for the client and contractor, i.e. there is a different number of hierarchy levels. Problems are inevitable.
A further problem unfortunately arises from frequent statements and implementation of “an internal project must also function without LA”. How is that supposed to work?

I would like to conclude with the typical problems here.

What 3 core messages should you take with you today?

  1. We must understand the differences between the Project Board and the Steering Committee and always recognize the two types of bodies, and
  2. actively design.
  3. Feel free to contact me for active exchange.

Working Out Loud

Working Out Loud is particularly suitable for working in projects. It is not a classical method, but claims to be an attitude to life – with associated practical techniques. The elements are: Making work visible and improving it, making contributions, building social networks and working together purposefully.

Introduction to WOL

Working Out Loud is an approach from the USA, which is particularly suitable for employees in projects. The initial father of the idea was Bryce Williams. John Stepper skillfully generated a movement out of it. It is currently sloshing across the ocean and gaining new users in Germany. This attitude to life also leads to lived values which are not everyday in this combination. Austin Kleon also presents similar approaches in Show Your Work.

The five core elements of Working Out Loud are (as originally listed on workingoutloud.de):

  • Make work visible – publish intermediate results,
  • improve work – cross-connections and feedback help to continuously
  • improve your results, make generous contributions – offer help instead of self-portrayal,
  • build social networks – this is how broad interdisciplinary relationships emerge that advance,
  • work together purposefully – to exploit the full potential of the community.

The application in a company like T-Systems with parallel application of classical project management is presented.

Content are practical examples of the application, the success criteria of the approach and its hurdles in a project organization before.

Working Out Loud in a project management organization

How does an application work in a group like T-Systems using classic project management approaches? Isn’t that contradictory? Employees at ThyssenKrupp, Robert Bosch and T-Systems practice these attitudes and techniques.

„Working Out Loud“ means „publishing“ one’s own work, reporting progress, problems and mistakes and exchanging information with other colleagues so that everyone can benefit from what has been learned. So nothing new you think spontaneously?! A combined application of the core elements of the Working Out Loud approach requires discipline, openness and consistency.

How does this happen in practice in the project?

The exchange in „one’s own juice“, i.e. in one’s own project, is not enough. A first basic requirement is to approach central departments such as those responsible for tools or processes, or in the best case also other projects. Even with positions that are often not very popular, such as central quality management units, project management handbook managers or tool owners, is necessary. An intensive exchange about objectives, application and solution of the upcoming challenge is a must. I have lived this consistently for my current project in which we had to develop a degree of progress and forecast process and tool that did not correspond to the company standard due to special circumstances. Even the sharing of micro results with project colleagues who are not (directly) affected raises undreamt-of potentials. The integration of stakeholders such as clients, users and policymakers is common practice, but only partially increases the potential. Networking also outside the Group for the exchange of ideas is essential. Otherwise, the efficiency and effectiveness of every project will suffer. The process, the specification, the tool, the training and the rollout took an unprecedented three weeks. Just two months after the introduction, what had been created was then presented to the annual group-wide worldwide project manager community and defined as good practice in the sense of „making contributions to the community“. A degree never achieved before in this time span. Strictly speaking, it is not only the speed that is unusual, but also the „overall“ (apart from standard processes and tools). Working Out Loud opens new horizons and brings a fresh vitality and interactivity into and around the projects.

Even in large corporations, this „combined approach“ Working Out Loud is applicable from already known approaches and bears fruit beyond the individual project.

The author presents further practical examples of the application, the success criteria of the Working Out Loud approach and also its hurdles in a project management organization.

Active participation in „WOL with Group Security and NDA“ working group

If you would like to actively participate in a working group on „Working Out Loud with Corporate Security and NDAs“, please contact me.

Presentation

In the spirit of the WOL I have released the presentation of the PM-Forum Version 3.0 again for commenting. Thank you very much for all previous hints about Version 1.0 and 2.0!