Is a governance board a rubber stamp if it always approves projects?

Consider a recent article by Mark Suster, suggesting that the decisions at a governance board meeting should be foregone conclusions.  Would't that make the board pretty much a rubber stamp?  Maybe, but not necessarily.

What are effective metrics for seeing whether your governance process is effective?
At first glance, if a so-called review board always approves everything that it is presented, perhaps it is just a rubber stamp -- a pointless waste of the time lost in the pause needed to get through this milestone review.
So a metric might be the proportion of reviews resulting in approval.
Not so fast.

When checking your premises, there is value in going to the opposite extreme. What if the board rejects almost everything?  For those who actually made the effort to prepare something properly, over-engineering a decision package in hopes of trying to get over an unreasonable bar is a waste of effort.  And everyone will be finding ways to evade the process completely.  These don't sound like the symptoms of an effective process..

Mark argues that it is not in the nature of executives to debate one another -- with winners and losers -- in open forum.  Forcing that dynamic can produce unpredictable consequences.  Things may work better if the PM briefs the members beforehand and deals with any issues.

The problem with this "political" approach is that it leaves a lot of doubt as to whether the due diligence which was the board's responsibility is really being carried out.

Here are some circumstances under which near-automatic approvals are signs of a working governance process:

• The proposals already form part of an approved higher-level program - or the sponsor of that program has agreed to cancel some approved work in order to make room for the new idea
• The board meeting has been preceded by technical reviews which confirm that (if approved) the project should be delivered effectively
• The decision materials that are furnished clearly illustrate that the project team has thought through the issues and approaches

By the way, these are "and" statements, not "or".

Does your board approve everything put in front of it?
Does it have these assurances?

If not, how do we go about moving it in a more transparent and effective direction?

We do not always fear failure if it is someone else's

Getting along by going along may be the current trendy mantra but it spells disaster for governance in particular and organizations in general. The whole point is to make sure that the questions that ought to be asked before dumping a lot of money on a bad idea, do get asked.

Sometimes accepting an inadequate result so that everybody will feel good about themselves may be tolerable. Kids need to be encouraged and gain confidence on unimportant things. Most work-related things are not thst way.

When there are millions of dollars, or dozens of jobs, on the line, it's no longer appropriate to smile sweetly and let things continue on.  But -- of course in the past, not, ahem, in my current assignment -- I've seen this a lot.  "What are you trying to do, embarrass me?" Well, no, not really. I tried to help you get ready for the decision board meeting but you decided it was a hassle.  Hundreds of thousands, or millions, at stake and for you a bit more than a 3x5 is too much trouble. All the templates do is make sure you've thought of the key points, but you still have to think the matter through. If you're unable to address those issues when the board asks about it, whose fault is that. Yup, you do look bad. Rightly so.

I definitely don't want that mindset going on with regard to anything that is important to me. And I've seen it recently - even in life-threatening situations. Sometimes professionals are reluctant to embarrass their colleagues; fortunately my spouse has friends sufficiently prominent in their profession that they're able to "just sit in to see what's going on". Amazing the change in open-minded vonsideration of the possibilities when that happens. So it should be when your project governance board members are getting briefed.

Schadenfreude.  What a grand rolling word for a very destructive urge: taking pleasure in watching someone else fail. If we know they're on the wrong track and we don't say anything, are we really just helping them avoid embarrassment now, or are we cheerfully ensuring that the embarrassment will surely happen?
 

Decision-makers' primary fear: loss of power

"Power corrupts; absolute power corrupts absolutely".  That quotation -- itself corrupted by long usage -- probably did not really originate with Lord Acton.  Through some tortuous means it came to him from an originator in the Cro-Magnon era.

I prefer John Steinbeck's version: "Power does not corrupt.  Fear corrupts - perhaps the fear of the loss of power". (Hat tip to goodreads.com).  Many of the odd behaviors standing in the way of effective governance are really all about people being afraid of losing power.

