Projects will continue to fail when nobody has the will to make them succeed

Hope, they say, is not a strategy. Without any idea of how to execute, or the will to simply do that which already know how to do, an elaborate "strategy" is not even hope: it is hopeless.  So many after-action reviews conclude that a project failed because it was under-resourced.  What most project retrospectives will not say (wisely, for career purposes, but indicative of the problem) -- the elephant in the living room, if you will -- is that the primary missing resource may be courageous leadership.

Can it be that the same elephant lurks behind the decade-on-decade consistency of the Standish Chaos reports?  Why do large organizations, including but not limited to the federal government, have so much difficulty getting projects completed satisfactorily, let alone on time and on budget?   Why do they have to re-implement basic project management practices every 4-5 years?  Can it be that nobody really cares what happens with all this money or whether these systems really work or not?  Or at least they do not care about that as much as they care about not offending any of their buddies or not changing any current behaviors.

Wanting something to succeed doesn't mean it will.   Projects do not succeed just because the leadership and/or the team maintain a cheery attitude, all smiles and no commitment.. You have to want it enough to motivate yourself to do the things that will make it succeed. If you are not willing to push yourself (and, more importantly, others) to do those things, then the project will fail no matter how much you had hoped it would succeed.  Courageous leaders do what needs to be done, make others do what they know they should do, and refuse to allow the organization to fritter away its time and money on things that do not need to be done.

Why would an organization's leaders undertake a project if they don't really care about it?  Again, if by "care" we mean "enough to do what needs to be done", Healthcare.gov (the Obamacare website) is Exhibit A.

Before going there, let's give credit where it is due to the many competent government managers and contract IT companies that are annually delivering over $30 billion in IT projects that are delivered without incident.  Well, according to the Federal IT scorecard anyway.  And we should note that the IRS' ACA companion piece -- also highly complex and highly expensive -- did work just fine.

Why do we keep re-hashing Heathcare.gov?  In the less-than-uplifting words of Hillary Clinton, "after all this time, what does it really matter?"  Healthcare.gov keeps getting re-hashed because (a) the truth keeps changing and (b) it provides so many object lessons in how to mismanage a project.

Nobody can suggest that the administration did not care about the success of this project.  At the start, anyway.  It was, after all, the means of implementing the administration's signature accomplishment.   It had tons of money.  It had plenty of time, indeed, from the outset it was derided for the overtly political delay of the program for an entire Presidential election cycle in order to avoid the possibility of failure before the next elections.  And, while ambitious, the scope was eminently feasible. Progressive Insurance (and no doubt others) has been providing real-time policy pricing comparisons since at least 2007.  The government's own employee health insurance system displays dozens of options.  In other words, unlike a great number of other initiatives that are obviously half-baked from Day One, this one had every likelihood of succeeding.

In many organizations, the governance process appears to stop with the project approval process.  Other than setting resource priorities, the choice of specific projects may actually be the least significant of a governance board's contributions.  Given clear priorities and budgets, program managers can usually figure out what projects need to be done to accomplish the program's aims.  What the governance board can uniquely do is to sweep away obstacles when, as they must inevitably do, projects run into problems AFTER they have started.and governance processes are the means of helping them through to a successful conclusion.

So it should have been no surprise when Healthcare.gov encountered challenges.  As usual "the contractors" took the blame.  The selection of a vendor without experience in this domain was a reliable predictor of the eventual outcome, but the fact is that the contractors reported the issues in plenty of time to have taken some corrective measures -- except that their reports were swept under the rug.  The contractors insist, and have never been contradicted, that they were reporting issues over a year in advance of the roll-out.  The Federal IT scorecard shows that particular project reporting "green" for quarter after quarter, until January of 2013 (nine months before the roll-out date), when it reported itself as "red" with some concerns noted about unsatisfactory test results. Evidently HHS conducted some sort of intervention that it felt to be satisfactory, as the project resumed reporting "green" until August 2013, 2 months before the roll-out, when the ENTIRE  Federal IT dashboard conveniently stopped reporting  for several months.

Well, the secret is out, and things are moving nicely now that the incompetents have been removed from office ...  oops, that was the script for another movie, I guess.  To this day, the identities of these incompetents remains a mystery.  And what a mystery it must be: the same press corps that has no difficulty finding illegal aliens or international terrorists when it wants to interview them is completely flummoxed when it comes to locating ostensibly public servants. Still, we should not have to rely on the press.  The point of governance is that you set up a framework to preclude, or at least to identify and deal with, problems yourself.  The administration's lack of interest in finding out what happened and firing those who were responsible is a crystal-clear example of the leadership failures that cause so many initiatives to fail: simply not caring enough about getting it right.

