Sharing thoughts on Gap-Based Delivery in Programs

Risk management in Gap-based delivery

Ricardo Guido Lavalle, PgMP, PMP This case is an actual one. I had been called to take a huge cloud project out of the mud. It had been poorl initiated, and the customer hadn!t properl staffed its side, and ultimatel had come "ith an old#fashion, authoritative Project $irector. The relations bet"een parties could hardl be "orse. The project had a fairl reasonable risk plan. The plan hadn!t foreseen the lack of communications among stakeholders and bet"een provider and customer. The status meetings had no meeting minutes. %oon after I initiated meeting minutes and the proved effective to depict the serious gaps that populated the project, the &ustomer!s Project $irector canceled regular status meetings and forbade email ans"ers from main customer!s pla ers. In change, she put a nominal PM bet"een her and our project management. The PM had no po"er at all, other than 'uestioning minimal stuff in the schedule, and no decisions and agreement could be made valid. In ( months I had not a single private meeting "ith the Project $irector. In the "hole project!s duration "e had no access at all to the internal# to the customer schedule and risks. )ere, a non#planned, unkno"n risk had triggered at e*ecution time, let!s call it +proper communication between parties is not granted,. -aturall the Plan could not deal "ith it. no provisions could have prevented it once the project had been initiated the "rong "a "ith the "rong people. The first assessment I made, the project "as scre"ed. -o Plan could deal "ith the man gaps and faults it had. Thus a tactical, "orkaround emergenc plan "as put in place. The $octor had said m father had had a sick hearth, "ith main arteries blocked, but that over a long time he had developed a peripheral, much less efficient arterial mesh, et efficient enough to someho" make the blood distribution for a rather long "hile. I don!t kno" if that "as true at all, but I liked the idea. /hile complaining for the e*isting gaps and tr ing ever "a to get and provide feedback and status b the formal procedures, "e developed peripheral communications channels. /e needed to promote the entire team as communication channels. /e empo"ered customer!s ke people "ith privileged information the could use. This promoted a quid pro quo spirit. In some cases the strateg backfired. 0or instance, "hen the nominal PM "as probed "ith privileged information she immediatel reported it, so that informal channel had to be canceled on the spot. 1ther channels succeeded in diverse levels of efficienc .

Sharing thoughts on Gap-Based Delivery in Programs

2 the time of the first deliver "e had a fairl trustable vie" of the customer!s relevant milestones and e*pectations, risks and issues. 1n the other side, our channels had been fed back "ith strategic information, current internal and operational status and success factors, and so critical s nchroni3ation information reached the relevant levels in customer!s side. The project "as delivered "ith negigible dela . Lessons learned. first, a gap#based, tactical approach to risks "as effective in the absence of a +straight,, planned "a . %econd, the gap#based approach "as justified just because the whole project was in risk, not because the risk impacted just a couple activities. In fact, "e needed to reprogram man tasks, "ith the painful conse'uences this carries. The end results "ere being compromised, and the actions "ere oriented just to secure the end results, not to put the project on track 4according to the official minute task schedule5, to compl "ith the e*isting schedule, or "hatever. Risk management cannot be overemphasi3ed. If ou are an e*perienced program or project management practitioner ou have alread perceived that Risk, %takeholder, 6thics7, 8ssumption, 9ualit , %cope, Time and &ost management are all mutuall interdependent. There are program managers that prefer to approach the project b the Risk side, other b the %takeholders: side, a lot from a &ost side. That!s all#right as long the manager remembers that his;her dut is to come to a happ end "ith the program or project still able to be called a program or project, not in pieces. The conscious manager "ill seem to be caring for just one dimension, but that!s just an e*ternal perception because of the manager!s bias. The seasoned practitioner kno"s he;she needs to govern the "hole pack from current status, through the gap until a success status. In tactical times, "hen the Plan is not "orking because of terrain realities, some priorities among the Triple &onstraint dimensions can change, but it!s the manager!s responsibilit to balance them in order to maintain the program!s integrit and "orkable balance.

7 /ell, 6thics is usuall considered as kind of unmovable dimension. I invite ou to read m discussion on ethics and gap# 2ased deliver if ou "ant a broader elaboration on the matter.

Sharing thoughts on Gap-Based Delivery in Programs

The dashboard and the risks

