Easy in theory, difficult in practice

You might assume that a television show which portrays the transformation of Mr. Chips into Scarface would provide more relevance to the logic of paying high school teachers as opposed to being a source of useful lessons for project managers. Hopefully I can correct you of that assumption!

**SPOILER ALERT** I hope that any reader who has interest in Breaking Bad is already aware of how the show ends, but if not, spoilers are going to be discussed!

In no particular order, here are a few lessons from the story as well as from how the show itself was made.

“Are we in the meth business or the money business?” – Walter White originally started breaking bad as a means to provide for his family after his lung cancer diagnosis, but somewhere along the way, his objectives significantly changed. You might argue with me that there was always a little bad guy within him waiting to get out, but his original intentions were driven by necessity and opportunity. If there is a major shift in a project’s vision, make sure that you work with your project sponsor to help your key stakeholders and team members understand the rationale for the change and what it will mean to them.

“Would you just, for once, stop working me?” – The relationship between Walt and Jesse Pinkman is one of the most fascinating aspects of the show. Walt appears to goes out of his way to protect and promote Jesse, but it is all done to further his agenda. Jesse frequently recognizes that he is being used, but goes along with it to get the recognition and attention from someone whom he considers almost a surrogate father. Project managers often wield a great deal of influence over team members and stakeholders, but there’s a very fine line between influencing someone to do what’s in the best interests of the project, and working them to satisfy your own ego or a personal agenda.

“So, you're chasing around a fly, and in your world I'm the idiot.” – One of the more amusing episodes of the series takes place during Season 3 when Walt’s chronic insomnia causes him to obsess about the risk of contamination from a single housefly which has entered the meth super lab. His attempts to remove the “contaminant” result in physical injury to him as well as almost maiming Jesse. Tunnel vision can often occur to us on high stress projects – we lose focus on the big picture and begin to obsess on minutiae. This is when having a trusted impartial observer can help to set us straight – so long as we are willing to listen to them!

“We're just getting started. Nothing stops this train." – The episode Dead Freight from the final season provides a great example of how a project which appears to be right on track can go horribly wrong if basic expectations for behavior have not been established with team members in advance. After Walt and his crew had successfully pulled off the methylamine heist in almost perfect fashion, Todd Alquist kills an innocent kid who most likely had not even witnessed anything incriminating. Had Walt done a better job of setting his expectations with his team members for handling such unforeseen surprises, things might have gone differently.

“W.W. I mean, who do you figure that is, y'know? Woodrow Wilson? Willy Wonka? Walter White?” “Heh. You got me.” – Midway through the fifth season, Walt learns his cancer has returned, but having achieved his financial goals is ready to live out his remaining days in peace. Unfortunately, his mistake of not disposing the copy of Walt Whitman’s Leaves of Grass which had been personalized by Gale Boetticher gives his brother-in-law, Hank, the final puzzle piece he needs to connect Walt to the meth empire. While I had indicated in an earlier lesson that obsession is dangerous, a lack of attention to detail can also introduce risk into projects.

“Sell off what we have and then...well, then I guess I'm done.” – Vince Gilligan knew he had a hit on his hands with Breaking Bad after the first season aired and he could have tried to keep milking the cash cow well beyond the fifth and final season. However, having spent several years writing for The X-Files, Gilligan was also well aware of the dangers of a show “jumping the shark”. Ignoring or encouraging gold-plating or other attempts to increase scope might appear to be harmless and in the best interests of the project customer, especially when you are ahead of schedule or below budget, but it’s not the project manager’s place to make such a decision.

To use one of Mike Ehrmantraut’s great quotes, if you ignore these lessons, someone may eventually say to you “If you'd done your job, known your place, we’d all be fine right now!”

(Note: this article was originally written and published by me in January 2014 on Projecttimes.com)

Patrick Lencioni’s book The Three Signs of a Miserable Job is an easy-to-read parable covering key sources of employee disengagement and what can be done to eliminate them.

The book takes the functional manager’s view – Lencioni states on his web-site “The primary source of job misery and the potential cure for that misery resides in the hands of one individual - the direct manager”. For staff working in a matrix organization, a significant proportion of their effort is spent on projects, hence Lencioni’s recommendations should be adapted for use by project managers as well.

The three signs that Lencioni identifies are irrelevance, inability to self-measure performance or success (or as Lencioni’s puts it, “immeasurement”) and anonymity. Let’s review some ways in which project managers can reduce these sources of misery.

Unless we are sociopaths, we want to know that the work we are doing is making a difference to someone, somewhere – without that we feel irrelevant. Projects are a medium for generating value through change, and if that change is expected to positively impact some stakeholder community, then that is something to feel good about.

Project managers should always ensure that their team understand the benefits of the work they are doing. This should start as early as the project kick-off meeting but that should not be where it ends. If the project manager can solicit periodic visits by representatives from stakeholder groups to talk to the team it can help to revitalize stress-dampened spirits.

