SAFe - acronym or solution?

The Agile approach to project delivery has gone mainstream over the past few years.  Now the big question is whether Agile, with its focus on self-directing small teams, really can be used effectively in to produce solutions that are necessarily very large-scale and highly complex, with serious consequences for getting it wrong.  "People might get killed" would be a serious consequence.

Such work is often found in the public sector, and you can tell that a concept has already been mainstream for a while when the government starts pushing it as the latest thing.  As usual, the latest thing is also being pushed as the silver bullet that will make government programs super-efficient.  The truth is that government projects don't fail because of process - they'll get enough money thrown at them to overcome a whole lot of process inefficiency.  They fail because they are - well, complex and very large scale to the point that nobody really understands the whole solution to the point of being able to assess the consequences of a butterfly wing flapping on one side of the effort.

Most of the heavy-duty engineering processes are intended to mitigate the risks posed by those conditions by at least trying to document what is going on and making sure that everyone involved has a chance to put in their two cents as to potential impacts when an change is contemplated. But it takes time (and money) to write all this down, time to read and understand it, and time to comprehend the implications of proposed changes to it.

Discussions of "Agile at Scale" have been going on for several years, but one leading candidate approach to achieving that goal is the SAFe method (http://www.scaledagileframework.com/).  I have not studied it enough yet to say that it provides all the meat that is really needed (for instance, a comparison with DSMD would be useful), but it has some solid case studies and it is certainly attracting the right sort of attention. A lot of that may be due to the brilliant acronym for dealing with government offices because it addresses precisely the number one concern: can a system developed via an Agile process be considered "safe"?  "Safe" having many meanings:

• Will it grow to support tens of thousands or millions of transactions or users?
• Can we trust it in life-or-death situations (military, air traffic, fire or police dispatching, etc.)?
• Will it be proof against determined cyber-attack?
• Will we be able to use it and repair it many years from now when the current leading-edge technology is long obsolete?

And of course the most important question: "Will this go well enough to delivery that I won't be embarrassed by having championed doing something different?"

There is no way that a development project can deliver quickly if every aspect of the surrounding infrastructure (both physical and process) has to be debated at length is not re-invented from scratch for each project.  My own interest in the topic was stirred through being unable in several different agencies to get any pragmatic or pro-active guidance from enterprise architecture or from IT security; even waterfall projects would complete half their development work in the time it would take to get a review of the initial concept.

That simply won't work for an Agile approach. The enterprise needs to make key decisions at a high enough level that they can be defined and decided (even if they have to be changed later) so that the development teams can get on with providing those useful deliveries. And the enterprise needs to be protected from short-cuts taken by fast-moving but tunnel-visioned project teams.

My favorite quote in the SAFe materials is the idea that Enterprise Architecture must be treated as a first-class citizen.  To that I would add, "and enterprise architecture needs to earn its citizenship", by providing the patterns and guidance that project teams need - or agreeing to work with the front-running project to tweak its requirements to permit the adoption of whatever the team comes up with as the enterprise standard.

I don't know that SAFe really does address all the legitimate concerns of an enterprise, or whether it really only does so using the same processes that would also be employed by any competent organization even if it were using the waterfall life-cycle model.

Anti-maturity; When It Just Isn't Worth the Investment

How often, really, have organizations started down the roads of project management, governance, enterprise architecture, internal controls .. you name it, they've tried it; but after the dust settles, the initiative has failed and faded like so many before it.  And now, you, lucky you, have been named to lead the next new fad.

Let's face it, a lot of organizations manage in spite of themselves to ride market forces to a place where corporate resources can absorb a lot of mistakes.  For optical purposes they may have to satisfy oversight groups, regulators, shareholders etc. by trying out some new approach, but they don't see any terminal consequences of paying nothing more than lip-service to the idea.  You, however, will join the long list of casualties.

Is there a way to tell whether an organization simply isn't interested in the types of benefits that these initiatives might create?  Kudos to Kik Piney for developing the Anti-Maturity Model.  You can read his approach (which he says isn't fully developed but you will find it pretty informative just the same). The gist of it is that you are wasting time trying to climb off Level 1 of any maturity model if the overall organizational culture is going to actively undermine most of the key elements of any process or discipline.  Immaturity suggests that you want to get better but don't quite know how; anti-maturity means you don't really want to improve.

