Handover of a Program in 6 Phases

If you are leaving a program, you should consider a few things when preparing and handing over the program. Here, a 6-phase approach has proven to be the best for me, which I use again and again.

1. Preparation (as early as possible!)

  • Align with stakeholders
  • Outline Knowledge-Transfer-Plan
  • Agree budget for knowledge transfer period
  • Search for successor and receive okay on specific person from stakeholders
  • Confirm final start date of successor (adapt timeline of knowledge transfer plan)

2. On-boarding (-3 weeks)

  • Successor starts on project as additional source
  • Project assignment to be defined
  • Onboard successor following all regular administration activities as access rights, calendar invites, handover process documentation etc.
  • Introduce successor in newsletter
  • Shadowing (-2 weeks)

3. Shadowing (-2 weeks)

  • Successor is your current stand in if anyhow possible
  • Successor attends all of your meetings too
  • Successor is watching all of your core activities
  • Successor updates and amends joint knowledge transfer plan and ticks off activities

4. Re-Shadowing (-1 week)

  • Show less presence, only attend team meetings but no customer meetings
  • Be there for any help for your successor
  • Be prepared to take over some operational activities
  • Send all still incoming requests / questions to your successor

5. Backup (starts with day of handover)

  • Show less presence, only attend team meetings but no customer meetings
  • Be there for any help for your successor
  • Be prepared to take over some operational activities
  • Send all still incoming requests / questions to your successor

6. Phase Out (+1 week)

  • Process all off-boarding activities for yourself
  • Release Project Assignment
  • Be there to help your successor
  • Do not take any operation tasks anymore
  • Give a farewell party and say good bye in the newsletter.
  • Send all still incoming requests / questions to your successor
  • Leave! (+2 weeks)

Success factors for a proper handover

  • Involve customer and all stakeholder in an early stage.
  • Do not arrange processes program / stream person centric but process / accountable centric.
    • Do not be single point of contact for multiple processes yourself,
    • Instead make each of your team member accountable for one or more processes from the beginning of the engagement (Management by Objective).
  • Plan and prepare your leave as an own project itself.
  • Prepare a knowledge transfer plan which must be agreed by all stakeholders.
    • Break down knowledge transfer in granular activities (1-3 hours).
    • Ask your successor to maintain this plan and tick each closed activity off.
    • Handle this plan and update it like any other project plan.
  • Communicate your leave to whole team latest at beginning of knowledge transfer period.
  • Foresee a backup period after successful knowledge transfer of up to two weeks.
  • Define a clear handover date in knowledge transfer plan.

Have fun in your new project / program!

Agile vortex?!

Summary

Agile work or delivery is only possible if necessary decisions can always be called up. It also does not work without appropriate governance. There is huge similarity in turnaround situations of classical projects with the approach of agile projects. The focus here is on short iterations and close coordination with the customer. The introduction of agile principles should be based on this observation. Agile principles will continue to spread differently in different industries. But whoever thinks of agility about method or technology is wrong! Early results in the project and close coordination with the real customer are not method or tool results.

Agile project management does not work without appropriate governance

Agile work or delivery is only possible if necessary decisions can always be called up. In my article “Communication Principles in a Project” it is easy to see that the short time until a decision is made is extremely important. This is often slowed down or even blocked by the middle layers of management in a company. This so-called permafrost cannot comprehend the need for agility often sensibly identified by top management. Likewise, decisions necessary in the course of the project cannot be made by the senior management themselves, as are not be placed correctly with them.

Agile project management is very similar to the approach of classic projects in turnaround situations

In both cases, the focus is on short iterations and close coordination with the customer. The introduction of agile principles should be based on this observation. The classic project plan is then usually only a reference for contract-relevant delivery items. The chain of failure in projects is the customer relationship and thus the governance structure, then the tools and processes and at the latest the employee frustration. When introducing agile principles, the sequence is exactly the other way around. In my experience, the team atmosphere in project organizations can indicate a wide variety of problems at any time, and not only that “something” is wrong, but also in which project management domains (see my article SmileyPoints). It would also be interesting to use this method when introducing agile project management.