Regular recognition of a team member’s efforts is important, but a generic “keep up the good work” is no substitute for one’s ability to quantify the progress they are making for themselves. As Lencioni explains, this is one of the benefits that salespeople enjoy – they have a very quantitative method of assessing if they are succeeding! For those of us whose days are spent in a never-ending stream of meetings without producing or selling anything tangible, self-assessment can be a little more challenging.

Projects provide an excellent opportunity to avoid this source of misery. By defining and completing a backlog of work items, team members are able to quantify their own progress. While this is not the primary rationale for scope decomposition, project managers could use this as part of their “sales pitch” to convince team members that this is a necessary practice. This is also the rationale behind the agile practice of using sprints or iterations – it is a lot easier to assess progress against work items that can be completed within one sprint than it is against activities that span multiple weeks or months.

Employees want to be recognized as individuals.

The ubiquitous use of the term “resource” should be banned – it furthers perceptions that team members are a fungible commodity. We may only work with assigned staff for a brief span of time, but it is in our projects’ best interests for us to get to know them as more than just a set of initials on a Gantt chart activity line.

It is a good practice for project managers to meet with team members as they are assigned to a project to review their work assignments and to set expectations for expected performance. This also provides a great opportunity to learn something unique about the team member and to share something unique about yourself with them.

Other opportunities for avoiding anonymity could be to start your team meetings by having someone talk about something interesting they did over the previous weekend. You could facilitate a team building exercise to identify team members based on a unique attribute, behavior or experience.

If you can demonstrate to your team members that you recognize and respect them as unique individuals, help them understand how the work they are performing matters and help them measure their own performance, you may realize John Quincy Adams’ quote “If your actions inspire others to dream more, learn more, do more and become more, you are a leader.”

(Note: this article was originally written and published by me in December 2012 on Projecttimes.com)

“Plus ça change, plus c’est la même chose”

Jean-Baptiste Alphonse Karr’s warning reminds us that it is very easy to ignore the Manifesto for Agile Software Development’s value statements.

We might have done away with heavy project governance, premature or excessive planning, and documentation for documentation’s sake, but if we don’t remind ourselves why our team performs specific agile ceremonies, we are no better than our brethren toiling under the burden of traditional, one size fits all delivery practices.

Let’s start with sprints. Short time horizons should focus our efforts towards delivering value early and regularly while having fixed time boxes enables forecasting when we should be able to complete a release.

But if we start treating sprints as phases (e.g. development, testing) or we batch work items within sprints in a waterfall manner, we haven’t really gained benefits from this approach. Similarly, if we don’t respect sprint end dates or we regularly modify the duration of our sprints we can’t forecast effectively.

How about your daily standups or scrums?

These are meant to serve as micro-planning opportunities to align team members towards accomplishing sprint goals. They also provide an opportunity to surface blockers in a transparent, safe fashion to ensure these get resolved in an efficient and effective manner.

But if team members are absent, we don’t start or end on time, one person monopolizes the discussion, or they turn into status meetings, why hold them at all?

Velocity enables teams to assess their throughput sprint over sprint. Used correctly and with the right underlying discipline on work sizing and backlog management, velocity can help a team forecast.

But obsessing over velocity is as bad as focusing on percentage work complete in traditional approaches. When abused velocity leads to progressively reducing quality, erosion of team morale and unhealthy comparisons between team members or teams.

Showcases or demoes give a regular opportunity for key stakeholders to view what has been completed, to provide feedback to ensure that what is delivered meets customer needs, to maintain sponsor commitment and to provide a forum for visible recognition of the team’s hard work.

But holding these ceremonies when there is nothing meaningful to demonstrate provides limited benefit to the invitees. Having the agile lead or other team member be the only person conducting the demoes doesn’t give everyone a chance to have their day of glory. And having team members get defensive when constructive feedback is provided about a feature which doesn’t quite hit the mark is just going to further the gap between the delivery team and the customer.

“Meet the new boss, same as the old boss” – Pete Townshend (Sante - that's a 70's reference, just for you!)

(Note: this article was originally written and published by me in May 2017 on my personal blog kbondale.wordpress.com)

You thought that this day would never come - the scope of your project has been delivered and you are ready to close out the project. Your team breathes a sigh of relief and looks forward to some well earned time off. Unfortunately, the project closeout phase can sometimes cause more grief than all the other project phases combined.

Here are some tips on how to drain your project swamp before your team becomes mired in closeout quicksand.

Avoid closeout criteria confusion

Before you and your customer sign off (formally or informally depending on your project management governance practices) on your project plan, make sure that there is a clear definition of acceptance conditions that should be met for the project to be closed out. Then, re-check those conditions and make sure that you and your customer have the same understanding of them. By working through interpretation gaps about deliverable acceptance practices and other such conditions up front, you reduce the likelihood of these gaps causing prolonged delays and rework during project closeout.

Establish (and maintain) good financial relationships

In many organizations, projects cannot be considered closed unless full financial closeout occurs. However, as financial cycles for reporting may not necessarily mesh with your project's timelines for closure, this could cause a project to be held in an "open" state beyond expected timeframes. This is where a good relationship with your procurement and finance staff as well as your vendors can go a long way towards accelerating timelines - being able to get copied on invoices or to receive summary financial reconciliation reports in a timely fashion is key.

