On occasion, you may have found yourself asking “If only my team members would do what I asked them to, I’d be able to spend time on more value add activities?”
Perhaps you are asking your team members to provide you with regular updates on the completion status of their assigned work. One of them neglects to provide this information by the requested deadline.
Being a collaborative project manager, you’ll meet with them to confirm that they understand the expected reporting timelines and may even ask them if there’s anything you can do to simplify the process so that expectations won’t be missed in the future. If nothing changes, you may commence nagging them or even escalate to their people manager in the hopes that things will improve. At some point, you may simply give up and start guess-timating how far along they are and using that instead of true actuals.
All that we have done is encourage a continuation of the behavior we were hoping to change.
Nagging or escalation will cause a good team member to disengage and estimating progress without their direct input will eventually come back to haunt you when other team members realize they can get away with this, or worse, your estimated progress reporting is proven to be wrong.
Hindsight is 20-20.
Having the team members as a group define the best way to report progress such that it wouldn’t impact their work while still meeting your reporting requirements might have avoided the current challenge. In that case, instead of you having to confront a team member for not adhering to your rules, you can engage the team in holding one of their own accountable to their rules.
But all is not lost – you can still use the same approach. In the next team meeting, let them know that some team members are struggling with the reporting requirements. Acknowledge the effort it takes to do this but also use it as an opportunity to refresh their understanding of how this information gets used and why it is so critical to have it provided accurately and in a timely manner. Show them a recent project status report or dashboard so they can see it live. Then, step back, and ask them to come up with ways to improve the process.
By involving the full team in the development of a solution, you will increase team members’ engagement and they are likely to demonstrate greater ownership of such administrative activities in the future.
When we point the finger at others, many times, the issue lies in the direction which the remaining fingers are pointing to.
(Note: this article was originally published in November 2015 to my personal blog, kbondale.wordpress.com)
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)
I've previously written about the importance of courage and discipline for agile teams, so let's review another important quality - respect. The Oxford English Dictionary provides two definitions for which are apropos:
You might think that showing an appropriate level of respect is table stakes for anyone in any role regardless of their being an individual contributor or part of a team. That is true, but there are many dimensions to respect which need to be considered. Here are just five which I expect to see in practice in mature teams along with a few examples of how we fall short with each.
Respect for the organization's resources
Producing excessive or unnecessary documentation, inviting people to meetings who don't need to be there or not running disciplined meetings, and not regularly inspecting and adapting ceremonies or other delivery practices are just a few ways in which we needlessly squander the limited financial resources of our organizations.
Respect for our customer
Publishing out-of-date or inaccurate content in information radiators, failing to engage our customer in key ceremonies or the product decisions which they should have been involved in, avoiding the escalation of key blockers which our customers could have resolved or releasing low quality products just to hit a deadline are all examples of disrespect for these critical stakeholders.
Respect for our product
Skipping quality assurance procedures because we don't have time, ignoring our Definition of Done just to say we completed our sprint backlogs, kicking low severity defects down the backlog, ignoring technical debt and regular refactoring show that we don't really respect what we are producing.
Respect for each other
Making sprint commitments without full team participation, gold plating, showing up late for ceremonies, listening to make our point rather than actively listening, multitasking when we should be focused on what someone is saying, hoarding knowledge, not offering to help a team member when we are ahead on our work, and not having the courage to raise impediments which affect the entire team during daily standups or retrospectives demonstrate that we are putting our agendas and egos ahead of team success.
Respect for ourselves
Blindly following poor decisions without challenging them, making a sprint commitment which we know we can't achieve, refusing to ask for help when it would result in more efficient, higher quality outcomes and failing to invest in ourselves (e.g. personal development, sleep, exercise) are common ways in which we make it difficult to look at ourselves in the mirror.
Confucius said it right: Without feelings of respect, what is there to distinguish men from beasts?
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)