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?
The sixth principle of the Manifesto for Agile Software Development is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation".
We have all experienced situations in which our not seeing the person we were speaking with resulted in a misinterpretation of what was being said. When teams are composed of dispersed members who don't have the benefit of seeing one another face-to-face it takes longer for them to trust one another. It also can increase the volume of documentation required to create shared understanding.
It should be fairly simple for teams working for a single company on small, low complexity projects to be co-located, but as project complexity, scale or the number of distinct delivery partners grows, multiple constraints including the availability of skilled contributors, financial restrictions or real estate limitations might prevent team members from working in close proximity.
It is always a good idea for leaders to organize early and regular face-to-face opportunities to build trust within the distributed teams they are supporting.
But is that enough?
Augmented or virtual reality technologies have still not evolved to a point where we can accurately simulate being co-located, but using dedicated video conferencing facilities or even the webcams on our laptops can boost communication effectiveness.
Such tools can provide us with benefits such as:
Albert Mehrabian's 7%, 38% and 55% rule about the relative impact which verbal, tone and body language cues have on how much we like someone is frequently misstated as representing the impact of all communications. But we should never forget that old saying: "Out of sight, out of mind".
A highly touted good practice for project teams is that they should be self-organized.
Rather than rigidly following direction, team members possess the necessary enterprise savvy coupled with the awareness of what they do and don’t know about the project so that they can come up with the best way for them to plan and deliver the project’s scope. Self-organized teams are flexible so as changes occur to the project, they tailor their approach accordingly. They are also resilient in that while they will rely on each other’s skills, they aren’t crippled by the loss of any one team member and they are ready to onboard and assimilate new team members into their collective.
This is in marked contrast to what is the norm in many companies.
Projects are staffed with an emphasis on resource competency rather than how well they play together. Employee performance programs are geared towards recognizing individual accomplishments over the success of project teams. And enterprise governance policies lean towards favoring compliance with process over satisfaction of control objectives.
Facing these sorts of constraints, is it any wonder that many teams exist in name alone? So when the decision is made to encourage self-organization, this change won’t happen overnight.
Team members who have been used to looking out for their own interests over the success of a team will struggle with the shift to collaboration over consensus. They are also likely to lack the necessary confidence to effectively adapt practices and approaches to fit the needs of a given project. Some might follow an anything goes approach but reprisal for failed projects or broken organization policies is usually likely to be swift. Others might be paralyzed when they request governance bodies for guidance only to be told “It depends” or “You are smart and now we’ve empowered you, so go figure it out“.
Self-organization is a progress, not a transaction.
Coaching on appropriate leadership and team member behavior can help but rarely will there be sufficient coaches in place to address the demand, not can they be procured in a time or cost-effective manner. Definition and implementation of a development strategy based on a coach-the-coach model will be critical.
For process tailoring, initial changes should focus on providing guidance for a limited number of choices where previously a single choice had been prescribed. As confidence and competency increases, constraints can slowly be relaxed.
There have been some instances in recent history where prescriptive dictatorships have been toppled by foreign powers. With projects as it is with politics, if sustainable support mechanisms don’t get institutionalized by liberators before they leave, anarchy rather than self-organization is often the tragic result.
(Note: this article was self-organized in July 2016 on my personal blog, kbondale.wordpress.com)