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

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!

The three most misused terms in project management

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 (4)

Product-centric teams have skin in the game!

I'm midway through Nassim Taleb's latest book, Skin in the Game: Hidden Asymmetries in Daily Life. As is usual with Taleb's writing, he provides thorough but humorous coverage of a concept which can be applied to many contexts. The premise of this book is that without skin in the game, asymmetries emerge which encourage unfairness, poor decision making and can contribute to a lack of understanding of realities.

One of the key principles discussed in the book is that there should be a negative incentive or cost to decision makers when things go wrong. Without this, we have an asymmetry since risks get transferred away from those who should have been held responsible. A common example of this is seen in companies where sales teams are compensated for initial sales but are not held accountable to some degree for customer satisfaction beyond the point of purchase. This can encourage salespeople to over-promise with inevitable expectation shortfalls. Another highly publicized example is that of the financial company executives who were never jailed for poor decision making which led to the 2008 financial crisis.

This principle can also be applied to some project teams.

There are industries such as large scale construction where the cost of poor quality in extreme cases (e.g. a bridge collapse) will result in punitive consequences to the engineers who were involved. However, in other domains such as software development for internal use where deadlines may be emphasized higher than product quality, there is no such downside. The teams who delivered the buggy release will have likely disbanded and the team members will have moved on to different departments or projects before the real cost of ownership is understood by the business owners.

On the other hand, when there is a product-centric model delivered by long-lived teams, there's greater skin in the game. Escaped defects are no longer the responsibility of an operational group or some future project team. Quality issues will come home to roost in the delivery team's backlog and the Product Owner has an incentive to focus on improved quality if he or she doesn't want to have ongoing uncomfortable stakeholder interactions.

Taleb also states that skin in the game supports the principle of survival of the fittest. Product Owners or teams which consistently miss the mark with their releases are unlikely to be around for long in product-centric contexts whereas in project-centric organizations, it may be easier for individual mediocrity to fester if there isn't ongoing vigilance.

"Skin in the game prevents systems from rotting" - Nassim Taleb

Posted on: December 16, 2018 07:00 AM | Permalink | Comments (11)

Six reasons to not punt kickoff meetings

Holding a kickoff meeting as the first “real” event on a project should be a fait accompli, but you’d be surprised as to how many projects launch without one.  This mistake is growing in frequency as the proportion of projects with virtual and/or global stakeholders & team members increases.

The causes for skipping kickoff meetings could include:

  • The project has been “on hold” or pending resource availability for so long, that there is no patience to do a true kickoff as everyone just wants to “do it”.
  • Everyone is so busy that it is impossible to schedule everyone’s time (especially across international time zones) to hold it.
  • So much effort has gone into the pre-project justification or sales work of developing a business case or negotiating the Statement of Work or contract that the kickoff is perceived as an academic activity.

To counter these excuses (because that is really what they all are!), here are some legitimate benefits of holding a proper kickoff meeting (preferably in-person):

  1. First and foremost, it’s the best opportunity for the project sponsor to present the vision and purpose for the project to the overall team (many of whom might not have been assigned during the pre-project phase) and to sell them on the benefits the project will bring to the organization and themselves.
  2. It’s a chance for the project manager to review project rules of engagement with all stakeholders and team members, and to be able to get the project sponsor to back him/her up visibly!
  3. It’s an opportunity to have a very quick, informal “fear, uncertainty & doubt” – the formal risk identification session will likely come later, but this meeting does give the PM the chance to start to understand the risk biases of project participants.
  4. While not a formal planning session, it can be used to voice and discuss assumptions and constraints to ensure they are in fact, valid.
  5. It presents the PM with the first real chance to see the body language and interpersonal behaviors of the team members and stakeholders.  If the PM has not worked with this group before, long running department or individual conflicts might start to become apparent.
  6. It starts the team development process in (what should be) a non-threatening and neutral environment.

Skip your kickoff meeting, and your project could end up as flat on its back like Charlie Brown!

(Note: I originally punted this article downfield in February 2011 on kbondale.wordpress.com)

Posted on: December 12, 2018 07:00 AM | Permalink | Comments (13)

“Medium” is another way of saying “Don’t make me choose”

