Gap-Based Delivery and Program Management: two faces of the same coin.

Ricardo I. Guido-Lavalle, PgMP, PMP August, 2013.

Youve been were appointed to manage a 18-month program. Such program is meant to change the organization from state A to the new, desired state A. Eighteen months later, despite of great SPI, CPI and a series of EV and other objective indicators the PMO applied to your program, the organization hasnt reached state A, and they say your program failed. You couldnt make the A to A gap.

We think we act based in reason, while most of our actions are based in beliefs. You sure remember the movie Matrix, based onto Baudrillards Simulacra and Simulation. To introduce the topic, perceive that you walked the street yesterday and the 1000 days before; you walked it today and it was ok, and you believe you will walk it again tomorrow without sinking into a suddenly molted iron manhole cover, especially since tiles, bricks and iron manhole covers use to be quite hard and non-melting. You also expect that the Sun will appear tomorrow by the East, and raindrops will go downward. Thats what Baudrillard calls an image (belief) as the reflection of a profound reality. That means that the belief closely matches the reality. On the other hand, some attitudes we have regarding complex systems are those images that mask and denature a profound reality. Beliefs rooted on wrong analogies, since big problems are NOT analogous to small problems when it is about control and causality. Interestingly, we really feel at ease in our Matrix-like program, be it aligned with the organizations reality, be it just a complete fake image of the underlying reality. One common misrepresentation of reality is the belief in control, in cause and effect. There is a bias well ingrained in in our minds after Isaac Newtons success with cause and effect. It makes us believe that IF we do our part, THEN things will happen following a controllable, repeatable casual fashion. But complexity, being causal, behaves like it is not. At all practical purposes, most major challenges have many, many degrees of freedom, many stakeholders, many pieces, and the probability of failure increases just because of this complexity. You cannot simply *control* your program: you can at most govern it. For control is about cause and effect: you pull this lever, and a well-defined action happens. Please read with me this comment by John Ikeda in Why Large Complex Projects Often Fail:
Executives and Project Managers will bring in charts, graphs, numbers, assessments, all showing that the project can be done. But, on large projects, this is just an attempt at creating a sense of control. Control that we dont have. Too many things could go wrong, and they will. Accept this up front before you begin.

Why do large complex projects fail? Because life is unpredictable and the larger the project, the greater the odds of something happening that will negatively impact the project. In other words, large projects will undoubtedly be late and over budget, because they are large.

Yes, get used to it: size matters. Now, its time to present you with one of the precursors in common sense: Charles Lutwidge Dodgson, pen name Lewis Carrol. Before you complain about Carrols mind, recognize he was a professor of Logic. Nothing more far from him than out-of logic situations, so his tales are especially meaningful. Lewis Carrol makes Alice live strange mutations and stranger experiences. One of those experiences is a weird crocket game, played with flamingos as bats, and live hedgehogs as balls:

C.L. Dodgson, a.k.a Lewis Carrol

Fig 1. Alice playing crocket with a flamingo

As you surely know, Crocket is quite a predictable game, like snooker or tennis, for you need to estimate impulse, trajectories, bounce angles, etc. Now, how in heaven could Alice do any computation, or even a biased guess on ball trajectory, in her case? Crocket is about planning and computing, and the flamingo and the hedgehog make it impossible to do so. There is nothing wrong with either the crocket game itself, the underlying rules, or the supporting laws governing movement. Any plan made in these circumstances is just chance. And all huge, complex projects do have crazy stakeholders, intricate agenda, many flamingos and hedgehogs to deal with and manage their expectations. It is now appropriate time to define what Program Management is in this context: Consider a Program as a disciplined approach executed on a sufficiently complex scenario to bring about with a final organizational state that will produce benefits according to a pre-established vision and taking in account the organizations operating values. Ugh! It sounds terrible, but lets invest a little time in this definition:

