Three C's and a D

The other day, with a good friend, Alex Walton, principal at 3PM LLC, I was expounding on a favorite topic: applying a dose of system engineering to portfolio management. I call it "three C's and D".

A bit cryptic? Well, not so much when you spell it out:

Coupling, coherence, cohesion, and diversification

The short form explanation looks like this:

Can you actually manage these things from the perch of a portfolio?  Yes, so long as you're not too hung up on metrics, as in: "you can only manage what you can measure". In some respects, there are only notional explanations for these concepts with corresponding notional ideas [metrics] of success. Nevertheless, "I'll know it when I see it" can be valid as management doctrine.

Here's a little explanation:

Coherence

Coherence is what gives rise to reinforcement and to synergies. Coherence gets its power from phasing and sequencing....in other words, timing. Take 20 people and let them chat at a party and you have--to the macro listener--noise; but phase things correctly and you could have a choir. In other words, from noise a song!

The phasing aspect of coherence gives rise to a success criteria, phase error. We tend to think of things being "highly coherent", or exactly in phase or in sequence.

Coherence also gets its power from consistency and commonality. I once did a project with a company that claimed they had 2M customers. When we cleaned and consolidated several  customer databases, and imposed rules of consistency and commonality, the company really only had a few hundred thousand customers. The rules for sales customers were incoherent with the rules for service customers until we got the relationships right and imposed common data rules

Another idea behind coherence is optimization. In portfolio management it's common to try to optimize for the larger good. In effect, create the conditions that reinforce the highest goals to the greatest degree, even if lesser goals are foregone. If you've ever studied the Theory of Constraints by Goldratt, then you understand the idea of coherent flow-down of goals so that the organization is not working against itself.

So it is with projects in a portfolio: sometimes, real success only comes with the right phasing, the right timing, and the adherence to common rules.

Cohesion

Cohesion is what makes things stick together and perform under stress; to accept tension among parts and keep on going. In a portfolio, it's a matter of making good on the overall business value proposition, and doing so under stress.

The qualitative idea is weak or strong cohesion; ordinarily the metric is strength under stress, which for projects is tolerance for failure.

Strong cohesion means that if one project, or some aspect of a project, fails in some sense, the tensions created among projects because of failed dependencies are not crippling to the business outcomes. Cohesion requires redundant or alternate paths to customer satisfaction through the network of portfolio projects.

Cohesion also requires effective conflict resolution under stress, and it requires that individuals and teams are prepared to give commitment and accept accountability even if all is not as they require.  Portfolio managers establish these principles of behavior and make demands for adherence.  Managers also establish and manage the incentives for cohesive behavior, and manage the resource pool for redundancy and stress relief.

Indeed, one principle of agile methods--though not exclusively an agile idea--is that hockey stick heroics to pull the project through at the end are to be avoided.  Cohesion eventually breaks down with sustained overcommitment.

Coupling

Coupling is well understood notionally: it's the idea that one effect or outcome directly influences another. Generally, we think of coupling as being loose or tight, referring to how well one effect is transferred onward. Insulation loosens the coupling between outside and inside, etc. In projects, loose coupling is usually the desired quality. A failure in one project is not coupled into the next is the idea. In portfolios, the same is true. We want high coherence and strong cohesion but loose coupling. And, all three together is sometimes a challenge.

As in the insulation example, barriers, sometimes physical barriers, are the best way to loosen coupling. A virtual team is about as loosely coupled as a team can get. A co-located team is tightly coupled. On the other hand, it's harder to get cohesion in a virtual team, and correspondingly at the portfolio level, the more barriers among projects the more loose will be the coupling, but the greater will be the challenges of obtaining other good qualities.

Diversification

Most of us understand diversification from the financial portfolio experience: when one investment is down, another is up, and the overall result is within a range of acceptability. If all investments are really independent of each other, the range of results is compressed by approximately the square root of the number of investments in the portfolio--the square root of N rule.

The same is true of project portfolios. The secret sauce is independence. If coupling is not loose, independence is forfeited, and so also is the power of diversification forfeited.

How to sum up?

Perhaps I'll just say there's a place for system engineering in project management.

 Bookmark this on Delicious  

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

5 things never say while negotiating

For many of us, negotiating never gets too much beyond getting a good price on an automobile. But project managers often find themselves in some kind of negotiation with sponsors, and if there's a contract involved, then for sure the project manager is going to be involved.

 There are a lot of roles to play, from technician to answer detailed technical questions, to the legal guys, to the 'decider' that accepts responsibility for the deal.