In a previous post I depicted the Tactical $ashboard for a program. It!s intent is 'uite the same as $amian Mc<inne from Mc<inne Rogers comments in this video. In short, the Tactical $ashboard is not intended to provide program or project status to upper management #although it can be of help in order to format an status report#, but to tacticall sho" the management team "hat the tactical situation is. If "e are running out of resources If "e have a dangerous issue arising /hat the deadl risks are, and ho" are "e dealing "ith them /hat immediate ne*t actions need to be e*ecuted 4either listed or not in the schedule5 /hat ne*t tactical goals are, and "hat!s conflicting "ith them. <e stakeholders "e need to closel manage in this stage. <e messages and communications for this stage. What risks should be present in your tactical dashboard? I!m tempted to ans"er +just those not Plan#managed risks that actuall put our program or project in risk of not completing the goal 4the product or result for the project, the benefits for a program5,. This s'uare, minimalistic ans"er carries the unrealistic assumption that both ou made a good risk planning during project or project planning 8-$ that to successfull end our program or project is our onl goal. 2ut e*cept for ver fe" projects, speciall in engineering ones, I!ve rarel seen a project "ith a through, careful and continued risk management in place. Moreover, ou probabl "ant also to survive to our successful project, so ou "ill probabl need not onl to come "ith the results on time, budget, etc, but also ou "ill need to do so "ithout perturbing too man stakeholder!s life. Therefore at a certain point in the project!s e*ecution phase ou "ill have. Planned, foreseen risks. =our team has alread identified them, assessed them for 'ualit and impact, and has also assigned them to an o"ner. =our team has alread planned the response actions, like avoidance, transference and mitigation. The same for the secondar risks derived from the response actions, our team has alread took provisions for them.

Sharing thoughts on Gap-Based Delivery in Programs

Foreseen risks, unplanned. This is not necessaril a project fla". 6ither because their lo" probabilit of occurrence, because of their unmanageable 'ualit 4+what if the world blows up?,5, or because our team is confident the can manage them as the sho" up "ithout too much disturbance, our team decides not to manage them. Unforeseen risks, unplanned yet budgeted. =ou include some percent of total budget in order to deal "ith unforeseen risks. =ou are b the "a a great negotiator if ou can commit mone from finances! area for such immaterial things. Plain unforeseen risks.

0or risks ou didn!t provide a contingenc or a "a to avoid them in the Plan, ou have t"o "a s to deal "ith them. 8s soon as the are identified and 'ualified, if the are manageable in the conte*t of the e*isting provisions in the Plan, m advice is to do so. Let!s sa a team member got sick and ou hadn!t a replacement, but the tasks in the schedule do suffice to deal "ith the situation through schedule engineering, b making use of slacks or b getting a "aiver for a tolerable dela , ou just do it and accommodate the immediate impacts and due communications. If the risk can either risk the final results of the project or it ma promote such a perturbation that could evolve in a major crisis even after the project deliver or program completion, ou certainl need to get tactical and make a bridge for that gap. These risks "ill be part of the tactical dashboard

Sharing thoughts on Gap-Based Delivery in Programs

The manager "ill probabl need to get "aivers from the sponsor, the e*ecutives and ;or the steering committees in order to proceed out of the Plan. The manager "ill tr to assess "hich risks can actuall be moved to regular, Plan#managed risks. The lesser the critical tactical risks, the more focus, hence the more chances. 8 thorough stakeholder!s risk thresholds levels assessment "ill need to be conducted. /hile ou and other stakeholders can stand the involved levels of stress the solution poses, man relevant stakeholders ma not be read to stand them. Remember that declared risk threshold levels are not the same as "orking threshold levels. /hile a stakeholder ma sta muted "hile the project or program is in normal condition, it!s probable he;she "ill take advantage of the crisis and ask for a risk threshold change. 8s financial and time concerns are the most immediate and more visible impacts, special care must be e*ercised "ith them. 4this of course can change if the priorities are different, like reliabilit #space projects#, environmental impacts #social, agriculture, marine projects#, etc.5. It ma happen, too, that a planned risk evolves in an unforeseen "a into a danger for the the program or project!s ultimate goal, in "hose case ou "ill need to process it in tactical mode>. You should try to process as many risks as possible according to the Plan, if necessar b altering it. This "ill re'uire ou to activate proper governance devices. 0or instance, ou "ill probabl be re'uired to make a &hange Re'uest that "ill need to be processed b the established change processes for the program. That is the best practice, the recommended "a to do things unless ou have no other option but to get tactical and in need to pull the program through the gap 4b using gap#based deliver tactics5 instead of pushing it according to the Plan.

