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."
Those of you who have followed me for a while will know that I value pragmatism over absolutism when it comes to delivery practices, tools and techniques. Pick the right tool for the right job should be a guiding principle followed by all project teams.
Easier said than done!
It is difficult when enterprise standards dictate a fixed tool set, but it is even more challenging when a company is undergoing a fundamental transformation of its delivery practices. When adopting new delivery frameworks it is tempting to embrace the bright, shiny new tools while branding those of the previous delivery approach as obsolete, but if we understand the context in which their usage will still add value we should still find a home for them in our toolboxes.
A good example of this is the use of Gantt charts by teams who are following an adaptive or agile delivery life cycle.
Although Gantt charts have been around since the early 1900's, just as with people, age is not negatively correlated to value. Tools such as burn-up charts provide an objective means of evaluating progress towards completing a release, but it is rare outside of pure product development contexts to find projects where a traditional representation of a schedule wouldn't also provide some incremental benefits.
This need could arise from any of the following causes:
The project team will want to define the best way to combine the use of traditional and agile scheduling tools to avoid information duplication and inconsistency. Agile teams can continue to use their default tools, but traditional scheduling tools can be used to track other work which is not captured in the backlog yet still needs to be completed for project success.
If there is a need to have an overall integrated project schedule, the agile teams' sprints can be shown as a series of sequential fixed duration activities without the need to decompose those to any lower level. By reviewing burn-up charts, the exact number of such sequential activities can be adjusted to reflect accurate completion dates.
With significant change, there is a greater likelihood of success if you preserve valuable current practices when introducing new ones.