WBS by phase or deliverable?

In almost every project of any complexity, a debate arises as to how to set up the work breakdown structure.

Traditionally, it is about the work.  If you're building an airplane, you need engine, wings, body, and so on. They often get produced by different vendors so it makes the contract management and earned value reporting much simpler to keep these products together.  It allows one to see the progress towards having a completed component or product.  Besides, it's called a work break down structure - shouldn't it be about the work?  But more often that not, the project WBS looks like a life-cycle:  plan, gather requirements, design, build, test, deploy (or something pretty much like that).

As soon as you start decomposing a product-based schedule, assuming an organization with some level of process maturity, you notice that you're just cutting and pasting task names. Each element of the solution requires each of the life-cycle phases. Now each phase has deliverables in it, so those deliverables are repeated numerous times through out the schedule.  And each of them has a set of generally-identical steps: draft document X, review document X, update document X, obtain approval for document X, publish and distribute document X.   Very tedious.

It doesn't take long before somebody says "why don't we organize this thing the other way around?"  Put all the planning and approval actions together, all the requirements gathering together, and so on.  This is especially prevalent where the organization has defined a fairly comprehensive list of artifacts, while the actual products the project is to deliver are somewhat nebulous.  All the more reason to expose those products at the highest level of  the project!

The math on this is actually quite simple:  under every circumstance but one, it doesn't matter.  The number of tasks is the number of components times the number of process steps.