No matter your role, what you say, your words will be felt. So, what's a good protocol for participation?

Mike Hoffman has a few words of advice on his post: "5 Things You Should Never Say While Negotiating"

• The word "between"
• "I think we're close"
• "Why don't you throw out a number"
• "I'm the final decision maker"
• "Screw you!"

"Between" always reveals your bottom line, so that's an obvious no-no. "I think we're close" reveals fatigue and willingness to accept something that will end the 'ordeal'. Throwing out a number sets an anchor. If you say this, be prepared for the other guy to use your anchor for the discussion. "I'm the final decision maker" limits your ability to obtain room to reflect and consider before actually deciding. And, the last one is simple: don't make it personal.

 Bookmark this on Delicious  

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

Project Management for middle schoolers

For the inquisitive and energetic 6th - 9th middle schoolers in the piedmont area of Virginia, there is an opportunity this summer to get involved in a large number of workshops, ranging from art and architecture to CSI forensics and project management, held by the Piedmont Virginia Community College.

Project management? For middle school students? Yes! Start'em young.

Disclosure: Gordon Meriwether, the principal at Uriahgroup.com, is an associate of mine going back many years.



 Bookmark this on Delicious  

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

Happy Easter

For many, this is Easter Sunday. Happy Easter to all.

What science knows business doesn't do

Dan Pink has interesting talk on TED about motivation. His thesis: "if/then" rewards and incentives only work well when the task is rule based and the goal is clear. Perhaps more important, he asserts that evidence shows that such incentives actually detract from performance in cases that demand creative and other right brain congnition.

Is that your experience?

My experience is that you have to be careful what you wish for: if you incent discovery of errors in software code, for instance, then coding tends to be more sloppy and error detection goes up! The 'joke' around my shop: "I'll think I'll go out and code a new car!".

This brings up the second point: look at the counter measures. You would think performance follows the money.... it does, in many cases, but incentives are another form of work rules. Work rules are often the blinders to more creative and optimum performance.

Pink, in his presentation, says the new world order is: personal autonomy, personal mastery, and meaningful purpose. Autonomy is the opportunity for self-direction; mastery is knowing your the best at something; purpose is being part of something that is important to a larger audience.

He cites Encarta vs Wikipedia, and the personal time allowed by Google and others as the demonstration of his thesis.

Whether you agree or not, his presentation is engaging.

 Bookmark this on Delicious  

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

Is there a case for process simplicity

Phillipe Kruchten has a thoughtful posting on software process models, the basic theme of which is 'ever more sophisticated process models haven't delivered on their promises'.

Phillipe uses this quote to make his point:

“… perfection is achieved not when there is nothing left to add, but when there is nothing left to take away.”

Antoine de St. Exupéry, Terre des Hommes, 1939, chap.3

You may not agree with Kruchten's theme, but you might be swimming against the tide. Survey's about software project success and failure are essentially consistent: it's hard to have a successful software project.

Of course, success is measured three ways at least: PM success of invested resources, technical success of project deliverables, and business success of deliverables in the hands of users. There's a lot of blog discussion on the latter point: for every blockbuster like "Angry Bird", there are dozens, if not tens of dozens of techical successes that are user-acceptance failures. This is one of the points about Agile: it's not a success unless the user says it's a success. [By the way, I've not heard if Angry Bird ever paid it's investors back, or not]

It's not just software. It's any intellectual property project, whether it's writing a book, a proposal, or developing a marketing campaign. The process steps can be specified and regulated; the content of each step much less so. It's too much in the eye of the beholder.

 Bookmark this on Delicious  

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

Off the map

Sir John Keegan is not the man I would ordinarily look to for insights about project management.

Sir John is an esteemed military historian--indeed, acclaimed by many as the best military historian of the modern age--whose 20+ histories focus on the interrelated factors of popular culture, political struggle, strategic geography, battle terrain, military culture, influencing technology, tactical maneuver, and strategic vision.

In his most recent book, "The American Civil War: a military history", he dedicates a chapter to 'generalship'.

In that chapter, about USA Major General Joseph Hooker*, Keegan reports: "... Hooker lacked the ability to make 'war on the map'", meaning Hooker "... functioned well only as long as his troops were under his eye."

And, most telling, this statement: "Once they moved beyond his field of vision, he lost the power to visualize their whereabouts".

