Managing Risk after Risk Management Fails

A recent newstand version of the Sloan Management Review, MIT's business school magazine, has a provocatively titled article: "How to Manage Risk (After Risk Management Has Failed)" by authors Adam Borison and Gregory Hamm

In the authors' minds, 'risk management' comes in two flavors:

"The first view — termed the objectivist, or frequentist, view — holds that risk is an objective property of the physical world and that associated with each type and level of risk is a true probability. Such probabilities are obtained from repetitive historical data

The second view is termed the subjectivist, or Bayesian view.  Bayesians consider risk to be in part a judgment of the observer, or a property of the observation process, and not solely a function of the physical world. That is, repetitive historical data are essentially complemented by other information." 

It's the authors' assertion that 'risk management' is largely practiced by managers who depend on  the sort of fact-based decisions you see illustrated in decision trees, and -- too often -- the sort of 'facts' you see on the project risk register. The authors make the case that such an objective approach to risk analysis often fails, and fails for three distinct reasons.

"First, it puts excessive reliance on historical data and performs poorly when addressing issues where historical data are lacking or misleading.

Second, the frequentist view provides little room — and no formal and rigorous role — for judgment built on experience and expertise.

And third, it produces a false sense of security — indeed, sometimes a sense of complacency — because it encourages practitioners to believe that their actions reflect scientific truth."

Of course, the root problem begins with the definitional idea that there are 'ground truth' probabilities for the physical world, and these 'truths' are knowable by the project estimators.  In some cases, where there is historical data, that may well be the case, but all too often 'truth' is more often a guess.  In engineering terms, probabilities that are guessed are 'uncalibrated'. 

And another problem is 'anchoring', explained well by Amos Tversky and Daniel Kahneman.  The anchor effect tends to narrow the estimated range of upside and downside ranges, and also inhibits 'out of the box' consideration of unusual events.

Of course, in most project risk management shops, you're going to find one or more of these three practices
-- A risk register that supports Impact-Probability analysis, largely to establish priorities
--Monte Carlo simulations of budget and schedule to establish the likely distribution of outcomes
--Failure Mode and Effects Analysis to objectively establish cause-effect relationships in product and process performance.

The first two are certainly components of probability risk analysis, PRA.  Done right, they can easily incorporate judgement to make them Bayesian.
 
Nevertheless, the authors claim that risk management has been co-opted by the frequentist--that is, objective analyst--and it's this flavor of risk management that often fails and fails spectacularly. 
In other words: although the logic of Bayesian reasoning may be known and understood my many, it is not mainstream risk management.  Part of the problem is that the protocols for combining judgement with 'facts' are not well understood by project professionals, and it's even harder to communicate such a hybrid to outsiders who may be evaluating business impacts from project effects.

Maybe so.  In the other blogs I've written on Bayes, you'll fnd a tool called the Bayes Grid, that help focus the mind and implement a practical protocol for reasoning the Bayes way.

You can re-up on Bayes by looking back to the series we did here at Musings on our friend Thomas Bayes, or check out my whitepaper on SlideShare.net.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Bigger is easier

David Brooks had an interesting piece this month on the theme of "Bigger is Easier", meaning: big bold ideas are oft times easier to get approved and underway because smaller initiatives are easier to understand and therefore attract many who 'think they know' and all but kill the idea with analysis and discussion and debate.

My experience bears out his thesis. Only, my example is "the bicycle rack". If ever you want to get your local governance to approve a bicyle rack for a public facility, or a public conveyance, you'll understand too. Everyone can understand a bicycle rack; everyone has an opinion, and everyone often wants to join in the debate, if only to 'see and be seen'.

I've been a part of a number of very large and nationally important projects. The 'bigger the easier' is certainly true. On the big picture stuff, most people will sign up. But, start disaggregating down to the bicycle rack level and all manner of 'staffers' get involved.

Then, the inevitable round of 'staffing' begins. This is the term used to describe the process of briefing a principal's staff, then briefing the principal in private so unwitting and unflattering questions can be addressed, and then taking the whole show public when all the private work is done.