Didn't we say earlier that obviously the administration really wanted this project to succeed?  Sure.  But apparently an even higher priority was  to avoid any suggestion before the elections that the system might encounter problems, which was accomplished by suppressing that information, thereby ensuring that the problems would occur.  Apparently an even higher priority was to avoid any possibility of anyone being exposed as an incompetent and disciplined -- which ensures that future initiatives will turn out in exactly the same way.

Maybe you were thinking all this is confined to the public sector because it doesn't have the market discipline of the private sector.  It won't take you long to think of several examples of particularly stupid or venal decisions by private sector executives leading to substantial problems for their companies.

What is a simple project manager or portfolio manager to do about all this?  Surely these issues are quite a bit above their pay grade?  Yes and no.  At the outset of a project, you can insist on knowing where your project falls on the priority list so you can assess the viability of your resource assignments.  You can establish a clear reporting process and an escalation path.  You can make sure hat deciders have the correct information with which to decide.  But it is true that if executive leaders are weak, indecisive or corrupt, then most of the time things that are at all out of the ordinary are not going to go well, and you'd be well advised to find another organization in which to practice your profession.

Why should we care about basic operations?

Operations is often viewed, even by its participants, as low-level drudgery, unappreciated (at least until the lights go out), and generally hardly worthy of a manager's valuable time. Project managers, portfolio managers and governance boards are near-unanimous in wanting to analyze, rack-and-stack and execute the exciting work of projects.

PMI is not the only source of PM wisdom but you can't deny that it is influential. One of the long-running battles in the PMI community was the role of operational activities. In retrospect, this was very unfortunate as it set a generation of project managers off on the wrong foot on the road to understanding how projects really work in the larger organization.

As long as PMI was only interested in how PMs could manage the one project they were assigned to, one could close one's eyes to operational matters. Eventually the community recognized that projects seemed to be connected to other efforts that kept moving around, and PMI adopted the concept of a "program". Well, really they only adopted the word. In their language, "program" meant a collection of related projects, and -- here's the unfortunate part -- the definition specified that the program could not contain any non-project work. Yet most project managers will testify that one of the greatest challenges on their projects is that their critical technical experts keep disappearing to deal with emergencies in the operations world.

Meanwhile, in the DoD, which had been running programs for a long time before PMI came along, programs most emphatically do include operations and maintenance activities. The program must account for the cost of keeping the lights on once the hams on the project teams have left the stage, and a great deal of the early analysis goes towards validating the vendors' and project manager's claims that their solution is "maintenance-free". Every dollar or hour that goes into maintenance after a project is over is a resource that cannot be applied to some other project or activity. And, despite the importance of the innovations that projects are to bring, most organizations have been extremely unsuccessful in building a culture where "important" outweighs "urgent". I've seen several CIOs who wanted to see themselves as value multipliers if not actual profit centers for their organizations -- but as long as the e-mail system was acting up, the other executives had no intention of investing in innovation as long as the company was having a problem handling as-is technology.

In my own experience, we found that the annual infrastructure support costs were growing at a rate far exceeding inflation -- and this in an industry that prides itself of Moore's Law, which should suggest constant and dramatic declines in costs of service. One of the stark realities of operational costs is that you can leave them out of the budget sheets if you want, but they'll still show up. Then there is no option to just let things go until the next fiscal year. Our program management team applied the DoD's default support costs (100% of the acquisition costs spread over the net 5 years) and concluded that the operational activities would consume the entire budget, leaving no funding for any significant project investments, within the next 3 years. This assessment was pooh-poohed in the first year, and the executives added on another few million dollars worth of projects (which would also have to be supported eventually). But by the end of the second year it became clear that the inflection point had already been reached. And the money that was spent on those projects was gone -- you can;'t just turn your unused code in for a refund. Key organizational priorities had to be shelved for a year or more, and the organization had to fund a short-term increase in the budget to fund an investigation into how to reduce operational costs.

Do your programs and governance processes exclude operational costs?
Are you finding that the project work always seems to be delayed, mostly because of resource availability?
How can you change this?

You cannot make significant structural changes overnight. That makes it all the more important to start campaigning to bring operational costs under management control along with the rest of the budget.

Backroom deals as a governance process - why not?