That statement really struck a cord. I've seen this too many times in the project space: team leaders, promoted to a more strategic position, unable to manage the project "on the plan", meaning they, like general Joe, can not effectively visualize what is going on when they get beyond the 'daily stand-up' and the opportunity to manage by walking about.

My observation is that these managers can't scale their management style and leadership attributes to fit the larger scope.  They are befuddled by teams that are physically distributed, projects have resources in many locations, other companies may be on the project team, and the project is accosted not only by risks afar but by the forces of politics and self-interest.

+++++++++++
Photo: US Library of Congress

*Unlike most of his contemporaries, Hooker was a West Point graduate, and so presumably was educated in the military sciences.  However, to fight the Civil War, armies on both sides of the conflict raised a total of over 1000 general officers in the course of four years, starting from just a handful in the antebellum US Army of the day. Thus, most Civil War generals were accidents of circumstances, nearly none of which had any formal education in military science, the management and maneuver of large units, nor the elements of leadership. 

In the US Army, all but two were either brigadiers or major generals.  Until late in 1864, three years after the war began, the US had only one lieutenant general and he was desk bound in Washington as Chief of Staff.  Thereafter to the end of the war, only there were only two, one of which was Supreme Commander in the field, LTG Grant.  Today, there are still about 1000 flag officers in the U.S. military, though about 300 are 3 and 4 star rank.

 Bookmark this on Delicious  

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

Agile Project Management library

Looking for a 100+ articles and papers on Agile PM in a pdf download format? I wasn't, but I fell onto this site looking for a specific agile topic. A quick look down their page index shows a really wide range of topics.

I've not been through many of these, so no recommendations except this one that is a reprint from the "Communications of the ACM" from December, 2005: "Agile Project Management: Steering from the Edges"

Frankly, I like it because it is written at a post-college level, something hard to find in the Agile literature, it's a case study focusing on PM, and it has some interesting insights.

One thing I don't agree with is that it equates complex software systems and projects with 'complex adaptive systems' [CAS].  CAS is definitionally about biological systems that have the ability to change and evolve behaviour in response to stimulus.  Ant colonies are the classic example.  I don't buy that one.  Software always works the way it is designed to work, even if it's designers don't understand the design they wrought, and users don't understand how the system reacts to input and control.  There's nothing biological about software, and it certainly doesn't learn, WATSON et al not withstanding.

However, there are aspects of CAS that do apply:  CAS are non-linear, and software systems can certainly be non-linear, especially when tangible system assets can't meet the demands of the intangible software.  CAS are open and dynamic, responding to environment.  As repects the project rather than the software deliverables, I agree that many projects that deliverable intangibles have such characteristics.

But I digress: read the paper.  There are things to be learned 

 Bookmark this on Delicious  

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

More about decision making

Tom van Gelder, a 'down-under' from Melbourne, Australia--a sister city to my former residence in Melbourne, FL USA--has a nice post from last November on decision types in decision making.

By van Gelder's reckoning there are four major categories that can be distilled from a myriad of articles, papers, books, and pontifications about decision making.

I like his list because its short, simple, and appealing to my own personal experience:

Intuitive Decisions

• They tend to be made rapidly
• They are made by individuals deciding alone
• There is little or no conscious reflection
• There is little or no following of rules or procedures
• Usually only one option is considered
• The cognitive process is typically “recognize/act” – the decision maker recognizes the situation and immediately “knows” what an appropriate thing to do in that situation would be

2. Technical Decisions

Technical decisions are those made by following some well-defined technical procedure. Very often a spreadsheet or computer program plays a key role in the decision processing, and indeed sometimes the decision making can be largely or completely turned over to a computer.

3. Deliberative Decisions

• Involves conscious articulation and evaluation of various options and the considerations counting for and against options
• Takes anywhere from minutes to months
• May be made individually, or by a group
• Often involves discussion and debate
• Doesn’t involve computers in any important way, since the relevant considerations are usually “informal” or qualitative cannot be rigorously specified or quantified
• Is not governed by strict rules or procedures, though it is subject to various norms and conventions (usually unspoken or implicit)

4. Bureaucratic Decisions

• Are important/weighty/high stakes
• Are “standard” sorts of decisions for the organisation; hence they
• Are made following a codified process, involving lots of steps and rules
• Involve lots of people playing their assigned roles
• Are based on lots of information, extensively analysed
• Have detailed documentation