Break the walls down 

Remember that your project is just a delivery mechanism for achieving business value. To achieve that business value, an operational team will need to execute and support the new or changed business processes delivered by your project. Be sure to prepare for this transition thoroughly. This includes knowledge transfer, transitioning open project issues that are material in the operational world, organizing and archiving project documentation appropriately to facilitate access by the operational team. And be sure to involve key operational stakeholders in the closeout review meeting to ensure that their needs are met and that they are willing and able to grab the relay baton and run with it.

Give a hoot, don't pollute 

Projects generate a vast amount of soft and hardcopy documentation over their lifetime. Not all of this information is required once a project has been completed. Take the time to weed through document repositories, project war rooms, file servers and other information stores to archive unneeded files and to properly organize official documents for easy future access.

Evaluate your team

Even in functional organizations where project managers have very little power of any kind, there is value in providing written feedback to team members on their performance. It may not get used by their functional managers as an input into performance evaluations but the team members can add it to their own personal portfolios. It also demonstrates that you respect their work and the effort they have made.

Harvest the lessons (to be learned)

Although this should have been done throughout the lifetime of your project, project closeout is your team's last chance to document useful tips for future projects. In addition, it is an opportunity to scrub or refine lessons that had been documented earlier in the project's lifecycle.

Celebrate 

Whether or not you have a formal budget approved for a project closeout event, it is important to take the time to celebrate your project with the team, stakeholders and customer. A good way to prepare for this celebration is to take photos or video clips of significant events over the lifetime of your project. Analogous to the videos that are shown at weddings (or perhaps a better comparison would be at funerals!), this gives everyone the opportunity to reminisce about the good, the bad, and the ugly that they experienced. Further to this, I would recommend burning copies of this video to DVD and presenting the attendees of the celebration with a gift-wrapped copy of the DVD.

When it comes to project closeout, do not follow Dylan Thomas's advice "Do not go gently into that good night..."

(Note: this article was originally written and published by me in October 2009 on Projecttimes.com)

While there’s probably a little Homer Simpson in all of us (especially when faced with a “forbidden doughnut”), he has spouted off some witticisms that provide some lessons learned for project managers!

1. “Well, it’s 1 a.m. Better go home and spend some quality time with the kids.” While project managers are notorious for burning the candle at both ends, work-life balance is important as sooner or later, you will have no more (work) projects to manage.
2. “I want to share something with you: The three little sentences that will get you through life. Number 1: Cover for me. Number 2: Oh, good idea, Boss! Number 3: It was like that when I got here.” All great examples of what Neal Whitten would call project managers being too soft.
3. “Kids, you tried your best and you failed miserably. The lesson is, never try.” Failures are not what makes us, it’s how we handle failures that makes us.  Project managers who get jaded or disillusioned after experiencing project failure are doing themselves and their organizations a disservice.
4. “I’m normally not a praying man, but if you’re up there, please save me Superman.” Faith is good, but project managers need to leverage some earthly sources as well!  Having developed good relationships with your sponsors and stakeholders and (hopefully) having a mentor or two can provide you with multiple layers to your support “onion”!
5. “Donuts. Is there anything they can’t do?” Flexibility with regards to procedures and practices is important.  Applying a project management methodology rigidly regardless of the scale or complexity of a project will likely result in frustration and resistance from your team and your stakeholders.
6. “What do we need a psychiatrist for? We know our kid is nuts.” Even if you have specific expertise into a decision or issue, project management is about using the right skills from your team to the right problem at the right time.  Too many project managers take on too much decision making by themselves and undermine the skills and roles of their team members.
7. “Oh, people can come up with statistics to prove anything, Kent. 14% of people know that.” Yes, statistics can be wrong some of the time, but failing to use quantitative project performance metrics means you will likely be wrong 100% of the time when monitoring your projects.
8. “How is education supposed to make me feel smarter? Besides, every time I learn something new, it pushes some old stuff out of my brain. Remember when I took that home winemaking course, and I forgot how to drive?” Project managers (especially seasoned ones) can sometimes become complacent about their own professional development.  While there’s a lot to be learned from the school of hard knocks, the profession is evolving with research across multiple knowledge areas and a project manager who refuses to spend some time on knowledge enrichment is setting themselves up for obsolescence.
9. “If something goes wrong at the plant, blame the guy who can’t speak English.” Scapegoats exist in all companies, and it’s often convenient (and easy) to blame project failure on one.  Professionalism comes from taking responsibility for project outcomes.
10. “If something’s hard to do, then it’s not worth doing” Applying many of the hard and soft project management competencies is not easy – this doesn’t mean that you jettison them as soon as things get tough.  To quote President Kennedy “…not only because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win…“

And finally, here is one Homer Simpson quote that is applicable to all project managers “All my life I’ve had one dream, to achieve my many goals.”

(Note: this article was originally written and published by me in October 2011 on my personal blog, kbondale.wordpress.com)