My article last week discussed the need for team members to act with responsible transparency. Each team member requires discipline and wisdom to judge when an issue preventing them from completing their work items can be resolved quickly without the need for broader communication or escalation.
If a blocker surfaces and no one other than the person who encountered the impediment is aware of it, the delivery of that work item could be critically impacted resulting in a cascading set of delays. The same holds true for the team as a whole. I've occasionally worked with teams whose members are uniformly confident in their ability to resolve any blocker which arises. Such teams can go out of their way to show that they are in control and everything is going well on their delivery work, right up till the moment when it is clear to all that this is not the case.
So assuming that team members are doing a good job of surfacing impediments, how should these be communicated and tracked?
The project manager will likely be accountable for maintaining a project issue log but depending on where that artifact is housed it might not be visible enough to create the right sense of urgency from the stakeholders who can help the team resolve issues. Also, such a log is likely to track higher level issues and not just those affecting individual work items.
If a detailed schedule is being used to plan and track work activities, blockers could be directly linked to the affected activities, and indicator icons or flags can be set to highlight the tasks which are currently blocked. But that still requires stakeholders to regularly review the project schedule.
A better approach is to expose blockers through existing information radiators.
If a work board is used to help the team manage their work flow, blockers can be identified in one of the following three ways:
Blockers can also be tracked separately using a pain snake (sometimes called a "snake on the wall"). Every time a new blocker is identified, a new stickie is added to the snake. The length of the snake will help encourage the team not to allow too many blockers to remain unresolved.
So how bold are your team's blockers?
I finally completed reading Nassim Taleb's book Skin in the Game which I had written about in a recent article.
In that piece I had applied his principles when comparing the benefits of a product-centric orientation to the project-centric model which is still found in many organizations. But after finishing the book, I realized that there is a much more compelling example of the challenges experienced with risk asymmetry in many large organizations, namely with those staff who are responsible for developing the policies, standards and methods used by teams for delivering projects or products.
In small companies, how a product gets developed and delivered is usually defined by a "Big Brain" (e.g. a solution owner or similar role) or developed collaboratively by those actually building the solution. But as the size of the organization increases and stakes get higher, control partners emerge to influence not only what but how production occurs.
Where things get difficult is when these control partners do not experience first-hand the downside of their decisions.
For example, in some companies, project management standards are set by a centralized department such as a PMO. While some delivery roles such as program or project managers might report in to the same PMO, there are staff whose sole focus will be to define and maintain standards. As those staff are not in a project delivery role, even if they possess years of practical experience, as they won't themselves have to use the templates and tools which they have developed, they don't have true skin in the game. Delivery staff may complain to control partners about how onerous or non-value add specific practices are, but there is little direct impact to them.
There are a couple of ways to rectify this situation:
Method makers and framework formulators - practice what you preach!
(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.
There was an important point made on page two of the PMBOK Guide (Fifth Edition): the organization and/or project management team is responsible for determining what is appropriate for any given project.
This advice is not provided to encourage a free-for-all whereby each project team does as they please. Some practices consistency is crucial when one needs to evaluate a portfolio of projects, and it can also help to reduce ramp up time when staff are assigned to projects.
The guidance is there to remind us that we need to assess a project to determine which practices can be used as is, which need to be tailored to fit, and which are simply not applicable.
So what’s the problem with not hitting the “sweet spot”?
If insufficient practices are applied, or if the practices are diluted too much, there is an increased risk of partial or total project failure.
On the other hand, if teams are applying a “one size fits all” approach, the risk of project failure is reduced, but is replaced by increased cost of project delivery and frustration with project management in general. Over time, this frustration will translate into teams following project management practices just to pass a delivery gate instead of applying them to improve their odds of success.
For companies which have assigned an individual or a team (e.g. a PMO) to be responsible for assessing and improving project management capabilities, ongoing feedback from project teams can be a good way to progressively develop a knowledge base to help practitioners with adapting practices to the needs of specific projects.
Going a step further, in companies with strong internal policies or regulatory requirements, an independent (internal) consultant might be engaged to provide such assistance. Their responsibility could include the review and approval of the compliance of the adapted practices with the overall philosophy and intent of the organization’s project management policies.
Unfortunately, for those companies which have not centralized the responsibility for project management practices, the onus for doing this falls solely on project teams.
In such situations, project managers may need to develop a “play book”. Such play books could include the following details for each key project management practice:
The benefit of such a play book is that it can facilitate a structured discussion with the team at the start of a project. It can help to educate team members as to the necessity of certain practices whose rationale might not be intuitive and it can also demonstrate that the project manager is taking a right-sized approach to the project.
A well written practices play book could be the project management equivalent of this knife which you COULD bring to a gunfight!
Information radiators can help stakeholders remain informed and can reduce effort spent by a team in handling requests for updates but to reap these benefits we must ensure that the information published meets their needs.
As with any type of communication, if the content published cannot be trusted due to obvious inaccuracies or a lack of currency, stakeholders will cease to consult the radiators and will demand that traditional reporting methods are re-established.
Such defects will also reduce the credibility of the team in the eyes of the stakeholders.
This is one more reason to ensure that if Kanban boards or other work visualization views are made accessible to stakeholders outside a delivery team that team members are diligent in updating them while work is being done rather than after the fact.
If an information radiator generates more questions than it answers, it will become a burden for the delivery team. Not only does this mean that legends, titles, and thresholds are clearly presented, but it also requires that any information which could be misinterpreted should be accompanied with some context so that stakeholders get the correct story.
For example, if a sprint burn down chart is being published daily and by the midpoint of the sprint it appears that very little has been completed, a stakeholder might reasonably assume that the team is going to complete significantly less than what had been agreed to during sprint planning. However, if some context is provided that the team's delivery process includes an independent review by an external inspector who is only available one or two days per sprint, this apparent lack of progress might be perfectly acceptable.
This also means that we should review what is being published to ensure that stakeholders can perceive the forest as well as the trees.
Publishing a sprint burn down chart or Kanban board without providing a team's Definition of Done is only part of the story. Posting a release burn up chart without indicating what is being delivered in the release will not promote shared understanding.
Finally, it's important to educate stakeholders so they can effectively pull information from the information radiators and to set expectations that radiators are to be consulted as the first source for updates.
Poor information radiators are a constant reminder of George Bernard Shaw's caution that "The single biggest problem in communication is the illusion that it has taken place."