Easy in theory, difficult in practice

Those of you that have managed projects with a significant procurement component may grimace in familiar recollection after reading this column.  For the rest of you, forewarned is forearmed!

Project management capability does not benefit from the ideal of the whole being greater than the sum of the parts.  When you deal with business partners at different levels of PM maturity, you will likely find that the quality of the PM practices applied will degrade to the level of the most immature partner regardless of how much expectation setting, coercion or terms & conditions are present in the contracts.

Let’s consider two common scenarios:

1. The vendor is at a higher level of maturity than the client – most of the time the vendor recognizes this and may introduce strict requirements management or project change control practices to protect their interests OR alternately they will refuse to participate in any remuneration arrangement other than a time & materials model.  In either case, budget overruns or chronic change order “nickel & diming” behavior will affect project success.  Pity any vendor that does not recognize you are at a lower level of maturity – they may lose their shirts on the deal!

2. The vendor is at a lower level of maturity than the client – even if the client is able to protect their financial interests by following good practices such as milestone-based payment or pay-for-performance and imposes unlimited penalties for non-delivery or low quality, the expected business results will not be achieved in either a timely or quality fashion.  As the saying goes, never mud-wrestle with pigs – the pigs enjoy it, and you just get dirty!

So how can you avoid either of these situations?

1. Use agile approaches wherever applicable – these will help to minimize sunk costs and will provide an early indicator of trouble.

2. Try to partner with vendors that are at a compatible level of maturity to yours – too often the focus in vendor selection is only on price, delivery terms & conditions or scope.  To these criteria you should also add project management and delivery approach practices.  This is especially important if you are working with a remote or offshore partner – impacts of varying maturity levels are magnified significantly in these cases.

Ignore varying PM maturity levels at your own peril – if your project fails, it may be you who hears Anne Robinson’s famous words “You ARE the weakest link – GOODBYE!”

(Note: no business partners were harmed in the original publication of this article in July 2010 on kbondale.wordpress.com)

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

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:

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

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)