Wall Street is not the best model for your portfolios

Portfolios and programs are not the same thing at all. There's another post that discusses what a program is. So what then is a portfolio?

Courtesy rgvmetro.com

This term gained currency during one of the great stock market run-ups (the pre-dot-com-crash one) when everyone fancied themselves to be the next Gordon Gecko.
Financial advisers were always pursuing you to balance your portfolio.
So the PPFM world glommed onto the word "portfolio" to make their idea sexy. The problem was, everybody assumed that project portfolio management worked the same way as your Merrill Lynch statement.
It can, as you will see in the later fuller discussion of the topic, but it doesn't have to, and for most organizations it doesn't.
The Wall Street model is based on assembling a market basket of financial instruments and balancing their risks and rewards; but in the end they are all just different forms of money.
in most organizations, there are stovepipes in which some level of activity is needed, no matter how worthy the activities in other stovepipes may be. No algorithm can model this short of actually specifying what the selected investments are and then faking up an algorithm that reproduces that selections.
In such a case, a portfolio management effort to use a unitary weighted criterion list that decimates certain types of investments is sure to be rejected.
And so they are, on a regular basis. That is why the Wall Street model has not worked in situations beyond financial instruments.

At this point, we can just agree on terms.
Actually you can disagree if you want (hey, comment away!) but at least you'll know what I mean when I use the term.

Portfolios are groups of things that are similar in some manner, perhaps just one manner.
Similar, but not necessarily dependent.
The portfolio provides a means for a manager who is concerned about that item of similarity to look at a wide range of activities, perhaps even all activities in the entire organization, to assess how they stack up with regard to that particular aspect.
One might have a portfolio of all security-related IT investments in the company. Or a portfolio of all IT investments of all types, with the data being examined being the specific issue of whether or how they conform to the company's security standards. In a non-IT setting it could be a look at all employee records to see whether they are current on a particular certification, or it could be the list of all applicants to see how diverse they are. It could be an inventory of bubble-gum trading cards that is being tracked to see whether all active players are represented, or to see which ones have the highest resale value and why.

In other words, a portfolio can be anything you like if they can all be assessed against a common measure, and if that is what you want to measure.
The examples above are a sort of portfolio. The common thread is that they all involve someone analyzing all the items in the portfolio against certain criteria.
In a later set of posts we'll go into how a portfolio is managed, and how that fits in with the organization's program and project management processes.

For now, we'll just say that portfolio management is the practice of evaluating many alternatives against a specific set of criteria.
Nothing more, nothing less.
It might be the means by which the organization selects its investments. It might just be a list of the systems that have employee information in them. The portfolio manager may have decision authority, or may have veto power, or may just be a staff functionary.
It may be used to choose, to rank, or to find things that do NOT fit - as in the picture.
This is not to denigrate the role of portfolio management, just to define what it is. At least, what I think it is. Your experience and ideas may differ: feel free to share your view.

Forrest Gump and the Analysis of Alternatives

Forrest Gump observed that "life is like a box of chocolates.  You just never know what you are going to get".

In most cases, assorted chocolate boxes come with a code to the different shapes that you will find in the box.  You may not know what combinations will be in the box, but once you're locked into that box, it may often be perfectly clear as to what your choices are and what each one brings.  Unless of course the seller has given oochy-kootchy names to the little delicacies so you have no idea what is really inside.  "Misty Mountain", for instance.

This situation has plenty of work relevance.  First of all, on the large scale, you never really know what the mix in the box is going to be.  If I ever write an autobiography I think I will call it "Things have changed" (hey, that's copyrighted now, you can't use it).  Whether forced by the external environment, or a lack of planning, or just the caprice of the organization or just one manager, it is not uncommon that organizations make radical changes of direction quite often, even when there is no real reason to do so.  And just as often, the organization somehow never seems to get with the program that its current executives have thought up. So if indeed you find that you are dealing with a box of chocolates, be happy; most people are trying to swallow something that has somehow turned to - well, evil-tasting, for sure.