This model might be also be helpful for many PMs in career considerations.  As you work your way up the PM ladder, the sign that you have actually arrived is that great interview where the panel emphasizes how the organization has come to really value the benefits that some aspect of PPFM can bring, and how they need someone with your experience to really bring it to life.  On the strength of an hour or two, how will you find out whether this is really the job you've been working towards for years, or the beginning of a 2 or 3 year nightmare featuring broken promises, carer threats, and endless wrangling?  You'll live through it, and be the stronger for it in the end, but how much nicer it would be for all concerned if you could determine in advance of taking the gig. Maybe a working knowledge of the symptoms of anti-maturity would help ask some penetrating questions during this same interview.

Kik doesn't get into why an organization would choose to behave that way.  It's often useful to observe the behavior and respond based on a knowledge of how an actor will behave, rather than speculating (often incorrectly) about why.  Having said that, recall that people rise to the top of an organization because their particular skills and preferences fir the way that organization works; once they rise to the top, they pass those same predispositions onward. For instance, IT organizations should in theory be run by managers with experience running IT operations; but all too often IT operations are run by people with a history of seeking to be responsive to customers  and other stakeholders by making undocumented on-the-fly changes that bring the whole system down -- and then build their "team player" credits by coming in overnight to fix the problem that they would never admit to having created.  Then, of course, they are promoted because they always got the extra mile.  Then they read a book about how great ITIL is, or maybe an external audit forces it on them. Do you really think there is any chance of success? Do you think it is a coincidence that something as inherently obvious as the precepts of ITIL has had rather limited adoption? The whole scenario is anti-maturity at work.

Enjoy the read!  

Minute-o-phobia

In a separate post we discussed several different views on the appropriate level of accuracy to include in meeting minutes.  I also noted that even more prevalent than different ways of taking minutes is for a meeting to have no record at all.

We all know that spies and politicians do this, but surely the entire PMBoK is about transparency, consistency and making a record. Yet so many PMs are among those who seldom document a meeting (at least for public consumption; what goes into your little black book for self-protection does not count!)

Why so little practice of transparency?

• Some PMs perhaps think that taking minutes (and more importantly, typing them up) is a secretarial function and they're much too important for that. Bad thinking. If you put the meeting record together you can make sure that the important things are included and that the needed actions are assigned. I certainly wouldn't want to say that you can remember the meeting sort of the way you want to ... but it happens that way sometimes ... don't overdo it.
• I know I often forget, or maybe a day or two of back-to-back meetings overcome your good resolutions, and the next thing you know you are twelve meetings behind and what the heck, nobody will notice missing a week. Which may well be true. And the next thing you know it's a month.
• The committee holding the meeting doesn't bother to read the minutes, offers no corrections or clarifications, and never votes to approve them. Why bother? {Ahem. See the first bullet).
• The committee members don't want to be held accountable for their decisions.  Now we're getting somewhere. Is it that they really don't want anyone to know what they decided? Ask them how anyone is supposed to do what they decided if nobody knows what that is. If you're still not getting any sensible answers after going down this road, consider whether your organization is so process-phobic that trying to implement PPFM is pretty much a waste of time (see the Anti-Maturity posting)
• Actually it's more likely that the members are OK with having votes etc recorded but they don't want a record of who said what in the deliberations leading up to the vote. Well, all right. If that's the only compromise you have to make in implementing your governance process, you are well on your way.

Here's another old favorite: our team is small and everyone knows what's going on. Why waste time on administrative overhead?
Hmm. Ever heard of turnover? Ironically, the logic is almost the reverse: the tighter your group, the harder it is for a new person to come up to operating efficiency. It's amazing how many processes that "everyone knows" turn out to be known in a different way, or not at all, by almost every member of the team. When a new person comes on board, it is of enormous help to be able to take a few hours reading through an abbreviated life history of how we got to where we are. Of course the minutes won't tell you everything you need to know (nor, unfortunately will your new team-mates) but within a few hours hours the newbie is at least familiarized with the issues and the stakeholders.

I'm not insisting that senior managers be the actual scribes or document typists. Go ahead and have someone else do it. As long as it gets done.