Many appointed (vs. professional) project managers people resist governance initiatives because they think it imposes a lot of extra burden on them - decision papers, approval boards and so on, for no apparent value.  That can be true, but the reality is that in codifying governance process, the real people being constrained are those who were until then exercising unaccountable power in the course of making decisions.

In very few organizations are the executives and senior managers actually stupid.  What they do is what works for them.  That may appear counter-productive for you, but that's because you are on the wrong side of the value chain.  Your ideas may be theoretically sound, and they may even be objectively better for the country as a whole of even for the stockholders of that company; but that isn't what has gotten these top managers into the positions that they are in.  And you may rest assured that they will use every trick in the book to avoid letting your new-fangled ivory-tower scheme make any inroads on something that has benefited them very well.  The fear of losing power will motivate them pretty strongly.  The managers most likely to resist governance are unfortunately those who could most benefit from it: the weak managers who, unsure of their own skills or knowledge base, avoid any possible exposure of weakness and see any predictable process as an infringement on their sovereign rights.

What happens in an organization that appear to lack governance?  (Actually it has governance, it just is not codified.  And it is ugly.  But things happen somehow).  If no decision is recorded, then nobody in authority can be held responsible (you can be sure, however, that the lower level line manager will take the fall when things go too far wrong).  If no decision is taken in public, and/or no decision is final, then managers never have to tell anybody "no", never have to account for any decisions, and never have to deal with the consequences of allocating the same funds two or three times over.  Consistently the result is the same. Unrealistic promises, no priorities, and nothing ever gets done even in part before being shoved aside for the latest crisis.  The organization spirals from decline to chaos to implosion. Then some outside auditor cleaning up the mess says: "What you need is to implement some project management best practices".  Without a change in the organization's culture, this will simply kick off another identical cycle.

Project and program managers often say they are frustrated by an organizational inability to get anything done because it is never clear who has been tasked to do what. Surely this is an easy fix?  The head of the organization (or a board) needs to set and enforce priorities; how hard would that be?  Since so many organizations are having trouble with that, evidently it is quite hard.  It requires the executives to be accountable for decisions they make (never a secure route to the top).  But if there is enough squawking about actual impacts of indecision, changes may well ensure.  The interesting thing is that all too often, the squawking can be just for show.  In all too many of the organizations in which project and program managers bemoan the lack of governance, we find some of these events happening:

• Program managers drop into the vice-president's office to get some funding out of the apparently bottomless budgetary grab-bag for yet another project
• Project managers routinely overshoot project dates and budget (again reaching into the miraculous bag to pay for the overruns).  Actually delivery dates and costs are not even tracked in any material way.
• Project managers do nothing about resource availability conflict.  After a while they just extend out their completion  forecasts. Actually nobody is really checking on those anyway.

Now one can argue that at some point a PM simply becomes tired of fighting the battle, and likely finds it to be career-threatening.  Maybe it is better just to do what seems to work.

But it is possible that the situation is not as bleak as you might think. I repeat: most executives are not stupid. They are indeed largely political animals, but it also means that they are probably compulsively competitive, even where there is nothing to compete about.  They are capable of discerning that everything they do turns into a disaster, even if they are pretty good at papering that fact over, and they'd rather have an actual success than have to spend time always papering over failures.  If a PM has the facts, and does a decent job of the analysis, it should be very possible to take these simple steps:

• Report pending resource contentions
• Report other issues that the PM cannot solve without higher-level assistance
• Know what the impacts are of not getting a decision (and by when)
• Have some ideas as to what an effective relief action might be. Whining doesn't solve anything.

This has worked for me in some pretty dysfunctional places, and it could work for you.  Of course in the fifth year of the longest non-recovery in history, PMs may be reluctant to stick their necks out by offering suggestions that their projects are in less than stellar conditions, particularly if the leadership seems so obtuse that they might not notice this themselves for months or years.  If that's your situation, then a PM's gotta do what a PM's gotta do.  I get that.  Been there, done that. Keep cashing the paycheck, but don't blame your frustration on a broken governance process if you're the one helping it stay broken.