Curiously, van Gelder does not address the risks attendant with each style. Even a cursory inspection suggests the trade offs of speed, quality, consensus and participation, and quantitative back-up.

There's no 'right' answer here. "Risk is the price we pay for opportunity": thus, risk is a component of the cost to be weighed against the benefit.

Even the intuitive decision maker, making a decision  for the benefit of speed, probably has a least a fleeting sense of the risk even as all formal risk management is eschewed.

On the other had, the paralysis of risk analysis that arises because there's no real calibration of data points to drive convergence to a decision, or perhaps nearly as bad--resorting to a guess--doesn't add to the quality of the decision making either.

Conclusion: the risk management process--for which you may have defined only one in the singular RM plan--may need to become 4 processes within a risk management framework, each process tuned to the exigencies of the decision making.

 Bookmark this on Delicious  

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

More on the agile value question

If you are PMI member and interested in Agile, perhaps you caught Jim Highsmith's webinar presentation on agile in the PMI Agile Community of Practice [CoP]. Presented live in March, 2011, it's still available for viewing if you login and join the Agile CoP. [Search under 'webinars' tab for past webinars: "Beyond Scope, Schedule, and Cost: Rethinking Performance"]

One of the main points he makes is that whatever product feature or function is developed and delivered it should have two valuations:

• A top-down allocation from sponsors or those making the investment in the project
• A bottom up estimate of effort [read: cost] to develop

Highsmith was not clear on this point: is the value allocation from the intended investment to be made in the project, or is the value a proportion of the total benefit expected, adjusting for time with discounts?  Given the uneven nature of ROI, this distinction could be important.

Highsmith makes the oft described admonition: the top-down valuation should exceed the cost to develop.  Said another way: 'quality' is often defined as getting more for your money than you might have expected.

Of course, in my experience, it can go the other way: the cost to develop exceeds the value allocation.  In fact, it often goes the other way.  Sponsors, users, and product masters are--as a group--more optimistic than project managers.  Consequently, they  underestimate risks, overestimate benefit, and most often underestimate cost.  As a group they are afflicted with optimism bias.

What then? 

That's what I call the project balance sheet risk:  there's a gap between resources needed and resources expected to be provided.  To close the gap, the project manager takes a risk with an intent to find a way to deliver.

In the webinar, one listener asked the obvious question, which I paraphrase: Where does a credible dollar figure come from for the value side of the equation?

Highsmith seemed not to have an answer ready with which he was comfortable.  He said, in effect, value assignments are made by allocation, but he had no rules or protocols to offer about how to go about this.

What he should have said was:
Of course, there's no universal definition of value; rather, there're many definnitions of value, much like there're many definitions of quality, no one of which is 'the' definition.

That said, it's a matter of environment, experience, competition, history [reference projects] that all combine to provide a value judgment that is a few parts rational [that, is facts] and a few parts emotional or qualitative [that is, the art of the situation].

It should be obvious: there's no formula for getting a value judgment right.  The Nano failed and the iPod soared.  It happens.

But also: the farther down the WBS you get, the less valid is any value judgment.  What you get is more of an ordinal valuation: "this is worth more to me than that". 

And, you get anchor bias: "that's what it cost last time, so that's what it should cost this time".  The first one to throw down the anchor, whether the value figure or the cost figure, has the negotiating advantage.

However, the power of agile is that this judgment is frequently revisited, and in the revisit process there is opportunity to evaluate, calibrate, and test the value judgment.

And by the way: I'm talking about the business value of the investment, not the business value of the opportunity.  Highsmith didn't talk about it, but there's actually three parts to every project econometric:

• How much a sponsor wants to pay
• How much a project needs to succeed
• How much the business expects to earn from the investment

The value allocation is made from the investment at bullet 1; the cost estimate is made at bullet 2; the ROI is estimated from bullet 1 and 3. Usually, a NPV discounted cash flow analysis is done so that all econometrics are in the same timeframe.

Bottom line: There's an art [value] and science [cost estimating] to be reconciled by iterative reexamination as progress accumulates. Of course, this is not exclusive to agile; every methodology includes this idea. It's just that agilists accept it as a centerpiece of agile management.

 Bookmark this on Delicious  

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

Seven rules for risk and uncertainty

John Carlos Baez blogs at "Azimuth", a kind of 360 look at number of grand challenges, the current focus of which is climate change. Baez is a mathematical physicist, so a lot of his posts are steeped in formulas and technically oriented.