The speed of the process is inverse to the size of the issue. Billions are often easier than a few million, sorry to say.

Nevertheless, many project management hours go into this kibuki dance in order to get through the tribal protocols.

Sometimes I say: God help us!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

A failure of risk management

25 years ago today, the ultimate failure in risk management:

Challenger, STS 51

At the time, my family lived in Melbourne, FL, within real-time viewing of the shuttle flight path.  My wife and kids, in their school yard as always for a launch, witnessed this as it happened.  A real OMG! moment

NASA's official memorial photo:

Photos: NASA.gov

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Strategic Initiatives Leadership Forum

Greg Githens, whom I've known and done business with for 15 years, has been asking good questions on the group he started on Linkedin, the Strategic Initiatives Leadership Forum.

One recent question: Why do strategic initiatives fail? We'll leave aside for the moment what is a strategic initiative, but my post on this question more or less has my definition implicit in the text:

1. Loss of political constituency: strategic initiatives are longer term, and time is the enemy of all coalitions of the willing. Over time, if the strategy atrophies, then the initiatives lose their anchor. And, of course, there's always regime change: what was strategic to the other guys is no longer strategic to the newcomers: cancel the project, sell the assets, layoff the staff

2. Overwhelmed by tactical performance, feasibility, and all the issues of resources, requirements, and commitment that others here have explained in full

3. Project success but business failure: The project manager earned all the project value in a EVM sense, but the subsequent business value doesn't materialize and so the strategy fails to achieve a goal. This is the bane of many start-ups, research projects, and marketing misses. Re the latter: "New Coke". This was a project success and a business failure, leading to a failure of a strategic initiative to capture a market share unserved by classic Coke.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Risk is the price

Risk is the price we pay for the possibilities of opportunity

"Blue Bloods" TV series

 Bookmark this on Delicious

Red Team the WBS

The idea of the "red team" as an independent review team was the subject of a blog earlier this month. In a few words: Red teams are indispensable to achieving quality workmanship, but they are also a good practice for defeating group think about the project deliverables.

So, it should come as no surprise that applying red team techniques to the preparation of a WBS is a no-brainer, particularly so if the WBS is part of a competitive proposal.

Fill in the WBS:

A WBS is technically an organization of project deliverables, something we call 'nouns' to distinguish them from tasks that are properly on a schedule. Tasks are something we call 'verbs'. String the verbs and nouns together and you have the project narrative.

Now, most teams use the schedule tool to schedule the tasks required to produce the 'nouns'.  Then the schedule analyst applies resources to tasks or teams, and then levels those resources by skill, by time period.

My recommendation is  to export this information and use it for ancillary fill in the WBS.

Thus, each crosspoint in the WBS is a capture point for several bits of information: the 'noun', the resources required, the hours/cost of the resources, and the organizational source for the resources.

WBS Math

Now, "WBS Math" requires that a WBS add-up horizontally and vertically. That is, the number of hours/cost should be irrespective of view. Obviously, a spreadsheet or simple database that can do the row/column math is the way to go. You really don't need to invest in a red team for the arithmetic check.

In some enterprise situations, the WBS numbering scheme is an extension of the chart of accounts, such that the resources from the schedule, as captured on the WBS, feed directly in the accounting ledger.

I like to say that the WBS is the 'present value' of the schedule; that is: the WBS has no temporal dimension, but it can be a tool for adding up all the resources identified on the schedule which, of course, should match the cost proposal, which in turn, should match the ledger roll-up of the project.

Enter the Red Team:

 But, the red team, if familiar not only with the customary practices of the enterprise, but also with the customary expectations of the customer vis a vis a responsive proposal, as well as some idea of the likely practices of the competition, can do a lot of good looking at the WBS from these several points of view.

Consider this example to illustrate the point:
Let's say we are bidding competitively and the red team is aware of the special attention that the customer pays to 'data management'. What does the red team do?