So let's sneak a peek under the lid of the box.  It doesn't promise what you are going to get on the next bite, because that's pretty much up to you.  Hopefully, it lets you see what your choices are so that you can pick your favorite, or save your favorite for last, or maybe pawn off your least favorite on your sibling. This is pretty much what your governance board is hoping to be given to work with.  The overall situation that requires a decision (the box) is what it is, at least for the moment.  Now they'd like to understand what the options are - some less appealing than others, but all practical choices depending on their assessments of what would be best at this time.

How very different the material can be when it is brought forward for a decision:

• There is only one candy in the box.  Take it or leave it.
• There are only two candies in the box.  Hey, there's a choice!  Except that the other one is a horse apple.
• There are no candies in the box, just a thick document full of generic phrases about how important it is to eat candy now and then.  And the invoice for the box.
• There are no candies in the box.  There are a lot of fishing lures and other shiny objects that are appealing to someone for other purposes, but nothing in the box is really very relevant to the thing you are trying to get done now.
• The box is completely empty, but the salesperson holds it tightly in their hands, keeping up a running patter all the way to the cash register and avoiding any effort to actually look inside it.  Well, you wouldn't really understand what these things are anyway, you just just give the man the money because ... well, that's what you're there for, isn't it? 

Anyone else have any other examples?

Next time you look at an alternatives analysis, no matter how slickly presented, ask yourself what's in the box.

As Forrest Gump would say, that's all I got to say about that.

Right Solution, Wrong Problem

So you got selected for this great Director-level job, and you've been given the task of "implementing Project [or Portfolio or Program] Management.  It's our top priority this year". Straight from the horse's mouth, which is to say a very senior executive.  Yeah.  Congratulations, or something (h/t Glen Kessler, Washington Post). Now don't go all Messianic, and don't let your head swell.

First off, any organization whose top priority is to implement a fundamental supporting process is probably in big trouble.  Hopefully their top priority has something to do with the mission, or making money.  Is your sponsor really trying to snow you on Day One? Now this is not to say that PPFM wouldn't help; but we need to be very clear about what problem it is exactly that they think will improve through PPFM.  That will be your ticket to success.  

Here's your bedrock principle in the PPFM world: a PPFMO cannot be effective by trying to force an organization to change. It can only facilitate a change for which there is already a consensus (at least among the key influencers).  Remember "RTP" when you were preparing for the Big Test (whatever it was)?  Why wouldn't this be true in real life too?  Make sure that you Read The Problem; then your PPFM solution may turn out to be the right answer.

Unless you've invented an entirely new theory of business, you're not bringing to an organization that can afford to hire you anything that they don't already know about.
In the organization you are joining (or that has promoted you to this assignment), key people know perfectly well how to do alternative analysis, how to do scheduling, how to do budgeting and so on and so on.  You're not really there to show them how to do this.  You're there to implement something that until now they have chosen not to do.

So your number one question, beginning with the hiring interview if you get the chance, is to ask "what's different today?"
Until today, the organization has not needed or wanted to do structured decision-making or planning, nor hold people accountable.  Now it does.  What's different?
Be very skeptical of answers like "We want to be completely compliant with [XYZ standard]".   Really?  So what's changed to make that a priority?
Keep drilling until you get an answer that either makes sense or at least seems sincere.

"We had an inspection and they say we need to buck up our project management".  Sorry, not good enough.  Doubtless this sort of inspection has happened before.  What is different this time?  Perhaps the unit has a new manager, but unless there is something more behind it, the business inertia will overcome the new manager's enthusiasm.

What sort of answer would be acceptable?  One that sounds honest enough as to why they would feel a powerful need to make a change in the culture.

• Our customers are losing confidence in us because it's obvious we are totally disorganized.
• We are having a lot of turnover because our staff feels like they are just getting jacked around and they never can get anything accomplished.
• Our investors are hesitant because they say they are nervous about our ability to deliver

The answer doesn't have to be totally, bet-the-company dramatic.  They can have a narrow scope as long as it is clear that the speaker really wants a real problem to go away.