However, for those of us with a more ordinary grasp of mathematics, a guest post by Curtis Faith caught my attention--and it's readable by all.

Faith lists his "seven rules for risk and uncertainty" which are taken from his book "Inside the mind of Turtles", a treatise on financial trading risk.

By Faith's reckoning, the seven rules are these:

1. Overcome fear,
2. Remain flexible,
3. Take reasoned risks,
4. Prepare to be wrong,
5. Actively seek reality,
6. Respond quickly to change, and
7. Focus on decisions, not outcomes.

The one that gave me a double take, especially from the view of project management, is the last: "Focus on decisions, not outcomes". Frankly, I'm an 'outcomes' guy.

However, a close reading of Faith's point is that when facing decisions about risky outcomes, especially those that may have calamitous outcomes, the rule really is :
Don't be paralyzed in the decision process by the impact of the decision's likely outcome; make a decision based on an integration of best practice, experience fit to the circumstances, and the impact of not deciding.

The other rule that seems a little unusual as stated is "Actively seek reality".  Here again, one has to read between the lines.  An alternate construction: "Constantly monitor the situation to ensure relevance and applicability of risk assessments and responses."

Perhaps I'll conclude with Rule 8: When reading rules  1 - 7, translate them into a relevant project context.

 Bookmark this on Delicious  

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

Sampling ideas for project managers

Recently, I authored a paper on how project managers can use, and should use, statistical sampling of large populations to reduce the cost and timeliness of handling very large data sets.

I posted the paper at slideshare.net, and you can take a look at it there, or click on the embed below.

Whether sampling for proportion, like what proportion of process users require or endorse this feature or that one, or sampling for descriptive statistics, like the average error rate among development objects, the fact is almost every project manager runs into situations that are best handled by sampling over the course of a few projects.

If you've some Six Sigma familiarity, then you've already studied these techniques. If you've got to explain things to a functional manager, this paper might help.

I used these ideas on a recent ERP project where we were faced with converting millions of data records from legacy systems to the ERP system. We never would have had time or money to validate the readiness for conversion without these techniques.

Project examples for sampling and the law of large numbers

View more documents from John Goodpasture

 Bookmark this on Delicious  

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

WBS benefits

A posting by Brad Egeland entitled "Benefits of the Work Breakdown Structure" caught my eye because, above all else, the activity to create such focuses the mind and draws attention to the architecture of the project outcomes.  And Lord knows, obtaining focus is no small matter!

Creating a WBS is an exercise in disaggregation: breaking things down into pieces and parts from a top-level notion of what the outcomes should be.

However, I've found it handy to then add the pieces and parts up from the bottom and see if their summation reveals any gaps. 

That's the well-known 'V-model' from system engineering: break it down, then add it up and verify the top-down and the bottom-up come to the same project outcome.

Many recognize the 'V-model' as a variant of the well known dictum: "Tell them what you're going to tell them; Tell them; Tell them what you told them"!

That's why when I first saw Egeland's first bullet, I thought "right!", that's close to my thinking also.  But, alas, his detailed description seems to confuse schedule and WBS.  He writes:

1 – WBS forces the team to create detailed steps

The WBS forces the project manager, team members, and customers to delineate the steps required to build and deliver the product or service. The exercise alone encourages a dialogue that will help clarify ambiguities, bring out assumptions, narrow the scope of the project, and raise critical issues early on.

NO! The WBS does not delineate the steps to build anything. Actionable steps to do things are in the schedule.

If by 'steps' Brad means disaggregated deliverables, then ok. But if by 'steps' he refers to activities to achieve those deliverables, then NO.

There's no time line in the WBS, and as debated here before, no work in the WBS either. The WBS is just the proceeds of the work; and those proceeds--that is, deliverables--end at the 'water's edge' of the project.

 Bookmark this on Delicious  

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

Time Management of Complex Projects

Lynda Bourne has a post about a new book to be published in the United States this month: "Guide to Good Practice in the Management of Time in Complex Projects" . It was written by the Chartered Institute of Building in the UK.

I was intrigued by the title, and although I have not read the book, there is a nice 8 page Preamble at the publisher's site that invites more reading.

From that free document come the principles shown below. Of the four principles listed, three deal with risk--I guess that follows naturally from the topic of the book which is complex projects, complex enough to require some serious analaysis to synthesize a schedule from the project plan.

