Easy in theory, difficult in practice

My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

What's blocking your benefits realization?

Is your project information system of record the grapevine?

What's in YOUR sprint backlog?

Lessons in agility from wine tasting…

Control partners should have skin in the game!

What's blocking your benefits realization?

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?"

Posted on: January 20, 2019 07:00 AM | Permalink | Comments (6)

Is your project information system of record the grapevine?

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)

Posted on: January 16, 2019 07:00 AM | Permalink | Comments (11)

What's in YOUR sprint backlog?

Categories: Agile, Project Management

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:

  • Work items which directly add customer value to the product. Features, requirements, enhancements and fixes fall into this bucket. Learning activities such as spikes would also qualify.
  • Work items which indirectly enable or are required for product delivery. Environment support, deployment management, regulatory documentation are examples of this category.
  • Work items which improve the delivery process. Improvement ideas from retrospectives are one type of such work item

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?

Posted on: January 13, 2019 07:00 AM | Permalink | Comments (8)

Lessons in agility from wine tasting…

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)

Posted on: January 09, 2019 08:21 AM | Permalink | Comments (15)

Control partners should have skin in the game!

Categories: PMO, Project Management, Tools

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:

  • Serving in such control functions could be a rotational responsibility. After someone has spent a reasonable amount of time in a control role, they should be required to spend an equal amount of time in a delivery role. This will also help them better identify patterns and anti-patterns specific to a given context.
  • Introduce performance measures and incentives for control staff which are tied to the impacts created by their work as opposed to just the completion of this work. For example, quantifying the cost of control or conducting regular satisfaction surveys with delivery staff are two methods in which we could bring back skin in the game.

Method makers and framework formulators - practice what you preach!

Posted on: January 06, 2019 07:00 AM | Permalink | Comments (4)

A doctor can bury his mistakes but an architect can only advise his clients to plant vines.

- Frank Lloyd Wright



Vendor Events

See all Vendor Events