There are many aspects to the job of a project manager including a planner, a leader, and a conductor. However, one of the most important roles which a project manager can play is to remove obstacles to unleashing the creativity and productivity of their teams. Without that, the best planned project will still encounter delays and cost overruns.
Sponsors might introduce hurdles by imposing perceived constraints on the team such as due dates without clearly indicating that those are just targets. These can then reduce the confidence and increase the stress level of team members resulting in reduced velocity. Sponsors can also drag their heels on making key directional or funding decisions. A good project manager can avoid the realization of such risks through effective sponsor onboarding and ongoing engagement.
One of the many attributes of a stakeholder is their ability to hurt a project. Good stakeholder management and appropriate use of political influence can help the project manager reduce the likelihood or impact of such behavior.
Team members might also generate their own obstacles. Economic downturns or company restructuring can generate a very natural sense of disengagement and paranoia which can sap productivity. An effective project manager can recognize the symptoms of this malaise and will implement the right actions to keep the team focused. Sometimes, the obstacles might be the working practices of the team – while a good project manager shouldn’t mandate how the work gets done, they should certainly provide their team with suggestions on how they can improve things and should support them in cultivating a team culture of continuous improvement.
But sometimes, a project manager can be the source of the worst roadblocks to the team’s progress.
Here are just a few.
There are many hurdles which can slow your team down – self-awareness and actively soliciting feedback on how you are doing could help you avoid making things worse!
(Note: I bulldozed through writing this article in June 2015 on my personal blog, kbondale.wordpress.com)
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)