• "As the CxO, I am very frustrated that I never can find out what is going on.  I need better visibility.
• We have work piled up in this one process and those guys just flounder back and forth from one thing to another as the senior execs yell at them.  I wouldn't mind waiting if I knew the work was going to get done eventually, and when".

Now you have an idea of what the scope of the PMO should be, at least initially. Solve a problem that people want to have solved, and they'll support you as you seek to extend your mandate to a more complete service.  Over-reach in the beginning and you'll remind people why they resisted this program management thing the last 4 times we tried it.

4 approaches to dealing with impossible budgets and deadlines

All too familiar? "We are going to do [fill in the lofty goal] and all we got was [barely enough for a Happy Meal]. There is not a moment to lose!" If you've been around the block at least once, this is a pretty familiar situation; take comfort in the idea that it isn't only happening to you.

This problem occurs just as much at the program or portfolio level as at the project level. This era of "Do more with less" has been going on since at least 1990, and it doe snot seem to have an end in sight. So we'll just ahve to deal with it.

Here are some approaches one could take.

(1) "You'll have to find someone else". That probably works fairly well for a business; a business can't afford to sign a contract that cannot be fulfilled. I can't say I actually know any individual PMs who have had the financial independence to risk trying this approach. Comments from those who did pull this off are very welcome.

(2) Stick to your guns. You've done the research into comparable work. You know that it will cost twice as much as the sponsor has been given, and it will take three times as long. get away been able . Given your research you can probably come up with a semi-decent estimate of an answer that is, if not right, then at least somewhere in the right ballpark. Now here's the problem: even if your sponsor agrees with you, even if you make the greatest business case presentation in the world, if the governance board has already divided up the money that it has, where is the extra tens of thousands you need going to come from? Now you're wasting the executives' time asking for something that just is not going to happen,, and as a result you won't get something you could have had.

(3) Roll over like a puppy.  Well, we did just say that standing up for your estimates wasn't going to work. "Maybe", you think to yourself,  "if we can just get this thing going then as we go along we can squeeze the numbers we want".  Good luck with that.  "You signed up for this", they will say.  And so they should.  If you try to do the impossible your team will just start losing interest.

None of these sound too good.  the last one better be a doozy.

(4) The Hybrid: Oh, come on, that what every consultant suggests? Pretty much.  But this one doesn't just split the difference.  First, work out what you can do with the money you think you're going to get.  Make it something useful.  Promise to deliver that, and only that, within the allocated time.  If you focus on what you will deliver, people won't dwell on what you will not do yet.  Now that you've got them in a good mood, tell them all the constraints and all the risks and the possible bill for all this if many of the quite-possible risks do occur.  Now your conscience will be mollified and you'll be able to concentrate of getting the job done rather than on reasons why it will not.

Anyone else had this experience?  Any better or related ideas that you've tried?

If you are the only one following the rules, are you the loser ?

At some point in grade school the phrase "cheaters never prosper" may have crossed your path. If it did, you've probably been given ample opportunity to wonder whether everything you needed to know you really did learn in kindergarten, or did they just fill your head with loser mush?

The following little article would be quite amusing if it were fiction, but it is not. The punch line comes at the end.

Dying for a Chance to Get a Cheat’s Job - http://bit.ly/1dYSF7G (H/t: Project Managers.net).

Don't giggle at this as something that only happens in the Third Word.  At a national level, check your daily newspaper: anything goes as long as my friends are the ones doing it.  Especially if they are likely to do me a little favor in return. It speaks to the trend, endorsed even by our national leaders through their deeds, misdeeds and choices over what to do nothing about.

The moral of the story is: if nobody enforces the rules, there are, de facto, no rules.  This has pretty obvious implications for governance.