Which PPFM Skills to Implement First: The Spaghetti Axiom

People get all wrapped around the axle about how to implement PPFM.  Most of the methodologies have very structured prescriptions for doing this, not only at different "levels of maturity" but also detailed steps within a level.

For the most part, reality doesn't work that way.

Implementing PPFM in an organization for the first time (or worse, for the nth time) requires culture change, and it is quite a substantial one.  That's true even if the organization has at least the required degree of maturity to begin contemplating such an effort in the first place.  See Kik Piney's not-so-comedic article on the Anti-Maturity Model.

Think of PPFM as a nice steaming bowl of yummy spaghetti with equally yummy sauce that will, if mishandled, make some spectacularly messy and probably permanent stains on your best business suit. Obviously it must be handled with care.

Given enough time yo could probably come up with an optimal way to eat this delicious mess.  The third strand from the middle is the one hanging everything up, if you can just get to that one ... your lunch companions are not going to wait for this sort of nonsense.  So you stick your fork in there, twiddle it, and get what you can.  It may not be ideal, but it works well enough to keep everyone satisfied and the bowl gets eaten in a reasonably timely and tidy manner.

PPFM is like that.  Because of the interconnectedness of the iron triangle, any positive traction on managing scope, schedule or cost is going to have an immediate effect on the other two legs, and likely will impact the other PM areas also.

Are we having difficulty getting people to define the scope of their projects?  Move on, move on!  Get them to agree to making a list of the projects and committing to some due dates.  As the due dates get loser, the project teams will suddenly develop intense interest in the meaning of "done", and in order to avoid such misunderstandings in future the PMO will be required to write down that X is all that was agreed to.

"Stupid PMO, why didn't they think of that before?  Making us look bad."  Stupid like a fox.  Now the PMO is "forced" to implement proactive status reporting, scope management, schedule management, and quality management.   All the things people said there was no way they were going to do that.  Keep applying the Spaghetti Axiom - don't try to force people to eat the whole bowl, just pick a few things that will be productive and accepted, and will have a lot of knock-on effects. Sooner or later, and much sooner than anyone would have thought possible, you'll be at maturity level 2 or 3.

The Spaghetti Axiom: eat it or wear it.

Program management cannot mean just anything

Program management is a term used so much that it has taken on a wide range of meanings, which is to say that effectively it doesn't really mean anything. Oh dear.

Definitions are pretty boring and tend to invite the word-lawyers into the picture, but sometimes you just have to decide what the heck you are talking about. Otherwise your efforts to make improvements fall prey to arguments about who is right when in fact you are talking about totally different things.

So, what do I mean by program management?

Let's not agitate too much over the "management" part. The important part is that it means that the undertaking is too much for one person to overcome by brute force, or even by brilliance. Managers set the stage so that the elements within their system (and, principally, the people who are working on those elements) can succeed.

What about the "program" part?

PMI has expanded its definition over the years. The Project Management Body of Knowledge (PMBOK)(R) used to insist that a program was a collection of related projects, but could only be composed of projects, that is, no operational activities. That flew so obviously in the face of the experience of so many PM professionals that over the years the definition was expanded to include "some" operational component and eventually PMI published a Practice Standard for Program Management in which the operational-to-project mix was no longer relevant.

PMI's current (Dec 2014) definition is "A group of related projects, sub-programs and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually".

Well, yes. And of course "program management" is the "application of knowledge, skills, tools and techniques to a program to meet the program requirements and to obtain benefits not available from managing them individually". Well, it isn't wrong, but it does seem trite. It would be pretty hard for the average person to tell whether they are a program manger or not, given that definition. And so the debates begin.

And, before that starts, let's be clear that a program is not a portfolio, at least not in my musings - there's a separate post on portfolios. A portfolio is used for broad-based analysis, but it is not (usually) an actual decision process. Portfolio managers make recommendations (some may even have a veto), but it is the program managers who get to make decisions.

In the US Government the idea of programs has been around for along time, as have processes for managing them. The Defense Department's program management practices amount in essence to project management for very large projects. Although they are very complex, they do not begin until the "program" has been approved for funding and they end when the product reaches Full Operational Capability and can be handed off to the military services to conduct operations and support. (Yes, true, there are follow-on modifications and versions over a product life-cycle, and at that point one moves towards managing a program instead of a really large project, although I would contend that not having responsibility for support relieves the manager of such a product from one of the key responsibilities of a program manager, which is to balance the resources needed to sustain operations with those needed for innovation).

