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)
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
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:
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):
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)
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:
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)
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:
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)