Fear of losing power (or losing your job) corrupts absolutely.

Earned Value and Agile - back to the future

"Ignore the arguments against Earned Value from those who have not successfully deployed it" (Glen Alleman, handle @galleman ).  Hat-tip to the College of Performance Management and presenter Robert VanDeVelde, although in this post I am going to deviate a bit from the direction that Dr. VanDeVelde went. .

The current dogma is that Earned Value Management (EVM) cannot be used in fixed-price and Agile, which only happen to be the the two methods of project delivery that are recommended nowadays in preference to old-school cost-plus work.  To spin off the quote that leads this post, we can be sure that this nonsense is being sponsored by those who benefit by avoiding measurement.  It is not true for fixed-price work (we'll get to that in another post). And it is not true for Agile; in fact, that returns us to the original intent of EVM.

Agile by definition attempts to maximize earned value (EV) within the constraints of resources and time.  But how to measure that EV?

• Cost as a surrogate.  Oops, back to cost-plus.  The more hours you plan to charge, the more value the delivery has.  Well, in fact this is true for the contract coders! But not for their customer.  Even assuming no sharp practice by the coders, what if they don't need all the resources for some sprints, which therefore cost less.  Are the features built in that sprint less valuable because they cost less?
• Story points.  Here a knowledge of the vocabulary is useful.  The Function Points that are used in software cost estimation are based on parameters of the effort required to code specific capabilities of a system (interfaces, file transfers etc.). Agile story points are even vaguer: a relativistic measure, unique to the team, that assesses the relative effort of coding one feature or another, simply to determine how many features can be attempted in a specific cycle.  This is problematic on two levels:
• At bottom, it is just a measure of level of effort
• It takes quite a bit of time before the team reaches a stable enough definition of the points and a stable enough working environment that it can define its capacity to do X many story points in a sprint.  Until then the metric is quite useless.
• As a team gets more competent it can knock out more features in the same amount of time, but the measurement system (often expressed as "T-shirt sizes" - small, medium, large) remains the same.  So the metric itself changes over the life of the project, with considerably more content in a later "mediium" than an early-round "medium".
• There is still no relationship between the story point and the value of te feature.

So labor costs or labor effort are not good surrogates for value delivery. Once we've gone there, we can open up any number of non-financial metrics instead.

If we are going to do EVM on a project that uses an Agile approach, we are going to have to award customer value points to the features up front (this is also true for non-Agile approaches, but that's a post for another day).  There are a number of weighted value approaches that one could take, but why fix what isn't broken?  Agile already requires us to prioritize the features so that they can be allocated to sprints and releases. As a simple start, assume that the features have value in the same degree to which they have a priority ranking - only in the reverse order, e.g. in a 30-feature list, the lowest priority feature would have 1 value point and the highest priority feature would have 30 value points. In practice the project team needs to establish some sort of weighting system to separate the features from a simple ranking system.

Using this approach, one can develop an earned-value delivery curve which would NOT be a straight-line that simply reflects the team's capacity to do work.  It would in fact show diminishing returns later in the project - precisely the point that Agilists intended to make in the first place.  Staying ahead of the earned value baseline means finishing the features that have the highest priority, and the team cannot pad value statistics much by stuffing in low-hanging fruit from the bottom of the priority list.

Why did we lead off with "back to the future"?  This is exactly the process that was advocated when earned value first appeared. At that time, EVM distinguished itself from the then-current Cost/Schedule Status Reporting approach precisely because it tried to break the cost = value linkage.  The point then was that one should maximize the delivery of the things that provided value to the customer, not maximize the number of hours billed or the number of lines coded.  The real problem is that EVM has been co-opted by the usual suspects into an endorsement of the cost-plus mind-set -- the precise problem it was intended to solve.  Welcome to Washington.