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 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.
Those of us who have been managing projects for a few years seem to run into the following myths and misconceptions on a sufficiently frequent basis that I felt it might be of value to consolidate and publish a few of them.
Project management competency is about learning tools and techniques
As with any other profession there are hard skills which need to be acquired to claim competency, but soft skills trump hard skills in project management every day of the week which ends in “day“.
Planning is everything
Yes, if you fail to plan, you plan to fail, but organizations don’t invest in projects to deliver infinitely detailed plans. Delivering business value in a predictable, consistent manner is the true value of project management.
The right PMIS will solve everything!
Did we learn nothing from the legacy of failed CRM, ERP and other enterprise applications? Automation makes a broken process break faster, so make sure you have defined, repeatable processes before purchasing and implementing a project management tool.
The squeakiest wheel needs greasing first
Stakeholders often follow Teddy Roosevelt’s advice to “Speak softly and carry a big stick“. If your focus is on the loudest stakeholder, you might end up making a detractor of a quiet, but highly influential one.
Certification is crucial
There are many qualified, competent project managers who are not certified along with many unqualified, incompetent practitioners who are. On top of that, just because someone is competent at managing one type of project within one organization doesn’t mean they will be successful at doing so in another or in a different domain. Caveat emptor.
Agile only applies to software or systems projects
Agile is a philosophy which can be applied to almost any project. Agile methodologies (e.g. Scrum) are relevant to specific project domains.
The PMBOK is a methodology
PMI’s PMBOK is a body of knowledge. The PMBOK Guide is a document containing a subset of the PMBOK. Neither are methodologies.
Changes to scope are to be avoided at all costs
Scope creep is bad. Managed scope change through reprioritization or formal change control is an expected outcome of the uncertainty present on all projects.
I’ll close this week’s article with what I believe is the greatest myth of project management: lessons learned.
Need I say more?
(Note: These myths were original debunked in November 2015 on my personal blog, kbondale.wordpress.com)
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".