1. Its a disciplined approach: yes, we require, for this kind of managerial activities, to have some structure and repeatability, traceability and the opportunity to be improved; 2. executed: it is not just a point of view, but it is actual work being deployed, realizing ideas into measurable results. Important to note, a Program is usually the means to realize a vision, the bridge that transitions the gap between strategy and execution; 3. on a sufficiently complex scenario: for whats the purpose to deal with trivial problems? We do not need a strategic managerial approach in order to deal with well-boxed projects or self-managed, controllable initiatives. It is complex when you have a number of correlated projects and initiatives, many people involved, and rather fuzzy success scenarios; 4. to bring about with a final organizational state: Yes, the above complex scenarios will most likely produce a relevant change in your organization, as a means as to either adapt to a new reality, to match a challenge, or both; 5. that will produce benefits: for you are not doing it for fun, but to get something in turn. By the way, benefits are not deliverables, but some deliverables can be performed in sync to produce the desired benefits; 6. according to a pre-established vision: yes -and this is crucial-, for your program is the execution part of a corporate strategy that is aligned with the objectives the organization 1 tries to achieve ; and 7. taking in account the organizations operating values: benefit is relative to the organizations value system. To grow the living standard in 10% for whole population is meaningful for a governmental administration, but maybe it is not that much valuable for a company thats looking for increased stock prices. We can also say that projects are to programs what driving a car is to manage a citys traffic system. Now, lets say you the scenario above in place, and your program is on course. You and your team developed a high-level choice of coordinated projects that will lead your program from A (initial state) to B(desired, final state):

Fig. 2: The program

You thus decided that a suitable way to do it would be to execute your program according to some schedule you, your team and your sponsors liked:

PMI also calls Program to a group of projects and activities running in sync in order to achieve some benefit like economies of scale, common PMO practices and simplified management for those project portfolios. I guess that kind of programs arent the kind of programs I mean in this article, for they have no links to corporate vision, but in a marginal way.

Fig. 3:This schedule will lead you to success

What does this schedule say to most people? IF we all follow this plan, THEN we will harvest every planned benefit and our program will successfully end on time/budget. Now you purchase a leading magazine that says that barely XX% of big projects fail. You even learn that most of those projects did have a well-established plan, but they still failed in a major way. So you meet with your team and stakeholders and opt for prudency. You explain: Why dont we wait to see what happens with Project A first, before launching Project D? This would allow us to have some tactic insight about what could happen.":

Lets be prudent!

Fig. 4: This schedule will lead you to success, sure.

In some point of your program, you are able to show management that you are performing well, according to cost/time parameters. However, you can see severe risks approaching: you needed to re-program some acquisitions, because the purchase management is not responding well. A key partner is showing it is unable to cope with your demand (a bright startup, but it was acquired by Google and they cannot scale to maintain former quality and timeliness). You are a seasoned Program Manager, so you recognize that, regardless of whats committed in the schedule by purchase manager, your program is likely to crash in the near future.

So, what are you going to do? Are you going to rely in your plan and your schedule, for they undoubtedly provide you with a safe net (you can always ask Google on why do large projects fail, in order to support your position after the failure). Or do you really want to try to save your program?

Gap-based delivery
Mc Kinsey recently published an interesting report on large scale projects. It recommends acting upon: focusing on managing strategy and stakeholders instead of exclusively concentrating on budget and scheduling mastering technology and project content by securing critical internal and external talent building effective teams by aligning their incentives with the overall goals of projects excelling at core project-management practices, such as short delivery cycles and rigorous quality checks The first suggestion may sound strange for many PMs. How is that about not caring much about budget and schedule? The key here is, we were hired to somehow bring to the organization the desired outcomes and benefits. If parts of the program are over budget, out of schedule or even lower quality, this can become a second priority, as long as we provide the organization the required benefits. You are right, if the sponsor is a PMI-certified person (like I am), its likely that he or she will complain about the lack of adherence to some project management best practices. Thats Ok! But if the sponsor is concerned about realizing benefits, he/she will think in terms of Program Management, not Project Management. Remember, Project Management is about delivering deliverables, while Program Management is about producing benefits. Now, whats the point with the Plan and the Schedule? Am I against them? Certainly NOT! You cannot execute large, even mid-sized projects without a proper plan in place. The problem is that just sticking to the plan and checking every task as 100% done you will not successfully finish your program. The point with programs is not how much you did, but how much and what you still need to make happen in order to successfully end your program . For why should the sponsor give thumbs up to your program with bright Earned Value indicators, if it is not going to produce benefits?

It is this very gap between current state and desired state that you need to care about in program management. You need to find ways to close that gap, and checking the schedule to 100% complete will certainly give you a sense of relief and will in a way protect you against critic, but it does not mean that you will ultimately get to the desired state.