Steve Kay, a Program Manager interviewed in the Closing Credit article of the August 2012 issue of PM Network made an interesting change on his mega-project – he altered the typical 5×5 risk matrix (e.g. very high – very low) to a 4×4 one to remove the “sitting on the fence” option for those participating in the qualitative risk analysis process.

This prompted me to check the risk registers for a few of the historical projects I’d been involved with and I noticed that when there is a three or five rating scale for probability and impact, the medium selection is picked much more often than one of the other choices.  This should not be a surprise since we can draw a reasonable conclusion that probability and impact values follow a normal distribution for projects with an average level of risk.

My concern is that the frequent selection of this rating relates more to indecisiveness or lethargy than to statistics.

The former cause might be tied to the common behavior in some organizations of people being unwilling to take a stand.  With a three point rating scale, providing a low severity for a risk which you had previously identified might incur the wrath of those minimalists who want the focus purely to be on critical threats or opportunities.  Doing the same for someone else’s risk event might put you at loggerheads with them as they might perceive a very different severity for their risk.  On the other end of the scale, assessing a risk event as high might brand you as a “Chicken Little”.

Such behavior might occur if risk analysis participants are lacking knowledge on what the different ratings imply and how to score risks, but more likely it is caused by participants that are uninterested in the process.  I believe that most staff are so focused on their day-to-day operational and project work and the “real” issues that plague them that they wish to minimize their effort spent on risk management which they perceive as being at best, an academic practice.

The recommendation in the PM Network article is a simple way to address the inappropriate use of medium ratings as it forces participants to pick ratings that will be either above or below the point of indecision.  This method could be enhanced by one or more of the following practices:

  • Take the time before qualitative risk analysis begins to clearly explain risk rating scales and illustrate their usage with examples.
  • Make sure that you effectively communicate the linkage between risk scoring and the responses that would be based on the scores as well as the implications of scores on risk reporting.
  • As of a follow up to the analysis session and only if you have sufficient risks to support this, you may wish to construct a graph of the distribution of impacts and probabilities to see if the overall shape of the curve “fits” the team’s perception of the overall project’s risk profile.  If it doesn’t, this could point to inconsistent scoring.

Yoda said “Do or do not, there is no try” – medium might just be the “try” of risk management!

(Note: this high value article was originally published in August 2012 on kbondale.wordpress.com)

Posted on: November 28, 2018 07:56 AM | Permalink | Comments (16)

Change requests should be read like tea leaves to help future projects!

Change requests are similar to many project management artifacts in that significant effort is spent over the lifetime of a project in creating them and getting them approved, but they are rarely looked at once a project is over.

This is a shame, since while the primary purpose of a change request is to formalize changes to one or more of a project’s approved constraints or baselines,  they can also be a valuable source of knowledge beyond the lifetime of the project.

Some examples of these benefits include:

  • During the final harvest of lessons to be learned at project closeout, change requests could be reviewed to identify change triggers that could have been avoided due to better planning, requirements gathering or stakeholder participation.
  • They provide a source of knowledge for the impact analysis or effort estimation on risks, issues and changes for future projects.  While their usage cannot be a substitute for knowledgeable subject matter experts, they can act as a reasonable substitute if these SMEs are not available in a timely fashion.
  • When change requests are reviewed across a portfolio of projects at regular intervals, they can help to identify chronic or systemic issues.  For example, if the majority of change requests are not scope related, but are instead being used to formally approve delays to project end dates, analysis could be done to determine whether there is a common cause for these delays such as poor resource capacity planning, ineffective work intake or prioritization, or overly optimistic effort estimation.
  • They can be used by project managers who are new to the organization to understand how projects are “really” managed as well as to help gain insights into the attitudes or personalities of specific sponsors.

Change requests are the rats of the project management world – we usually go out of our way to avoid them, but just as rats are a critical input into development of future lifesaving drugs, change requests can be used to improve the delivery of future projects!

(Note: No change requests were harmed in the original publication of this article in January 2013 on kbondale.wordpress.com)

Posted on: November 21, 2018 06:59 AM | Permalink | Comments (16)

A tree never hits an automobile except in self defense.