> -otice I use +tactical risk management, and similar e*pressions in a loose "a , not necessaril related to some attempts to s stematicall deal "ith tactical risks. In the conte*t of Gap#2ased $eliver there is no other s stematics than the ver focus on bridging the gaps "ith ever usable and proportionate#to the problem device or tool. Gap#2ased $eliver is about focus and attitude, not tools.

Sharing thoughts on Gap-Based Delivery in Programs

-otice that m solution to the crisis in the &loud project depicted above "as good enough as to deliver the project in its first stage, but it did not solve the severe management problem the project had. M intervention "as intended strictl to take the project out of the mud until first deliver , but that "as not enough as to bring a comprehensive ans"er to the initiation defects and subse'uent structural project issues. That "as not in the scope of a tactical intervention, and needed much more support and a drastic conte*t change. 8nd certainl the same emergenc PM "asn!t the appropriate person to do so. Tools. The tools ou "ill make use of are the same ou "ould use for Planned risks. =ou still need to assess the risks for 'ualit and 'uantit . =ou still need to assign a responsible. The can even produce #after the mitigation# secondar risks. /hat changes is not the nature of the risks but the timing of them, their criticalit and the e*ecution conte*t.

You are to be blamed

0or ou "ill be constrained to come "ith a course of action in a hurr , and in a conte*t that!s not the happ times in the planning phase. ?alues and priorities "ill seem to have temporaril changed 4but ou "ill be accounted according to the originall established values in our Plan5. Most probabl ou "ill be dealing "ith the risk in a fu33 , nois , dirt conte*t, "ith ever e e and finger pointed to ou and "ith a lot of people desperatel looking for someone to blame. The ?6R= first comment ou "ill hear "ill probabl be +WHY wasn't that risk mapped in the Plan?,. =ou are the PM, so ou are the first person to be accountable 4@to blame5. It!s natural and foreseeable. If ou don!t accept this fact ou are not et used enough to manage projects or programs. In the best case, namel if the risk hadn!t been mapped because it couldn!t be mapped in advance at planning time, ou!ll need to invest a couple meetings and emails in order to make it clear. 0or instance, a solar burst suddenl burned our antennae. 1r ou had planned for the Tea part not approving the budgetar la"s in the A%, but ou couldn!t foresee that the opposition in some countr ou are e*ecuting the program or project "ould suddenl decide to do the same.
In an organizational strengthening program I managed in Buenos Aires it happened, right before its launch, that a theater with thousands of young people attending a rock event caught fire and more than 200 people died. he tragedy had happened in a private spot, but it seems that safety inspectors had e!changed

Sharing thoughts on Gap-Based Delivery in Programs

waivers for bribes, thus the "overnor had some kind of indirect responsibility on the events. #e had took provisions for some $0 representatives being changed in the middle of the program because of elections %thus we needed to plan for the new stakeholder&s scenario%. #hat we failed to map was the governor being put apart by the new representatives. #hile the program did not fail, it was severely shaken, and some components could never been deployed, thus affecting the final benefits outcomes.

8s a final note, ou should differentiate bet"een critical, results#endangering risks from those nast , not necessaril too dangerous et trouble#carr ing risks. Most of these risks have to do "ith bureaucratic concerns or communication issues. 6ither a purchase process "as not properl follo"ed, or someone in the team made an inopportune statement in a meeting or to the journalism. The can branch in une*pected "a s and even become critical risks if not properl managed and contained. Risk management is not and it "ill never be a closed issue. That has nothing to do "ith tool availabilit but the ver nature of comple* s stems. Profession "ill manage to record ever possible risk ou can find in a specific kind of project. /hat catalogs and risk list could never account for is the inherent non#linear characteristic of comple* s stems and the volatile nature of human beings. Thanks God.
It is not the critic who counts. 'ot the man who points out how the strong man stumbled or where the doer of deeds could have done better. he credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood( who strives valiantly( who errs and comes short again and again( who knows the great enthusiasms, the great devotions( who spends himself in a worthy cause. #ho)at the best)knows in the end the triumph of high achievement, and who)at the worst)at least fails while daring greatly so that his place shall never be with those timid souls who know neither victory nor defeat. Theodore Roosevelt

The length of this document defends it well against the risk of it being read Winston Churchill ###o###
?isit gbdeliver .blogspot.com