If you're part of the Washington sub-culture then you also know from the Programming, Planning, Budgeting and Execution System (PPBES) process that there are major programs and appropriated programs. On the other hand, companies talk about the Human Relations program. Schools talk about their sports programs. And the third grade music recital has a program. Are these all really the same thing?

Our musician son puts together musical events. A typical event consists of a variety of different contributions, with the genre and performers selected to balance different goals. The acts are not really dependent on one another, except to the extent that one must follow another in some sort of sequence. Why is this not a portfolio? First, because that industry doesn't think in those terms. But in any case, all of the acts do depend on the program manager to furnish some common infrastructure and some definitive guidance. He gets to decide who is in and who is not (while in some cases having to persuade people to get in). He provides the venue and makes sure that the logistics are adequate. He arranges for someone to collect the money, which is later shared along some formula that he has orchestrated among them.

Now one such event on its own is really a project, perhaps with several sub-projects needed to get all the pieces to fall into place. But there is also an ongoing capability beyond the execution of the immediate event: it will be back next year, hopefully. So there is are ongoing activities, such as fund-raising, venue planning, and a general (if limited) management and governance process. It's a program! So is a football program: it goes on well beyond one event or even one season, and it definitely goes on longer than the career expectancy of anyone involved with it.

The program creates the environment in which a capability is sustained: the environment and the necessary processes must be there before the projects have a beginning, and they are there after the projects come to an end. Sounds somewhat like the Book of Genesis. Well, in a way it is like that. Whether it is a massive appropriation of funds to a government agency, or dad or mom's paycheck that enable junior to acquire a means of transportation, there is a finite limit to the resources and there must be a means of balancing them between competing priorities. The program managers focuses less on the week-to-week outputs of the projects or the operational activities than on the long-term building and sustainment of a capability to do work. In doing so, the program manager focuses on what DOD likes to call "Big A" acquisition (little A meaning just contracting actions). "Big A" does include contracting, but also skill sets such as planning, budgeting, financial management, human resources management, facility planning etc.: all the skill sets required to make sure that resources are in place when the work needs to be done.

Seems pretty obvious. Yet it is surprising how few organizations actually do this. Enormous expenditures are made to implement project management, but over years and years not much difference is seen. Why? Because the environment has not been conditioned by program management to make project management successful. No matter how hard they try, project managers cannot seem to bring projects in on time, on budget, with the desired capabilities, because the leadership, planning, guidance and coordination are not in place. Projects are under-resourced to the point that they cannot accomplish their aims, or, just as bad, over-resourced to the point that they are bloated, lose sight of their original aim, and crowd out all the other work that could have been done. Deliveries from one project to another are defined only by trial and error. Staffing begins only after the project is underway, guided by the untrained personnel who were the only ones on hand at the time: go, go, go! Nobody really knows who is working on what, except that everyone is sure that nobody is working on the Top Ten list. If any of this sounds familiar - you need to focus on program management before your project managers can be successful.

One hardly ever hears of an organization saying "gee, what we need here is to institute program management". Much more common is to hear that it has symptoms of issues in multiple areas at the same time. It is quite impossible to to fix project management and financial accountability and resource prioritization and effective planning and, and, and, all at the same time. In such a situation - and they are more common than you might think - the organization needs to get its act together from the top down and start managing holistically. That will mean making progress in small enough increments that they can be digested, even though each step will not move the needle much on anybody's Maturity Model. Of course, our objective is not to get a good score on someone's model, it is to make a positive difference in our organization. Besides, real life is not quite like the regular-looking steps on most maturity models: it's more like a critical mass thing (The Spaghetti Axiom).

So what do I mean by program management?

Program management is a method of applying a multidisciplinary approach to establish, maintain, and improve a complex capability over an extensive period of time, by establishing the environment in which the program activities can be successful, by defining and approving solution components, and by coordinating smooth transitions between existing and emerging solutions repeatedly through the life of the program.

Please feel free to enrich this understanding with your comments!

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.