Strategies to close the gap

In order to close the gap you will do most activities already in the plan, and this is confusing, for why dont you simply improve the plan as to cope with the gaps needs? Lets backtrack to Baudrillard. The Plan was built under the belief that theres a causal chain from Initiation, through planning, then execution, until delivery and success. If you at this point began to believe in me (no bad feelings if you dont) you need to find a way not only to push the program by executing the plan, but also to pull it across the gap that separates current program status from the final, successful desired state. Pull it. Visualize what the final state should be, you go there yourself, and pull it to you. The Plan will provide organization and structure, and thats great. You will provide purpose and direction. You will not schedule tasks (the Plan does that), but you will justify the tasks: You need them there in order to close the gap. You will not cancel the tasks (the Plan does that), but you will manage to give them low priority or to decide to cancel them if they are a burden in order to close the gap. You will not cut/add on risks, scope and quality, but you will manage to provide a value system that makes them either negligible or required. You will partner with your stakeholders so the value systems accommodate your needs. You will not create accessory projects and you will not cancel projects in the program, but youll manage to show stakeholders and governance how initiating or cancelling projects will benefit the ultimate benefits goal. You will nott give the governance directions, but you willl manage to get the governance committee aligned with your execution vision and values. Do you remember Neo and the plug to virtual reality they inserted in his cerebellum in Matrix? You will do that to the program. Your vision, your values and your reality will be the Matrix that governsinstead of control- the Plan. Specifically: First, you need to recognize that a schedule 100% on track is likely to not be the same as being closing the gap. It may happen that most tasks in the schedule will collaborate to close some gaps, but schedules are mostly used to get people in sync and on the same page. The schedule will allow functional managers know when and how much his/her resources will be used. It will also be useful to negotiate with stakeholders. To give a sense of control and predictability. Second, use Go/No-Go gates. While it is true and it is good that they are used for authorization purposes (the program governance will allow you to proceed to the next stage), they also give you the opportunity to develop gap assessment dashboards, long before the actual Go/No-Go decision is made. In those dashboards you keep a checklist you will check all the way until the actual Go/No-Go meeting. The basic question for those dashboards is: what is missing in order to get a Go on this? Notice I am not talking about which items were already checked: that is for the governance team. I am talking about missing items The Gap.

Fig 5: a gated approach

The gap assessment dashboard will likely have most entries (or its equivalent in executive 2 language) in it. It will (dont you dare to take this as kind of method !), have all that needs to be accomplished to pass that gate (be it included or not in the published Plan), be aligned with the strategy, organizational vision and values (it can collide with best execution interests), not necessarily include every item in the schedule, and not be constrained by previous assumptions and provisions in the Plan.

In short, the gap assessment dashboard should allow you to depict the actual, wild success conditions, regardless of any previous provisions and agreements, so you can freely choose your best options in order to make sure youll have a Go for that gate. This could include: other projects) Scope change/reduction Budget raise Resource allocation Risk buying Contract revision Stakeholder reengineering Quality reductions Cancelling projects in the program (for instance, to move its resources to Time allowances Full program reformulation I mean, whatever it takes you to get that Go!

I guess most PMs will jump at proposals like scope, budget or quality being changed, and they will be right, for its never advisable to mess up with the Triple Constraints items. But your goal is NOT to comply with the PMBOK, but to come up with the benefits (or ultimate deliverables, or results, you name them). By the way, this reminds me of a good story I read once, a Samaniegos fable. Its about a rabbit. It almost crushes with a fellow rabbit, breathless:
2

If you think those items are kind of method, you did not read the previous text. The key assumption for gap-base delivery state of mind is we cannot assume things will run according to a pattern . You will adapt your strategy according to the specific case and the tactical situation, not the expected scenario. You dont need to create another Matrix.

-Hey, wassup? -Two rogue hounds are chasing after me! -ok, but they arent hounds, they are greyhounds They keep arguing about hounds and greyhounds until they both get killed by the dogs (they were terriers, another rabbit told me later). That is it, this is my point regarding our attitude towards whatever is needed to fill the gap. Oh, yes. Third: before trying First and Second, you better get properly backed by top sponsors. For you are probably going to mess up with tough guys and sacred principles. Or else be prepared to die honorably. I could create a religion with my many deaths, true. Mind the gap! --o--