Easy in theory, difficult in practice

If I’ve heard it once, I’ve heard it a thousand times – “I wish I had more decision making authority”!

Whether it’s formal authority over their team members, handling of an issue, establishing project governance, or setting direction, there is a common sentiment that the grass is greener when it comes to decision making.

Don’t kid yourself – managing projects wouldn’t be that much easier.

Imagine that you are the owner of a private company with no debt owed to outside investors. You have complete authority over all decisions made within your company – within the boundaries of the law, of course!

Will that guarantee that your company would succeed? Does that automatically mean that you will enjoy your work that much more?

Of course not.

Success comes down to having the right product or service at the right time, developed and delivered in the right way by the right people at the right price point to the right customers, and unfortunately, all the decision-making authority in the world won’t ensure all those stars align.

On top of that, it can be a pretty lonely existence – total decision-making authority would naturally separate or alienate you from the others you work with no matter how much benevolency you’d show.

And finally, absolute power corrupts absolutely. Just because you can make all the decisions doesn’t mean you should – with great power comes great responsibility. Acting on the temptation to cut corners by unilaterally making decisions is a great way to lose your best team members.

In the end, you will have reaped the real “reward” of omnipotence – being able to proudly say that the project’s failure was yours and yours alone.

Act as if you are the CEO of your project, but be thankful that you can benefit from diffused decision making authority: strength through diversity, healthy conflict and greater ownership and engagement.

(Note: I had the decision-making authority and acted upon it to re-post my July 2015 article from my personal blog, kbondale.wordpress.com)

Risk management, like nearly all project management knowledge areas, is iterative. We don’t just identify risks at the beginning of our projects. As we learn more about what we are expected to deliver, our risk registers experience progressive elaboration in the same way as does our knowledge of our customer’s requirements or our work breakdown structure.

While this iterative nature of risk management helps to increase the currency of risk information, it does have a dark side.

The risks we’ve most recently analyzed might appear to be more relevant than those identified much earlier in a project’s life. Given how busy we all are, if those older risks have not yet been realized, it can be tempting to assume that they can be safely ignored. And when our vigilance drops, that’s usually when those risks will strike.

To protect against this, we need to implement countermeasures which won’t consume much effort, but can provide us with sufficient lead time to recognize that a risk may be realized so that we can execute response plans with a higher probability of success. This is why it is important to identify risk triggers which should be as specific as the risks they are associated with.

It’s also a good reason to consider going beyond simple probability and impact-based assessments of risk severity by incorporating the failure mode effects analysis practice of estimating how easy it is to detect that a risk is about to be realized. By doing this, a moderate risk with low detectability will gain importance relative to those which we can see a mile away.

Of course, none of this matters if risk information is not reviewed regularly.

You may want to review risk triggers for your key risks at each team meeting to find out if any have been detected. You might even consider creating a “Project’s Top Ten Most Wanted” cubicle poster highlighting the triggers tied to your most critical risks.

Whatever techniques you use, regular reviews of meaningful triggers can act as a gauntlet around your project, ensuring you don’t get rear-ended by a risk Mack Truck!

