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:
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?"
I’ve written a few posts about the challenge of achieving compliance with consistent project management practices.
Today's focus is the Project Information System of Record (I’ll let you get a Bart Simpson-level kick out of the obvious four letter acronym!). For those of you that are not from an IT background or have not heard this term before, Wikipedia manages to sum it up quite well as being the authoritative data source for a given piece of information.
When project management procedures are properly institutionalized and these procedures are supported or automated by appropriate systems (read Vaughan Merlyn’s post on the topic of appropriate tools) the Project Management Information System becomes the Project Information System of Record.
Executives treat project information gathered through the grapevine or in elevator conversations as hearsay, and they go to the PM Information System to understand what’s really going on. That message percolates through the ranks of stakeholders, sponsors and project teams such that the staff responsible for entering and updating project data in the PM Information System know that they need to keep the information A) Current and B) Accurate.
On the other hand, when executives ignore the PM Information System and readily accept project information through other means, they are sending the clear message that the PM Information System is a pale substitute for the grapevine.
The mantra for PM Information Systems should be “If executives swear by it, compliance should follow”.
(Note: I did NOT hear this article on the grapevine back in December 2009 when it was originally published on kbondale.wordpress.com)
The Scrum Guide states that a sprint backlog "is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment."
We expect to find requirements, enhancements and even fixes in the sprint backlog, but is that it?
Remember that one of the three pillars of Scrum and a key principle of most agile approaches is transparency. Meaningful, significant work should be visible to all as agile doesn't encourage hidden factories. If we don't surface all major work being done by the team, it is understandable that a Product Owner or other stakeholders might assume that there isn't a lot of work being done in a sprint or that the team isn't being productive.
We can separate work which is worth being made visible into three broad categories:
By sizing, prioritizing and tracking work items across all three of these categories, a Product Owner and team will gain a complete understanding of what they expect to work on in a given sprint. This encourages healthy trade-off conversations during sprint planning and will help the team identify opportunities for improvement which might otherwise have been missed. For example, if some team members are spending significant effort in keeping build and test environments operational, the Product Owner or other stakeholders might be more inclined to understand why this is needed and what they can do to reduce that effort.
There is a fourth category which you may not want to include in the sprint backlog, and that's the activities performed by the team which are completely unrelated to the product or project. This could be year end employee performance assessments, town hall meetings, operational work or (hopefully not!) even supporting another project. Assuming team members have some insights into how much of their availability over the next sprint will be consumed by this unrelated work, they should communicate that to the rest of the team during sprint planning to ensure a reasonable sprint commitment is made.
So, with thanks to Capital One, what's in YOUR sprint backlog?
One of the benefits of living in the Greater Toronto Area is being less than an hour away from a large number of good wineries in the Niagara region. After visiting many wineries over 2018, I have come to the conclusion that wine tasting and agile have more in common than you might think.
It helps to have a guide
You could certainly partake in a flight of wine with friends without the benefit of a sommelier, but you won’t enjoy the experience as much and you might learn some bad habits such as not giving your wine a chance to breathe or drinking without sniffing the bouquet. Similarly a coach can help steer a team past anti-patterns so that they have a chance to appreciate what agility truly is.
Start small and grow from there
For novices, visiting more than one winery in a day could be a recipe for disaster. Without having developed the discipline to pace themselves they run the risk of getting tipsy too quickly and might get turned off by the experience. Starting with a large project is inadvisable for novice teams – they won’t possess the discipline to scale their behavior and practices and might blame agile rather than their immaturity.
There is no one right way
While there are good principles for enjoying wine, don’t let anyone try to convince you that you must follow pairing guidelines. While a robust red wine might be a good match for a meat dish, if you enjoy its flavour there is no reason you can’t have it with any other type of cuisine or even on its own. User stories are a good approach to starting a conversation about functional requirements, but don’t be bullied by agile wannabes who insist that all requirements must be captured as stories. Like with any practice, context and culture count.
Teams doing agile might make you want to drink but I prefer to have the perspective of the (wine) glass being half-full.
(Note: this article was originally decanted in June 2017 on kbondale.wordpress.com)
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!