Easy in theory, difficult in practice

My musings on project management, project portfolio management and change management.
I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success.
This blog contains articles which I've previously written and published as well as new content.

The essence of project work is uncertainty, and much as we say that we thrive on variety and change, our teams face multiple challenges on a daily basis. A certain amount of venting on the part of team members is bound to happen over a project’s lifetime, but when blowing off steam becomes the norm instead of the exception, and the majority of the complaining is purely negative, it can start to suck the energy out of the entire team.

While most project managers might feel this is the lowest priority of the issues they will have to manage each day, negativity is contagious, and one team member’s chronic complaining will eventually infect others with this behavior and will irritate the remaining ones – in both cases, productivity gets impacted.

Even more corrosive is when the project manager exhibits such behavior. While most project managers are likely to feel that they don’t possess sufficient formal authority over their projects or team members, they do wield enough influence that their negativity is likely to rub off and impact the productivity of the overall team.

Don’t get me wrong – I’m not advocating that everyone on the project has to join hands and sing Kumbaya in spite of how well or poorly things are going. There ARE going to be issues, some of which cannot be resolved optimally, but what we can control is how we choose to handle these situations.

The book The No Complaining Rule is written around a parable to provide practical approaches on how to tackle the issue of workplace negativity, and while most of the techniques provided by the author are intended to be applied individually or at an organization-wide level, there’s no reason why they can’t be adapted for use at a team level as well.

One way is to institute a No Complaining day each week – team members (including you, Mr. or Mrs. Project Manager!) who complain without providing solutions or without qualifying complaints with positive thought or action are charged a nominal penalty. The paid amounts will be saved up and used to fund team celebrations or a charitable donation. Once the team is able to successfully handle one day a week without complaining, increase it to be one week each month, and so on.

If the team is already in the grip of negativity, it can be hard for someone who is as close to it as the project manager to identify, but if metrics such as work item completion velocity are being calculated and tracked on a regular basis, it should be possible to identify productivity declines. The project manager should also practice active listening with stakeholders or the customer to see if they are becoming keenly aware of the project being a never ending “whine & cheese” party. Finally, it may be worth inviting peer project managers to sit in on the occasional status meeting – not being directly involved they may be able to pick up on such issues.

To plagiarize (and misquote) a famous Jedi Master: Negativity is the path to the project dark side. Negativity leads to stress. Stress leads to reduced productivity. Reduced productivity leads to project failure.

Culture (organization & team) and enterprise environmental factors all influence how a project gets managed but personal style and approach also plays a critical role. Within the constraints of the previous factors a project might be managed successfully but the degree of efficiency can vary widely between project managers.

It might not be advisable to invest a lot of effort in analyzing how we are adapting and executing each of the PMBOK processes, but we can lean (pun fully intended) on process excellence to help us identify common sources of project management waste.

Waiting: While we might complain frequently about how long they have to wait for others to approve deliverables, make decisions or complete in scope activities, how many times have we introduced unnecessary delays by avoiding conflict with a team member, procrastinating on having a difficult conversation with a key stakeholder or escalating an action or issue that was impeding our team’s progress? Do you always start and end your meetings on time?

Over-production: Do you print out copies of reference materials for all team members prior to team meetings? How many of these copies actually get referred to? How about reports for executive presentations? Are team members having to produce different status reports for you and their own functional managers?

Rework: Do you encourage your team members to ensure they are balancing quality with speed or is the message they are receiving that you are only interested in having deliverables out on time? Are you giving yourself sufficient time when updating forecasts or putting together proposals so that refinement is minimized?

Motion: Do you encourage virtual participation to avoid unnecessary travel when physical presence is not required to achieve a meeting’s objectives? Are you or your team members printing unnecessary materials and losing time in going back and forth from the printer?

(Over) Processing: How often are you guilty of staring at an e-mail message, presentation or report and tweaking it over and over again. Communication does consume most of a project manager’s day, but are you gold-plating your communications?

(Waste of) Intellect: Are you getting the best out of your team members (and yourself) or do you bog them down with low-value, soul-draining administrative tasks?

Inventory: Is your work breakdown structure decomposed sufficiently that work-in-progress is minimized? Have you leveraged tools such as Kanban boards to visually identify task inventory backlogs?

Transportation: Have you assessed the end-to-end flow of activities from requirements through to completed deliverables to ensure that time isn’t lost in unnecessary transportation? Do you still insist on “wet” signatures when e-mail approvals might suffice?

Is your approach to managing projects as efficient as it could be, or are you stuck in a WORMPIIT?

I was asked to facilitate a lessons learned session for a program team using a retrospective format. After the team had brainstormed, prioritized and discussed most of the challenges they had faced, it became clear to them that there were only a couple of root causes for most of the main pain points they had identified. Neither of those root causes was a true learning but rather they were just simple reminders of good practices to follow for large, complex programs. I then asked them the somewhat rhetorical question: "Remembering now what should have been done then, how will you ensure that this doesn't happen on a future program?"