How will the agile vortex spread now?

As can be deduced from my article “Project Manager in 2030“, the agile principles will continue to spread differently in different industries. What this “agility” will look like, whether pure SCRUM, SRUM of SRCUM, Kanban, scaled agile, SAFe, LeSS, Spotify will be shaped by the customer and company environment (i.e. products, services, industry, size, etc.). Is “classic project management” dead? Certainly not, because there are certain complex (very large programs) and complicated (repetitive projects) for which classical project management will be the better alternative. Nevertheless, it makes sense for the classic project manager to make tool picking out of the agile box. But whoever associates agility with method or technology is wrong! Early results in the project and close coordination with the real customer are not method or tool results. Concepts and planning are required in both approaches. Approaches such as scaled agile approaches e.g. SAFe take this aspect particularly into account.

The challenges for product owners or project managers

The challenge for the drivers of ventures, whether product owner, project manager or program manager, will now be that they should play different instruments in different environments. Because the dogmatic orientation “we only do agile single projects” can only take place in companies that have no need for diverse interfaces and environments. The exclusive product owner or program manager will therefore rather remain the rare species. A stigmatization of the two approaches is therefore certainly not meaningful, but the combined application or simply said the agile classical project is the future. Early and constant results and close end customer coordination are the success factor in all projects.

Project planning software – everything just crap?!

Summary:
Using a project planning and control software only as a visual representation of the planning status is a waste of time. A few tips have to be followed and MS Project and Co are also very useful for project monitoring and control.

I often hear from prospective project managers, but also from experienced project managers, that a project management tool such as MS Project is not practicable. It is too complicated and the actual control is not really possible.

If you consider the following tips nothing will go wrong anymore:

  • Set in the options that MS Project or the tool of your choice will base the planning on “fixed work”.
  • The availability (hourly capacity and holidays) of resources/qualifications must be entered in the project calendar.
  • Do not set a manual date (fixed date), except project start or finish date.
  • For each task / work package, a predecessor (at least the project start milestone) and successor (at least the project end milestone) must be entered.
  • Do not enter a duration, only the effort for the task / work package.
  • Only one resource/qualification should be entered for each activity.
  • Always display the critical path in the schedule (Gantt). This must be displayed throughout the entire project duration without interruption. Otherwise there is an error, e.g. manual date set.
  • Only plan detailed for a maximum of 2-3 months in advance (resources and effort).

And the last obstacle is again and again that your company does not invest an MS Project license for you. Then get ProjectLibre as Opensource or another freeware.

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

 

Meeting Agenda

Effective meetings are always a challenge. There are many guidelines and checklist available for meetings. But up to now I have not found a good template for an effective meeting agenda.

In my daily usage I identified the need for two different agenda formats depending on the length of the meeting or better the number of agenda topics.

Having a telco I always use following simple format (in case not many topics need to be covered) since years:

INITIAL SITUATION/AUSGANGSSITUATION

  • Project status needs to be reported to steerco until Friday 12:00 CET

PREPARATION NEEDED / ERFORDERLICHE VORBEREITUNGEN (including owner)

  • Please update your work packages until Thursday 10:00 CET Server Link (ALL)
  • Please update action items status / resolution Server Link (ALL)
  • Update reporting template (ML)

AGENDA

  • Review interface issues between work packages (MW)
  • Align on action items across work packages (MW)
  • Align on Team Discussions items on project server (ML)
  • Issues and risks to be aligned on (ML)

RESULTS EXPECTED OF THE MEETING/ ERWARTETE ERGEBNISSE DES MEETINGS

  • Aligned view on the project status

NEXT STEPS AFTER THE MEETING/ NÄCHSTE SCHRITTE IM NACHGANG ZUM MEETING

  • Report to be consolidated (ML)
  • Report to be reviewed and send to steerco (MW)

 