I like the one second one because it speaks directly to the role of architecture in the design of the project narrative and the management of risk. I don't necessarily agree that parallel structures are needed, but definitely there needs to be loose coupling between problematic elements, even in sequence.

In order to achieve effective time management there must be:

■ A competent appraisal of the risks which are likely to severely disrupt and delay the progress of the work;

■ A design which permits the work sequences that are likely to be severely disrupted and delayed by foreseeable events to be separated into parallel, rather than sequential paths;

■ A‘ time - model ’ for the project against which progress, or lack of it, can be measured;

■ A practically achievable strategy for dealing with intervening events during the design, procurement and construction processes.

 Bookmark this on Delicious  

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

Controlling chaos--really?

The April digital edition of PMnetwork has an article entitled "Controlling Chaos", a title meant to be provocative and eye catching, even if it is an oxymoron. After all, the mathematical or engineering definition of a system with chaotic properties is one with dynamic properties such that small changes in initial conditions render widely varying responses that are all but impossible to predict.

Some call this the 'butterfly effect', as illustrated by this recent example: A vegetable vendor in remote Tunisia sets himself on fire, and twelve weeks later a myriad of political events have transpired: two Arab governments have fallen and NATO bombs Libya.

So, now we learn there is a formula for chaos 'control'?

I don't think so.

Actually, the PMnetwork article had almost nothing to say about chaos, but focuses instead on possible but infrequent events, the so-called Black Swans.  Black swans and chaos are really not the same thing; the former could the outcome of the latter, but chaos is more about systemic responses.

But, the subject matter is timely, what with the Gulf oil spill last year, the earthquake et al in Japan, and the 'Arab spring', to name just a few recent events.

In the PMnetwork article, many managers give their advice: the universal black swan strategy seems to be to formalize a process of imagining the possible and then imagine the response. One manager recommended segregating Black Swans onto their own risk register.

That's advice I endorse. Effective management requires effective compartmentalization and affinity grouping. If you are going to walk and chew gum, it's best to have the gum separate from the walkway.

But here's my main point: if you can't practice, model, or simulate the response, or don't make the investment to do these these things, then you're probably just tilting at windmills. In some cases, given the complexity of some events, you might even have engage 'game theory' to evaluate responses.

What I'm saying is that atrophy sets in quickly in these one-off events. When you need it, response and responders are often unavailable, untrained, inoperable, rusty, or perhaps they don't even work as designed.

We learned last week that the blow-out protector for the Gulf oil well actually tried to do its job, but it didn't work as intended because designers didn't imagine that the well pipe might be bent by other calamities, like a gas explosion. Even worse, the performance shortfall may have been caused by a ubiquitous feature of the design.

Everyone it seems has their own black swan story.  Here's mine:

About ten years ago I was responsible for a business unit in Manila where I had 400 employees working in a downtown office building on the 4th and 5th floors. 

At the time, Manila, a city of 12M or more, was notorious for poor fire fighting response in the urban center.

There was only one small staircase for emergency exit.  I ordered my local managing director to organize and practice a fire drill.  Of course, the first issue was: "what is a fire drill?"

Second issue: no where to go. At first no other tenant, like the adjacent parking lot, would agree to let our evacuees assemble. [They wound up across the street in the mall]

A few weeks later I got an email in my office in Atlanta reporting the drill metric: 45 minutes to clear the two floors.  I called to find out why so long?  The answer: everyone was slowed down because they felt compelled to carry their desktop computers to safety!

The point: imagining the event [a fire] and the response [an orderly exit via the escape stairs] was not enough.  You have to invest in training, organization, and practice to have a workable black swan response!

 Bookmark this on Delicious  

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

Cockburn on leadership

Alistair Cockburn--the humanist of project management--writes in what you might call a 'conversational tone'.

Here's a bit on leadership--actually, the posting is on "Leader or Manager?"--wherein he comments on what's he heard at the NASA Project Leadership Forum of 2009:

... to “lead” already implies “change”. So a leader leads a change. (Somehow this thought had escaped my notice – had it escaped yours? It hit me pretty hard in the lecture.)

If the leader in question is the PM, the person is leading a change in order to stabilize things (we can lead in order to increase stability). (This thought knocked my socks off.) ... and then the PM can “manage” the stable ongoing situation.

I think I'll just let his comments stand on their own, except to say his posting has a rich compendium of commentary from the forum, well worth a look.

 Bookmark this on Delicious  

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