If governance is about making the best decisions possible, wouldn't you want to do it in the best way possible?  Wrong on two counts.

Perfect is often the enemy of good enough.  Too many process-improvement efforts come to grief on that rock, and governance seems to be particularly subject to it.  The key facts are:

• the people who run the organization will continue to run it after the process project is over.
• the processes they have been using got them to the top.  Why would they change?
• they are at the top.  The process-driven offices that tend to sponsor governance efforts tend not to be at the top.  Many PMOs, most acquisition offices and almost all enterprise architect offices are buried several layers deep in the organization.  Generally, top executives aren't too excited about being critiqued by anybody, let alone some staff groups they never heard of.

What if the effort is commissioned at that highest level?  Then there is certainly more opportunity to achieve something of broad utility. But it's not going to happen by demanding that the decision-makers start managing out of a book. Once in a while a fad (remember TQM?) may sweep their preferences aside for a short time, but the central fact is that these folks got where they are by doing (largely without having to think about it) what they are doing.  The burden is on you to show how that isn't working as well as it could -- without suggesting that you are smarter than these top leaders.

The second aspect is even more important.  Governance practices are about making clear who gets to decide, how they are allowed to decide, and how anybody knows what was decided. They are not inherently going to produce better decisions, except to the extent that "sunlight makes the best disinfectant". Leaders who are accountable for their decisions tend to want to make better decisions and may be inspired to seek out the due diligence practices that "good" governance represents.   But of itself, governance is not about making wise decisions.You can have good governance processes and yet have really lousy ideas.

Which brings us to the original question: can a secretive process be the approved governance process?  Of course.  If that is the way the senior leaders are going to make decisions anyway, then why not let everyone else know and save a lot of time in pointless meetings trying to convey the impression that  some other process is going on?  Does it really matter whether a PM makes a certain presentation to the leadership group if that group is comfortable that they have made the right decision based on all the information that they have?

If you don't buy that, consider what should happen if the board thinks that the PM's presentation is flawed.  The members can only know this if they bring into the process their own knowledge or experience that goes beyond whatever the PM has presented -- and indeed they must be able to discard the information that the PM does present.  Then perhaps the presentation itself is not the deciding factor, and may be barely relevant.

Does the governance body even have to be a group?  Can a dictatorship be a governance process?  Again, well, yes.  If that is how the decisions are going to be made anyway, just say so and be done with the hand-wringing.

Whatever the method of making a decision may be, the important thing is that to make sure that everyone knows what that decision was so they can get on with executing on it.

The only "governance" practice -- well, really a non-practice -- that is NOT acceptable is a process in which people go in to the decider/s is in secret and nobody does find out what was decided.  The inevitable next step is that the next person who wants something also goes in for a private meeting and then -- at least according to them --  gets their own decision which contradicts the first decision.  From that point forward, resource contention becomes the order of the day.

Governance can work fine with a secret and/or dictatorial decision process.  But it does require that the resulting decisions are adequately publicized. Pravda, anyone?

What is this Governance anyway?

Governance.  Woooo.  Such a scary-looking word. Sort of like --- aakk! -- "bureaucracy". But all it means is knowing how the organization makes decisions. Which is not to say that it is easy to get right.

Governance is just the process of defining how your organization will:

• make decisions
• see that the decisions are carried out, and
• see whether the decisions are working as expected.

What's so hard about that? As the far as the words themselves, it all sounds pretty simple. Actually doing it can be another matter altogether. That explains why organizations continue to pay whacking great fees to the usual consultants, who now form a trillion-dollar industry, to provide them for the umpteenth time with a set of recommendations, procedures and templates that are no different from what was received the first time. They are, after all, best practices - or they would be, if anybody practiced them.


What we get out of governance is the framework that makes it possible to identify the right things, exclude the wrong things, and execute the remainder effectively.

The tools of governance are also fairly well-known: strategic planning, tactical planning, budgeting, financial management, contract management, human resources, project management, portfolio management, process management. Effective governance requires several equally well-known supporting skills such as cost estimation, market analysis, budgeting, contract management, human resources, and other skills that are particular to some industries. Probably the only arm of governance that the average manager might think to be something they know little about is is business and enterprise architecture, and as we will see, they already know most of what that is all about; they just didn't know it as "architecture".

That wasn't so bad, was it?
Why would we NOT do this?
Let's get started!

Please feel free to leave a comment, and explore the rest of the governance blog series.

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.