For face2face workshops or long lasting telcos I prefer using following format also for many years:

Berlin, Hauptstr. 14-16, 1.OG, Room E1.15a, Monday 05. Feb 2018 – CMO FMO Big Picture
Goal: Common understanding of CMO and FMO Big Pictures and related activities
Approach: Time Boxing
Preparation: Presentation: Link on Server
Materials: 2 beamers, moderation suitcase
Time (CET) Topic Host Input and preparation needed / Owner Result expected / Owner  Attendees 
09:30 – 10:00 Introduction and target of meeting MW  Introduction – no preparation needed  All  All
10:00 – 10:30 CMO Picture Overall  LI  Slide deck / LI Common understanding of the CMO  All
10:30 – 10:45 Break        All
10:45 – 12:45 CMO / FMO INM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and UA
12:45 – 13:30 Lunch break in restaurant        All
13:30 – 14:15 CMO / FMO PRM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and AB
14:15 – 15:00 CMO / FMO CHM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and SE
15:00 – 15:30  CMO / FMO CFM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and ME
15:30 – 15:45 Coffee Break       All
15:45 – 16:15 CMO / FMO CPM  LI  Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS KE, CS, MA, UA and KL
 16:15 – 17:00 Wrap up and next steps  MW   Action item log updated. / MW

Work package descriptions amended. / work package owners

Steering Board Decision preparation / LI

 All

 

Project Manager in the year 2030

Summary:

Does the project manager still exist in 2030 – as we know him today? The answer in a nutshell: No. The tasks of the project managers will change in the areas of leadership, organization and project implementation.

I was tempted to take part in the German Projektmagazin’s blog parade. Because on the one hand we are talking here about a term “project manager” that has come under intense discussion (especially in the German speaking project manager community using terms project managers and project leaders slightly differentiated) and on the other hand about a period of time that is very long even for futurologists. The researchers do not believe to be capable to define changes in this time dimension.

The project manager as a term

Both parts of the word project manager are currently in great discussion as to whether they are meaningful or even contemporary. Projects as such like in BI unit of Otto are no longer seen as necessary. The (project) leader or project manager is not intended in the pure agile set. Here, leadership will be given an even more important focus than it already is today. Managers in the sense of controlling and directing will become less and less relevant due to the already visible developments.

It is problematic to give a future statement about the project manager in 2030, if already today the term as such no longer has the anchoring, as perhaps in the preceding decades. Let us dare an attempt.

Time as a yardstick

It’s 12 years till 2030. Appears long. If you think about what the world looked like 12 years ago, backwards from today 2018: There was no iPhone, no Android, no app stores, no Youtube, no Spotify, no Kindle, no Tablet, no digital full format sensor in a serial camera (to put my hobby into context). One recognizes it happens more in 10 or 12 years than one assumes. That’s why futurologists don’t calculate in years, but in weeks in order to emphasize the short-term nature and to evaluate future models and statements faster and make them more comparable. The futurologist assumes 50 weeks per year. How many weeks have passed since New Year’s Eve? Three. So less than 50 weeks to New Year. In these three weeks not many things happened according to the human feeling. In the best case, you have planned three weeks and reflected them three times. But the “cross-week” tactical themes don’t seem significant. Nevertheless, project managers, Scrum Masters or one-man companies are working on the revolutionary aspects of the future. In the next 597 weeks until the year 2030.

What will the project environment look like in 500 weeks?

What will the world look like in 500 weeks? It seems pretty certain that in 500 weeks I and 70% of the German population will no longer own a car. In 500 weeks we won’t have any smartphones anymore. In 500 weeks we will no longer be using a supermarket. In 500 weeks we will produce more electricity in our households than we consume. In 500 weeks we will eat meat bred in laboratories. In 500 weeks we will receive ears for people from the 3D printer as medical spare parts. In 500 weeks robots will support the care of elderly people. In 500 weeks, 40% of the German population will have intelligent non-medical implants. In 500 weeks …