How many of you are filling out templates for the PMO, for the budget office, for the security review and so on and so on, all in the name of the serious consequences that might arise if we didn't go through this analysis? Set aside for the now the matter of the quality of the work. It still takes time to do it. And now how many of you have experienced the annoyance that another project somehow gets money and staff and goes sailing off (often over a cliff, true) without any of this oh-so-vital paperwork? All the hands still in the air, I see. At that moment you start thinking to yourself, "why did I waste time on all that? Next time I'll just scrape some crap off the internet and turn it in. Or buy the boss a beer and not bother with turning anything at all".

It may be worth evaluating "if everybody did that, would the organization come crashing down?" If not, then maybe it is time to back off on the policies and templates and give people some credit for having common sense and technical competence.  If such a catastrophe really might occur, then it is worth opening up a dialog as to who is allowed to cheat and why. Possibly a useful risk-based oversight framework might evolve.

So, please, weigh in on the basic question: If you are the only one following the rules, does that prove why you are a loser ?  Or should you be praised (by whom?) for soldiering on heroically?

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.

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.

Is your sponsor really an executive, and does it matter?

Most of our governance best practices place very high value on the effectiveness of the executive sponsor and/or decision board. What if true executives are disappearing?

The role of the executive. whether in the organization or in the specific context of governance, is to make decisions that have significance, can be implemented, and will stick.

The literature assumes that "executives" are as a matter of definition sufficiently well-placed in the organization to provide "top cover" or "air support".  As this story line goes, the executive has a strong interest in the success of the investments (projects, if you will) because they are accountable for that success. They understand the business drivers, and are able to determine the balance between speed, cost and quality. When things need to be smoothed over, a few words between executives can result in a remarkable increase in cross-group cooperation.  When a project manager needs a bit of support, the mere possibility of the executive having to get involved serves as a major deterrent. When project managers have the opportunity of presenting their project at milestone reviews, it can be a make-or-break moment; that in turn provides the governance staff (PM, security, etc.) with the opportunity to help the PMs get through those reviews.  If unfortunate events occur, the executive may be able to reach into some sort of reserve fund, or at least reshuffle priorities across other activities, to allow resources to move to where they are needed.  And, when the project is successful, the sponsor has some ability to set the corporate rewards machine to flowing.

In order to have these capabilities, the executives must:

• Be fully accountable for the success of their initiatives.
• Have the ear of the top executives.  
• Have quite a bit of discretion to act, or not act.
• Have discretionary resources.
• Have some control over their time.  If "managing by walking around" was rare when it had to be written about, it is very much rarer today. I am starting to think that this is the single biggest factor that distinguishes an executive from an overpaid middle manager.

But it has been my observation that fewer and fewer executives have these resources.  Why?

• More meetings, more paperwork, more meetings, more rules, more meetings.  Maybe the flood of "information", all requiring reading, digestion and collaboration, has achieved critical mass. If the executives do not have time to participate meaningfully, how meaningful is their participation?
• Rules.  Ever-increasing compliance requirements are being levied on both the technical work and the basic processes for managing the organization itself.  Organizations are run by rules, not by leaders.  (Of course, one might argue that the events in so many private and public organizations over the past 10 years provide clear evidence that rules are a poor but necessary alternative where leadership is completely lacking).
• As a sub-set of "rules", there is not much in the way of overt discretionary funding.  A lot of deals get made under the table, which undermines governance even further, but the modern executive doesn't seem to have the resources to make an impact on a project once it is launched.  They most certainly do not seem to have any way of rewarding the project team for a job well done, except perhaps to mentor one or two them to more important roles as the executive herself moves up the organization (or to others).
• It does seem to me that executives are increasingly insulated by politics (internal, not partisan) from any real accountability.  They take the bonuses and nobody at the top gets fired, even if things do not go well.  Rocking the boat just gets the executive chucked out of it; sinking quietly yields a generous severance or pension.

What do you think?  Are there lots of enabled executives out there? If so, let's hear about organizations are making that work.

Is your board room just an echo chamber?

Are CIOs (and other executives) simply listening to their own voices echoing off the boardroom walls?

You may want to weigh in on an excellent posting from Jim Anderson on "The Accidental CIO", an occasional (sort-of biweekly) blog that usually has something insightful to say.   This week's edition is about how a CIO can engage in effective listening, and how to tell whether that is working.