However, the one exception may actually be the norm.  If many of the product components move through the process at exactly the same pace, then they can be handled together on a single artifact set (requirements document/s for wings, fuselage, wheels as one document, requirements for the engine as a separate document, rather than tracking 4 sets of artifacts through their creation.  If the entire work is subjected to a series of phase gates, where work is essentially being steered towards at least notional stopping points, this is not an unreasonable point of view.   It does encourage a realization that the work does have to pass through these phase gates, and it does serve to acknowledge the governance's authority's right to stop the work where it doesn't seem to make sense any more.

The main disadvantage of focusing on the life-cycle rather than the work product is that it does seem to lead to a tendency to forget that the project is about getting actual working products or services into being rather than about getting a bunch of documents completed.  As noted above, if the project's real deliverable (not the artifacts) are unclear in the beginning, hiding that structure inside a canned SDLC structure is not going to provoke the necessary thought; such a project is almost sure to end up missing some very important capabilities, the absence of which may not be detected under the sheer volume of artifacts.

Now, what is NOT acceptable is to use a life-cycle approach for things that are turned out at different times. That completely masks visibility into the progress of the products.  For instance, if a solution will be rolled out in three distinct increments, it is very important that all the work leading to each incremental roll-out be part of an integrated package.   Much of the work for subsequent increments does build from similar work in earlier increments,  but that's no reason to package (for instance) all the design work for all increments under an overall "design" heading.

Perhaps one of the reasons that this issue keeps coming back up is the ability to pile a lot of detail into tools like Microsoft Project.  Just because one can do so quite easily does not mean that it needs to be done. Putting it in there is one thing; managing it is another (and no doubt there are professional schedulers who relish the job-security a grossly over-complicated schedule seems to provide them, at least until the project collapses under the weight of its overhead).  A grossly-abused "best practice" in project management is to have no task lasting longer than two weeks.  If we go to the references, we see that the actual recommendation is that tasks in a schedule should be no longer than twice the reporting cycle - and that reporting cycle should be based on what makes sense for the level to which reports are being rendered. No doubt a work team leader wants reporting weekly, but in that case, what is the proper degree of granularity for a business-unit executive?

Let's not forget the other guidance in this area: projects should be baselined (and then reported on) at the contract WBS level , which is defined as one level (at most two levels) of indenture below the contract itself and therefore at most only only the third level in the project.   If you've got tasks like "review draft report" in your schedule, you'd better be leading the team that is actually writing or reviewing that report.  If this sort of task is making its way up the reporting chain, you're adding a lot of fairly meaningless reporting overhead and costs to your projects, and the sheer volume of all that may be distracting you from much more important observations.

Is cloud computing the future or the past?

More years ago than I prefer to think about, we learned computer programming using a dumb terminal that could only do whatever the central processor agreed on -- and there were many evenings and many trees wasted on re-doing punch cards until the CPU was satisfied.  .  Anything beyond running the few programs we were allowed to use required the intervention of the "gold coats" - the system administrators, who knew how to run the machines but were of no help whatever with building programs.

One day, some brilliant young fellows in California (and an older fellow in Texas) came up with the idea of providing people with the ability to do their own computing.  In a remarkably short period, the entire planet underwent a new industrial revolution.   And in a remarkably short period of time ... the experts want to turn it all off again.

Hot new trends include virtual desktops, tablet computers and cloud-based software.  All of them have a common thread:  without connectivity; they are completely unusable.  Everything must be done through the central processor, or nothing is done at all.  Sure, it's handy having a solution right out of the box - well, really without a box at all.  Just log in and off you go.  Once established and proven, a cloud system will probably be pretty effective in meeting the center-of-mass requirements.  If the cloud system has already worked out how to interact with other systems, you can have a whole suite of software solutions at your fingertips in a matter of hours.  But you'll need to do everything their way.  And you have to trust them to get it right.

As it happens, I am a fan of cloud solutions.  You can get productive very quickly, effectively and generally inexpensively.  But before going all-cloud all the time, stop and think about whether you are fully comfortable with the risks you must assume.

If we have learned anything in the past decade or so, it should be that large organizations will, by the sheer law of averages, make large mistakes that have great impacts on everyone else (although seemingly little consequence for themselves).  A large provider's network operations certainly are run better and cheaper than you could do for yourself.  But when large providers do fail, they do so on a large scale that it is hard to avoid.  You or our company can join the victims of technology or data events that are related to your business only in the very vague sense that you (and thousands of others) share your computing space with someone else.

The whole point of automated work is to make it more productive.   The ultimate cloud application - remote working - takes care of having to shut down the business just because of icy roads.  Workers can stay home and work.  Of course, all these things have flip sides: if your remote workers cannot connect, then you're back to paying everyone to not work.  Or, if you have virtualized your desktops in the office too, then you'd better make sure your network is very stable.  The only thing worse than paying people to sit hoe and not work is to make them come into the office and paying them to sit around and not work. Productivity gains from allowing workers to telework instead of losing a day to weather are erased if the network is out of action for a day.

Does all of this matter?  As far as being able to do anything about the inexorable drive in the industry to put itself out of business, probably not.  But it is worth thinking about whether one-size-fits-all does in fact fit you, and what you're going to do about those times (and they are definitely "when", not "if") when you and your team cannot connect to the network.

Can you afford to be Agile?

Agile practices have the buzz of yielding results that are better, faster and cheaper.  But if so, why is it having such a hard time catching on?  Sure, many people are using it, but it is still considered a bit of a fad

I like the approach myself, under the right circumstances, and I contend that I have been using it for about as long as some of today's coders have been alive. Prototyping and mockups; Rapid Application Delivery; Joint Application Design -- these are all forerunners of Agile, all aimed at cutting through the ever-increasing pile of documentation that slows development and adds to its cost.

And let's stop calling everything Agile just to try and stay in the cool-kids club.  Releases every three to six months aren't Agile. A normal set of Agile sprints - 6 to 10 - would take 2-3 years to complete at a quarterly cadence, and most of these so-called Agile efforts don't deliver working product for the first 2-3 sprints anyway.  A year from inception to first delivery?  That's not Agile. It's iterative (and nothing wrong with that).

Over the past year I've had the opportunity to fund my own software development effort and certainly did not adopt an Agile methodology.  I've also set up a major development effort in an organization that does accept the Agile construct - but for this project we didn't use it. If Agile is so great - why didn't we use it?

• For smaller development efforts, Agile is VERY expensive.  A standing team of developers and business analysts (even if it is only a couple of people and working at well below market) costs 160x50 = $8,000 per person per month. Let's say only 4 people, and say 3 months to run 10 sprints after setting the project up.  With a couple of extra thousand in incidental expenses, that's $75,000 to flesh out requirements and develop a minimal viable product.  Don't even think these folks are going to "work for equity" - they have to pay their bills, and you're stopping them from making money elsewhere if you're asking them to go full-time on your project.  Most startups can't handle that amount of investment. Even if they do have the money, or even if you are thinking about a smaller application within a large company that can afford to pay these folks, is there a business case for spending at least $100,000 by the time the solution goes into production?  That's not "just a little application".  Incremental iterations won't be as fast or efficient for the same amount of code, but they can be more affordable.
• In the larger situation, we're not building an application.  We're building out a major infrastructure capability.  The full scope hasn't really been shaken out but it needs to be in place when the customers need it -- that puts us in front of them, which creates some challenges, most particularly that they haven't really locked in on what their needs will be at the time that this infrastructure is needed.  We don't yet have a solid future-state architecture.  And the hardware and software versions that this capability will use aren't even for sale yet.  We can't just start developing a solution.

Again, I like Agile - in its place.  There are far too many artificial barriers to using it in larger organizations.  In future postings we'll discuss those barriers and some was to get past them.  At the same time, let's not blindly chase the trend.  Sometimes, Agile is not the right answer.

Have you got examples of where an Agile approach is either impractical or undesirable? Maybe we can work out a classification system that would help people cut through the hype and pick an approach that will work for their actual situation.

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.