All these endeavors – let’s call them projects here for simplicity’s sake – are accompanied by people. This is not about generating ideas, but about implementing them. The fact that the creation, definition and implementation of ideas should be close to each other in terms of personnel is supported by some and criticized by others.

Requirements for today’s project managers in 2030

What impact does this have on me and all the other project managers from 2018? The visionary project manager who drives this one idea will no longer exist. We can already see today how complex the world of work and the world as such has become. This can no longer be united by one person. So it will have to be more and more a team effort. Which is good. This naturally has an effect on the aspect of leadership. We recognize trends already in agile beginnings which do not represent however yet the end of the road. The following generations have and demand a different attitude to work. I have experienced this many times myself and already talk like my grandfathers (“The young people today”). But also this change is good, because …

“No change, no development.”
Birgit Ramlow (*1948), employee and hobby aphorist

Transformation vs. Revolution

And now a much criticized term from the business economics: Transformation. When I think in weeks and design endeavors in a manageable time frame, there are transformation aspects. It is revolutionary when we experience a complete technological or paradigm shift. The smartphone was not a revolution, but a courageous and creative combination of available technologies. The push came somewhat delayed by the apps. But even these are not a classic revolution, but a further development on another platform and therefore used by more users. Why was the smartphone ultimately perceived as revolutionary and has this outward appearance? Well, my thesis is that managers of competitors like Nokia and Siemens weren’t brave enough and didn’t listen to the market. Imagination and creativity were not lacking. Because carmakers are also being predicted the whole development today and the reactions to it are, in my opinion, too hesitant. In development periods of 4 years per real model change, i.e. 200 weeks, you can no longer act today. So what can we deduce from this for the project manager?

He will work a lot in transformation projects and will contribute to the revolution by quickly placing new projects with courageous and fast acting managers.

Company management or committees in 2030

The biggest changes will certainly be one level higher in the hierarchy (if you want to talk about it at all – today at least one level higher) required at the portfolio board, at the product owners or however a company implements strategic decision making for itself. At Otto in the product area, in the agile environment by the product owner – as a representative for the management or the portfolio board in classical project management. These committees will certainly have to meet the defined requirements even more than in my article, written in 2016, in order to enable the timing between the transformations to revolutions. And let’s be honest, in the ~ 60 weeks since this article was written, the claim is still not fulfilled. So there is a need for action.

Different demands on the project managers

Will the development depend on the type of project?

There will no longer be a project manager who can manage projects universally in all industries and project types. At least today’s challenging attitude will be less and less correct.

In the area of software development, agile approaches and hybrid mix forms will develop for large programs. A design of these hybrid forms is material for another blog post.

Investment projects will continue to be similarly organized as today. And thus also the role and tasks of the project manager. Even if today’s examples, such as Berlin Airport, are not promising.

The young project manager in 2030

But what about the young project manager who will manage projects for the first time in 2030? He starts with a handicap. Because he himself, but also his IT architects and other colleagues, will not have experienced any more “journeyman years” here in Germany, since all “journeyman activities” were already relocated from the last century nearshore or offshore in the 1990s. It will no longer be so easy to start a career as a project manager, however shaped it may be. This can be observed today in environments that have changed for some time, such as the textile industry. Here in Germany today there are often problems to find qualified seamstresses for the sample collection. For this reason, companies themselves have to relocate business-critical areas such as design and sample collection abroad. This will also be the case with the project managers of the future. In the virtual world, with the supporting technologies, it will always be easy to carry out projects here in Germany. But also the proximity to the customer is less and less important due to the virtual support technologies. This means that in 2030 it will also be possible to carry out projects completely from a remote location (including project managers) without missing customer proximity in Germany.

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!

Advantage through early warning in the project – team spirit as an indicator

– Methodical usage of emotions in the project –

Summary

As a project portfolio manager you want to avoid full blown up project audits in all of your projects to identify potential deviations. Therefore you may use a very simple survey to avoid any surprises.