I think if the CIO has gotten to that step, the organization is already in the top quartile.  Two-way conversations are important. But a workplace is going to be dysfunctional if it can't even handle one-way communication.

As a consultant for most of my career, and a government manager for the rest of it, my perspective is probably skewed; people don't often hire consultants to help improve things that are working well.  They hire consultants to fix things that are broken.  Very often, the executives want help with better oversight mechanisms (governance!) because from their perspective it appears that the organization is simply backsliding on carrying out their instructions, policies and strategies.  And more often than not once you start poking around you find that the rest of the floundering organization is frustrated that nobody seems to be in charge of it (or there is a little cabal doing back-room deals, which in practice amounts to the same thing).

I've always been astonished at the results of a simple test.  In any open meeting, have people fill out a blank 3x5 card (no hints) with what they think the CIO's top 3 priorities are (this works for any leader, really) .  Then have the CIO reveal what he/she thinks they are.  Then reveal what the people thought.  The revealed gaps - if any - tell you all about whether there is any open communications channel at all.

I suppose one could vary this to test for upward communication too.  How do you do that?

Can it be that PM best practices -- aren't ?

 I've always found it ironic that the major and minor consultancies around DC are paid billions of dollars every year to continue providing the same advice on best practices that (in the of project management anyway) have been largely unchanged since the 1980s.  There are only a few possible explanations for this:

• Consultants are very bad at providing advice.  
• The advice the consultants are giving is very bad.  In other words, all this project management stuff is just a bunch of malarkey.  
• The clients are incapable of implementing the advice they are paying so much for. 
• The clients do not wish to implement the advice that are paying so much for.  which would mean that they really do not care.  In which case, why would they continue to pay for it?  (And why would we keep giving them all this money for work if they don't care whether it gets done or not)?

Did I miss an obvious answer?

Although the fourth choice (they don't care) seems like an easy answer in these days, I don't think I am ready for that one just yet.  There are too many cases I know of where public servants really are trying to get things done. And too many case where, despite their best efforts, nothing seems to happen.

The third choice (incompetence): the vast majority of public employees are pretty sharp and very hard-working.  Maybe they aren't ready for Silicon Valley or Seattle, but for the most part we're not talking about those skill sets. Federal employees must be able to define, plan and oversee a project, with enough technical knowledge to avoid getting too much of a snow-job.  I think the agencies have lots of people answering to that description. Whether they are allowed to exercise those skills goes to the fourth option. Maybe public-sector IT projects are biting off more than anyone can possibly chew?  Clinger-Cohen and later policies have tried to address that by requiring delivered capabilities within 12-18 months, but that has been largely ignored (see option 4). If we really believe that the public-sector is simply unable to attract the skilled labor needed to manage and execute IT projects that are otherwise perfectly feasible, then we have to figure out a way to get someone else to be responsible for delivering these highly-complex projects.  Not just contracting out - that's what we do now.  It would require a pretty creative solution.

Option 1: I'm not opposed to laying some of this at the feet of the consultancies, which after all have a vested interest in a permanent presence.  So maybe they are providing over-engineered solutions that are theoretically elegant but quite impractical and so never quite take root.  But in that case their advisory services should be equally ineffective in the private sector, where in fact it does seem to work (or maybe we just do not get to hear about those failures?).  Maybe the people buying the services need to take a look at why private-sector IT seems to have moved so far ahead of the public sector.  Or else only the newest or worst consultants are being used on public-sector accounts.  If you agree with option one, then you should be looking at a major business opportunity.

Well, if you're not buying any of that, there's option 2: it's all hocus-pocus.  As a certified project manager and architect, I'm supposed to (and do) believe that these disciplines can work together to produce efficient and effective solutions.  It seems self-evident that an organized approach has to work better than just muddling through. Yet so many organizations seem to operate on that opposing premise, and they not only survive but thrive (even if their projects are frequently fiascos).  Ulp.

In this confusing environment, we must be very clear about the intended benefit of any governance practice.

• If the organization doesn't want it, there will be no benefit from any investment in it.
• If the benefits of governance as compared to the status quo are not crystal clear, then the organization (especially those who benefit most from the status quo) will not want it.

If the benefit is not totally clear, then perhaps this piece of governance can wait while we focus on the parts that the organization will get behind.

What do you think?

The Internet doesn't make people stupid. Incompetent education makes people stupid.

Here's something that must be true.  I just read it on the internet.  Ivan Schneider's article does not really say that the internet is making people stupid, although one could read it that way.  What he really means to say (and does so) is that the internet facilitates a number of social disruptions and people need to be made aware of that potential so they can guard against it.  However, that conclusion is only half-complete.

You'll probably want to know how this topic is related to the overall topic of the blog. Well, if Mr. Schneider is correct, the quality of governance decisions is going to suffer pretty badly if the rising generation of leaders has been made stupid by the internet.  First, let me say that my recent few months of extended exposure to the start-up community allowed me to meet a great many young coders, sales people and business founders. There are a great many pretty smart cookies out there.  You'll be working for some of them soon enough.

But for the moment let's swallow the conventional wisdom (gained, no doubt, from the internet) that there are a scary number of brain-dead employees and voters out there.  You cannot simply blame that on the internet.

The real symptom is that people (some stupid, some just cynical; you can be the judge on that) say stupid things in a public forum and other stupid people read and believe them. That, of course, has been going on for millennia; the Roman emperors felt that they would remain in power as long as the kept providing the people with bread and circuses. Today, the internet provides these already-stupid (or cynical) people with a wider range for their pronouncements and provides other already-stupid people with greater access to those other stupid people masquerading as educators, journalists, (ahem - bloggers) and of course politicians.

The real way to solve this is not to try and educate the already-stupid people (who have already demonstrated resistance to conventional education) on the internet's dangers, which are already widely known to those who are not stupid.  The way to solve it is in the problem statement: if we can prevent people from being already-stupid in the first place, then they will see these politicians, analysts, journalists and other con artists for what they are.

How do we do that?  We can't do much about the varying levels of gray matter that nature furnishes us with, but we can help people make the most of what they have.  Let's start by stopping trying to convince children and young adults that they don't need to use their noodles at all because someone will make sure they come to no harm.

We need education that includes critical thinking that enables a student to start connecting the dots and, most importantly, to identify when something is poorly supported or biased.  Education that requires some degree of real learning of useful information and requires retention of that information.   Education that does not depend on children to somehow come up with knowledge as a result of group learning exercises.  Education that does not permit the dysfunctional few to impede the progress of the vast majority of future employees, entrepreneurs and taxpayers.  Education where an A is not given just for effort or for having a compelling background story of social deprivation, real or imagined.

This isn't a rant about teachers, for the most part.  Most the problems can be laid on the institutions within which the educators labor despite the obstacles placed in front of them.  We need education systems that do not cocoon the actual educators in layers of union protections that enforce mediocrity - and does not treat and compensate the educators as unskilled labor.  The fact is that most school districts and colleges take in more than enough money to compensate teachers and professors fairly (meaning commensurate with the tremendous responsibility we wish them to shoulder), but it is wasted on layers of bureaucracy and on capital expenses that are more for the sake of competing with other wasteful institutions than for adding any actual learning.

It seems doubtful that the political system, which more than any other depends on feeding rubbish to the masses, has any intention of improving the situation. Anyone think otherwise?

Strategy - just enough to understand is the way to go

My first assignment as a contractor was to write the Strategic Plan for the submarine fleet computing capabilities.  As a former Army officer, about all that I knew about any of that was what Tom Clancy (RIP) had just published in the Hunt  for Red October (yes, it was many years ago), which the Navy acknowledged represented an accurate picture of their capabilities ... 10 years earlier.  Meanwhile, the rest of us had just taken ownership of the IBM AT, the first PC that you could actually use for business in much the way we do today.  It was very hard to imagine where they should be in 10 more years when we could not really absorb where they were now.

Your first opportunity to "do strategy" may have seemed just as high of a cliff to climb.  My boss showed me a process for coming up with a strategy, which I have used several times since, but I recall thinking "is that all there is?".  Of course it is not that simple.  The template is not the strategy.  The hard part is having the expertise, vision and intuition to come up with the right answers to put into the framework.  That skill is what those massive corner-office salaries, bonuses and stock options are supposed to be paying for.  The consultant's role is to help focus the executives' attention long enough, in a structured enough manner, to get those highly-compensated neurons firing.

There is no shortage of books on how to "do strategy" and no shortage of consultants willing to do it for you. You cannot outsource ownership of the actual strategy.  It's fine to get a facilitator, and a graphic artist to sex it up, but a successful strategy is not something people read.  They need to experience the executive team living it, 24 x 7.

A "good enough" strategy makes it easy for everyone in the organization to understand and internalize:

• What things will look like when we have achieved our definition of "success"
• How we will accommodate the significant changes we should expect to run into between now and then
• The few (4-10) major initiatives will we undertake to get there? 
• Are they realistic (do they match the culture and knowledge that we have, or could realistically get)?
• Are they allocated reasonable levels of resources?

If the strategy makes those things clear, then it is good enough.  Everyone will understand, at all times, whether the thing they are doing right now facilitates or impedes the strategy.  If it cannot make clear what the few important things are, then more detail is not really going to help.

Having developed a strategy that is good enough, the organization has to have the will to follow through on it.  If that is the issue, your problem is not strategy but leadership.

Update on Windows 8 internet access stability

Isn't it embarrassing to convince the family to invest in the latest must-have technology and then not be able to get it to work?  As we learned last month (thank goodness I tested before exposing it to the crowd), your nice new Windows 8 machine has the potential to embarrass you mightily.  Before you jump too quickly to revisit some steps you might have to take to get your nice new holiday computer working properly (i.e. accessing the internet, a pretty much indispensable requirement), here's an update on that story.

Many of the steps I took last month came from a host of different websites in search of a solution that would work.  By now I'm not sure whether some particular actions actually made no difference, but the combination lasted for a month, even getting me through a real-time programming class requiring internet access in a large university lecture hall.

Over the holidays the glitch was back, or more specifically I couldn't get on the internet.  At first I thought it might have been because the whole neighborhood was at home and logged in, but since my tablet was working just fine I reckoned it was the computer.  Theorizing that perhaps the wireless adapter wasn't properly installed (which I am told is fairly common) I took it in to the Geek Squad to see if they could either put a meter of some kind on it, or perhaps just re-seat it.  As it turns out, modern computer design does not envision component swap-out so they just replaced the whole box.  (Hmm . maybe another post is forming on how the entire computer industry is rejecting the business models that made it a multi-trillion dollar industry).

Now for the good news: Microsoft and/or Best Buy have updated their configurations in several ways and very little needed to be done to keep the new box on line and productive.  The security systems do not seem to be in conflict and the power setting that turns off your wireless adapter to save energy has been removed from the default settings (although you definitely want to check that one).  And of course to do so you need to be able to find the Control Panel.

This you can do via <Windows key>-<D>, which gives you the alternate command "charms" (what were they thinking about with different command menus for different views in a system that actually has no documentation?).  Flip the charms out of the right-hand side of the screen (no idea how you do this if you don't have a touch-screen), choose settings, and at long last the Control Panel appears.  Choose the Power setting and make sure this option is turned off in your active power profile.

The other way of doing this is to download the classic shell, i.e. the Windows XP or Windows 7 "start button" which returns control of the process to you, the user.  It also allows you to have more than one window available at a time, and really if that doesn't seem important to you then you'd be much better off with a tablet.

Those minor fixes aside, the new computer has now been running for a couple of weeks with no difficulty and seems to be quite happy.  The good news about Windows 8 is that it boots up really fast: the computer beats my cell phone by a mile in a boot-up race.