1. Look at every workpackage for data management and add up the total effort of the WBS. Does it comport with the customer's expectations? [typically a benchmark as a % of the total program]. 


2. Identify workpackages that are either over or under resourced on this activity and recommend corrections that will avoid issues that could reasonably be expected to be raised by the customer.

3. Look horizontally -- in other words, in the functional view -- to get the big picture of the data management service/function/product being offered. Can it be proposed more effectively by distributing resources differently? Are there synergies that have been missed? Does the big picture hang together and make sense to a data management professional? After all, the customer is likely to have a data management specialist who is going to take this somewhat parochial view of the WBS

4. Look vertically -- in other words, in the product view -- to see if each product is adequately covered with this product of special interest to the customer. Would it make sense to the customer's product manager?

5. Finally, evaluate the WBS against an enterprise checklist of quality attributes that comport with the enterprise brand in the market.

In sum: walk a mile in the customer's shoes by viewing the proposed WBS in the same way the customer will.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Emotional projects

Chuck Jordon was GM's design leader back when the 'greatest generation' were just getting to middle age.  His projects were cars, like the 1959 Cadillac, and his mantra was:

"We deal with an emotion"

He went on to say:

We deal with design — an intangible and emotional subject. There are no rules or steps to success. It’s a matter of opinion. This isn’t research or engineering with computer programs and hard data.

Words may not communicate it exactly. You gotta see it and feel it.

The point is, of course, is that in spite of GM's notorious command-and-control business culture there was a place for subjective, even a bit of agile, thinking and doing. Although the scope was generally fixed--it's a Cadillac after all--and the timeline was fixed by the model year rollout, the actual design externals didn't follow rules. It wasn't til you got under the hood, so to speak, that SAE standards, GM rules, and other mandates directed traffic.

So, what we have here is an engine of design innovation coupled with a project governance that, up to a point, allows for a 'no rules' emotion charged process to be the front end for a rule-driven engineering and production project, no doubt populated by pocket protectors, short sleeve white shirts and thin black ties!

Photo credit: http://oldcarandtruckpictures.com/Cadillac/cadillac1950-1959.html

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Red teams

Where I come from, we would never submit a proposal for competitive work without a peer review by a Red Team. Pick your own color, but an independent peer review, not once, but at every gate of the proposal process, is a no brainer and essential for quality.

My motto: "Good writing is not written; it's rewritten!"

I've written literally more than a hundred competitive proposals for very tough and discerning customers. Most were much more than a few pages; my largest: 1,000,000+ printed pages, albeit that was multiple copies, and was both an initial submission and a "best and final offer" BAFO.