As a project or program manager you want to compare your current endeavor with previous engagements in a very simple way.

There are multiple ways to gather the team morale in project teams. I am using following approach for a few years now with reliable and sound results.

There is a systematic way in doing so by gathering “SmileyPoints” via an online survey tool. Examples for free tools are kwiksurveys.com, the free version of surveymonkey.com or Google Forms.

Questions to gather in the survey

  1. “How happy are you being on the program/project?” Then the below picture should be attached to this question.
  2. “What can Program / Project Management do to improve?”
  3. “What can you do yourself do to improve?”
  4. “Rumor Box: If there are rumors around and you have any questions related to these please let us know here to clarify.”

In larger programs you may add a question to identify the participant’s team assignment to be able to give indication on the discrepancies between the different teams within the program.

The survey should be run every second week in case of a longer lasting projects or programs. It can be a good trend indication during the project life cycle. The minimum participation of project members should exceed at least 10% of all project team members. Less will not be representative. For smaller teams a higher minimum participation ratio must be achieved.

Result interpretations

The average and the standard deviation of all results of responses to question number one gives you a clear indication on the team morale within the program or project team.

The higher the standard deviation of all values to question one the more obvious are
– a lack of communication within the team
(especially from top to down and bottom to up)
– roles and responsibilities not well defined or not transparent to the team and
– the scope not well defined or not transparent – at least to the extended team

The lower the average value of the results to question one is the less attractive is the project for the team members. Therefore the enthusiasm being part of the project is lower too. In very critical project situations (e. g. work life balance not achievable due to work load) the average tends to be low.

Now the question comes up of there is a *correlation between standard deviation and average”? Not really in all instances. The standard deviation should be low in a well-organized program. In the same over-worked organization if such things as structures, roles and responsibilities, communication channels, scope are well defined and transparent to the team the standard deviation should be still low.

The next questions is what is low and what is high”? A good one! Experience shows that values between +2 and +4 as an *averageare very common for projects in good shape. Of course there is a tendency for new joiners in a project to rate their personal happiness in areas of +6 to +10. These artifacts need a critical mass of responses to balance out.

This does not support the hypothesis that a new project with new team does automatically mean a good SmileyPoint average value. The team as a whole is well observing all team quality criteria before providing their SmileyPoints and in average the rating will be again to the “real” value.

On the other end of the SmileyPoint scale low average values as -6 to -2 indicate projects which are in a turnaround mode or at least in a need to turnaround. Immediate actions need to take place.

For standard deviation following pattern can be identified. Values of 6 show massive deficit of structures implemented, missing role definitions or at least transparency on it. Criteria e) to i) from below listing do impact the standard deviation up to my experience. Programs in a good shape show a standard deviation of less than 3. 

Of course a survey like this will not replace individual talks and interviews but it gives you a very precise supporting evidence of your findings in conversation or at least an initial feeling in case you did not have any contact to the program at all.

In a next posting I will list a couple of elements and ideas on what to implement to improve the SmileyPoints in your team.

Your comments and participation to improve SmileyPoints

Use SmileyPoints actively in your projects!

Your comments and active participation are welcome. Both can be entered in the following survey and you will be informed about new findings on request.

This values shall be gathered
– average and
– standard deviations
– number of participants out of total number of team members

from some of your projects and programs. Especially helpful would be if you can add a typical auditors or your personal rating on the same scale from below on following topic clusters:
a. team morale within the extended team
b. program financials in good shape and transparent to the project management
c. infrastructure well established (e. g. printers, office space)
d. right skills on board
e. architecture and solution well defined
f. methodologies applied properly
(e. g. project planning, issue and risk management)
g. roles and responsibilities and structure well defined
h. scope and acceptance and completion criteria well defined and transparent
i. governance well defined and in place

Please use this form to submit your feedback to improve SmileyPoints.

This article was originally published on 23.07.2011 on GooglePlus.