We might assume that transparency should be a given when delivering value through our projects so why is it that the actions of teams or the stakeholders supporting delivery don’t always demonstrate that basic hygiene factor? Transparency is so critical that the Scrum Guide lists it as one of its three pillars and it is similarly echoed in the reference materials for many other agile delivery methods as well as in PMI’s Code of Ethics.
Transparency is a rising tide which lifts the attitudes of all stakeholders:
- Customers benefit as they have to spend much less effort in understanding what is really going on
- Sponsors benefit as they will develop stronger, more positive relationships with teams and are better equipped to support their teams in a more timely manner when issues arise
- The project manager and team benefits as they don’t have to worry about putting the right “spin” on events and are less likely to get distracted or waste effort in needless status updates for stakeholders. They will also benefit if the higher levels of trust which result from increased transparency encourage enterprise groups to lean out governance requirements by focusing on the few outliers rather than punishing the majority.
I wrote a few years back about the downsides of unfiltered transparency as this could generate unnecessary panic or encourage micro-management from our stakeholders, but responsible transparency is key to creating trust.
Responsible transparency is about providing the truth, warts and all, but ensuring that sufficient context gets provided so that our stakeholders’ reactions to the truth are appropriate. Project teams have many tools and techniques available to them which can provide transparency about progress and impediments, but using these in isolation may not provide that context. For example, reviewing individual work items in a sprint backlog without also being aware of the sprint goal(s) identified by the Product Owner doesn’t help a stakeholder see the forest for the trees. Similarly, trying to interpret a burn down or burn up chart without understanding the team’s delivery approach or the contents of a sprint or release backlog might create the wrong perceptions.
So as you strive for transparency in your information radiators and other communication methods, ensure that you are providing the necessary color commentary to make the information meaningful.
The single most important ingredient in the recipe for success is transparency because transparency builds trust – Denise Morrison, (Former) CEO, Campbell Soup Company
PMI just released the Benefits Realization Management practice guide this month which provides comprehensive but still easily consumable coverage of a benefits management framework covering principles, practices and roles. There is no doubt that benefits management is a critical competency for any company whether they are for profit or not-for-profit but it is also not well implemented in many organizations.
Overly optimistic business cases might be one reason for this as I’d covered in an earlier article, but there are other potential causes including:
- An unwillingness to hold sponsors accountable for expected benefits. While punitive measures may create a culture of fear and drive otherwise effective sponsors away but there still needs to be some way of ensuring that sufficient due diligence has gone into identifying benefits. Independent verification of benefits analysis is one way to reduce inflated expected outcomes without scaring off potential sponsors.
- A lack of objective definition of the benefits expected to be realized when executing a given investment. Even for initiatives with a financial benefits motive, it may be difficult to demonstrate causality between the outputs of the project and expected financial outcomes as there will usually be more multiple projects with the same types of measures (e.g. increase revenue, reduce costs).
- Limited monitoring of expected benefits over the life of an investment. Projected benefits like scope, schedule and cost baselines represent what is expected at the point in time when they were defined so ongoing forecasting is crucial. Without this, delivery might be successful within approved scope, schedule and cost constraints, but the project’s ROI is never realized. Sometimes there is no owner identified for tracking benefits during the life of the project while other times an owner has been anointed but is ineffective in that role or is unwilling to declare that the project won’t deliver expected benefits proactively.
- Benefits realization timelines are excessively long. The more time which passes between the end of a project and when expected benefits should materialize, the more fragile those benefits will be due to the impacts of internal and external changes.
- Poor project delivery. While the outcomes of a given project may not change, if the costs or timeline for realizing those increase significantly due to delivery issues, the project’s ROI will be worse than expected.
For leaders looking to improve benefit realization from their project investments, doing some root cause analysis to identify why projects aren’t generating expected benefits can help them to focus their improvement efforts.
Mohamed El-Erian – “Investors have to ask themselves two questions. How much can we grow our investments? And, can we afford our mistakes?”
If you are sensing a theme here, you probably are.
After writing about the importance of courage for project managers and team members last week, I thought I’d cover another important characteristic, especially for those working on projects which follow an agile delivery approach: discipline.
Merriam-Webster offers a number of definitions for discipline including a few which I’m not overly fond of such as “Control gained by enforcing obedience or order” and “Punishment“. Neither of these sound well aligned with an agile mindset, do they?
However, the following two definitions hit closer to the value of discipline for agile teams: “Orderly or prescribed conduct or pattern of behavior” and “Self-control“.
So how do agile teams demonstrate these orderly patterns of behavior and self-control?
Some are obvious:
- Showing up on time for ceremonies while also ensuring that they add value
- Updating Kanban boards or other information radiators in a timely manner such that they can be trusted by stakeholders as an accurate source of delivery knowledge
- Adhering to the team’s Definition of Ready and Definition of Done unless there’s a good reason not to do so for a given work item
- Self-awareness of bias and being sufficiently mindful to not act on impulse
- Making sure that product knowledge (e.g. training and support documentation) remains current
However others are more subtle:
- Resisting the temptation to gold-plate
- Demonstrating courage in coaching senior stakeholders when they want to add more work than the team can complete at a sustainable pace and in a quality fashion
- Avoiding early commitments
- Not completing another team member’s administrative work for them unless there is a valid reason for their not doing it themselves
- Granting a team or a team member the freedom to fail
If there is one lesson I learned from my brief foray into the world of martial arts, it is that self-control is critical to success. Given the parallels which get drawn between learning a martial art and becoming agile (e.g. Shu-Ha-Ri), it is little wonder that self-control is important for successful agile delivery as well.