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.