[If you're thinking: how did you get 1M pgs to the customer? Answer: rent the corporate jet, take out all the seats, and fly it to the USAF!]

[If then you're thinking: who would read 1M pgs? Answer: lieutenants!]

I've been on many a red team, and been the object of many red team critiques. If want to win, write like you mean it, and be sure your peers agree!

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Extreme teams

As recently reported:

[When he says] turn left, we turn left; there is no discussion

Trauma team member
UMC ER, Tucson

Few of us will ever need the team work of a trauma team.   But if it happens, there's nothing like a little "command and control", a leadership style too often dissed in contemporary PM discussions.

And, TRUST.  No extreme team--indeed, no team at all--can work without unfailing trust in the performance and loyalty of every team member to the objective.

Also, instincts--and freedom--to do the right thing at the right time.  A trauma team executes a collection of practices, less so a methodology, and there is constant iteration, evolution, and inspection, to say nothing of improvisation, and iteration: all tools of team members reacting to risks, unknowns discovered, and the exigencies of the situation.

There may even be time for feedback and reflection before the next 'project' as described by this passage:

"While patients were in surgery, [the chief trauma doctor] called a quick huddle of all the doctors still in the trauma center, and they reviewed the list of patients, with each doctor calling out additional information for all the others to hear.

Most of us are not doctors, or platoon leaders in combat--another small unit extreme team situation--or even leaders of mission critical projects, but nevertheless there are lessons here for anyone.

One worth remembering is a 'simple' paradigm: PDCA--remember Deming?

PLAN [quickly, of course, but even an extreme team in an extreme situation follows a general plan]-
DO [according to accepted practices and protocols that are proven and trusted--time is of the essence]-
CHECK [on your work, and don't forget iteration]-
ACT [on the feedback and reflection of results--some evolution is likely].

People, it's been around for three generations, but it still works, even in the extreme!

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

A sailor's look at Agile, Part II

In Part I of the sailing analogy for Agile, I left it to this posting to explain estimating the cost and schedule, and by extension the earnable value.

The lay line value plan
As discussed in Part I, the lay line is the plan for delivering requirements. To be clear, a lay line is actually a course between navigation points [project periods, or multiples thereof]. To get from start to the finish, the plan may call for several lines in sequence that dodge about hazards and obstructions [project risks], and thread the way through navigable water [analogous to policies and workflow applied to the project]

From a benchmark of performance of the boat-crew-sails combination to sail a lay line [make throughput],  the captain quickly size up how many units of performance are needed to sail the lay line under ideal conditions.  Of course, the benchmark is established before the project begins.

For example, if the benchmark is 8 nautical miles in 1 hour--that is, the boat is ideally capable of 8 knots--then 8 NM is a performance unit.  [8 NM sailed is the throughput of the performance unit, aka sprint or iteration] Continuing the example, a 40 NM lay line [a NM is analogous to a story point] would ideally be planned for 5 performance units of 8 NM per unit.

And, of course, we know the $-cost of the boat and crew to execute a performance unit, so a little arithmetic will give us the planned value in cost terms; similarly, we can  schedule the lay line.  In this example, the ideal schedule would be 5 hours corresponding to 1 hour per 5 performance units.

Variance to plan
From Part I, we know it's unlikely that the captain can pilot the boat along the lay line from start to finish mark, simply because the wind [representing project energy and risks, biases, and attitudes] is unlikely to be in a favorable alignment for the whole of the sailing experience.  Some resistance to progress or inefficiency is to be expected.  Thus, we need a 3-point estimate for the sailing plan.

3-point estimate
Stuff happens!

In the sailing game, it's the wind and the effects of the wind more often than not. The wind is not only the motive energy for the boat [project], but it's the source of most of the risks and uncertainties. These various energy components interact in unpredictable ways, but their effects are estimable in many respects.

1. The most optimistic outlook is when a favorable wind enables the boat to perform each increment of the plan ideally. The efficiency of the boat's use of the wind's energy is 100%.

[For most modern boats, the wind will be coming from forward of the beam. And we'll assume the boat is sailed exclusively in displacement mode, thereby obviating the complications of extending the analogy to sailing on a plain.] 
In this example, the MOO is 5 performance units, as explained above.

2. The most pessimistic outlook is when the wind is in direct opposition to the boat [headed, in sailing terms], maximizing the effects of risk and minimizing the amount of energy the boat can draw from the wind to make value along the lay line, as shown in the illustration.  In such a situation, the captain will tack the boat back and forth across the wind as described in Part I.

Looking at the illustration, the lay line represents accumulating value, not accumulating time.  The length of the performance unit arrow represents the effort of one unit of performance, in this case: sailing 8 NM. The  projection of the arrow to the lay line is the value earned for the effort expended; the fact that the projections are shorter than the arrows means that not all requirements were earned.

For a number of reasons specific to the sailing analogy in this example, the most pessimistic outlook is with the wind heading the boat on the lay line.  This is the case illustrated. A reasonable estimate is that two increments of actual performance will yield only 1.4 increments of achievement along the planned lay line.

Thus, the efficiency of the project's use of the motive energy of the wind is:  output / input = 1.4/2 = 0.7 or 70%. 

The actual forecast is then calculated as:

Input = Output / efficiency

Input = 1.43 x Output

For this example, the MPO is 1.43 x 5 = 7.1 performance units.

Of course, the wind could slacken, or even go calm, and so the long range forecast may call for more pessimism.  However, those are circumstances that are to be addressed in the near-future time frame of the project, and thus belong on the risk register.

3. The most likely outlook is estimable once the wind direction is known; it will be bounded by the most optimistic and the most pessimistic outlook.

From the three points, Monte Carlo estimates can be made, assuming it's reasonable to apply the estimates to each performance unit [sprint, iteration]

Scale
Obviously, we have to account for sailing in a fleet, where the project manager is in overall command of the fleet, but each boat is now a team within the project.

How to maintain order and coherence?

Obviously, there are 'rules of the road' known to all that are applied by boat captains at the moment, thereby avoiding conflicts and collisions. But each captain has lattitude to maneuver for best advantage to the mark.

Boat-boat communications certainly feed 'over the horizon' information [rolling wave] from the lead boat back to the fleet. Thus, each boat is a node in a situational awareness network that circulates information more or less according to customary protocols.

From time to time, the fleet may have to 'lay up' and all captains [team leaders] assemble on the flag ship [project office] for a staff meeting and exchange of information not possible when in the team setting.

Feedback and evolution
During the course of the sail, the captain is constantly taking in data, processing it into useful information to manage the boat and its crew. No plan survives first contact with reality, so some evolution and improvisation are normal.  Additional performance units may be required.  Some performance units may have to be replanned.  Thus, in the planning of the lay line, including a buffer to absorb unplanned increments is prudent. 

It may even be necessary to get back to the admiral and rebaseline if things go really awry. 

Satisfying the sponsor
In the end, how much value is earned?   The planned value of the lay line is the earnable value.  Making the mark satisfies the sponsor and delivers the expected scope. The actual expenditure will be dependent on the wind and other events or circumstances that may arise.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Standing for something

Somewhat on a downbeat, I was struck by a recent description of smart guys who fail at leadership:

It's not enough to know a lot about a lot of things and have an opinion on everything; you have to stand for something

A paraphrase of a thought by Timothy Egan

An unambiguous core is part and parcel to attracting followers and influencing your nemesis'. Of course, other qualities are needed, to be sure, not the least of which is a measure of personal charm and charisma.

Project managers don't get a pass on this stuff. The culture of the project is the culture of the leader, pure and simple. The core value of the project emulates the core value of the leadership.

This is 101 level material, but it's amazing how smart guys often don't get the memo!

One simple test: is there a "big idea" that arches over the project narrative? If not, it may be hard for followers to see the way, day to day. If so, the big idea should connect to, or be, the core belief... that's why we're here, guys!

Remember my definition of narrative: verbs from the schedule and nouns from the WBS, strung together in a paragraph that explains what's going on.

In Egan's view, the big idea need not be complicated; in fact, to borrow a page from agile, KISS... keep it simple, stupid. Said James Carville: "it's the economy, stupid", and we all remember where that went.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Risk management in competition

“If the customer is not satisfied, he may not want to pay for our efforts. If he is not successful, he cannot pay. If he is not more successful than he already was, why should he [pay]?”

Niels Malotaux

In a proposal, you must be optimistic and assured; most customers reading your proposal want reliable solutions from a confident supplier.

On the other hand, most risk managers are pessimistic; they expose unreliability in the estimates. There is a natural disconnect here.

If you are proposing sole source, you can spread a risk premium among your work package estimates; if you are bidding competitively, can offer the risk premium as an optional insurance package. The customer may not buy it, but the customer will nonetheless be exposed to your risk assessments and may well give you "points" for foresight.

Either way, it's tricky territory.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Virtual teams interpersonal relationships

Brad Egeland has a post on virtual teams at PMTips.net that hits on a couple of ideas about boundaries. I'd like to pick up where Brad left off and develop the idea that boundaries and relationships across boundaries are inextricably linked. Effective relationships within virtual teams is perhaps one of the most important risks to be managed. Four attributes govern relationships, and each has unique risks when applied to the virtual team.

Inheritance:
Virtual teams--unlike there co-located counterparts--do not routinely inherit the culture and values of the project leadership or the project’s host business enterprise. Extra effort on the part of project management is required to instill values and culture among participants that may only be transient members of the team or the business.

Misunderstandings that arise from cultural differences can be profound and lead to risks of unintended consequences. For example--and from my own experience--a failure of a project activity as viewed from the perspective of one cultural outlook may be evaluated as poor planning and execution by the activity manager. But at the same time--viewed from the perspective of another culture--that same activity and result may be seen as appropriate risk taking, even though the risk did not work out favorably.

Depending on what culture is inherited, the activity manager will either be penalized or rewarded. Certainly no project manager wants a confusion of values; ensuring the inheritance of a commonly understood risk attitude is a very important project management task to obtain a smoothly working project in a virtual team setting.

Cohesion:
Co-located teams draw effectiveness from the cohesion among members that share a common environment, team goal, project culture, and willingness to support each other. Such cohesion depends greatly on trust. Trusting relationships do form in virtual teams, but they generally form more slowly, thereby risking the near term schedule and perhaps the associated budget.

Lack of trust is among the most cited reasons for team failures. Virtual teams have no easy way to establish trust but commonly employed mitigation usually involves occasionally getting team members together physically in some way.

Some projects have produced metrics that show better team performance if team members have been personally introduced.  A prominent example is  the early space programs that employed far flung teams in remote tracking stations that had to work together on a common mission and pass information accurately and with timeliness

Coherence:
Coherence is an attribute of the familiar idea that teams can achieve more together than their members can when working independently. In the absence of coherence there is often confusion, ambiguity, wasted effort, and sometimes an outcome that lacks essential customer value.

Coherent behavior is time sensitive. We are all familiar with the difference between the noise of a crowd talking among themselves and those same individuals singing in a choir. Singing is an example of coherence; the noise of the crowd is those same voices without phase (timing) coherence.

Communications and collaboration among team members is sensitive to coherence. The time lags within virtual team communications and collaboration degrades coherence, raising risks because things are out of phase with each other.

The common mitigation for improving coherence is to introduce an opportunity for simultaneous communications that are time sensitive. Sessions for time sensitive communications are scheduled so that they overlap the working day for as many members as possible. To make these sessions practical and productive, the working day may have to be time-shifted for some participants.

Coupling:
Coupling is a measure of sensitivity, correlation, and interference of one activity upon another. Within teams, activities are more highly coupled than the coupling between teams. But virtual teams are not as highly coupled internally as co-located teams, and this reduced coupling is a risk to performance.

Informal person-to-person communications is a form of coupling. The informal communications by casual association that is a centerpiece of co-located teams is all but missing in virtual teams. These so called ‘water cooler’ conversations are a very important communications channel for coupling one activity with another, but this coupling mechanism is all but missing with virtual teams, raising the communications risk.

Photo credit: http://www.geekpreneur.com/

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

A sailor's look at Agile, Part I

There's been no lack of sports analogies when it comes to Agile. Obviously, we have rugby that gave us the scrum. And, there have been similar analogies with American football. But, I don't recall one where Agile is compared to sailing.

Sailing? For many non-sailors, watching a sailboat race is like watching the grass grow, so where's the analogy here? Is there anything going on?


The Agile metaphor
Well, if you've ever tried to win a sailing race, you'd see the comparison immediately, but let me fill you in:

Every sailor tries to "make the mark", where a 'mark' is a buoy or other fixed object that is the target. Let the 'mark' stand for the sponsor's expectation for the project...something material and memorial that is the project outcome.

From the starting point to the 'mark', a sailor plots the 'lay line', the most efficient course from the start to the 'mark'.  Let the lay line represent the 'planned value' that the project intends to earn as progress is made along the lay line.

Now, of course, there is the wind. The wind may blow steadily for a few hours, but it shifts direction and intensity as influenced by both 'knowns' and 'unknowns', introducing uncertainty [probabilities unknown] and risks [probabilities known].

Of course the wind is the source of the motive energy of the project, but it's also the energy behind the bias', attitudes, and pressures of the sponsor, users, stakeholders, regulators, and market forces; and a variety of technology issues. All of these interact unpredictably, as the wind is also somewhat unpredictable.

How it works
A sailboat is an interesting collection of physics that interact with both static and dynamic forces.  These are the project methodology and the myriad practices that inform the methodology.

So, now we come to the interaction of the boat [methodology, practices] with the wind [energy, risks, uncertainties] and the need to make the 'mark' [sponsor's expectation], guided by the most efficient plan [the lay line].

Modern sailboats are designed to be pulled through the water by the 'lift' generated on the front of the sails which are themselves vertical wings that work just like the wings on a plane. In fact, the Wright brothers controlled lift by twisting the wings, and the same applies to a sailboat using various lines [called 'sheets'].

It may not be obvious, but to generate lift [and thus boat velocity] from the energy of the wind, the boat-sails combination needs to maintain a certain relationship with the wind--not too close, but not too far--from the general direction of the main energy.  In fact, the wind needs to be forward of the boat, much as the risks are forward of the project.

Enter Agile:

To make the mark, using the lay line as the general plan, a captain [the project manager] must tack [turn into, and across the wind] one way, and then another way, in a sequence of short performance increments, to make overall progress along the lay line.

Of course, the lay line is the 'long term' view of the project's value plan. Any individual tack [increment] is a tactical response to wind and waves [the energy for, and the resistance to, project progress].  Any individual tack may appear--in the short term--to be at wide variance with the planned value. But a successful captain of the boat [team leader and/or project manager] always has the larger objective in mind, even as he/she maneuvers for advantage.

From energy to value earned
To generate the most velocity from the motive force of the wind, and yet avoid the unfavorable risks of the wind, the boat team trims the sails to adjust the 'lift'; indeed, it's possible to capture the favorable wind and 'dump' the unfavorable at the same time by nuanced use of the sail trim tools.  The team does these things almost by instinct, requiring no commands from the captain.  Though the process for doing so is documented in general terms, the application of the process is very much up to the collective wisdom of the team in the boat at the moment. 

The important thing, of course, is to integrate all the actions of the team, including the captain whose hand is on the tiller, so that maximum velocity is made in the direction of the lay line and the terminal buoy.  From the diagram, it's obvious by inspection that even sailing in one increment across the lay line sets up the opportunity to sail in the direction of the line, thereby earning value [progress along the lay line] as velocity is applied.

Scope, Cost, Schedule
Now, of course, making the 'mark' is the scope, but what about cost and schedule? The cost of the crew [the team] is a known amount on a unit basis, and the throughput of the boat is known [velocity on a given point of sail, which is a benchmark of the boat design].

What is not known is the number of tacks, because the wind is overall an unknown. Thus, the total number of units is not known, nor is the time to make the mark, even though the velocity benchmark is known.

Nevertheless, it is possible to make an estimate of the overall resource need.  In our next post on this analogy, we'll get into this cost-schedule issue more directly.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

A culture of impatience

I read recently that we have moved inexorably to a 'culture of impatience' that requires 'satisfy me right now' functionalities -- think: cell phone apps, video games, 140 character tweets, and so forth

In fact, here in Orlando, Disney has installed 87 'gaming stations' in the line to Space Mountain to entertain 'guests' waiting--patiently--for the opportunity to ride.  And, there's now a real-time C&C bunker under Cinderella's castle to manage ride and wait dynamics.

Is this news?
Is this culture shift news? Probably not. Who could have missed this shift, or drift?

Certainly not we bloggers who have inserted this 'short form' rapid fire info source into the project space formerly occupied only by the deck of briefing charts and white papers.

[Does anyone read the long form anymore? To answer my own question: Yes, my white papers I post on slideshare.net get a pretty good airing, so somebody still reads]

[And, I recently bought new bookcases for my office to hold my personal library, about which I was asked: "bookcases? really? why?". Since one of my own PM books is now selling on Google's "Ebooks" site, I find myself working on the elevator-speech answer for that one!]

Impatience begets Agile
Enough digression: The topic is 'impatience' and the project management answer to this, so far, has been Agile for a large class of projects [not all of which are software, by the way], or the US DoD's 'evolutionary acquisition.'

So, what is Agile? Agile is both a mindset and methodology.

The arching value is "change should be provoked to incrementally close the gap between the 'as is' output and the 'as is' need".   The going-in presumption is: unavoidably, there is always going to be such a gap. 

Good grief! With this construction, Agile is really just a risk management strategy!  Who knew?  Perhaps it will show up in the next incarnation of Chapter 11 in the PMBOK Guide.

So, the prescient project manager is unlikely to believe in the spot or single-point solution, but is otherwise personally committed that the project is going to get 'close enough' that the gap--even the residual gap when the project is complete--is 'narrow enough' that the sponsor is not only satisfied but is willing to pay for the effort.


Change should be provoked
In case you missed it, 'provoked' is an actionable task, not a 'we will deal with it if it happens' risk response on somebody's register.


To reduce to practice the agile value  'change provoked'  requires a governance paradigm that is constructed for just this purpose. Such a paradigm introduces, or provides control of, a project dynamic...that is, a temporal cadence... that is relatively rapid. Material things happen in a matter of a few weeks in the best of cases, and few months in most real cases in real business' with real trappings that are not to be dissed.

Different project dynamics
The extension of 'changed provoked' into project practices means that the project office needs to run on the same dynamic as the development/delivery cycle. Thus, PMO tasks and artifacts need to be leaned sufficiently to support the cycle times. But, it's not only a matter of lean.  Conventional practices that depend, in part, on long-term analysis to develop the 'facts' to guide decision making and to develop the calibrations for probability assignments, will have to be modified for pieced-wise discreet performance intervals.

And, not to leave out communications, about which we  bloggers have some acumen, the sponsor-PM relationship and the information flows are likewise to be tuned. Thus: the popularity of the short form 'dashboard', updated webpage, and daily 'stand-ups'. Even POTUS Obama gets a daily security and economic threat briefing....backed up in 20th century writing...that is commensurate with the pace of events.

photo credit: target picture: ntang on flickr; c's castle monorail express on flickr

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Virtual Team Boundaries

Virtual teams have more boundaries than co-located teams. Some of these are internal to the team, but others are external and unique to the nature and architecture of virtual teams. Thus, there is an amplification of activities and relationships that are defined and constrained by boundaries, each of which is to be managed for the risk to both budget efficiency and performance effectiveness.

Networking
With virtual teams, every team member is a potential node on a network and a point of interface with other members of the team. At each node for each team member, there are governance rules. Some of these rules are general purpose and apply to every node, and others will be very specific to the circumstances at one node and not apply to others.

Governance on the network
The purpose of network rules is to control or direct workflow among team members, and to mitigate the risks of time and distance between team members. One mitigation is to use the rules at boundaries to establish a degree of command control that is naturally present in co-located teams, but not so in virtual teams.

Work cycles
Because virtual teams can operate around the clock, the need to synchronize configuration control of the project’s intellectual property—documents, standards, designs, reports, data, and procedures. Synchronization errors can become a significant risk to the integrity of the material. Rules for configuration control typically require that check-in and check-out cycles operate 24 hours per day so that no team member is locked out during their work day, but this puts unusual stress on the system because there is no time-out for stabilization, maintenance, and for processes to load and apply changes to run in batch cycles. One approach is to rotate required downtimes among all work day cycles.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

A quality correction

I wrote a blog on quality last month, and in the course of doing so, I made a quality blunder, herein corrected:

The reference to the blog that triggered my thought was incorrect. So, if you were trying to find it, take a look at Luis Coehlo's blog at "ah-ha-moments.com"

 Bookmark this on Delicious

Happy New Year!

From all of us at "Musings", wishing you the best for the new year

Photo credit: http://s62.photobucket.com/home/jumbo50