The confluence of a couple of recent writings got me back on the "quiet" thing. One is the recent publication of the book "Quiet, the power of introverts in a world that can't stop talking" (which is much less about power and much more about it's ok to be an introvert) and an article about the architecture firm NBBJ that is promoting really open space office plans. One of their more recent engagements is the new home of the Bill and Melinda Gates Foundation for their 1000 or so employees.
Connecting the dots......
If you've ever taken the Myers-Briggs assessment, then you know a bit about the I's and E's (introverts and extroverts). The most profound thing I learned is that the I's are exhausted by interaction with people and need quiet isolation to recharge; the E's are just the opposite, exhausting themselves with quiet and needing people to recharge their batteries.
So, when I read about really open office plans with no cubes and no offices, I think first of the I's: what an exhausting day that's going to be. Then, I think of all the energy the E's will contribute.
Of course, many E's are closet I's. They have a professional E personality so they can compete in business (corollary: it's hard to be competitive with others if you've no working relationships with others, certain SME eccentrics excepted because we have to have them). The closet I's go home at the end of the day totally wasted; or after about 8-10 hours, there're not much good to anyone, including themselves.
On the other hand, I've been in a situation (for years) with an office I never used and an open plan I sat in so I could absorb the body language and other small stuff you can't get any other way. Alistair Cockburn calls this communication by osmosis (or osmotic communication).
And, I subscribe to the school that says that innovation is more likely to come out of colloboration than not. (Of course, one wonders about all the innovation that came out the Bell System Labs populated by all the I's with pocket protectors!). So, on balance, I think the I's (or professional E's) have to suck it up and be open!
Monday, April 16, 2012
Saturday, April 14, 2012
Time zone bubbles
Sometimes, it's the simplest ideas that are the most effective. In the IT production control world, "bubble charts" are a common artifice to show the workflow of various scripts, user/operator interactions, and programs that have to run in sequence, or with dependencies, or a particular time (scheduler), or "on demand".
Fair enough, but no news there.
Then I read a blog post by agile guru Johanna Rothman about time zone bubble charts. So simple, but so effective as a communications device for the distributed team. It's a simple image, suitable for the war room or the background on some far flung work station.
Johanna offers six ideas for dealing with the myriad issues of time zones and teams. She writes:
My experience was [India west coast (UTC +5:30)] to [US East coast (UTC -5)]. That's 10:30 hours difference in time, and not all that uncommon among software teams.
Here's what we did:
Bookmark this on Delicious
- Show the timezone bubble chart to your managers so they understand what you are attempting to manage.
- Share the timezone bubble chart, so all the team members can participate in selecting planning and standup times.
- Share the timezone pain. Do not make only one person or only one timezone delegate always arise early or stay late.
- Know if everyone needs to participate.
- Ask people if they will timeshift. Make sure you ask in advance, so people can make arrangements for their personal lives.
- Make sure people either have necessary bandwidth to participate at home or food and beds to participate at work, if they need to participate outside of normal work hours.
- Dedicated phone room with open line for about 4-6 hours per day (anyone could walk in and talk or set up an offline conference)
- Time shift (mostly by the India workers)
- Alternate early/late conferences so that both US and India shared the inconvenience
- Real-time document sharing via shared resources
- Teleconferences by video on a case by case basis. (We didn't have Skype or Facetime at the time)
- More care with documentation to compensate for ESL (English as second language)
Bookmark this on Delicious 
Thursday, April 12, 2012
Road warriors
I've put in my time as a road warrior. Around the world on PANAM 1; 2 1/2 million miles domestically; and a lot of hotel nights. But, my experience is dated.
In a recent article on the changing accessories in business hotel accommodations we learn that "wireless is like air" to the millennials that are now part of the travelling business crowd.
But beyond a charging station at every chair and wall-to-wall wireless, we hear that iPads are now offered in every room, replacing conventional controls for lights and environment, but also serving up the morning paper.
The old days of carrying a case of dial-up phone connectors and adapters is sure a long way into the history books. But, some millennials were hardly born when that was de facto standard.
My own experience is similar: This summer, while on vacation along the Maine coast, I was simultaneously teaching an e-course, keeping up with student emails on a smart phone, and posting lesson commentary on a laptop by night. (My observation of this work-play: not for those without an accomodating spouse)
In a recent article on the changing accessories in business hotel accommodations we learn that "wireless is like air" to the millennials that are now part of the travelling business crowd.
But beyond a charging station at every chair and wall-to-wall wireless, we hear that iPads are now offered in every room, replacing conventional controls for lights and environment, but also serving up the morning paper.
The old days of carrying a case of dial-up phone connectors and adapters is sure a long way into the history books. But, some millennials were hardly born when that was de facto standard.
My own experience is similar: This summer, while on vacation along the Maine coast, I was simultaneously teaching an e-course, keeping up with student emails on a smart phone, and posting lesson commentary on a laptop by night. (My observation of this work-play: not for those without an accomodating spouse)
Are you on LinkedIn? Share this article with your network by clicking on the link.
Tuesday, April 10, 2012
Six risk practices
Pantelis Filippidis wrote this in reply to a question in my Risk Management class
Elsewhere, we learn that the risk questionaire is along these lines:
Of course, right of the blocks, practice (1) that invokes lessons learned and project records presumes a certain maturity, discipline, and commitment to the forward use of such materials on the part of the project office. We could all wish it were true more often than it is.
The questionaire, if made a routine part of the project plan, goes a long way toward setting the table for risk management. I salute that idea!
Regarding risk management I have found the following techniques effective;
(1) For planning RM: Review lessons learnt & records from previous projects, and get advices from more expert team members
(2) For risk identification: Risk Breakdown Structure (RBS), Risk Assessment Questionnaire, Brainstorming, Delphi, setting up subject-matter expert team, and lessons learnt & records from previous projects
(3) For Qualitative Risk Analysis: Probability & Impact matrix using only 3 level “high” / “medium” / “low”
(4) For Quantitative Risk Analysis: Failure Mode, Effects and Criticality Analysis (FMECA - an extension of failure mode and effects analysis (FMEA)), past records, and expert judgment.
(5) Risk response planning: lessons learnt & records from previous projects, subject-matter expert team.
(6) Risk Monitor & Control: watch-list of high/medium risks, subject-matter expert team meetings
The main success factor was the early identification of major risks and correct risk cost & time impact estimation
Elsewhere, we learn that the risk questionaire is along these lines:
The use of a Risk Assessment Questionnaire - The questionnaire encompasses 6 key areas: Clarity of Expections, Cost, Schedule, Client relationship and Impact, Resources, and solution complexity. The outcome of this questionnaire is to initiate action towards increase communication in the problem areas and mitigation strategies
Of course, right of the blocks, practice (1) that invokes lessons learned and project records presumes a certain maturity, discipline, and commitment to the forward use of such materials on the part of the project office. We could all wish it were true more often than it is.
The questionaire, if made a routine part of the project plan, goes a long way toward setting the table for risk management. I salute that idea!
Sunday, April 8, 2012
The risk matrix (again)
In 1711 Abraham De Moivre came up with the mathematical definition of risk as:
The Risk of losing any sum is the reverse of Expectation; and the true measure of it is, the product of the Sum adventured multiplied by the Probability of the Loss.
Abraham de Moivre, De Mensura Sortis, 1711 in the Ph. Trans. of the Royal Society
I copied this quote from a well argued posting by Matthew Squair on Dark Matter entitled Working the Risk Matrix. His subtitle is a little more high brow: "Applying decision theory to the qualitative and subjective estimation of risk"
His thesis is sensible to those that really understand that really understanding risk events is dubious at best:
Well, I've given you De’Moivres definition of risk in the opening to this posting. What then is an iso-risk contour?
Definitions:
"iso" from the Greek, meaning "equal"
"contour", typically referring to a plotted line (or curve) meaning all points on the line are equal. A common usage is 'contour map' which is a mapping of equal elevation lines.
So, iso-risk contours are lines on a risk mapping where all the risk values are the same.
Fair enough. What's next?
Enter: decision theorists. These guys provide the methodology for constructing the familiar risk matrix (or grid) that is dimensioned impact by probability. The decision guys recognized that unless you "zone" or compartmentalize or stratify the impacts and probabilities it's very hard to draw any conclusions or obtain guidance for management. Thus, rather than lists or other means, we have the familiar grid.
Each grid value, like High-Low, can be a point on a curve (curve is a generalization of line that has the connotation of straight line), but Low-High is also a point on the same curve. Notice we're sticking with qualitative values for now.
However, we can assign arbitrary numeric scales so long as we define the scale. The absence of definition is the achilles heel of most risk matrix presentations that purport to be quantitative. And, these are scales simply for presentation, so they are relative not absolute.
So for example, we can define High as being 100 times more of an impact than Low without the hazard of an uncalibrated guess as to what the absolute impact is.
If you then plot the risk grid using Log Log scaling, the iso-contours will be straight lines. How convenient! Of course, it's been a while since I've had log log paper in my desk. Thus, the common depiction is linear scales and curved iso-lines.
Using the lines, you can make management decisions to ignore risks on one side of the line and address risks on the other.
There are two common problems with risk matrix practices:
For "2", pick a grid point, perhaps a Medium-Medium point, that is amenable to benchmarking. A credible benchmark will then "anchor" the grid. Being cautious of "anchor bias" (See: Kahneman and Tversky), one then places other risk events in context with the anchor.
If you've read this far, it's time to go.
The Risk of losing any sum is the reverse of Expectation; and the true measure of it is, the product of the Sum adventured multiplied by the Probability of the Loss.
Abraham de Moivre, De Mensura Sortis, 1711 in the Ph. Trans. of the Royal Society
I copied this quote from a well argued posting by Matthew Squair on Dark Matter entitled Working the Risk Matrix. His subtitle is a little more high brow: "Applying decision theory to the qualitative and subjective estimation of risk"
His thesis is sensible to those that really understand that really understanding risk events is dubious at best:
For new systems we generally do not have statistical data .... and high consequence events are (usually) quite rare leaving us with a paucity of information.
So we end up arguing our .... case using low base rate data, and in the final analysis we usually fall back on some form of subjective (and qualitative) risk assessment.
The risk matrix was developed to guide this type of risk assessments, it’s actually based on decision theory, De’Moivres definition of risk and the principles of the iso-risk contour
Well, I've given you De’Moivres definition of risk in the opening to this posting. What then is an iso-risk contour?
Definitions:
"iso" from the Greek, meaning "equal"
"contour", typically referring to a plotted line (or curve) meaning all points on the line are equal. A common usage is 'contour map' which is a mapping of equal elevation lines.
So, iso-risk contours are lines on a risk mapping where all the risk values are the same.
Fair enough. What's next?
Enter: decision theorists. These guys provide the methodology for constructing the familiar risk matrix (or grid) that is dimensioned impact by probability. The decision guys recognized that unless you "zone" or compartmentalize or stratify the impacts and probabilities it's very hard to draw any conclusions or obtain guidance for management. Thus, rather than lists or other means, we have the familiar grid.
Each grid value, like High-Low, can be a point on a curve (curve is a generalization of line that has the connotation of straight line), but Low-High is also a point on the same curve. Notice we're sticking with qualitative values for now.
However, we can assign arbitrary numeric scales so long as we define the scale. The absence of definition is the achilles heel of most risk matrix presentations that purport to be quantitative. And, these are scales simply for presentation, so they are relative not absolute.
So for example, we can define High as being 100 times more of an impact than Low without the hazard of an uncalibrated guess as to what the absolute impact is.
If you then plot the risk grid using Log Log scaling, the iso-contours will be straight lines. How convenient! Of course, it's been a while since I've had log log paper in my desk. Thus, the common depiction is linear scales and curved iso-lines.
Using the lines, you can make management decisions to ignore risks on one side of the line and address risks on the other.
There are two common problems with risk matrix practices:
- What do you do with the so-called "bury the needle" low probability events (I didn't use 'black swan' here) that don' fit on a reasonably sized matix (who needs 10K to 1 odds on their matix?)
- How do you calibrate the thing if you wanted to?
For "2", pick a grid point, perhaps a Medium-Medium point, that is amenable to benchmarking. A credible benchmark will then "anchor" the grid. Being cautious of "anchor bias" (See: Kahneman and Tversky), one then places other risk events in context with the anchor.
If you've read this far, it's time to go.
Friday, April 6, 2012
A brief history of scheduling
Patrick Weaver gave a talk at Primavera06 about the history of scheduling. His talk is captured in an interesting paper: "A brief history of scheduling: back to the future"
Patrick is somewhat of a historian and prognosticator on matter such as these. He also has written:
Weaver writes:
We learn these additional nuggets:
Of course, one of the most profound developments was the arrival and market penetration of the low cost PC-based personal scheduling tools like MSProject. In Weaver's view that made schedulers out of everyone, but everyone is not a scheduler, or can even spell the word.
In my personal opinion, the integration of Monte Carlo tools with low cost scheduling applications like MSProject was equally profound. The MC simulation "fixes" some of the most egregious problems with PERT and the simulation idea has largely run PERT into obsolescence. The main thing that PERT does not handle well is schedule joins or merge, and the statistical merge bias that goes with it.
On the dark side, MSProject has profoundly muddled the whole idea of the WBS. The fact that one of the fields in MSP is called "WBS" is most unfortunate. There are a whole generation of project analysts who believe they created a WBS by the simple act of making that field visible. Not so: schedule is the "verbs" of the project; WBS is the "nouns". Together, WBS + schedule = project narrative.
Now, in Weaver's view, we return to the future:
Patrick is somewhat of a historian and prognosticator on matter such as these. He also has written:
- The Origins of Modern Project Management: www.mosaicprojects.com.au/Resources_Papers_050.html
- ‘Trends In Modern Project Management - Past Present & Future’www.mosaicprojects.com.au/Resources_Papers_061.html
- ‘Seeing The Road Ahead – The art of presenting schedule data effectively’www.mosaicprojects.com.au/Resources_Papers_106.html
Weaver writes:
Modern schedule control tools can trace their origins to 1765. The originator of the ‘bar chart’ appears to be Joseph Priestley (England, 1733-1804); his ‘Chart of Biography’ plotted some 2000 famous lifetimes on a time scaled chart “…a longer or a shorter space of time may be most commodiously and advantageously represented by a longer or a shorter line.”
Priestley’s ideas were picked up by William Playfair (1759-1823) in his ‘Commercial and Political Atlas’ of 1786. Playfair is credited with developing a range of statistical charts including the line, bar (histogram), and pie charts
We learn these additional nuggets:
- The science of ‘scheduling’ as defined by Critical Path Analysis (CPA) celebrated its 50th Anniversary in 2007.
- In 1956/57 Kelly and Walker started developing the algorithms that became the ‘Activity-on-Arrow’ or ADM scheduling methodology for DuPont.
- The PERT system was developed at around the same time for the US Navy's Polaris missile program
- PERT lagged CPM (Critical Path Analysis) by 6 to 12 months (although the term ‘critical path’ was invented by the PERT team).
- Later the Precedence (PDM) methodology was developed by Dr. John Fondahl; his seminal paper was published in 1961 describing PDM as a ‘non-computer’ alternative to CPM.
Of course, one of the most profound developments was the arrival and market penetration of the low cost PC-based personal scheduling tools like MSProject. In Weaver's view that made schedulers out of everyone, but everyone is not a scheduler, or can even spell the word.
In my personal opinion, the integration of Monte Carlo tools with low cost scheduling applications like MSProject was equally profound. The MC simulation "fixes" some of the most egregious problems with PERT and the simulation idea has largely run PERT into obsolescence. The main thing that PERT does not handle well is schedule joins or merge, and the statistical merge bias that goes with it.
On the dark side, MSProject has profoundly muddled the whole idea of the WBS. The fact that one of the fields in MSP is called "WBS" is most unfortunate. There are a whole generation of project analysts who believe they created a WBS by the simple act of making that field visible. Not so: schedule is the "verbs" of the project; WBS is the "nouns". Together, WBS + schedule = project narrative.
Now, in Weaver's view, we return to the future:
The changing role of the scheduler has been almost as interesting:
• The mainframe era saw scheduling as:
• Then came the PCs…… everyone and no-one was a ‘scheduler’ in the 1980s and 90s
- o A skilled profession
- o Central to the success of projects
• However, in the 21st century, the new ‘enterprise’ era sees scheduling as:
- o A skilled profession
- o Central to the success of projects
Monday, April 2, 2012
The Mann-gulch tragedy
The Mann-Gulch tragedy has been told many times. There are books and essays in abundance that tell about the 1949 forest fire in Montana that turned deadly.
One telling I like is in the book "How We Decide" by Jonah Lehrer.
In a few words, a fire team was caught when the fire suddenly turned and became an out of control conflagration. The team was led by an experienced fire fighter, but he was new to the team. When push came to shove, the team abandoned their new and untrusted leader and tried to make their own way. They all died.
The team leader and a couple of others improvised a heretofore unheard of practice: they set a backfire and hid in it, using their fire protection clothing and tools, accepting the lesser of two evils. They survived.
There are three stories within the Mann Gulch story:
1. A story of change: the fire suddenly changed character making known process, methods, and plans instantly obsolete
2. A story of trust and leadership: trust had not gelled between the relatively new leader and the fire team
3. A story of improvised methods driven by extreme need
Here are a few comments on point 2:
The Mann Gulch story is a poster child for unquestioning obedience to command, and the principle of command autonomy, perhaps more so than leader-follower which is different.
In life-safety situations, to include life-safety projects where failure is not an option, certain protocols need to be in place before hand. They must be practiced to the point of so-called system-1 "fast thinking" (See Daniel Kahneman, "Thinking Fast, Thinking Slow"), and embedded in the organization's culture.
At the moment of the event is too late to develop the intuition and trust. (Similar intuitive thinking examinations are in Malcolm Gladwell's "Blink")
Whether fueling the space shuttle, working in a level IV bio-hazard lab, leading a first responder team, or engaged in a military firefight, command must be unambiguous, and expected to change in an instant with the loss of the commander. Thus, obedience must transfer instantly to the new commander.
Many leader-follower scenarios are described as the followers giving permission to the leader to lead so long as the followers are satisfied. Effective in some situations, it will get people killed in a Mann-Gulch project.Thus, we make a clear distinction between command-obedience systems and leader-follower systems.
An excellent text on leadership is "Leadership without easy answers" by Ronald Heifetz
There are, of course, exceptions with prejudice to command-obedience. In military situations, this is called mutiny. Sometimes, mutiny is justified. Two fictional accounts illustrate the point well: "The Caine Mutiny", a story of a warship in danger of floundering in a hurricane; and "Crimson Tide", the story of a violation of nuclear launch code protocols.
On the bridge of the Caine, in the midst of "Halsey's Typhoon", in the Pacific in 1944, the captain is panicked and making life-threatening decisions. The XO mutiny's, takes countermeasures, and saves the ship.
On the bridge of the submarine, USS Alabama "Crimson Tide", the captain violates launch protocols; again the XO mutiny's, takes countermeasures, and in a courts martial, he is exonerated.
One telling I like is in the book "How We Decide" by Jonah Lehrer.
In a few words, a fire team was caught when the fire suddenly turned and became an out of control conflagration. The team was led by an experienced fire fighter, but he was new to the team. When push came to shove, the team abandoned their new and untrusted leader and tried to make their own way. They all died.
The team leader and a couple of others improvised a heretofore unheard of practice: they set a backfire and hid in it, using their fire protection clothing and tools, accepting the lesser of two evils. They survived.
There are three stories within the Mann Gulch story:
1. A story of change: the fire suddenly changed character making known process, methods, and plans instantly obsolete
2. A story of trust and leadership: trust had not gelled between the relatively new leader and the fire team
3. A story of improvised methods driven by extreme need
Here are a few comments on point 2:
The Mann Gulch story is a poster child for unquestioning obedience to command, and the principle of command autonomy, perhaps more so than leader-follower which is different.
In life-safety situations, to include life-safety projects where failure is not an option, certain protocols need to be in place before hand. They must be practiced to the point of so-called system-1 "fast thinking" (See Daniel Kahneman, "Thinking Fast, Thinking Slow"), and embedded in the organization's culture.
At the moment of the event is too late to develop the intuition and trust. (Similar intuitive thinking examinations are in Malcolm Gladwell's "Blink")
Whether fueling the space shuttle, working in a level IV bio-hazard lab, leading a first responder team, or engaged in a military firefight, command must be unambiguous, and expected to change in an instant with the loss of the commander. Thus, obedience must transfer instantly to the new commander.
Many leader-follower scenarios are described as the followers giving permission to the leader to lead so long as the followers are satisfied. Effective in some situations, it will get people killed in a Mann-Gulch project.Thus, we make a clear distinction between command-obedience systems and leader-follower systems.
An excellent text on leadership is "Leadership without easy answers" by Ronald Heifetz
There are, of course, exceptions with prejudice to command-obedience. In military situations, this is called mutiny. Sometimes, mutiny is justified. Two fictional accounts illustrate the point well: "The Caine Mutiny", a story of a warship in danger of floundering in a hurricane; and "Crimson Tide", the story of a violation of nuclear launch code protocols.
On the bridge of the Caine, in the midst of "Halsey's Typhoon", in the Pacific in 1944, the captain is panicked and making life-threatening decisions. The XO mutiny's, takes countermeasures, and saves the ship.
On the bridge of the submarine, USS Alabama "Crimson Tide", the captain violates launch protocols; again the XO mutiny's, takes countermeasures, and in a courts martial, he is exonerated.
Subscribe to:
Posts (Atom)