(Note: this article was first seen in kbondale.wordpress.com's rear view mirror in June 2015)

(If the title of my article for this week has you confused gentle reader, fret not - I'm just merging two distinct topics into a single post)

In 2003, Barry Boehm and Richard Turner coined the acronym C.R.A.C.K. (Collaborative, Representative, Accountable, Committed, Knowledgeable) to cover key characteristics of an effective Product Owner (PO). Unfortunately, some POs leave us with the perception that they might have been smoking crack!

Having worked with some POs who lack one or more of these attributes, I recently had an epiphany. I have always felt that there is no single delivery role which is the most critical, but my exposure to ineffective product management has convinced me that the PO is the hardest role to successfully fill.

Good agile leads (a.k.a. Scrum Masters) might be worth their weight in gold, but they are out there. If you aren't getting good ones the cause is not likely a lack of supply but rather blockers within your own organization (e.g. toxic culture, poor compensation) which are preventing you from attracting them, and in a pinch, contracting might be the way to go. Development team members are also valuable, but talent across most skill areas is available for the right price and with the right culture in place.

The challenge with the PO role is that not only do you need someone who has deep business process knowledge regarding the product they are supporting, but they also need to have well established relationships with key stakeholders who will influence product direction. While it is difficult to satisfy the first requirement, especially in those organizations where knowledge exists in silos, it is much more difficult to meet the second requirement. Simply parachuting in someone from the outside won't work regardless of how knowledgeable they might be about the domain.

So if you are lucky enough to have an effective PO, retain them at all costs.

On a different note, Eric Uyttewaal, asked whether I would be interested in reviewing his latest book - Forecasting Programs - Best Practices for Scheduling Real-World Programs.

I don't normally write reviews on my blog, but I have deep respect for Eric's knowledge of MS Project and his ability to make it able to stand on its head. Eric has written multiple books on effectively using the tool and given the dearth of guidance on using scheduling tools like MS Project to manage programs, I felt this was a worthwhile exception.

I was pleasantly surprised to see that the book goes beyond MS Project to providing general scheduling guidance for managing programs. While the examples and step-by-step procedures do focus on MS Project, they can be adapted for use with other scheduling tools.

Eric has done a good job of covering the analysis which a program scheduler might go through in deciding how to organizing their schedule, and I especially liked his Project Ideal and Constraint Matrix (PIC-Matrix) which can help a scheduler in deciding which scheduling approach to use given the primary expected benefit and primary constraint for a given program.

While there is guidance for scheduling projects following an adaptive lifecycle, Eric has taken a very narrow view of agile delivery. Sprint-based delivery might be the most commonly followed approach but it is not the only one. His compromise to find a happy scheduling medium by defining the content of a full backlog in detail so that work items can be assigned to all sprints and estimating all backlog items is not suitable for projects where requirements are expected to evolve dynamically. His approach to converting story points to effort hours is also concerning as there usually isn't a linear relationship between the two.

Eric's company develops and sells a number of add-on products to MS Project. While a certain amount of self-promotion is to be expected, I did find that the number of references to these products was more than I would have liked. In fairness, Eric does reference other third-party tools but generally positions his tools favorably relative to these competing products

I felt the book's greatest strength is the number of options which Eric has provided for scheduling programs which makes this book useful regardless of the maturity level of the practitioner.

A swing thought is golf-speak for focusing on a single instruction while making your golf swing.

When you add up the multiple suggestions which one’s mind can generate when the ball is addressed, not having this focus means that you may become distracted with thinking about everything which you should be checking, and your resulting shot is more than likely to go astray.

This approach also applies to project management.

While the timelines for decision making are increased, the voices in our heads telling us everything we need to remember can be equally overwhelming. Faced with too many competing and conflicting choices, we might either fall into analysis-paralysis or might shoot from the hip.

There are numerous scenarios where this could happen – negotiating project scope, cost or schedule baselines with one’s client, entering a difficult conversation with a team member or having to deliver some bad news to a sponsor.

Here are a few tips on effective use of swing thoughts.

Keep them simple. The more complex they are the more likely you are to forget them when things get tough. There’s a good reason that mantras are short – with our mind’s tendency to wander, anything more than a few syllables is asking for trouble!

One size doesn’t fit all. Just as a golfer might use a different swing thought for a difficult putt than the one used for a tee shot, you should identify a few different PM guidelines to use depending on the circumstances.

Practice makes perfect. Hours on a driving range or time spent taking a practice swing before a real shot can overcome the novelty of a coaching suggestion. Look for safe or low risk opportunities to practice the use of a particular project management guideline so that you aren’t put on the spot when you really need to use it.

Of course, it is important to have the right swing thoughts – when presented with a water hazard, focusing on “Don’t go in the water” is likely to result in a golfer’s ball entering the watery grave!

The business world rarely gives you a Mulligan, so come up with a few good project management swing thoughts and your project might avoid a bogey!

(Note: this "hole in one" article was first sunk on May 2015 on my personal blog, kbondale.wordpress.com)

I am not endorsing a switch to a career in gambling but there are a few lessons which project managers can learn from the game of poker.

This shouldn’t seem a stretch given that a poker tournament meets the usual definition of a project. Each tournament is unique from a rules, location and setup perspective, it has a start and end, it consumes resources (sometimes more than we would want!) and is expected to generate value.

Play the player, not the cards

While you could certainly memorize the probabilities of achieving each hand ranking, that will still not make you a consistent winner. Luck also plays a role in determining outcomes for a round, but the key competency for poker is being able to read your opponents and exploit their biases and tells.

Success in project management is about building relationships, reading difficult stakeholders and managing expectations. Visible tells in challenging meetings can work for or against you so self-awareness and mindfulness are critical both for poker and for project management.

Find the balance between risk and reward

The player who goes “all in” at nearly every half-decent hand will get eliminated early on. The player who folds consistently based on their hole cards gets blinded out. Neither blind optimism or ultra-conservatism will help you win.

When managing projects there will be times when the safest alternative is the right decision, and other times when there can be significant opportunity (or real) cost of playing it safe.

Adapt your approach

There are hundreds (if not thousands) of poker variants – Texas Hold ‘Em just happens to be the most popular at present. Context is also critical. Just because you have been successful when playing a few hands in a social round with friends doesn’t mean you won’t be wiped out swiftly when playing against pros at a casino.

Utilizing a one-size fits all approach when managing projects is a similar recipe for disaster. The culture of the organization and team, organization policies, project constraints and other attributes should all influence how you manage your project.

You gotta know when to hold ’em

No good poker player always bluffs. Faced with a 2-7 hole card pair, except in cases where they risk getting blinded out, most players will fold.

It can be tempting to take a strong stance when facing project conflicts but situational leadership dictates that you evaluate each situation and apply the tactic that is in the best interests of the project’s overall success.

I’ll close with the following quote from Chris Moneymaker which could also be said about project management:The beautiful thing about poker is that everybody thinks they can play.

(Note: I went all in on this article in October 2015 on my personal blog, kbondale.wordpress.com)