A project team I've been working with has struggled with judging how many work items they can successfully complete within a sprint. In the retrospective for their last sprint, they identified a number of simple, effective ideas for resolving this chronic concern. Again, I challenged them with the same question: "You've come up with a great list of ideas, but how will you ensure that you actually act on those the next time you are sprint planning?"

Both of these experiences reminded me of how difficult it is to break habits.

In his book The Power of Habit, Charles Duhigg has written about the three part neurological loop governing habits which was discovered by MIT researchers: a cue, a routine and a reward.

In the project team's case, the routine has been to accept more work items than they can complete in a sprint even when historical evidence shows this tactic hasn't worked out well. The cue is that moment in the sprint planning ceremony when the team makes their sprint forecast. It's hard to say what the reward has been but perhaps it's the temporary high which comes when we take on a significant challenge as a team.

To break habits, we need to find a way to substitute a different routine for the old one and soliciting the help of a close, trusted colleague might be one way to do this.

The team could designate a single individual to come to the sprint planning ceremony with a stuffed pig or some other visual gag which represents gluttony. Then, when the team is about to forecast how much they will accept in the sprint, that team member could hold up the pig and say "Oink! Oink!" to remind all of them to be a little more conservative. While the team might not bask in the short term glow of having accepted a bloated sprint forecast, they will enjoy the much more rewarding experience during their sprint review when the product owner and other stakeholders congratulate them for improving their predictability.

Breaking habits is hard to do but by identifying cues and implementing good routines to swap in for the old ones, we can prevail.

When I first started to manage projects, I had envisioned the role as being similar to that of an orchestra conductor – while not being directly responsible for playing specific instruments, possessing familiarity with the strengths and weaknesses of each, and being instrumental (pun intended) in creating harmonious melodies instead of raucous cacophonies.

This illusion rapidly dissipated after a few days on the job. I came to realize that project managers need to be like Lon Chaney – the man of a thousand faces. Here are a few of the roles that a PM might be called on to play in a typical project.

1. Salesperson – Successful PMs need to be able to create a need for and “sell” their customers, stakeholders and team members on decisions or recommendations that may not be popular.

2. Football lineman – A PM must often be the offensive lineman preventing their “quarterbacks” (a.k.a. team members) from getting tackled by distractions.

3. Coach – Vince Lombardi nailed the essence of effective project management with his quote “Coaches who can outline plays on a black board are a dime a dozen. The ones who win get inside their player and motivate.”

4. Diplomat – PMs are often called upon to help resolve conflicts, negotiate for win-win outcomes and to deliver bad news in a constructive fashion.

5. Historian – PMs should be able to review the past life of their projects, analyze events and derive lessons that can be applicable to future projects.

6. Diagnostician – PMs require the analytical ability and perspective to look beyond symptoms to help identify the root issues that are plaguing their projects.

My guess is that there are probably a hundred other roles that could be part of this list – how many can you add?

(Note: I was wearing my blogger hat in November 2010 when this article was originally published on kbondale.wordpress.com)

After observing the frenzied shoppers competing with one another at Black Friday sales this week, one might be forgiven for forgetting that Thanksgiving was originally about expressing gratitude.

The Scrum Guide doesn't specifically identify expressions of appreciation as a key ingredient of sprint retrospectives, but it does list activities which can incorporate appreciation such as the inspection of team member interactions and the role of the Scrum Master in encouraging the team to not only be more effective but to also have a more enjoyable time in the next sprint.

Retrospective facilitators often encourage participants to identify what went well or what they liked. This provides a good opportunity for team members to appreciate the efforts of others during the past sprint in a genuine, heartfelt manner.

Similar to identifying opportunities for improvement, team members should not only recognize big accomplishments but also small ones which can add up over time. We are quick to recognize a team member who dropped what they were doing to help us out for a couple of hours on a really tricky issue, but how about that team member who took us out for a coffee because they happened to notice that we seemed to be particularly stressed on a given day?

Just as with providing constructive feedback, we shouldn't wait for an upcoming retrospective to recognize one another, but this ceremony provides a good opportunity to provide belated thanks to those whose efforts made a difference over the past sprint. A Scrum Master might introduce this practice in one retrospective using chocolates or some other small gift to be given by team members to those whom they wish to recognize. In subsequent retrospectives, the team can identify novel ways to do this to keep the practice fresh.

Anyone who has participated in or initiated a "pay it forward" chain would likely agree with the article's author. When someone verbally appreciates what we do, we feel an urge to do likewise. Expressing positive sentiments to one another on a regular basis might incrementally improve culture within our teams, our departments and eventually our overall organization.