Musings on project management

Back to the real world?

2012-02-02T07:00:00.000-05:00

In one of the myriad prognostications on "the future" we've read around here, we learn that in 2012 we begin the great migration back to the real office, where real people collaborate, innovate, and create. In fact, we are told to expect these behaviors:

The landline, the jacket [for men], the commute, the handshake, and above all the office itself.
Out of fashion will be the virtual office in which employees sit hunched over laptops in their local Starbucks, joined to their colleagues by webcam and e-mail.
Employees will turn up to work at predictable hours five days a week, and will comport themselves with greater formality than before.
Face-to-face meetings will be preferred to video conferences; ideas will be exchanged not by tweet, but by the coffee machine.

The Economist, December 2011

Well, that's great news for agilists.

Agile is built around person-to-person face-to-face collaboration. It's pretty hard to do what Alistair Cockburn calls "communication by osmosis"--that is, absorbing what's going on around you--if you're not there to absorb.

Communication by osmosis is sort of the body language of office communication. There's something in the air,perhaps in the water, and you have to be there to get a sense of it. Otherwise, you're out of loop on some of the best stuff.

But of course everyone is not doing agile, so what's driving "back to the real world". Three things:

1. Defense: people with jobs want to be seen, and be seen productively engaged.

2. Culture: Remote working has been disastrous for spreading corporate culture, and

3. Inheritance: Virtual working has made it difficult for younger workers to pick up the tricks of the trade. And, that sword has two edges: older workers can learn from the young--new tricks, and all that!

And, to top it off, Volkswagen has turned off corporate email for most of its workforce during off hours. Good grief! Does that mean returning to a regular work day when stuff got done in the work place? What's next?

Bookmark this on Delicious

The plan is to persevere

2012-01-31T07:00:00.002-05:00

"... all things are always on the move simultaneously ... One has to do the best one can, but he is an unwise man who thinks there is any certain way .... The only plan is to persevere"

Winston Churchill as quoted by Max Hastings in "Retribution"

With this bit of wisdom tucked away, one can only marvel at the multi-tasking capability of the human mind, the tolerance most have for distraction, and the dynamic range we deal with from the trivial to the calamitous, with normal in between! Could Watson ever do as well?

Bookmark this on Delicious

Do the math!

2012-01-29T07:00:00.000-05:00

A funny thing happened on the way to advanced project management. Too many want the mantle but too few want to do the math. In fact, the PMBOK 4th edition has less math in it than the 3rd edition.

Project managers are most often judged on their metric performance--cost and schedule, etc--but few want to invest in the math skills to drive the metrics better.

For those wanting to catch up a bit, I strongly recommend the 15 minute videos at the online Khan Academy. You can start back in the 5th grade and work yourself through a graduate education in math and statistics. And, it's free. And, it's in bite size chucks. Here's a sample:

Bookmark this on Delicious

It takes a Theme

2012-01-27T07:00:00.000-05:00

Definition: A theme is the central idea or ideas explored .....

While you might start with an issue or theme in mind, themes will also develop or emerge as you write. It may not be until the editing stage that you even begin to recognize your themes. Having recognized them, your themes will help you determine what to cut .... and what to highlight.

Quoted from About.com

So, as between message, messenger, and presentation--the three pillars of communication--themes are the message.And, they show up everywhere:

Portfolios: Ask this: what's the message of the portfolio that binds the constituent programs, projects, and initiatives together?

In my PMO days, I had one portfolio that was exclusively CRM (customer relationship management); the message we wrote conveyed our idea of customer intimacy. (Remember Michael Treacy's and Fred Wiersema's 1993 paper in the Harvard Business Review: "Customer Intimacy and other Value Disciplines"? Intimacy, operational excellence, or product excellence are the big three)

Programs: like a portfolio, the "big idea".

Projects: the theme should come right out of the charter, the raison d'être as it were: why are we doing this project, or what's it to accomplish.

The agile guys have picked up the "theme" thing. In fact, agilists say that portfolios have "investment themes", the driving message for why invest in this or that portfolio. I like that one. And, then themes tie to epics--the top level narrative that explains what's going on. Leffingwell writes:

Epics are development initiatives that are intended to deliver the value of an investment theme and are identified, prioritized, estimated, and maintained in the portfolio backlog.

Agile Software Requirements

And, let's not forget marketing and sales; they've been around for centuries. In modern days for project managers it's proposals, the response to an RFP. Right up there in the executive summary ought to be the win theme--why me (or us)? If you've not tried to write such a message, give it a try sometime. You might find the message harder than it looks to get succint, effective, and memorable!

Bookmark this on Delicious

Experience from synergy

2012-01-25T07:00:00.000-05:00

Mike Cohn has a nice posting on something he calls "communities of practice" but which I think of as experience from the synergy of multiple players. Regardless of how you label it, I think his diagram says a lot:

Looking carefully at the diagram, notice both cross team and intra-team (vertical) participation in the "communities" (horizontal). Mike is Scrum-centric, so his diagram has a Scum master community. If I'd done the drawing, I would've been less prochial since there are many competing methodologies, other than Scrum, that provide quite good agile experiences.

And, by the way, this is not an agile idea per se. I've been doing things like this in the defense and aerospace business for years (old wine, new bottle?). However, Mike's presentation is very effective. (Remember: communications = message + messenger + presentation)

And, of course, the diagram is only a hint at what you can do. It's probably best to extend this to a program or portfolio. The PMO often instigates and sponsors such collaboration.

Many groups call such a matrix "birds of a feather". I have attended many "birds of a feather" collaborations at conferences and such. But Mike is saying: make it a regular and sustained practice, not just an occasional get together.

Good advice!

Bookmark this on Delicious

Tell me again, what's risk management?

2012-01-23T07:00:00.000-05:00

When I teach risk management, I always get these three issues:

The risk register, if it's done at all, is a dead end. You do it, probably up front, and rarely revisit it. And, you don't budget (or, are not allowed to budget) for the response plans, and like a dangling participle, the RR never connects to the real project (aka, baseline).

But, hey check a square: the RR is done! (And, so is risk management. Whew! that was hard stuff)

Second issue: Evaluating the quality of an estimate, or evaluating the quality of incomplete information--as from a sample--is said to be "not risk management". It's estimating or it's decision-making or it's sampling or it's quality management, but it's not risk management.

And third: without a formal process--like the six steps in the risk management knowledge area of the PMBOK as an example--there's no risk management going on, or there's no risk management that can go on.

Well, the first issue is troublesome, but not fatal. As many have said: "It's not the plan, it's the planning that has value". If''ve you got no funding, and an insensitive sponsor, then your risk response plan is "accept the risk". But, having done the planning, you'll be that far ahead if the risk event actually occurs. Not great, but usually not fatal.

The second is just misunderstandings. There're no facts about the future; only estimates in the present of what the future could be. There's uncertainty in every estimate, and thus by definition, there's risk. Risk management ideas apply, even if you don't do a risk register for every estimate. And, by the way, nobody does except for those estimates that have material strategic impact to the project. Otherwise, you fall back to reasonably accepted practices, like 3 point estimates and Monte Carlo simulations. That's risk management, even if it's estimating also.

The third is another form of misunderstanding. Everyone thinks about and manages risk every day, from driving to work to putting hot coffee in your lap. It doesn't take a formal process, but the mind, either working in System 1 or System 2, rapidly steps through identification, prioritization, evaluation, and response. You may not be conscious of the systematic way you process risks.

Of course, what about safety engineering and design? Doesn't that incorporate risk management in projects? And, don't leave out the "ilities". Mean time between failures (MTBF), mean time to repair (MTTR), and other "ilities" are all based on statistical uncertainty and statistical models. Where would projects be without the Poisson or Exponential distributions?

And, what about post-project business risks? These reflect back into the project as effects on performance, functionality, feature, and aesthetic appeal. Shouldn't these risks be "risk management" to the project manager?

And, on an even larger scale, every alert project decider considers the consequences, to include the affordability (or not) of consequences, in everything decided. That's risk management also. It's just not written down.

So, everyone's a risk manager, all day, every day!

Bookmark this on Delicious

Agile oscillators

2012-01-21T07:00:00.000-05:00

When I first got out of engineering school, one of my first projects was to build an oscillator. An oscillator is a device--should I call it an object?--with "just enough" reinforcing feedback of output back to input, with the feedback arrival timed just so, such that there is a constantly varying cyclic output, swinging first one way and then the other.

The nature of the varying cyclic output can be quite jarring, or it can be nuanced and smoothed out:

Now, along comes Agile, and my thoughts go back to the oscillator. And, I'm not the only one. Jim Highsmith has been thinking about the same thing. The architecture (stucture and behaviors) of all agile methods includes feedback, mostly from customers/users, but also from sponsors/stakeholders. The mandate for agile teams is to respond, and be responsive, to feedback. That is, a sample of output--in the form of user experience--becomes a part of the input to the deliberations of the agile team.

Now, if the feedback is phased (timed) one way, it will stablize the iteration. Change the timing a bit and it will destablize the iteration and cause oscillations. In effect, the team builds one thing, only to find out--in the wrong timing--that the customer has changed their mind; the team responds to the change. But, meanwhile, the customer is experiencing the wrong (earlier) thing and seeks correction. Ooops! the team is driven back, or a different way.

If the timing is never corrected, the iteration becomes oscillatory and really nothing gets done.

Time for the project manager to step in and call a halt and dampen the oscillations. Everyone needs to take an Iteration 0 break to do a little reflection and get the timing reset. Maybe a spike needs to be inserted to allow for some non-deliverable prototyping or modeling.

In any event, oscillations can not be allowed for more than a cycle, perhaps two. If not naturally damped out, the PM must take action!

Bookmark this on Delicious

Square root of 2, and more!

2012-01-19T07:00:00.006-05:00

I started to tag this posting "trivia" but thought better of it. But I was interested to learn from John Baez, a mathematician of some renown, that the Babylonians had pretty much worked out the square root of 2, an irrational number not the ratio of anything, and they did it using a number system with base 60.

Here's the proof, according to mathematician Baez. A tablet, written by a beginner because of the large lettering, has sides of length 1/2 (30 in base 60) and writing that shows the calculation of the diagonal to an excellent approximation of Sqrt(2)*1/2, or 1/Sqrt(2).

Baez explains:

Well, actually, there's no evidence that the Babylonians (now, Iraqis) ever knew about irrational numbers. They expressed everything in fractions and used approximations.

And that by the way is the lesson for project managers: we live in the one-sigma world where a decent approximation is "good enough". A lot of really good project management gets along fine on approximations. We can leave to Dr Baez to give us the theoretical underpinnings!

Bookmark this on Delicious

What are you doing?

2012-01-17T07:00:00.000-05:00

If you can’t describe what you are doing as a process, you don’t know what you’re doing.

W. Edwards Deming

Bookmark this on Delicious

Government technology opportunity

2012-01-15T07:00:00.000-05:00

TechAmerica has issued a very readable report entitled Government Technology Opportunity in the 21st Century. There are four top level recommendations:

1. Develop a Professional Program Management Capability (you might ask: isn't this a long time coming? Hasn't the US federal government been in this business since WW II?)
2. Promote Agile/Incremental Development (Now of course this is a genuine newbie)
3. Strengthen Risk Management (again, a bit late, but welcome anyway)
4. Enhance Internal and External Engagement (needed for agile, but needed in any event)

On the first point, this telling quote from someone who contributed to the report:

“Strong program managers have overcome poor requirements, aggressive milestones, limited resources and constrained processes to deliver mission capability, while processes have not been able to compensate for a poor program manager even with clear requirements and sufficient resources.”

On the second point, we are told this:

The benefits of agile/incremental development can be seen in the results of a survey of commercial IT developers published in the June 2008 issue of Dr. Dobb’s Journal and cited by Scott Ambler, Chief Methodologist for Agile and Lean at IBM, in discussing the effectiveness of the methodology.

Survey respondents compared agile to other methodologies and rated it as follows:

 Productivity—82% rated it somewhat or much higher
 Business Stakeholder Satisfaction—78% somewhat or much higher
 Quality—77% somewhat or much higher
 System Development Cost—72% somewhat or much lower

To implement agile, the report goes on to cite a few regulatory and cultural hurdles to overcome. Glen Alleman puts it this way:

... self directed teams sitting in the same room with their customer, letting the requirements emerge as the money is being spent, probably isn't going to pass the smell test of Congressional oversight of spending the public's money

Nevertheless, if the recommendations in this report are acted upon, the federal IT business will be the better for it.

Bookmark this on Delicious

Agile PMO

2012-01-13T07:00:00.003-05:00

Over at Eight to Late, Mike Griffiths has a slide presentation on the agile PMO. He tells how the PMO can go from Present Many Obstacles to Provide Many Opportunities.

It's a nice play on the words, but there are some instructive ideas in the slide deck (available for download), if you can abide the agile-is-only-way arguments.

First, Griffiths builds the presentation around 9 bullets that are the things that PMO's are supposed to do:

Then he fills in details--from his point of view--about how traditionally managed PMO's need to change--a new game theory in his mind--to be compatible and useful to agile projects.

Of course, a balanced point of view is not Mike's forte. This is a red meat "preaching to the choir" presentation given to an agile conference of agilists.

For example, under bad old way, we read:
Monitor and control project performance – track progress against
inappropriate measures such as getting requirements fully documented and
signed off

Under agile is the silver bullet, we read:
Monitor and control project performance – track velocity, track team and
sponsor satisfaction ratings, look for dangerous velocity trends, check
backlog size, monitor iteration and release plans

Now, I count myself among practical agilists, as explained in my book, but I also know that literally billions of lines of code written the bad old way are up and working fine, so whereas I agree this generation has a good idea in agile, it's not the only game in town.

For another perspective on portfolios and agile, take a look at this:

Portfolio management and agile: a look at risk and value

View more presentations from John Goodpasture

Bookmark this on Delicious

Disorder

2012-01-11T07:00:00.001-05:00

Brian Greene is a superstring theoretical physicist and mathematician with a flair for communications. This fall he has been hosting a public broadcasting series on the fabric of the cosmos, based in part on his book, brilliantly written, of the same title.

Of course, the fabric of the cosmos is not about project management, but it is about complexity, and that's something we all endure in projects and in life.

One principle Dr Greene writes about struck me as spot on: the more complex a system is, the more disorderly it is. In fact, the natural tendency of complex systems, if not otherwise constrained, is to seek disorder.

On one level it's intuitively obvious: the number of communication paths between N devices approaches N-squared when N is large. Every communication path is a potential pathway to trouble.

So, when I read the literature on Lean thinking, the ideas of small batches, limited backlog, and minimialist tasks is all the more striking. Maybe the lean guys are onto something!

And the agilists and Kanban'ers have it going also: keep everything as small and simple as possible--like one sentence story cards and simple use case models--just like our friend Einstein counseled ("Make everything as simple as possible but not simpler"). Of course the simplest possible can still be complex, but at least we made the effort.

And, one more thing: that principle we started with--it was developed in the 19th century as the 2nd Law of Thermodynamics. Who knew!?

Bookmark this on Delicious

Adopting agile

2012-01-09T07:00:00.001-05:00

To succeed with agile, management’s need for results must be greater than their need for control. —Israel Gat, formerly of BMC Software

This statement is so profound, I think I'll just let it stand on its own.

Source: Originally quoted by Dean Leffingwell in "Agile Software Requirements", Chapter 22.

Bookmark this on Delicious

Predicting the future

2012-01-07T07:00:00.000-05:00

The best way to predict the future is to invent it

Alan Kay, computer scientist

One might have thought this would have been a Steve Jobs quote, but no--there are other innovators.

Of course, the point is that opportunities are only as valuable as we make them by engaging and applying ingenuity and effort. And, if the future is not as bright as needed, then envision what's needed and go "all in"

Bookmark this on Delicious

IT risk management spending

2012-01-05T07:00:00.003-05:00

In a recent posting, we are told that IT spending on various business services for risk management in business processes will out pace the traditional IT spending on financial applications. Everything from asset management to information security.

And, in another article, we are told that personal data privacy is only going to grow in importance and compliance demands. That's a good thing!

Wow! That's quite a development. Perhaps risk management has arrived at last.

And to projects and project managers, it all rolls downhill. We should expect to be evaluating, developing, and validating all manner of risk management applications and services.

And here's a thought: We may find ourselves using risk management to evaluate risk management!

Bookmark this on Delicious

NICE Cyber

2012-01-03T07:00:00.006-05:00

The National Initiative for Cyber Education (NICE) is hard at work. From their website, we learn that: "Today, there is little consistency in how cybersecurity work is defined and described throughout the nation. The lack of a common language to discuss and understand the work requirements of cybersecurity professionals hinders our nation's ability to:
-Baseline capabilities,
-Identify skill gaps,
-Develop cybersecurity talent in the workforce, and
-Prepare the pipeline of future talent."

Thus, a workforce framework has been developed by NICE, a unit of the National Institute of Standards and Technology (NIST).

The seven NICE categories are:

1. Securely provision - conceptualizing, designing and building secure IT systems;

Information assurance compliance
Software engineering
Enterprise architecture
Technology Demonstration
Systems requirements planning
Test and evaluation
Systems development.

2. Operate and maintain - the support, administration and maintenance necessary to ensure effective and efficient IT system performance and security;

Data administration
Information system security management
Knowledge management
Customer service and technical support
Network services
System administration
Systems security analysis.

3. Protect and defend - the identification, analysis, and mitigation of threats to IT systems and networks;

Computer network defense
Incident response
Computer network defense infrastructure support
Security program management
Vulnerability assessment and management.

4. Investigate - investigation of cyber events or crimes, which occur within IT systems or networks, as well as the processing and use of digital evidence;

Investigation
Digital forensics.

5. Operate and collect - the highly specialized collection of cybersecurity information that may be used to develop intelligence;

Collection operations
Cyber operations planning
Cyber operations.

6. Analyze - review and evaluation of incoming cybersecurity information to determine its usefulness for intelligence;

Cyber threat analysis
Exploitation analysis
All source intelligence
Targets.

7. Support - specialty areas that provide critical support so that others may effectively conduct their cybersecurity work;

Legal advice and advocacy
Strategic planning and policy development
Education and training.

Bookmark this on Delicious

Happy New Year!

2012-01-01T01:00:00.004-05:00

Photo

Communication pragmatics

2011-12-30T07:00:00.001-05:00

A recent book review on the pragmatics of communication highlighted three ideas I'd not thought a lot about, but perhaps I should:

In the presence of another person, it is impossible not to communicate: This point is so obvious as to often be overlooked: silence amounts to communicating that one does not want to communicate. [Think about this as you contemplate virtual situations ... communications may not survive all that well]

Every communication has two aspects to it: ..... what matters is not only what is said, but how it is said and the context in which it is said.

The relationship is defined by how participants perceive a sequence of exchanges: A dialogue consists of a sequence of exchanges between participants. However, the participants will punctuate the sequence differently [In other words, the value of communications is changeable by sequencing and cadence]

Bookmark this on Delicious

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

IT technology Top Ten

2011-12-28T07:00:00.003-05:00

Michael Cooney has posted Gartner's Top Ten for IT technology:

The Top 10 Trends and their impact, briefly include:

1. The evolution of virtualization: ... virtualization will ultimately drive more companies to treat IT [more] like a business. [Perhaps, but virtualization will more likely continue to change our idea of borders and boundaries, making them more virtual than real]

2. Big data, patterns and analytics: Unstructured data will grow some 80% over the course of the next five years, creating a huge IT challenge.

3. Energy efficiency and monitoring: The power issue has moved up the food corporate food chain.... An average x86 server that is turned on, but idle, will draw upward of 65% of its nameplate wattage, for example.

4. Context aware apps: ... context-based computing will go beyond the business intelligence applications and truly make a unified communications environment possible .

5. Staff retention and retraining: Loyalty to one company is not a quality found in new workers.

6. Social networks: Ignoring social networking is not an option

7. Consumerization: The key trend here is the fact that new application types will be developed to address mobile users but they won't be desktop replacement applications.

8. Compute per square foot: ... average server performance can move from today's paltry 7% to 12% average to 40% to 50%, yielding huge benefits in floor space and energy savings.

9. Cloud computing ...the biggest benefits of cloud computing are built-in elasticity and scalability.

10. Fabrics: Gartner defines this infrastructure convergence as: The vertical integration of server, storage, and network systems and components ...

Bookmark this on Delicious

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

That velocity thing

2011-12-26T08:56:00.015-05:00

Jim Highsmith, a guru in the agile space, has an interesting post on that velocity thing. Velocity, you will recall, is the agile name--originally an XP name--for the rate throughput can be delivered to customers, or, if not delivered to customers, the rate at which throughput--finished deliverables--can be queued for rollout according to some rollout strategy and workflow.

Now, the idea of throughput is not an agile thing, per se. Go back to the mid-1980s to Eliyahu Goldratt's Theory of Constraints (TOC). TOC is all about optimizing at the enterprise or project level maximum throughput to customers. Velocity was not a Goldratt idea, but Eliyahu certainly focused on cadence, using the metaphor of the drum-buffer-rope.

Of course, project managers may know Goldratt for his theory of the "Critical Chain", a risk management strategy for insuring on-time delivery. Critical chain is an outgrowth of TOC, and it's Goldratt's idea of how to put some of his throughput management ideas into the body of knowledge for project management.

I digress--as often happens here at Musings--so back to Highsmith's lament: he says that having positioned velocity as a calibration metric on team performance, project managers should not then count on teams to achieve the predicted performance because a emphasis on performance may then trump quality, the ultimate goal of an agile project. Even the customer may become part of the problem. In his words:

Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.
Focusing on volume detracts from the quality of the customer experience delivered and investing enough in the delivery engine (technical quality).
Giving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine.

Dean Leffingwell makes a similar point in his book "Agile Software Requirements: Lean requirements practices for teams, projects, and enterprises". He says that if the velocity metric is turned back on the team by managers, the team will do one of three things:

Practice continuous improvement to meet management objectives
Sacrifice quality in the name of speed, or
Sandbag estimates to create velocity buffers

Of course, my point is not to use the metric to amp up productivity, (that's Highsmith and Leffingwells's fear) but to use the metric as an expectation suitable for estimating. If you can't estimate, what's the point of the metric?

And, they've got a point about sacrificing velocity if quality is the ultimate driver. But that puts 'better' as the nemesis of 'good', and puts in question the real advantage of agile that, in my mind, is delivering best value (which could be different from best quality, though I've not thought that all the way through).

And, you ask, what's my idea of best value? Simply put:

Best value is the most valuable outcomes achievable, as judged by the customer, for the investment available from the sponsor
Best value is the most bang for the buck, a best compromise of scope and quality in context of fixed investment and a critical need date.

By the way, I'm all about throughput. You really can't do a decent job as a agile manager unless you can benchmark for throughput and then hold teams accountable.

The issue is: accountable for what? I say the answer to Highsmith's issue is to get the iteration backlog right with the customer and the project team at the point of release planning. Once planned for best value, then bring on the throughput!

Bookmark this on Delicious

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

Happy holidays to all!

2011-12-25T07:00:00.003-05:00

Photo

2011-12-24T07:00:00.004-05:00

On the eve of Christmas

Best wishes to all for the holidays!

Photo

Quantum computers in the offing?

2011-12-22T07:00:00.002-05:00

... the team has demonstrated that it is possible to take photons from two disparate sources and render these particles partially indistinguishable ... [suggesting] in principle that they can connect various types of hardware devices into a single quantum information network.

This bit of quantum news was recently reported by the National Institute of Standards and Technology (NIST) on their blog. And, actually you could say it's a breakthrough that might lead to quantum computers and a whole new era of amazing computational power. Who knows where that might lead?

I can't wait to hangup the silicon laptop for a photon computer!

Bookmark this on Delicious

Agile and architecture

2011-12-20T07:00:00.054-05:00

If you accept this fact—that the choices you make today will most certainly be wrong in the future—then it relieves you of the burden of trying to future-proof your architectures. —Richard Monson-Haefel, author of 97 Things Every Software Architect Should Know

It continues to amaze how some agile advocates fail to recognize, and even deny, that when you put together something as simple as two objects, you've created architecture (definition: a description or specification of behavior, appearance, structure, and relationship of and among components).

Thus, when some agilists say they need not concern themselves with architecture, or that it is not all that important, I wonder what planet they are on. Attention: even if it's not written down, or put to powerpoint, a system (two objects, or more) has architecture, and their behavior jointly may well be important and worthy of evaluation.

And yes, I'm aware of this agile principle: "The best architecture, requirements, and designs emerge from self-organizing teams", though I'm not alone saying this principle is decidely limited to the small bore and fraught with scalability issues.

My attention was drawn to a posting by Phillipe Kutchen entitled "Agility and architecture koan" for two reasons:,

I did not know what "koan" means; I thought I might find out.
He quote a truly mindless statement from a LinkedIn group: “Self-organizing teams can decide everything by themselves. So they don’t need an architect.”

The former means paradox, or non-sensical statement or question
The latter is just mindless, but to give the widest possible latitude, perhaps the author was referring to a dedicated position called "architect" and not trying to say that team members should not be architects, or worse: there's no architecture per se.

Anyway, I am in the Kutchen school. In a book I wrote about agile in enterprise projects, and in an article Kutchen wrote for Software (an IEEE publication), Agility and Architecture: Can They Coexist?, we both expound on the obvious: architecture is a matter of context, project context, but all projects and all systems possess architecture, whether you want it or not.

And, of course, even unabashed and credible agilists like Dean Leffingwell, author of numerous well regarded books and articles on software practices in general and agile practices specifically, says that as a project becomes more than the scope of one team working:

For developers, architects, and businesspeople who have experience building large-scale systems and portfolios consisting of systems, products, and services—with the extensibility and scalability a successful solution demands—a solely emergent architecture is counter to our experience. We know that some amount of architectural planning and governance is necessary to reliably produce and maintain such systems. Individual teams, products, and programs may not even have the visibility necessary to see how the larger, enterprise system needs to evolve. It can’t simply emerge. Something has to tie it all together......

For developers, architects, and businesspeople who have experience building large-scale systems and portfolios consisting of systems, products, and services—with the extensibility and scalability a successful solution demands—a solely emergent architecture is counter to our experience. We know that some amount of architectural planning and governance is necessary to reliably produce and maintain such systems. Individual teams, products, and programs may not even have the visibility necessary to see how the larger, enterprise system needs to evolve. It can’t simply emerge. Something has to tie it all together.....

Even minor, system-level redesigns can cause substantial rework for large numbers of teams, some of whom would otherwise not have to refactor their module. It is one thing for one team to redesign their code based on lessons they have learned; it’s quite another to require ten teams to do so based on another team’s lessons learned.

And no less an eminence than XP's Kent Beck writes:

Architects on an XP team look for and execute large-scale refactorings [and] write system-level tests that stress the architecture....

While the system is little, the architect makes sure the system has just the right little architecture.

In another space, Computing Now, Maurizio Morisio provides a half-dozen links to reputable thinkers about the role of architecture, architects, and the intersection with agile methods. Take a few minutes, and read all about it!

Source:
Chapter 20 "Agile Achitecture" from Dean Leffingwell(2010). "Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise", Addison-Wesley Professional. Kindle Edition

Chapter 10, "The Whole XP Team" from Kent Beck (2004)"Extreme Programming Explained: Embrace Change" Second Edition; Addison-Wesley

Bookmark this on Delicious

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

Risk or Opportunity management?

2011-12-18T07:00:00.008-05:00

What's going on here?

Venture capitalists put their money at risk and successfully backed a start-up called Facebook
Jon Corzine took a risk on European soverign debt and went bankrupt, but John Paulson and George Soros took similar risks during the financial crisis and made billions.
General Bernard Schriever couldn't risk a failure of the fledgling ICBM program, so he developed the Titan and the Atlas concurrently using different designs
General Samuel Phillips couldn't risk missing a presidential schedule for the moon landing, so he ordered an unprecedented test program to flight test the Apollo multistage rocket as one stack rather than test each stage independently.

Are these examples of risk management, opportunity management, or some combination? And, by the way, is there a difference, and even so, does it matter?

In other words, is "taking a risk" risk management, or opportunity management?
And, is this posting about counting angels on the head of a pin, or is there a worthy point to be made?

Actually, I say there is, in this respect:

Taking a risk is usually understood to mean taking advantage of an opportunity, an event out of the ordinary, or an event that is off the strategic path. If it works out, the "risk takers" get rewarded, in some proportion to the risk taken: more risk, more reward. If it doesn't work out, either the risk takers are punished, or at the least not rewarded.

Managing risk is usually understood to mean preventing an untoward outcome that might derail a course of action or unfavorably impact an outcome. If it works out, the risk managers are rewarded according to the project success, not according to the impact avoided. In other words, successful failure avoidance is not rewarded directly; reward is only indirectly through whatever incentive was placed on project success.

And, in the project domain, project managers, as a matter of routine, are expected to be successful. Rewards are modest, given the expectations. Stakeholders who "take a risk" and are successful are usually much more handsomely rewarded. This is not a sour grapes argument, just a discourse about risk and reward vs. opportunity and reward.

Dr Edmund Conrow is an academic, an author, an advisor to defense programs, and a skeptic of opportunity management (at least in the project domain, and domains are important because some concepts don't port well between domains).

But, Conrow provides us with a simple but useful definition of opportunity management: "In simple terms, it's a change in direction of the status quo that will leave us--we believe--in a better place than is currently anticipated". And, he says, to purse an opportunity requires "....allocation or reallocation of resources...".

I agree with Edmund: opportunity is a change in direction; and my corollary is: risk is a threat to not changing direction.

In an article written in 2008 in the DoD publication AT&L for March of that year, entitled "Opportunity Management", Conrow disses the idea that risk and opportunity are more or less opposite sides of the one idea that there are events in the life of a project that will push it off track--risk being a unfavorable outcome, and opportunity being a favorable outcome.

Conrow is not an opportunity denier; far from it. He advocates opportunity management in the sense of a search for alternatives, but not after the baseline is committed. Once committed, the baseline is to be managed to hit its targets until some formal baseline change is initiated and approved.

But, is a planned make/buy decision that is deferred until circumstances are more clear an exercise in opportunity management or risk management?

He sets aside, rightly so in my mind, the idea that project managers deliberately ignore four opportunity possibilities advanced by opportunity advocates, saying most competent managers maintain 360 awareness of these types of opportunities:

Opportunity to improve the baseline when there are otherwise no risks
Opportunities that are the inverse of a risk to baseline
Opportunites that arise from the interactions of risks to the baseline, and
"Pure opportunites" unrelated to, or different from, the baseline plan

Bottom line: taking a risk and managing risk are different; they both belong in the project manager's domain. The former is a change management agenda; the latter is a baseline maintenance agenda. There's room for both, as there should be.

Bookmark this on Delicious

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

Voice of the customer

2011-12-16T07:00:00.015-05:00

General James F Amos, Commandant of the US Marine Corps, has taken on the acquistion bureauracy since assuming command of the Corps.

At issue: favored acquisition programs for modern weaponry for the Marine Corps, and to some extent, a rescue of the Marine's mission, now under fire as an unncecessary second land army.

So, when I see in a recent interview where Amos says that he had appointed himself player-coach (his phrase) on a number of troubled projects, I had to read further.

A couple of his thoughts that caught my eye:

Math decisions are easier than thoughtful decisions based on strategy and what's best for [the mission]

[To his professional acquisition team]: You're telling me it will take 14 years to get the requirements right, develop this thing [a new amphibious vehicle], source select, test, and then field initial capability? You're crazy!

And of course he's right: if we've waited 14 years for major solutions, like the mine resistant reconnaisance vehile developed for Iraq, we'd be five years yet getting it.

Perhaps General Amos should take a page from USAF General Bernard Schriever, the father of modern program management and system engineering, who, the post war 1950s, pretty much invented how to do military weapons programs (the exception being the WW II program for the 'bomb', a program that Schriever did not participate in). In a recent book, "A Firey Peace in a Cold War: Bernard Schriever and the ultimate Weapon", by Neil Sheehan, General Schriever's acquisition methods are explained in a great tale of the Cold War.

His idea is to put system engineering on the front burner, work quickly with prototypes, develop high risk ideas with multiple concurrent solutions, drive hard for the initial operating capability, and don't let better defeat good. In other words, don't let strategy, or strategic purpose starve innovation. Be prepared to accept opportunity as perhaps a better way.

Perhaps, Schriever was the original agilist!

Bookmark this on Delicious

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

Risk management -- what a concept!

2011-12-14T07:00:00.023-05:00

While the firm encourages risk-taking ....., it also empowers its risk managers — at other firms considered the back office — to constantly challenge even the most senior leaders to keep them from going over the cliff.

"98 percent of my time thinking about 2 percent probabilities.” That is not something you hear from most .... chief executives

Andrew Ross Sorkin

What a concept: bring risk management out of the back office!

Now, here's the problem with that: Risk management is about avoiding failure; incentives reward creating success. It might look like this is two sides of the coin, but they really aren't. Project managers are told "it's your job" re the latter; sponsors and stakeholders are in the driver's seat for the former.

So, senior management follows the money. No news there.

But of course, we are told: risk and opportunities are both part of risk management. But are they really? RM has its own process; opportunities need not apply. Opportunities are managed either in a portofolio, strategic plan, or in a project's change management process. The overlap with RM is coincidental at best.

So, if there firms that put RM on the front burner, I say: more power to you!

Bookmark this on Delicious

Complexity anyone?

2011-12-12T07:00:00.010-05:00

John Biaz, a mathematician rather than a project manager, asks some provocative questions from time to time that are of interest to us. The latest in his post on complexity:

What can you do with just a little information?

• Bill Gates’ first commercial success was an implementation of a useful version of BASIC in about 4000 bytes;

• The complete genetic code of an organism can be as short as a few hundred thousand bytes, and that has to be encoded in a way that doesn’t allow for highly clever compression schemes.

This from Wikipedia:

Recent computer hardware advancements include faster processors, more memory, faster video graphics processors, and hardware 3D acceleration. With many of the past’s challenges removed, the focus .... has moved from squeezing as much out of the computer as possible to making stylish, beautiful, well-designed real time artwork

On the other hand, Baez's friend Bruce Smith produced this video (sans hardware infrastructure) in 4KB (that's a rounding error on a rounding error in most programs today). So, don't say it can't be done; don't accept bloat; be lean!

Bookmark this on Delicious

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

Keep calm and carry on

2011-12-10T07:00:00.000-05:00

Mike Clayton has a suscint post built around this WW II poster--which, itself, has an interesting history--that summarizes ten ideas for stress management (my editorials added; for Mike's annotation, click on the links):

1. Build in planning time
Of course, if you're not a natural planner, this is toughy, and you may actually be comfortable with the stress of deadlines.

2. Give yourself some contingency
Essentially, #1 operationalized

3. One thing at a time
If you are a natural at multiplexing, go ahead. I, for one, have three books that I am reading in multiplex format

4. A problem shared...
Nothing quite like the sounding board of a creative partner

5. Get up and walk around
What works for me is to change venue. Sometimes I take the laptop to a coffee shop. When working in a corporate setting, sometimes I go to an empty conference room.

6. Tidy up
Or, don't. It depends on if 'tidy' adds comfort or stress

7. Smart snacking
This one never works for me, so I don't keep any snacks around, except fruit

8. Have a rant...
... but choose your timing carefully
Actually, this one's not for me, either in person or by email (horrors!). Better left unsaid that which you can't afford to live with

9. Stress is a part of success
Yes, it is. Everyone needs stress to function; it's a matter of degree

10. Focus on your achievements
Yes, this is a good one from time to time.

Bookmark this on Delicious

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

Think like a beginner

2011-12-08T07:00:00.006-05:00

"Think like a beginner!"

That's the big take away from an interview with Salesforce.com CEO Mark Benioff. And, what exactly, does that mean, and what does it mean for project management?

Benioff was pontificating on why some established organizations can't get on the page of destructive innovation, and why they can't seem to get past a one-trick success. His take: they don't think like beginners... they don't think like they did when everything was a blank story board and they had no legacy to preseve and no install base to keep relevant.

Example: According to Benioff, failure to think like a beginner explains, in part, why Microsoft missed the mobile market. According to Benioff, who was a Apple guy when Jobs was there doing the Mac, the genius of Jobs was his ability to constantly think like he was starting over. Thus, Apple came in and destructively innovated the mobile market, unlike MS, in spite of both having a large legacy install base of personal computers and PC applications.

And, this is not first time Apple was willing to throw away the legacy, in spite of customer angst. Apple was the first to throw away the "A" drive at time when people had hundreds, if not thousands of records on 1Mb floppies. Instant obsolescence of the installed base. Apple's reply to customers: "get over it!"

So, what about projects? In most cases the project manager is not the product manager, not even the product owner. (Owner vs manager: I'm making a distinction between an inward looking manager and a outward looking manager, the latter having the larger portfolio (scope)). The project manager pretty much builds what the product owner wants, especially if the agile mindset is followed. There isn't any doubt that Apple project manager's developed what Jobs wanted.

So, is there a place for the project manager to indulge in "destructive innovation"? Yes and no is the indefinite answer. To restate the obvious: anyone can have a good idea. But of course, not everyone takes--or can take--responsibility for consequences. That's where project management comes in: the PM is accustomed to accountability. If there's a good idea--requiring everyone to think like a beginner--there's no beginning if someone does not step up to the opportunity. Someone has to be the risk manager--and guess what, there's no doubt who that is: PM every time.

Bookmark this on Delicious

December 7, 1941

2011-12-07T07:00:00.006-05:00

December 7, 1941: A day that will live in infamy!

To see how this ends, I suggest reading Max Hastings' brilliant history of the Pacific war for 1944-1945, entitled appropriately, "Retribution"

Bookmark this on Delicious

Kahneman and Tversky

2011-12-06T07:00:00.003-05:00

Daniel Kahneman and Amos Tversky have written notable papers about the biases that infect and affect project estimates, the business case, and all communications with executives and stakeholders. These papers are simply nothing other than "must reading" for every project manager.

I've posted about these guys and their ideas before.

Kahneman won the Nobel prize for his contributions, and if Tversky had not died in 1996, four years before the Nobel award, he would have been in Stockholm with his colleague for a joint award.

Now, Kahneman is out with a new book, some 500 pages--perhaps best read (or sampled) on an e-reader--to explain another idea. This idea is about how we think and what drives decision-making. Entitled "Thinking, Fast and Slow ", it posits a System 1 process and a System 2 process. System 1 and 2 are not new inventions by Kahneman, but his tour-de-force through the concepts is a work worth reading.

The idea is simple on the outside: System 1 is nearly unconscious thinking--effectively nearly instant reactive thinking. Everything from survival to instant analysis, like finding an open receiver downfield. System 2 is conscious analysis, slower than System 1, though not necessarily slow. These two ideas inform the title of this tome: Thinking, fast and slow.

Kahnenman writes: "Much of the discussion in this book is about biases of intuition.... my aim ... is to improve the ability to identify and understand errors of judgmenet and choice ....by providing a richer and more precise language to describe them."

And, here's one we can all identify with: "Unfortunately, professionals' intuition does not arise from true experience", indeed, executive "... judgments and decisions are [often] guided by feelings of liking and disliking, with little deliberation or reasoning". For the quantitative manager, decision making driven by such intuitive thinking is the height of frustration!

Summary: it's a tome to be sure, but it's a good read, and worthy of scanning and sampling--highlighting and bookmarking in an e-reader (there are many free ones for laptops and tablets).

Now,

Bookmark this on Delicious

To think first

2011-12-04T07:00:00.013-05:00

“It took a year of thinking before we built any prototypes,”

Serge Montambault,

Mechanical engineer with Hydro Québec’s research institute

And, to top it all off, his project to build robots to inspect high power transmission lines is a business success.

It's remarkable what thinking will do. And of course, take note that from thinking, the next step was prototypes, not full scale development.

Remember the spiral method? It's a prototype-first idea from the last century, inspired by Dr. Barry Boehm of then-TRW. His idea: you can't be sure of which direction to step off when faced with technology feasibility issues, so take the time to experiment to find the right direction.

Bookmark this on Delicious

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

Why plan

2011-12-02T07:00:00.008-05:00

It's agile! Why plan?

Do we really need to answer this?

Yes, we do!

If there are no plans, any outcome is acceptable; if there are no plans, there is nothing to estimate; without estimates, there is no reason to measure.

Without measurements, there will be no benchmarks, no improvement, and no answer to the questions of where are we? and what are we doing?

In fact, without a plan, anywhere and anything will do.

"Project management the agile way: making it work in the enterprise"

Bookmark this on Delicious

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

The server ate my homework

2011-11-30T07:00:00.008-05:00

The server ate my homework! In a recent article, I learned that some schools are taking big steps and making wholesale changes to introduce technology in the classroom. Here I find out that students do work on laptops--provided by the school--and in real time teachers track progress and problems on a linked iPad. Now that's interesting integration!

On the other hand, that's a lot of change management, and a lot of change management for what is commonly thought of as a bastion of traditionalism: the K-12 teacher corps.

If successful, whatever is in the water should be bottled and given out to every ERP project. Lord knows that industry could profit by the examples given in the classroom transitions.

Perhaps this was never more true:

If you can't make the trains run on time, do away with the trains

Bookmark this on Delicious

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

Value stream mapping

2011-11-28T07:00:00.000-05:00

Value stream mapping seems to be a new label on old wine. But nevertheless, the wine ages well. In the old days, we simply called it process mapping.

Value stream mapping derives from the Lean community, where of course the focus is on leaning out non-value add. So, in value stream mapping, each activity, to include the workflow of authorization and other governance, and ancillary activities, like a trouble report or a status report, is evaluated for value-add.

And, of course that begs the question: what is value-add? There is an answer, of course, but it may take a bit of customization to make it work everywhere. Simply put: anything that is ultimately delivered to the customer or makes the customer deliverable a good thing in the customer's eyes.

A lot of governance would not fit this definition directly, but most indirect activities don't. Nevertheless, most practical organizations can't live without them, so there's a certain non-value overhead that goes along with everything.

One thing I do like about value stream mapping is the clarity of the diagramming.Take a look at this diagram:

If you're interested in more, this diagram came from a nice post at LeadingAnswers

Bookmark this on Delicious

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

Messy information systems

2011-11-26T07:00:00.000-05:00

Do you buy this idea?

... science-based, method-driven approaches can be misleading. Contrary to their promise, they are deceivingly abstract and removed from practice. Everyone can experience this when he or she moves from the models to the implementation phase. The words of caution and pleas for ‘change management’ interventions that usually accompany the sophisticated methods and polished models keep reminding us of such an implementation gap. However, they offer no valid clue on how to overcome it…

Does this mean you have to see it to believe it, or does it just validate the ideas of progressive elaboration (defined in the PMBOK as continuous improvement and refinement) or emergence (unpredicted--though perhaps predictable--interactions of system elements that become known)--or neither?

No matter how you go on this, you might like the book review of "The Labyrinths of Information: Challenging the Wisdom of Systems" by Claudio Ciborra as reviewed by EightToLate

Bookmark this on Delicious

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

The project sentence

2011-11-24T07:00:00.000-05:00

Richard Feynman is a renown theoretical physicist (deceased 1988).

He once said that if he had to summarize modern science in one sentence he would choose: "The world is made of atoms".

Brian Greene, also a theoretical physicist, has written of Feynman's choice: "When we recognize that so much of our understanding of the universe relies on the properties and interactions of atoms......we can well appreciate Feynman's choice for encapsulating our scientific legacy."

And, there are other sentences. Many have said: "The business of business is business", meaning customers are swell, but shareholder value is better!

So, what about a project sentence? It would be great it would unify the three great values of project management:

Customer value (value as experienced by the customer)
Business value (value returned to the business as a consequence of project activity), and
Earned value (a measure of the effective utilization of the business resources committed to the project)

And, it would be neutral on plan driven vs outcome driven (agile)

So, how about this?

The business of projects is to effectively invest business assets to return to stakeholders value from the affirmative vote of customers

Brian Greene: "The Fabric of the Cosmos"
Photo

Bookmark this on Delicious

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

About change

2011-11-22T07:00:00.000-05:00

Change is the price of survival

Gary Player

Professional golfer

Bookmark this on Delicious

PMBOK Software projects practice standard

2011-11-20T07:00:00.000-05:00

LeadingAnswers has a nice summary of the motivations behind the practice standard for software projects now being put together by PMI. It's barely an outline now, but it will soon be joining the other practice standards that are either unique to an industry or to a domain, like construction and US Defense Department.

Here's a look at some of the issues to be addressed in the words of LeadingAnswers:

Specification problems – software projects are hard to define because they are intangible and hard to reference.
Evaluation Problems – We really need to see and use software to say if it is suitable for us, reading a spec is a poor method for validating functionality. IWKIWISI – I Will Know It When I See It applies.
Knowledge Worker domain – we are using subject matter experts to collaborate and share information rather than industrial works to repeat a defined process.
Speed of business change – system requirements change frequently as businesses evolve and change. Change rates are higher than in many other project domains.
Building with bits and not atoms – we are manipulating information and models not concrete and steel so our processes and controls need to be different.
Non-Linear progression – progress is often non-linear. Some things go quickly some things take a long time. Approaches that assume a linear progression to completion are more problematic to apply on software projects.
Uncertainty – We have more technology uncertainty and requirements uncertainty than many other industries and so need more tools to checkpoint and adjust if necessary.
Extreme modifibility – unlike physical construction where is difficult to move a bridge upstream when it is 75% complete, there are some changes that can be done late in software projects that have few parallels in other domains.

Here's my take:Software projects are "idea" projects. They are almost without boundary, both internally and externally. Not entirely of course: where the software meets the hardware, there is a boundary to be sure, especially if you are developing for an embedded processor, like a guidance computer in the tip of a weapon.

About ideas: ideas have no natural limitations: we all know that; it's unreasonable to imagine all ideas are ever known; ideas are volatile; ideas emerge and evolve with experience; ultimately ideas drive vision; and vision is the source of business value.

So, software projects are always going inherit the basic properties of ideas. As such, we need methods and management paradigms like agile to deal with ideas.

At the same time, projects more often than not spend other people's money (OPM). When you are responsible--and, gasp!, accountable--for OPM, your whole perspective changes. Order and predictability become very important.

A marriage of enterprise management skills and agile management skills perhaps is the answer. Anyway, that's what I been saying for a few years now.

Bookmark this on Delicious

Gladwell on intuition

2011-11-18T15:47:00.000-05:00

“A tremendous amount of expertise lies in the unconscious mind ….. Anyone juggling many different variables, dealing with incredibly new and complex issues, … has to, at some point, rely on this body of submerged knowledge to make sense of their tasks”

Malcolm Gladwell

Complexity

2011-11-16T07:00:00.000-05:00

Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them

Laurence J. Peter

I'll think I'll just let this one stand, but if you want to read more, browse through this explanation of the "wicked problem".

Bookmark this on Delicious

Option management

2011-11-14T07:00:00.000-05:00

I often hesitate to import risk management ideas from the financial sector into the project management domain--afterall, the risk management results in the financial sector have not been swell of late, and projects are not casino's--but the idea of "options" does port well to projects.

And an option is:
An option is a "right" that you buy for a small fee; then, you have the option to exercise your right at a later time. You can buy the right to buy a security at a specific price not later than a specific date, or you can buy the right to sell a security at a specific time at a specific price.

If you don't exercise the right you paid for, you lose the money you paid for the option. Obviously, you would only exercise your option if the transaction is profitable for you.

Option risk management features:
There are a couple of interesting features embedded in the option transaction that are attractive from a risk management perspective:

Time displacement (the distance between present and future) is usually a risk nemesis, but in options, time is on your side. Lemons become lemonade, as it where. In order for an option to become profitable, some time must pass during which the security changes value, hopefully in your favor. (Most securities trading works this way)
Downside risk is protected. The most you can lose (if you act rationally) is your fee for the right to the option, thus protecting you from the actual loss of the value of the security
Upside opportunity is amplified. Options leverage the value of the fee you paid. For your small fee, you may be able to participate in a very large gain, which on a percentage basis, is far greater than just trading the security.

Options in projects (and portfolios)
Let's say you anticipate a make/buy juncture in the project 2-4 months out (we never use single point estimates here at Musings). Two chains of project activities radiate from this decision event: one chain supports a 'buy' decision (essentially, outsource to a supplier) and one chain supports a 'make' decision (do all the work in-house).

An option scenario is that you do something now to protect your right to go either way at the decision event. You make a small investment now in order that 'no options are off the table'.

Done right, you make a friend of time: time can be used to set up the conditions for a decision that might not otherwise be available. By protecting both eventualities, you protect agains the downside of poor alternative, or an alternative foregone because of no preparation. And, of course, your small investment may be highly leveraged: a great outcome made more likely by a small fee for preparation.

Investment possibilities
So, what are some things you might do? A few prototypes to test your in house capability; some training of staff in skills that might be needed; some due-diligence and benchmarking on the supply chain; and some research into the various vehicles for outsourcing, like incentive contracts, etc.

If you are portfolio manager, then options in the form of independent R&D (IR&D, or IRaD) is a good way to invest a small amount now in order to have project options in the future. And, of course, investing in your customer (things you know your customer wants to do is perhaps the best use of internal investment)

Oh, and how big is "small" in the investment we are talking about? No right answer of course, but a few percent of the value of the opportunity you are protecting is not a bad figure.

To learn more
If you want to see some numerical examples worked through, go to the Khan Academy and search for the short videos on options.

Bookmark this on Delicious

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

Hold a meeting

2011-11-12T07:00:00.000-05:00

How many "how to hold a meeting" guides are there? More than enough!

So it caught my eye that no less an eminence than Donald Rumsfeld is giving his ideas on how to hold a meeting. He's on slide 8 of Bloomberg Businessweek's How To issue for September 2011.

He has four points, and three of the four are mundane: start on time/end on time, speak without jargon, and be inclusive (more on this later).

But he has one point that seems less obvious: no matter the subject, start with assumptions.

Why? Well, according to Don (can I address him as Don?) assumptions let's everyone know if they are likely to be in agreement with the topic. If so, it shortcuts the discussion of the unncessary so that the presenter can move directly to the punch line. Perhaps so. I'll be giving it a try.

On the other thing, being inclusive: not in Rumsfeld's written missive, but attributed to him by those in the know (as heard on "Morning Joe" on MSNBC), Rumy would often 'dis-invite' those that he knew did not speak up, did not offer critical thinking, and thus were unlikely to add value. So, inclusive yes; but only if likely to add something to the discussion. At the risk of group-think, which is not necessarily implied, I like this one also.

So, two good points!

Photo

Bookmark this on Delicious

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

Project balance sheet

2011-11-10T07:00:00.000-05:00

If you follow this blog you've read several references to the project balance sheet. So, is this about accounting? Yes, and no: Yes, it's about a double entry tool to keep track of "mine" and "yours", but no, it's not the accountant's tool used in your father's accounting office.

Take a look at this figure:

What have we got here?

First, 'mine' and 'yours'.

On the left side of the balance sheet is the sponsor's investment in the project. Investment need not be all monetized. It's the 'your's side of the balance sheet, somewhat akin to the right side of the financial balance sheet (money owed to creditors and money invested by owners). 'Yours' simply means it's resources owned by others and provided to the project.

On the right side is the 'mine' side of the project balance sheet, akin to the left side of the financial accounting sheet (assets owned by the business). The right side is the project side, and the right side shows the estimates and evaluations of the project manager.

And, take note: the left side, the sponsor's side, is the fact-free zone: it's a top down allocation of resources to the vision. It is the ultimate utility expression of the sponsors: what's valuable, and how valuable, even if not entirely objective.And on the right side, it's all about facts (benchmarks) and estimates (benchmarks applied to project circumstances). It's bottom up.

Of course, there's the inevitable gap where utility collides with facts and fact-based estimates. The gap is the risk between expectations and capacity-capability. And how large is the gap (risk): only as large as needed to create a balance--that is, a deal with the devil--so that the project can go forward.

In other words, the gap (risk), shown on the project side, is only as large as it needs to be to close the gap.Usually, it's a matter of negotiation, but once the PMB is set, the risk is the PM's responsibility to manage.

In other words, the PM is the ultimate risk manager.

In a real world example, I had this situation:

We bid a job competitively in a firm fixed price environment.
We offered a price that was equal to our cost; in other words, no fee (profit). We just wanted to keep the lights on and keep barriers to competition with our customer as high as possible.
We won!
And, in the next moment, my general manager said: "Your bonus depends on making 4% net margin". I had my gap! (oh yes, I made the margin and the customer was satisfied)

Bookmark this on Delicious

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

The human element

2011-11-08T07:00:00.000-05:00

The one element that can change every element is the human element

Dow Chemical tag line

People are our most valuable resource--correct? Well, that's always the line, but is it the reality? Lest we all forget, the 'facts' are that on the financial balance sheet, the one executives look at, people are a liability (accrued benefits and compensation), and on the expense statement, they are a cost.

But, fortunately on the project balance sheet, they're assets. Recall: the project balance sheet and the financial balance sheet are not the same animal. The former is a view of the top down/bottom up balance in the project, and the latter is a view of the distribution of monetary ownership between the business and it's benefactors.

Bottom line: there's a natural tension between business and projects, and the human resource is a part of that tension.

Bookmark this on Delicious

Risk waterfall, or not

2011-11-06T07:00:00.000-05:00

Waterfall is a four letter word in the project management space.

Everyone will tell you they understand the hazards and seek a more effective paradigm. Actually, the synonym is sequential process (sounds better, and more sophisticated) and the better idea, practiced by most, is sequences with iteration and feedback.

Most understand the idea of feedback as a control device (for those that want to brush up, a good read is Donella Meadows' book "Thinking in Systems"). So, when you combine a control device with the opportunity to do over or correct, you've got a sequence under control, and a sequence that is responsive to outcome demand.

Nice.

Now, the agilists call an iterative sequence under control just common sense, or complex adaptive (perhaps so, in some cases) or emergent (closer to what actually happens).But, usually the discussion on this topic is all about the vision, the requirements backlog, and the intended product or process outcome. The risk register--indeed, the whole RM process--is often ignored, or just not in the discussion.

Where does the classic RM sequence fit in?Recall the sequence: set the context; identify risks; qualitatively and quantitatively assess the risks; plan responses; do, monitor, and control the response and its impact.

Now, how does the risk sequence fit into an agile emergent paradigm, or a iterative sequential baseline process?

I posit that the right strategy is to distribute the sequence: the first two steps, set the context and identify the risks, and be done as part of the project business case and the original envisioning. The latter steps can be allocated to the execution teams. As such, every time the backlog is reevaluated, so also is the risk register reevaluated (thus, iteration to the project charter) and the assessment, response planning, and monitor/control are incorporated into the team work of each time box or other scope segment.

So, in effect, the sequential process, with feedback, is made iterative by time box or scope segment as matter of methodology design and management policy.

Bookmark this on Delicious

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

Opportunity or risk?

2011-11-04T07:00:00.001-04:00

Opportunity or risk?

Not to be too dry, let's nevertheless acknowledge that the 'official' definition of risk, as given by PMI PMBOK, is that a risk is an event or condition that could have either a negative or positive impact on project objectives. And, if you follow the thread in the PMBOK gloassary, 'opportunity' is the name given to the positive impact thread. Now, the ISO 31000 standard for risk management does not go quite as far, defining risk as an uncertainty that affects project objectives

So, what is opportunity? Risk, or just a postive effect? And, does it matter, really?

Well, yes, actually it does, for these reasons:

a. Risk has it's own register of possible and probable events and conditions, largely not in the performance management baseline (PMB). Thus, most risks are 'off-baseline'. And the reason is simple: risks are generally thought of as threats to project success, PMI's glossary not withstanding. The point of risk management is to mitigate threats to the PMB.

b. Opportunities, equally off-baseline, usually mean a change in scope. Thus, whereas an opportunity may thought of as scope creep, the general disposition is to accept worthwhile opportunities, not mitigate against them.

c. Incentives generally follow success, but risks are not about success. Thus, risks are not about incentives. Money tends to focus the mind, so focus is often not on the risk register. On the other hand, an opportunity may bring with it not only success but reward for foresight

d. Opportunities naturally find their way into the change management system, and are usually dealt with in an entirely different workflow from the risk management system.

The PMBOK, in Chapter 11, offers four response ideas for risks: avoid, accept, transfer, and mitigate.

The PMBOK offers a different list for opportunities: exploit, share, enhance, and accept.

However, when discussing this recently with my risk management students, one came up with three others that I think are quite clever:

IGNORE because it was out of scope; INFORM the outside party that it impacted so they can run with it; or INCLUDE in the project because it was a better way to achieve the project objectives.

Bookmark this on Delicious

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

All the risks up front

2011-11-02T07:00:00.000-04:00

Last month I was having a discussion and the point was made that perhaps risk managers should use a governance paradigm something like the original requirements paradigm: define all the risks at the beginning, and then only review plans and progress thereafter, resisting--with governance--changes during the course of the project.

I said no.

You can't freeze risks any more so than you can freeze requirements. The world simply does not stand still, and perhaps that is more true for risks than requirements, though I'm really not sure.In any event, as the requirements governance paradigm has evolved, and means and methods developed to deal with change--and perhaps Agile is the most extreme but not exclusive means and method for doing so--so also a regimen for risk management should have a governance mindset to deal with volatility.

To my risk management students I have posited the "cone of uncertainty", something written about by many, to include Dr Barry Boehm. The cone gives a temporal dimension to risk: the farther out in time, the more optimistic we are in evaluating risk. There's simply more time to deal with it; we feel we can fix it. Closer in time, some options are off the table, and we're more pessimistic. The cone begins to close down.

Thus, if for no other reason, the risk register can not be static. Even we don't discover any new risks, the risks so far identified will change character, or our assessment of them will change--we call this utility--and the risk response will change with accordingly.

So, bottom line: there can be no static up front identification and assessment. Even the PMBOK agrees that the process is repeated throughout the project.

Got to keep it relevant and current.

Bookmark this on Delicious

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

Hey, it's halloween!

2011-10-31T07:00:00.000-04:00

Happy Halloween!

Too much already!

2011-10-29T07:00:00.000-04:00

Mike Clayton at Shift Happens! has a nice post on portfolio prioritization. He asks this question:

Why do so many Organisations Resist Rationalising their Project Portfolios?

And, then he answers his own question with five reasons:

Patronage
It's all too difficult
Is it really essential?
Loss aversion
Lessons unlearned

Well, Clayton thinks #5 is the one, and I agree. He goes on to expand:

1.Lack of clear links between the project and the organisation’s key strategic priorities, including agreed measures of success.
2.Lack of clear senior management and Ministerial ownership and leadership.
3.Lack of effective engagement with stakeholders..
4.Lack of skills and proven approach to project management and risk management.
5.Too little attention to breaking development and implementation into manageable steps.
6.Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits).
7.Lack of understanding of, and contact with the supply industry at senior levels in the organisation.
8.Lack of effective project team integration between clients, the supplier team and the supply chain.

Bookmark this on Delicious

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

A great place to work

2011-10-27T07:00:00.000-04:00

Over at HBR Blog, Tony Schwartz waxes on the 12 Attributes of a Truly Great Place to Work. We've all seen lists like this one, but take a look at some of the comments to the blog. They are both amusing (as in: fire yourself before they can) and insightful (like, it's all about trust)

Admittedly, the first six are a little expensive for many and assume a brick-and-mortar environment, (provide a gym, and provide good food in the cafeteria) but the universally applicable advice gets started in number 7.

However, I skip all the way to 11 (provide learning and skill development opportunity) and 12 (stand for something besides profit--which I take to be a surrogate concept since there are non-profits and government units that can benefit from this list)

In my mind, to not be constantly learning is to be going backward, and backward is not forward to a better future. And, surely, even if the business of business is business (I think a CEO of Coke said that), there's got to be more to it than that, although I admit that the business of business is not God and Country. When I moved from the DoD to private industry, I learned that pretty quick!

Bookmark this on Delicious

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

Quote of the day

2011-10-25T07:00:00.000-04:00

“You know, it’s O.K. to head out for wonderful, but on your way to wonderful, you’re going to have to pass through all right, and when you get to all right, take a good look around and get used to it because that may be as far as you’re going to get

Bill Withers, R&B singer and philosopher

Perhaps a more complicated rendering of "best is the enemy of better", but a more elegant statement, to be sure.

Bookmark this on Delicious

Is everything a hammer?

2011-10-23T07:00:00.000-04:00

Well, our friends at Dark Matter have raised another issue that we found provoking, to wit: have we gone too far in some cases with the visual display thing? In other words, having invented the hammer, do we use it for everything? All the world is not a nail, afterall, so perhaps some pause is warranted.

Now, to be fair, the Dark Matter crowd is all about safety, complexity, and and technology risk, especially as it affects human reactions in human-system situations. So naturally, Dark Matter is all over this stuff.

On the other had, as project managers (rather than system engineers) we have some obligation to test and challenge the various solutions, even we don't have the competence to rule things in or out. It's sort of the project equivalent of "reign but does not rule".

Setting up independent design review boards--sort of the red team equivalent for proposals--with 'grey beards' to give independent opinion is one way to do it. (Does everyone recognize the term 'grey beard' or am I dating myself?)

In the post that got our attention, the issue was the elimination of certain tactile responses replaced by visual indicators. The case in point is the stall indication on the Airbus that crashed near Brazil a couple of years ago. The traditional "stick shaker" had been eliminated, as well as some other traditional tactile oriented systems.

There are all kinds of stories like this. In Gene Kranz's book "Failure is not an option" he describes similar debates between the rulers and the reigners. There was a lot at stake.

This stuff is not to be taken lightly, and certainly not to be delegated to self-appointed teams without a disciplined tie to established saftey regimes.

Bookmark this on Delicious

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

Those process guys!

2011-10-21T07:00:00.000-04:00

I was musing with a colleague the other day about "those process guys" who sometimes miss this bit of wit:

Rather than make the trains run on time, it may be better to do away the trains altogether

I acutally think I read an interview with Steve Balmer of Microsoft where he said something like that, but I don't think he took his own advice.

In any event, to give my friend a concrete example, I told him about a study I did on "the cost of a memo", circa mid-late '80's that goes like this:

In the beginning, there was no personal computer. As a director, I wrote memo's to my staff in long hand (I hear that is no longer taught in school) and gave the scratch to my personal secretary to type on a Selectric with correcting tape. She then gave me the typed copy to edit, retyped it for my signature, and then she printed and distributed the memo through the office mail. I calculated the cost of a one page memo at about $50. (I may have under calculated, upon reflection, but this was '85 or thereabouts, so we worked cheap then)

Sometime in the mid to late 80's, I bought my secretary a Mac and printer to replace the typewriter, but otherwise the process was the same. Cost went up to $60 to pay for the hardware.

Then, I bought myself a Mac and I could type the memo and send it to her for editing and printing. The process saved a few minutes of my time but we had an extra computer, so the cost of a memo is now about $70.A lot of IT spending so far, no productivity gain, and a greater expense. General manager is not happy!

Then came email networking adoption, and I could mail the memo myself. The cost has not gone down, still $70, but now the secretary has idle time (charged to the cost of a memo since the charges have to go somewhere). You can't fire part of a person, so we had to find something else for her to do.

Then, memo's went out of style, replaced by the world of casual email correspondence. My time dropped a lot (per memo/email), so the cost per email dropped to about half or less of the formal memo, call it $30.

Then, finally, with nothing to do, replaced by calendar applications and email, we fired the secretary, and the cost dropped again to about $10.

This arc took about 8 years to execute as we learned that with technology the idea is not to replace item for item in the process; it's to ditch the process and do something different with the technology.

I call this distructive improvement, but others talk about distructive innovation.

And we learned this lesson: putting in a bunch of IT personal application tools that save 10min here and there may not result in any real productivity or cost savings. It's rare that all these little segments coherently add to one headcount that can be released. You can't fire or transfer an FTE, only an integer person. So, as we saw in the 80's, and to some degree the cycle is beginning again, especially with ERP installs, there is capital spending without commensurate return to the business.

Another example, not project management, and further back: the transistor originally just replaced the triode tube, but the circuit design and functionality were not that much different. It wasn't until we grasped the idea that the transistor was a lot more than a 3 pin replacement for 3 pin tube did the whole digital productivity thing take off.

In any event: remember the wise words: It's often better to do away with the trains than to spend the effort to make them run on time!

Bookmark this on Delicious

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

Frank Gehry on projects

2011-10-19T07:00:00.020-04:00

I love architecture, though I'm not an architect, and never studied architecture. Of course, I love system architecture, which is both different from building and construction per se, and identical because a building is a system just as any other such integrated structure is a system.

Frank Gehry is one of Canada-America's more esteemed architects. He does projects around the world. The picture is of the museum in Bilbao, Spain. Of course, Gehry always designs some pretty unusual stuff, but in an interesting interview on cnn.com/gps for September 4, 2011, he says about his projects:

He's very thorough with the envisioning and conceptualization, often building 100 models before he 'sees' it. (Spiral, anyone?)
Everything he does has customer buy-in, and in the end, the customer never regrets (Sounds like an embedded agile customer)
The building has to work functionally (wow! it has to work. Have the ERP guys heard that one?)
You have to be able to actually build it, meaning it has to be technologically feasible and feasibly economical (perhaps we should revisit the Sydney opera house--not a Gehry design), and
It has to meet a budget! (Back to PM 101, and the consequences of "other people's money")

Actually, on these last two points, another flamboyant architect, Frank Lloyd Wright, never actually got it. Many of his buildings didn't work (roofs and windows leaked, for one thing), and he rarely (some say never) met a budget. And he didn't miss closely, he missed by a mile!

Some of these problems are like any 'new to the world' endeavor: stuff happens! But some is just downright delusional or deliberately deceptive. Some advice just never gets old: Buyer beware!

Bookmark this on Delicious

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

Density and productivity

2011-10-17T07:00:00.015-04:00

I just learned (silly me for not knowing) that it takes density to get decent productivity. And policies that discourage density have a likely unintended consequence of squeezing off improved productivity. This seems to be the message from Ryan Avent

In cities and urban areas, his advice is don't discourage growth, or least make it affordable for more people to join in the high production center. Dis-affordability, we are told, ultimately leads to declining, or least not improving productivity.

So, now transfer this to the project domain. (Notice: switching domains is often problematic and solutions often simply don't transfer. However, Avent himself brings up the topic of work productivity vs distribution, so perhaps I'm not too far off base). The thing that jumps to mind is the co-located team, a favorite if not a mandate for the agile community, and the distributed or virtual team, a favorite if not a mandate for the project at enterprise scale.

The conclusion is begged by the set-up: we should either expect a certain productivity premium for the co-located team, or on the flip side, we should expect to discount the productivity of a distributed or virtual team. Whether discount or premium depends on where the baseline is. From my experience, working mostly in larger scale enterprises, the baseline is the distributed team, so I see a premium for the co-location case.

So, in the context of "density begets productivity", I'm probably taking the right view. Co-locating, where possible, show pay a productivity dividend. However, reversing seven decades of ever larger scale--since the onset of WW II in 1940--is no small matter, and probably not desirable or practical. If we going to "go big" as the popular refrain goes, we're going to need big, distributed teams. We're unlikely to use agile methods to build Hoover Dam or the Golden Gate bridge (projects in the 1930's, and unprecedented in scope for the time, and pretty impressive, even today)

What's to do? Distributed teams are less productive, but necessary in most cases to get true scale. The important thing is have the right reference class for estimating. Obviously, the reference class should be one that likely has all the productivity discounts built in, else an underestimate is almost a foregone conclusion.

Bookmark this on Delicious

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

The courtesy of a reply

2011-10-15T07:00:00.015-04:00

How can it be that the number one skill and task of project management is communications, and the number one problem in project management is the discourtesy of no reply?

How can it be in this time of instant everything, especially communication, that communication courtesy is so lacking? Isn't closing the loop and acknowledging an exchange the essence of quality--relationship quality--and isn't quality what we are constantly striving for?

Quality is the prime motivator of the agilists

Lack of quality almost pushed American manufacturing to extinction

Have we gone over the top? There is so much communication that no one is communicating? A paradox, to be sure. I don't know. It just seems to me that the courtesy of a reply is a small matter with such large leverage. I know we are supposed to be in an age of "de-leveraging", but really I think de-leveraging in communications is a bridge too far!

(Full disclosure: I often don't return unsolicited sales calls .... admittedly, an exception to my rant, but having worked with a sales company for a few years, I understand sales people live a life of 'rejection')

Bookmark this on Deliciousdiv>

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

Complicated, complex, and complex adaptive

2011-10-13T07:00:00.016-04:00

"Complicated, complex, and complex adaptive": We see these terms a lot in the project business. I'm ok with the first two; the last one is a bit dubious for project managers in my opinion.

Here's some definitions. The first is taken from an interview with Michael J. Mauboussin by Tim Sullivan in the September 2011 edition of the Harvard Business Review, an issue that is dedicated to complexity:

A complex adaptive system (CAS) has three characteristics. The first is that the system consists of a number of heterogeneous agents, and each of those agents makes decisions about how to behave. The most important dimension here is that those decisions will evolve over time. The second characteristic is that the agents interact with one another. That interaction leads to the third—something that scientists call emergence: In a very real way, the whole becomes greater than the sum of the parts. The key issue is that you can’t really understand the whole system by simply looking at its individual parts.

And here's by Gökçe Sargut and Rita Gunther McGrath writing in an article in the same issue on the difference between complicated and complex:

Complicated systems, they say, have a lot of parts, but the parts interact in patterns of behavior we know and understand, and can reasonably predict.

Complex systems are versions of complicated systems wherein the patterns are there but difficult to know about (too many, too obscure, or outside our normal experience) and the interactions, though predictable, are too difficult to predict as a practical matter.

They observe:

Complex systems have always existed, of course—and business life has always featured the unpredictable, the surprising, and the unexpected. But complexity has gone from something found mainly in large systems, such as cities, to something that affects almost everything we touch: the products we design, the jobs we do every day, and the organizations we oversee.

Well, I buy the complex and complicated thing, but every example of CAS that anyone gives is more often biological than not. After all, the biological sciences has been the doman that has advanced the study of CAS the most.

What about agile?
Many say agile methods are themselves an example of CAS because of the property of emergence, and the myriad of agents (developers, testers, stakeholders, sponsors, customers, users et al) that are in constant interaction. Perhaps so. But I don't see agile projects and ant colonies acting the same way. There's simply too many intervening structures, inhibitions, rules, and constraints, to say nothing of project charters, vision, product managers, and market forces that focus the project.

As others have said, it's often nonsensical and many times misleading to cross domains too readily. For my money, I buy into emergence, and I buy into output effecting input (a necessary condition for adaption), but most of the other biological instinctive and survival behavior of ants is not what projects are about.

Bookmark this on Delicious

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

Traps when thinking in systems

2011-10-11T07:00:00.000-04:00

I've pointed to "Thinking in Systems: a primer" by D. Meadows in prior posts, and here I go again, largely because I think she's offered a lot that is useful to managers of all stripes, not just systems people.

Here's an abridged list of 'traps' she cautions against, a list of ills we should all be cautious about:

Success to the successful
If the winners of a competition are systematically rewarded with the means to win again, a reinforcing feedback loop is created by which, if it is allowed to proceed uninhibited, the winners eventually take all, while the losers are eliminated.

The Tragedy of the Commons
When there is a commonly shared resource, every user benefits directly from its use, but shares the costs of its abuse with everyone else. Therefore, there is very weak feedback from the condition of the resource to the decisions of the resource users. The consequence is overuse of the resource, eroding it until it becomes unavailable to anyone.

Drift to Low Performance
Allowing performance standards to be influenced by past performance, especially if there is a negative bias in perceiving past performance, sets up a reinforcing feedback loop of eroding goals that sets a system drifting toward low performance.

Rule Beating Trap
Rules to govern a system can lead to rule-beating-perverse behavior that gives the appearance of obeying the rules or achieving the goals, but that actually distorts the system. Rule beating is usually a response of the lower levels in a hierarchy to overrigid, deleterious, unworkable, or ill-defined rules from above.

Seeking the Wrong Goal
System behavior is particularly sensitive to the goals of feedback loops. If the goals-the indicators of satisfaction of the rules-are defined inaccurately or incompletely, the system may obediently work to produce a result that is not really intended or wanted.

Bookmark this on Delicious

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

The forest for the trees

2011-10-09T07:00:00.008-04:00

We are all taught from the first moment that the way to eat an elephant is one bite at a time. That is: to work on a complex problem, always start by simplifying the task by decomposition, disaggregation, and separation of the trees from the forest.

Ok, but what about this: (think: object = tree; distant background = forest)

In a posting on "Azimuth", John Baez has a part I discussion of evolution in complex systems from which the diagram, above, is taken.

In addition to the distortion arising from the point of view from which data is viewed, he goes on to caution about the the Dunning-Krueger effect (the uninformed, misinformed, and ignorant are biased to not understand their own cognitive deficiencies), saying, in part:

... if we don’t understand a system well from the start, we may overestimate how well we understand the limitations inherent to the simplifications we employ in studying it.

But, it's not only trees: it's also use cases and user stories, and then ultimately Test-Driven-Development scripts, all decompositions that have the potential to alter perspective.

Thus, constant attention to "re-composition" to validate low level requirements with high level vision is necessary. That is the essence of the "V-Model", a bit of system engineering that we can all take advantage.

Bookmark this on Delicious

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

To Push or not to Push

2011-10-07T07:00:00.001-04:00

A lot's been written about Steve Jobs' legacy at Apple since his decision last month to step down from CEO and remain only as chairman. Unfortunately, Jobs died Oct 5th.

Among the anecdotes told and retold is his oft repeated anti-LEAN doctrine: features and functions are to the PUSHED to the customer because, he says:

It’s not the consumer’s job to know what they want

And it's not only Apple. Sony has also been said to have not consulted any outsiders regarding the Walkman. Again, when it's "new to the world", what's a consumer to say? Hit, or no hit?

Well, what would the LEANers say about that? The Lean mantra, of course, is to pull consumer requirements from the customer, not push them (arrogantly) from the developers/stakeholders to the consumer.

And, what would the agilists say? Apple most assuredly does not embed customers/users on its product teams. They, perhaps as much as any competitive innovator, guards their intellectual property and marketing plans as closely as any. One only needs to go back to the infamous case of the lost/stollen iPhone prototype to see them in action.

That's not to say that a product manager internal to the company is not closely consulted on new products, but on the most important features and functions, hardly any less than Mr Jobs himself makes the final decisions. Others need not apply

Conclusion: Alistair Cockburn may have been spot on when he said: any methodology can be made to succeed in some situations; any methodology can fail. Perhaps, as it always has been: inspirational vision, leadership, commitment, and methodology.

Bookmark this on Delicious

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

Now on Kindle

2011-10-05T07:00:00.001-04:00

If you would like to follow "Musings" on your Kindle, now you can. "Musing" is published concurrently to the Kindle blog store and is available on a monthly subscription.

Just search the Kindle Store for "blog john goodpasture", and you'll get there.

Bookmark this on Delicious

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

Sins of progress

2011-10-03T07:00:00.002-04:00

Paul Solomon, an industry guru in earned value, has an article in a recent edition of the "Journal of Software Technology" (August, 2011, vol 14, number 3) that lists a number of sins that distort progress. I'm sure of none of you reading have done these things, but I repeat Paul's list so you can be aware.

Among his observations and examples of misuse and abuse of the project's management reserve (MR), he lists these tricks (paraphrased and translated for the non-defense project audience, so these are not a direct quote of Solomon's remarks)

Rework--in other words, error of feature, function, or performance requiring correction--is not included in the budget (though it's reasonable to expect some rework as part of the natural variation in the design and development processes). Rework is identified as a risk (on the risk register) and money to fund the risk response is included in management reserve (MR). Later, funding is transferred from the reserve to the budget when the design or test item does not meet, or no longer meets, technical requirements.

Cost drivers such as software lines of code (LOC), number of drawings, hours per drawing or per LOC, are understated (justified as aggressive interpretation of bottom up estimates) compared with empirical data and realistic estimates. The low ball estimate is called “management challenge” and identified as a risk, not an issue. Later, funding from the management reserve is transferred to the budget to cover the risk.

The same conditions exist, as above, but no “risk” was identified. Instead, the additional iterations are called “scope growth” even though the basic tasks were planned in the budget
The number of tests (and resultant rework and problem reports) is understated based on realistic estimates and empirical data. Later, the tests and rework needed to meet technical requirements are funded from MR as “additional scope” even though the customer requirements are stable.

Work that could not be completed internally is transferred to a supplier. MR is used under the pretext that it is “additional scope” or “unplanned.”

So, you might ask: what's the management reserve for if not to fund problems not foreseen? That's Paul's point exactly: rework--at least to some extent--should be in the baseline so that the project's cost is not a matter of deliberate deception. So also for the other practices. In other words, trust and integrity, so valued in the implementing teams, starts at the top. No news there, but never a bad thing to review.

Of course, these practices are not exclusively in the defense domain. Try big time construction if you want more examples. This is Bent Flyvbjerg's favorite topic, as depicted in one of his articles, "Design by Deception: the politics of megaproject approval"

Good grief! Is there no one on top of this?

Bookmark this on Delicious

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

Quotation for today

2011-10-01T07:00:00.009-04:00

Did you know this little tidbit?

Wall Street hires more math, engineering and science graduates than the semiconductor industry, Big Pharma or the telecommunications business

Rana Foroohar

Need an example? Consider Salman Khan, an MIT graduate, who went from school to Wall Street. But after a few years, found himself doing something a lot more useful: he founded the Khan Academy.

Would that others follow in his footsteps!

Bookmark this on Delicious

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

Type I and II

2011-09-29T07:00:00.011-04:00

From time to time, it's worth revisiting our old friends Type I and Type II:

In general, a Type 1 error makes you depart from the status quo and take some action that is wrong, while committing a Type 2 error means that you stick with the status quo when you should have acted.

Maintain control
Decision theory is always a trade-off.

In hypothesis testing, you make sure that the Type 1 error is the severe error, so you can control the probability of making it.

As a result, the Type 2 error may in fact have a larger probability of occurring (but it is the lesser of the 2 errors).

Examples:
A pharmaceutical company is testing the safety of a new drug:
Type 1 error: concluding it is safe when it’s not (kill people)
Type 2 error: concluding it is not safe when it is (lose some money)

The criminal justice system:
Type 1 error: convicting an innocent person (terminology: the defendant is guilty)
Type 2 error: not convicting a guilty person (terminology: the defendant is not guilty. It’s important to note that you never say the defendant is innocent).

A scientific researcher
Type 1 error: publishing your research when it’s wrong (embarrassment)
Type 2 error: not publishing your research when it’s correct (usually this means continuing your research until you can show progress)

Important terminology:

There is sufficient evidence to reject the null hypothesis in favor of the alternative.
The is insufficient evidence to reject the null hypothesis (NEVER ACCEPT THE NULL HYPOTHESIS – no one is ever declared innocent; they are declared not guilty)

I didn't make this stuff up. I credit a good friend, Dr. Pat Bond, a professor at Florida Tech, for these insights

Bookmark this on Delicious

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

Gilb on Agile

2011-09-27T07:00:00.005-04:00

Tom Gilb is a system engineer; he is also a project manager and someone with deep understanding of software engineering. His most prominent work is his 1988 book: "Principles of Software Engineering Management".

He is the inventor and thought leader behind an agile-like methodology named EVO (for evolutionary).

In my own book, "Project Management the Agile Way: making it work in the enterprise", I include a lot of material taken from Gilb's work. I like what he says, though frankly a better spokesman for what Gilb advocates is Niels Malotaux: he writes with clarity and simplicity, something that eludes Gilb himself.

Recently, I fell onto a string of Gilb'isms, starting with a 2004 keynote address to an agile conference entitled "What is missing from the conventional agile and eXtreme methods?" His answer, in one word: quantification. And by this he really means quantification of business results, outcomes generated by project outputs, in business terms. He more or less sums up the idea with the words value and quality.

He really takes agilists to task for promoting the idea of a single customer/user as the arbiter of product requirements; instead, agile teams should be consulting--weekly--with the business stakeholders, a diverse group Gilb says can be more than a dozen in any real enterprise.

And, he has heartburn with user stories and other low level practices, like TDD, that he says unnecessarily constrain the inventiveness of developers and leads to "amateur" engineering. Gilb's formula: write down the business quality values on not more than one sheet of paper, and let the developers go from there.

In 2010, he wrote a couple of magazine articles in "Agile Record". The first part, entitled "Value driven principles and values" is a better explanation of what was in the 2004 keynote. The second part, entitled "Values for Values" builds out his ten principles--first presented in the keynote address--and given also in the first part article.

Gilb's principles are ones we can live by. Here's a reproduction of one version:

As Gilb says of the Agile Manifesto: "it's heart is the right place". Even if you don't buy all that brother Tom says, his heart is in the right place: better quality and value for stakeholders through projects and software.

Bookmark this on Delicious

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

Building your personal brand

2011-09-25T07:00:00.001-04:00

I recently had an the opportunity to address a group of project managers about how to build a personal brand.

Ah yes! The personal brand. And what is that exactly? I told the group: these days, it's whatever the web search says it is. Your identity is more or less your public identity on the internet: it's whatever HR or the hiring manager, or anyone else can find about you as they figure out who you are.

So my advice was: take the initiative. Build your brand on the web yourself and get out in front of the web search. And, there's a lot of ways to do it. Of course, own your ownname.com; and create profiles on the professional network sites that will show up in web searches.

Another idea: have a friend interview you and create your own audio blog. It's cheap and its easy.

And, more, so here's the presentation as available on slideshare.net/jgoodpas:

Building Your Personal Brand

View more presentations from John Goodpasture

Bookmark this on Delicious

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

Coming in at 95

2011-09-23T07:00:00.005-04:00

The good news: we're still on the Top 100 Agile books list
The bad news: we've slipped a bit from last year. Oh well.

Still, this is the book we're talking about:

Bookmark this on Delicious

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

Bow-ties for risk managers

2011-09-21T07:00:00.002-04:00

Have you seen this one before? I had not until I was chasing down ISO 31000:2009, the ISO standard on risk management. In a slide show about that, I found this:

The left side is 'likelihood controls' and the right side is 'consequence controls'. Kinda neat, I thought. Certainly, a unique display of a risk matrix.

Bookmark this on Delicious

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

A touch of madness

2011-09-19T07:00:00.020-04:00

Madness! Madness!!

Last two words spoken

"Bridge over the River Kwai"

Sane was the watchword

In several posts, I've made the point that the passionless rationalist will often find it hard to reach a decision. They are wrapped up in the paralysis of analysis--they keep going over all the data and all the alternatives and never reach a consensus--with others or with themselves--on what to do.

My contention, said by many others as well, is that it takes a dose of passion for a vision to break the analysis cycle and reach a decision. And, note this: the passionate have stickiness--once decided, it's hard-to-impossible to move someone off their position.

How many times, on a big decision, have you had an instinctive feeling: this is the right thing to do! Once felt, there's no more paralysis and there's no more dithering.

That stickiness we spoke of is an elixir to the follower community: Yes! the leadership knows where we need to get to; there will be certainty and willingness to put it on the line to get there.

Now, I've also written about innovation, and the role leadership plays inspiring the creative to innovate something new to the world.

Along comes a touch of madness

But what luck! Now we learn that there's something that ties leadership and innovation together--something unique when a leader is both inspirational and innovative. In a book that ties it all together, it turns out that truly inspired and innovative leadership have a common root: it is the byproduct of mental disorder and mild manic depression. Who knew? In a stroke (no pun), we've now got the whole picture!

In a new book, author Nassir Ghaemi explains in "A First-Rate Madness: Uncovering the Links Between Leadership and Mental Illness" that some of our best and brightest are just a little mad. Is this surprising?
Perhaps not. But Steven Colbert was particularly insightful when he asked whether we should be worried that a madman may have his finger on the button (even if only the project button). Ghaemi said: "That's one way of putting it". But in his telling, benefits outweigh risks.

God, I hope he's right!

Bookmark this on Delicious

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

More about our friend Bayes

2011-09-17T07:00:00.074-04:00

When the facts change, I change my opinion.
What do you do, sir?

John Maynard Keynes

In a review of a new book "The Theory That Would Not Die" (S. McGrayne, May,2011) mathematician John Allen Paulos says this:

"At its core, Bayes’s theorem depends upon an ingenious turnabout: If you want to assess the strength of your hypothesis given the evidence, you must also assess the strength of the evidence given your hypothesis.

In the face of uncertainty, a Bayesian asks three questions:

How confident am I in the truth of my initial belief?
On the assumption that my original belief is true, how confident am I that the new evidence is accurate?
And whether or not my original belief is true, how confident am I that the new evidence is accurate?"

In other words, the Bayesian idea is this:

Form a hypothesis; assess the probability of its being true
Seek evidence that the hypothesis is true
Recalculate the probability of the hypothesis, given the evidence (assuming the hypothesis is TRUE) and the probability of finding the evidence

There are some obvious "calibration" problems, the same sort that show up in the risk matrix, and these calibration issues have challenged the efficacy of Bayesian reasoning in the same way:

It's difficult to get a calibrated probability for the initial hypothesis--what's the benchmark here, and can you be sure that biases are removed?
It's difficult to find the supporting evidence with clarity of cause and effect
It's difficult to assess the probability of finding the evidence--again, there may be no historical basis for such a probability.

Nevertheless, according to McCrayne's history, Bayes has these credits:

"It was used to search for nuclear weapons, devise actuarial tables, demonstrate that a document seemingly incriminating Colonel Dreyfus was most likely a forgery, improve low-resolution computer images, judge the authorship of the disputed Federalist papers and determine the false positive rate of mammograms. She also tells the story of Alan Turing and others whose pivotal crypto-analytic work unscrambling German codes may have helped shorten World War II."

For more, see my prior posts.

Bookmark this on Delicious

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

Stand firm

2011-09-15T07:00:00.022-04:00

Be sure you put your feet in the right place, then stand firm

Abraham Lincoln

An example:

In 1862, Lincoln, among other things he was thinking about that year, began to consider adopting a new paradigm involving freedom and citizenship for slaves in certain designated states. This would be a huge culture shift and require deft change management. Not everyone was on-board with the goal or the vision. For some, it was way too much; for others, not nearly enough. Some suggested caution: adopt a pilot program.

These considerations were the result of an emergence in purpose and justification for opposing the rebellion in the southern states: In the first three years of the war--and preamble to war--(1860-62) it was (from the North's point of view) a war to preserve a constitutional union that had no provision for de-unionization. But by 1862, the issue of slavery as it would be in the post-war had come to the fore. And there was a need to destabilize the threat (of a southern victory--after all, in 1862, the South was winning it all) by fomenting unrest among the slave population.

In debate with his cabinet (a quaint idea in the present White House era), Lincoln decided upon an emancipation of slaves in certain states then in rebellion. However, Lincoln, ever the decider, decided--and ended the debate. He subsequently let is cabinet back in to work the marketing and sales rollout.

But, he decided where to put his feet, and that is where he stood!

Lincoln was not a PMP, but nevertheless, there are lessons we can learn.

Bookmark this on Delicious

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

Are we there yet?

2011-09-13T07:00:00.003-04:00

Perhaps we are there!

Mike Cohn takes note of the limitations of the one small colocated team theory of doing software projects, the theoretical underpinning of agile, and the advance of agile methods into the space of larger projects and projects with practical resource limitations:

The early agile literature was adamant about two things: stick with small teams and put everyone in one room.

However, in the years since the Agile Manifesto, the increasing popularity of agile and the dramatic improvements it brings has pushed it onto larger and larger projects.

Additionally, having an entire team--especially on a large project--in one room, or even one building is a luxury no longer enjoyed by many projects.

Mike Cohn
Scaling Agile to work with a distributed team

I for one am glad to see the mainstream agile community get to this place. After all, the community has 15 years of experience behind it:

Mid-90's early SCUM and XP projects led by a small cadre of thought leaders
2001 at Snowbird, UT: Agile--the name--and subsequently the agile manifesto
2003-2005: a spate of books by the Snowbird 17 explaining it all
2010: my book: "Project Management the Agile way; making it work in the enterprise"
2011: here we are!

Mike summarizes his thoughts on scaling and distributed teams in a pdf download of his presentation this past April, 2011 to a user group. To those of us who have looked at the issues and practiced agile in such environments, Mike's points are pretty well known.

His scaling advice more or less comes down to the SCRUM of SCRUMS approach (Mike is mostly a SCRUM advocate/expert),

He has several ideas on distributed teams:
He has a nice pro-con comparison on things like (for the non-colocated team) 'the long telephone call', and offers advice like: make it two calls, the first to set the agenda for the second and set up expectations. That's probably good advice.

And, like Alistair Cockburn, he says: add documentation back to compensate for the osmosis of communication in small colocated team rooms.

Also, very telling, about distributed teams: beware that discipline and culture do not port well over time zones (zones are more important than distance: after all, Miami and Montreal are in the same time zone), and across national cultures (where yes may mean no, etc)

So, a lot of advice tid-bits in the presentation; worth a read

Bookmark this on Delicious

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

9-11-11

2011-09-11T07:00:00.003-04:00

The Pentagon, Washington D.C.

Ten years later: 9/11/11

Photo

Bookmark this on Delicious

Kaplan on strategy

2011-09-09T07:00:00.008-04:00

Robert Kaplan and David Norton are best known for inventing the balanced scorecard (and, to some degree, inventing the cottage industry that goes around it and sustains it some 19 years after the original paper in the Harvard Business Review in 1992).

If you're looking for a way to organize a business scorecard, this tool is as good as any.

But of course it also links to strategy. In an interview, Kaplan said this:

Strategy is a hypothesis. It’s your belief that if you do some things, then some expected results will happen. But it’s only a hypothesis!

And, Kaplan (and Norton) posit five principles for working strategy:

Accept that strategy is the job of senior executives. It’s their job to mobilize the organization. They need to understand that managing strategy is managing change and they may need to be the change agent.
Translate the strategy so that it can be understood. Translating strategy into objectives and, most importantly, into measures is important because measures now become the common language of your strategy.
Align the organization. This is the most important part of what we do. Here, we create a description of the strategy, convert it to maps and measures and then align every part of the organization to that strategy.
Make strategy everyone’s job. The strategy is formulated at the top and executed at the bottom, and if people at the bottom don’t understand the strategy, they’re not going to be able to execute it.
Embed the strategy into what you manage, essentially into your governance, so that your budgeting, human resource, training programs, goals, and incentives are all tied to the strategy.

Frankly, I like the last one best. It has the best chance of over optimization at the local level if the goals and incentives are pointed to the right objectives. The four points are good, to be sure, but they smack of a 'chief strategy officer' that is off enforcing strategy everywhere. It's my experience that such activity only lasts as long as the CSO energy level can be maintained waging strategy on everyone. And, that's not forever, so the best success will come if strategy is part of everyone's management objectives.

Bookmark this on Delicious

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

Leaders and followers

2011-09-07T07:00:00.009-04:00

Generals move pins on a map, ... but the front line soldiers have to get the job done

General Eisenhower

Sponsors, stakeholders,and in many situations project managers move the pins. Cost account and work package leaders, and, in the agile domain, team leaders are among the front liners that get the job done.

Leadership is always one of those things on the talking agenda about small team dynamics, and, of course, small teams practicing agile methods. In a recent discussion, I got this explanation:

Leadership and leaders in small team situations:

1) PROACTIVE
2) APPRECIATIVE WHENEVER NEEDED.
3) ABILITY TO KEEP COOL IN TOUGH SITUATIONS AND THINK OUT OF BOX
4) KEEP THE TEAM BONDED TOGETHER
5) BUILD A TEAM THAT IS MOTIVATED AND [SIC] TRUST and SUPPORT EACH OTHER
6) MAKES TEAM MEMBERS BELIEVE THAT NOT ONLY HIGH INDIVIDUAL CONTRIBUTION BUT COLLABORATION WILL BE AWARDED.
7) TRANSPARENCY WITH TEAM MEMBERS.

"Ability to keep cool..." .... I like that one, and also "Makes the team members believe ..."

Although the person who wrote the points (above) was not thinking in terms of the traditional "4-E's" of leadership, it's pretty easy to see how they fit:

Envision: be proactive; look ahead; be confident of the objective
Enable: keep the team bonded; we're not really going anywhere if we don't go together
Energize: and motivate with trust
Empower: with transparency. Make it obvious and above board, not Machiavellian

Of course one of the ideas in current thinking and theory is the 'self organizing team' and 'rotational leadership'. To the former, I say: works sometimes. The latter, I say: almost never works as envisioned.

In the military, although bureaucratic at the headquarters level, small teams are very agile in the sense of "planning is everything; plans are nothing" (Eisenhower), but there's no nonsense about who's in charge. There can be to question or argument about command authority.

On the other hand, both schemes (rotation and fixed command) somewhat deny the obvious: there are natural leaders and there are natural followers. Leader/followers don't change roles easily, and a team really doesn't work until these dominance stresses work their way through.

In the end, Mother Nature will have her way.

Bookmark this on Delicious

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

Machiavelli in the project office?

2011-09-05T07:00:00.006-04:00

Our friends at Eight to Late had a posting last month on 'actor network theory', or ANT for an acronym. ANT is to my eye and ear a variant of use cases; I'm sure there are differences, but the essential matter of mapping every person and every system as an actor seems to be common among the two ideas.

Actually, however, I'll leave ANT to you to follow-up on. One of the early ANT papers is quoted in Eight to Late, although it's a little dated, having been written in the old timer's era of 2001 about things that happened in the 20th century. Obviously, no mention Agile. Nevertheless, late 20th century is also the time when use cases were getting good play, so even though they are not mentioned, one can see the thought synergy.

My interest is in a quote in that reference paper picked up in ETL's post:

They (project managers) either take a Machiavellian view or promote superficial agreement and high sounding concepts while secretly working to their own goals, or they insist on all players subscribing to detailed design specifications expressed in the language of some dominant discourse.

Good grief! So PM's are either cunning and duplicitous, or we torture sponsors and stakeholders into agreeing to words, specifications, and documents they couldn't understand even if they read them.

My experience is that few of us are Machiavellian, but the other charge is too often true. On an ERP engagement I was struck by the futility of the methodology of our engagement partner to get stakeholders to 'sign off on' all the project design documents, as if they could read them (they were in English, but barely so), and more importantly thread them together into a narrative that made business sense.

After all, they (stakeholders/sponsors) were the guardians of the business value; we were the guardians of the earnable value. Our job--not theirs--was to make the translation from our domain to theirs--not the other way 'round. And, that was not the only project where I observed this ineffective sign-off practice. I never understood the value of a signature on a document that I knew was perfunctory and unrepresentative of what it was supposed to stand for.

So, whereas I don't buy the whole quotation (above), I certainly buy half of it! At least agile poses a more effective practice vis a vis the customer/user, even if the close proximity of the customer/user is problematic in many instances.

Bookmark this on Delicious

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

The virtual team thing

2011-09-03T16:13:00.014-04:00

As part of the Agile Project Management course I teach for PMI's eSeminarWorld, I get to talk to students about virtual teams and teamwork since that's how the course is constructed. (disclaimer: I didn't develop the course; I'm an instructor when they need me)

One of the discussions is about what's different about virtual teams; the answers are the one's you'd expect, leading with time zones and 'no co-located stand-up meetings'. But the one I like, though it comes up less often, is 'no body language'.

Having sat on endless conference calls, and participated in a mind numbing number of online chats, I can sympathize that there's a lot left out. But we know that from a lot of experience; we didn't need agile to tell us that body language counts for a lot, by some estimates more than 50%. Agile only reinforces the idea that it's hard to substitute for what Alistair Cockburn calls communication by osmosis--that absorption of information from the unspoken, the casually spoken, and the mere presence in the room, if you will.

On the other hand, reality intrudes: often there's no practical way to get body language in the picture. Yes, that is a shameful segue to video teleconferencing, including Skype and other pc-based video. But I can tell you (as if you need telling) that even with a good camera, video is not an osmosis channel. Nevertheless, better than a straight teleconference most of the time.

Of course, there's the wiki board, and the threaded discussions. They are a possibility also, and I've tried those too. They add value, to be sure, but in the end, there's just nothing like being in the same room!

Bookmark this on Delicious

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

Filter bubbles et al

2011-09-01T07:00:00.015-04:00

So we learned recently that the newest threat to our freedom and liberty is internet filter bubbles. Eli Pariser is pushing this idea (and his book "The Filter Bubble: what the internet may is hiding from you") and you can see his engaging talk on TED.

Now, of course, since his TED talk, there's a whole cottage industry around filter bubbles. Just do a web search on the filter bubble, and a somewhat unfiltered response is returned. A certain irony, there, to be sure.

And there's a counterpoint from academic Paul Resnick who argues that it's not that there is filtering on web searches, including social sites like Facebook--indeed, there is, and has been for a long time--but that the filtering is often done clumsily and ineffectively.

As a project manager, author, blogger, and instructor, I use the web a lot for search. I use multiple engines to include google, bing, and blekko; and all of these return different stuff. I also search google scholar, and the archives of many different sites, like slideshare.net, dau.mil, Harvard Business Review, and my local university library online. So, I may be in a bubble, but I don't see a conspiracy here.

On the other hand, I'm sure there's something to Pariser's theme, more so than book sales. So, to anyone who relies on just one search engine: you are in a bubble!

Bookmark this on Delicious

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

No is easy

2011-08-30T07:00:00.003-04:00

The remoteness of electronic communication makes "saying no" less painful than it ever was. This is probably not news to the blogging community. But couple less painful 'no' with the phenomenon of 'diffusion of responsibility', in which those who say 'no' and become blockers don't have to pay for their decision with accountability or responsibility for consequences, and you have a potentially dysfunctional mix.

I saw it myself when I worked for the US Government. Any mid-level guy could say no; to get around the mid-level took a lot of work, non-value work at that.

When I left government for private industry, I was really shocked by the different deciding paradigm: the decider decided, and the decisions actually stayed decided!

Diffusion of responsibility refers to spreading the decision making among so many individuals that really no one is consequentially on the line, except perhaps for the last guy in the line. It's the project equivalent to putting all 'deciders' in parallel so that no single decider is material. Thus, they can all say 'no' and not be accountable for the decision since 'who was last to say no?' is often not reported or known. Generally, the ordering of the naysayers is not material, so anyone can go first or last.

I've gotten to this point in the blog and I realize I have no answer for the issue. Who was responsible for the financial collapse? No one has really paid a price. Who was responsible for Enron: it's a little clearer there. Who's responsible for a lot of what we endure every day? I don't really know.

Diffusion of responsibility!

Bookmark this on Delicious

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

EVM standards compared

2011-08-28T07:00:00.009-04:00

I came across a white paper the other day that compares the ANSI 748 EVM standard to its Australian counterpart, and also provides some comparisons to the PMI practice standard. Conveniently titled "COMPARISON OF EARNED VALUE STANDARDS", and written by Paul Harris, it sums things up nicely for the non-expert in 11 pages, most of which is quite readable table of comparison.

I wasn't familiar with the Australian standard, AS4817, but I learned this:

This is a standard is a practical guide explaining:
1. The basic processes of an Earned Value Performance Measurement including the calculations.

2. The steps required to run an EVPM system and includes requirements, guidance, examples, graphs and tables.

3. Analysis and reporting techniques. It includes a number of charts and their interpretation.

This standard may be used by people who have project experience to assist in setting set up and running an EVPM system and to provide reports using the formulae and examples which assist in explaining the processes.

And, here's an interesting quote from a bookseller pushing a new PMI book on EVM, but you see it quoted elsewhere:

EVM is management with the lights on!

Bookmark this on Delicious

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

Never give up

2011-08-26T07:00:00.009-04:00

...the software quit before the pilots

Matthew Squair

Matthew's quote comes from his recent blog, one of his many, on the crash of the Air France flight into the Atlantic off Brazil.

This latest analysis is about what else? Software requirements. He lays part of the blame for flying a perfectly airworthy aircraft into the sea, tail down, at 10,000 ft/min, at the feet of the stall warning software, software that quit when foreward airspeed got to 60Kts.

Did I mention tail first?

Matthew's blog is called "Dark Matter". Aptly named in my view

Bookmark this on Delicious

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

That wicked thing

2011-08-24T07:00:00.001-04:00

In the project game, it's usually said: "it all comes back to requirements"

Usually.....

But, there's a thing called 'wicked', invented more or less to explain requirements--or lack thereof--in the political and policy domain. Unlike the domains most of us work in, projects that are motivated by, or subject to, political and policy influences as dominate influences often can not really formulate requirements, even requirements in the agile sense.

The wicked idea is this: the requirements are not knowable until the solution is knowable. From a project perspective, as conventionally governed, such an idea is a really perverse feedback loop.

In Excel terms, it's what the 'resolver' does: it tries a solution on the source to see if it fits. That's pretty much the wicked situation. You talk about the requirements, then you talk about the solution, and then on the basis of yet another solution that might actually be doable, you back fit the requirements.

I fell upon a paper, one of the source documents for this line of thinking ("Dilemmas in a General Theory of Planning" by Rittel and Webber) , that outlines 10 'wicked issues'.

1. There is no definitive formulation of a wicked problem. The information needed to understand the problem depends upon one's idea for solving it.

2. Wicked problems have no stopping rule

3. Solutions to wicked problems are not true-or-false, but good-or-bad

4. There is no immediate and no ultimate test of a solution to a wicked problem. With wicked problems, on the other hand, any solution, after being implemented, will generate waves of consequences over an extended--virtually an unbounded--period of time.

5. Every solution to a wicked problem is a "one-shot operation"; because there is no opportunity to learn by trial-and-error, every attempt counts significantly. With wicked planning problems, however, every implemented solution is consequential. It leaves "traces" that cannot be undone

6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan

7. Every wicked problem is essentially unique

8. Every wicked problem can be considered to be a symptom of another problem

9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution

10. The planner has no right to be wrong. Here the aim is not to find the truth, but to improve some characteristics of the world where people live. Planners are liable for the consequences of the actions they generate

Maybe the arguments about agile methods and requirements are not so bad after all!

Bookmark this on Delicious

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

Why projects matter

2011-08-22T07:00:00.005-04:00

If there was any doubt why projects matter in an economy dominated by services and led by consumers, consider this bit of wisdom:

... ultimately, moving numbers around can do only so much. Over the long haul, you've got to invent or improve real products and services to grow.

Rana Foroohar

Build something! Make something! Deliver something! What a concept--I love it!

Bookmark this on Delicious

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

A reason to be

2011-08-20T07:00:00.007-04:00

I scanned through a 'learned paper' the other day, and frankly I was not impressed with the argument. But the author made a couple of interesting points about the breadth of "reasons to be" vis a vis business projects.

Here's a digest of "reasons to be"

as integrating mechanisms enabling cross-functional integration

as contractual arrangements between markets and hierarchies

as time-limited teams working towards stipulated deadlines

as temporary organizations with distinctive characteristics vs the permanent organization

as effective tools in organizing product development

as the natural work form in [high tech] companies

and as the core units of analysis for understanding the production of high cost, complex products and systems, so called “CoPS”

And you might ask: What did you not agree with? Answer: the author's premise that "projects are an island" and that managers and executives fail to connect projects to the larger business context. The author says:

Contemporary thinking on project management is thus grounded in a lonely project perspective. Both textbooks and research literature primarily discuss individual projects. The perspective is from the inside. The dominant unit of analysis is one project at a time, the time frame is, at maximum, the life cycle of one individual project, and the dominant level of analysis is the individual project and sometimes the individual PM. In this perspective, the players and actions of the environment do not appear in their own right, rather through their relationship with the project in question. The historical and organizational contexts of the project are taken for granted, or simply not included in the analysis

If the author is talking about the PMBOK Guide and other generic project management literature, he's right. There's no way the PMBOK Guide can go much beyond explaining a general approach, and most of that explanation is given to planning, the one activity that is more or less ubiquitous.

But in real situations, I say: Nonsense! That's not my experience and I doubt it's the experience of many. When you're spending other people's money [OPM], they care, and they insist that performance is in the domain and personality and value system of the business.

Bookmark this on Delicious

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

Four leadership roles

2011-08-18T07:00:00.006-04:00

Blogs are all about lists and checklists, but hey! that's not all bad. Whole books have been written about the power of checklists

Here's another list: Four leadership roles for the program manager, and it comes with a swell graphic:

Chief Storyteller

Stories are a universally understood and appealing method for organizing thinking and persuading others. You can weave a lot of information into the telling AND you also arouse your listener’s emotions and energy.

Chief Learning Officer

The job of the leader is to create a constructive environment for learning. Of course, the premise is: there's something to learn. And what's to learn? About the vision, the mission, the direction, the imperative to move forward; certainly not the mechanics of project management, which most executives don't know anyway

Chief Integration Officer

Leaders fit the strategic initiative and its outcomes within the larger organizational, political, and social context. Pay attention to interfaces among these because many failures occur at the interfaces of these disparate systems.

Chief Decision Architect

The leader’s guiding principle as Chief Decision Architect is this simple guiding principle: Effective decisions lead to quality results. Of course, there's also to consider efficient decision making--efficiency often plays into and affects effectiveness. There's a case for deliberate and there's a case for 'get on with it!'

Bookmark this on Delicious

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

The decision making triangle

2011-08-16T07:00:00.001-04:00

Project management, risk management, and other related disciplines are replete with triangles. Here's one more for the collection, taken from an article on "metacognition" by Marvin Cohen and Jared Freeman.

As you can readily see, it's all about decision making under stress [indeed, that's the paraphrase title of their paper] when information potential [in the form of choices and perhaps disorder] may be maximum but data may be incomplete, conflicting, or unreliable.

Their principal conclusion:

Proficient decision makers are recognitionally skilled: that is, they are able to recognize a large number of situations as familiar and to retrieve an appropriate response. Recent research in tactical decision making suggests that proficient decision makers are also metarecognitionally skilled. In novel situations where no familiar pattern fits, proficient decision makers supplement recognition with processes that verify its results and correct problems

Of course, my eye is drawn to the word 'familiar'. In point of fact, there is a decision bias described by Tversky and Khaneman, named by them as "availability bias". In a word, we tend to favor alternatives which are similar to things we can readily bring to mind--that is, things are that are readily available in our mind's eye.

Back to Cohen and Freeman: "More experienced decision makers adopt more sophisticated critiquing strategies. They start by focusing on what is wrong with the current model, especially incompleteness. Attempting to fill in missing arguments typically leads to discovery of other problems (i.e., unreliable arguments or conflicts among arguments)."

Of course, there's the issue of calling the question and getting to convergence--or, in sales: getting to yes! Discovery is good, but it is also is the mark of a more experienced decision maker to stay on course and only evaluate new discoveries if they are truly in the path to a decision on the current problem.

Bookmark this on Delicious

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

Quotation on feedback

2011-08-14T07:00:00.004-04:00

Systems of information-feedback control are fundamental to all life and human endeavor, from the slow pace of biological evolution to the launching of the latest space satellite....

Everything we do as individuals, as an industry, or as a society is done in the context of an information-feedback system.

J.W. Forrester

Bookmark this on Delicious

You are leaving the American sector

2011-08-13T08:27:00.000-04:00

50 years ago today

The Berlin Wall, April 13, 1961

For a number of years, I lived in Berlin, attached to an intelligence unit there. We watched over "GSoFG"--Group, Soviet Forces Germany--that maintained a large army in East Germany and the Berlin area. Locally, we called it the "outpost of freedom", 110 miles inside East Germany.

This is really what it looked like:

Photo

Bookmark this on Delicious

What did you know and when did you know it?

2011-08-12T07:00:00.003-04:00

In a recent report, suggested by Glen Alleman, I read this:

We probed into if and when companies utilize Schedule Risk
Assessment (SRA) within their projects. More than one third
of companies indicated they did use SRA when submitting
proposals. This is interesting because there seems to be
no benefit—in fact there could be a major liability—to
publishing schedule risk during the proposal phase. If a
firm were to analyze its own risk and make pricing or bid
decisions based on that analysis, it would be applicable to
the Truth In Negotiations Act (TINA) and could be required
to be submitted with the bid, damaging the firms chance of
winning. As a result, many firms simply forgo this step during
the proposal phase

The picture below illustrates the statistics:

As a former PMO director that had a portfolio of about 20 - 30 defense projects going at any one time, and writing a dozen proposals a year for replenishment, I can say that what you read and see above is more the case than not. For the last forty years, the mantra of "what did you know and when did you know it" informs much process and decision making.

I used to quip: "the test is whether it will look good on the front page of the Washington Post". If not, don't write it down.

Nevertheless, the need for a SRA, as well its cost counterpart, led me to develop my ideas [in the last century, to put a time frame on it] of the project balance sheet. The idea here is a simple one in concept: there is always a tension between the business side and the project side because they come at things differently. The business, being optimistic, under values risk; the project, being conservative, over estimates cost and schedule.

In the proposal stage, the business wants to win, and at the same time the project may wonder if the business can afford to win. More than once, I remarked: "OMG, we won. What do we do now?"

The Project Balance Sheet

View more presentations from John Goodpasture

Bookmark this on Delicious

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

10 risk questions for executives

2011-08-10T07:00:00.008-04:00

I came across a business blog that focuses more on financial services risk than project risk, but in one posting, I found some advice worth passing along to the project community.

Entitled "10 Questions to Ask Executives About Risk", and written by Norman Marks, a compliance officer, it's a good executive communication checklist. Here's an abridged version of Marks questions:

How has the executive team become familiar with leading risk management practices? .... are you using a recognized risk standard or framework?
In broad strokes, can you describe how you identify, assess, and determine how to manage .... uncertainties?
How do you integrate the consideration and management of risk in the setting of strategy, achievement of goals and objectives, optimization of performance and management of major projects?
How have you assigned the management of risk ... [to specific managers], [and] are they informed, educated in risk management techniques, and provided the tools for the task?
How are risk criteria, including risk appetite and tolerance, set? How are those levels and expectations for taking risk communicated across the organization? How do you know when the levels are exceeded?
How do you manage the accumulation and interplay of risks when a single situation can affect multiple areas, or when the activities of one manager affect others?
Are you managing risk fast enough, so you can act when necessary? Is the organization agile? Are you able to change strategic directions if risk levels change?
If you have a risk office, what is their role relative to the responsibilities of management?
How do you make sure the risk management process is working as you expect?

Bookmark this on Delicious

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

KISS, again

2011-08-08T07:00:00.001-04:00

KISS: Keep it simple, stupid!

Is there anything new to report about simplicity, or its virtues?

Perhaps.

To get the conversation started, consider "Fifteen ways to shut down a Windows laptop"

On the serious side, I happened upon the book "Ten Laws of Simplicity" by John Maeda. You can download the book on Kindle for $12, but here's the gist:

But of course, there are many learned treatise' on this topic. For instance, David Pogue writes about gadgets, and his 'cause celebre' is also simplicity. In a TED talk on this , Pogue's "rules" (rules is probably an overstatement) are:

People like to surround themselves with unnecessary power
If you improve a piece of software often enough you eventually ruin it
One approach to simplicity is 'let's break it down'. (but disaggregation leads to its own form of complexity, e.g. the trees rather than the forest)
Violate consistency in favor of intelligence (don't alphabetize US on a list of 200 countries for US users)
Easy is hard: pre-sweat the details
Simplicity sells

Pogue actually mixes in some humor with his talent for piano and song:

Bookmark this on Delicious

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

Portfolio project management

2011-08-06T07:00:00.007-04:00

Looking for some sources on portfolio project management? Here's an aggregator site that gives a number of links to everything from 'A' to 'W' (Amazon to Wikipedia), with stops in between for numerous blogs and vendor white papers.

You might also like:

Portfolio management and agile: a look at risk and value

View more presentations from John Goodpasture

Bookmark this on Delicious

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

The human thing

2011-08-04T07:00:00.001-04:00

Crosstalk--the Journal of Defense Software Engineering--has an interesting review of "the human thing" in their May/June 2011 issue.

They chronicle a number of well known characteristics, but this article brings it together in a convenient table:

• Human Performance:
-Varies nonlinearly with several factors
-Follows an inverted U-curve relative to stress
-Excessive cognitive complexity can lead to task shedding and poor performance
• Human Error:
-Lack of inspectability into system operation can induce human error
-Incompatibility between human processes and machine algorithms can lead to human error
-Sustained cognitive overload can lead to fatigue and human error
• Human Adaptivity:
-Adaptivity is a unique human capability that is neither absolute or perfect
-Humans do adapt under certain conditions but usually not quickly
-Human adaptation rate sets an upper bound on how fast systems can adapt
-Tradeoff between human adaptation rate and error likelihood
-Need to define what is acceptable error rate (context-dependent)
• Multitasking:
-Humans do not multitask well
-Stanford University’s research findings show that so-called high multi-taskers have difficulty filtering out irrelevant information, can’t compartmentalize to improve recall, and can’t separate contexts
• Decision Making Under Stress:
-Under stress humans tend to simplify environment by disregarding/under weighting complicating factors
-Reduced ability to process multiple cues or perform tradeoffs
• User Acceptance:
-Overly complex system design can lead to rejection of the system
-Humans do not have to really understand software/system operation to develop confidence and trust in system
• Risk Perception and Behavior:
-Humans accept greater risks when in teams
-Humans have a built in target level of acceptable risk
• Human-System Integration:
-Humans are creative but rarely exactly right; however, human errors usually tend to be relatively minor
-Software/system solutions tend to be precisely right, but when wrong they can be way off

Bookmark this on Delicious

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

A quality model

2011-08-02T07:00:00.001-04:00

I was skimming through a blog about safety and security in software systems when my attention was drawn to a reference to the ISO/IEC 9126 quality model.

The interesting thing about this model is that it's ubiquitous: there's nothing inherently software-centric about the model, though it was written with software in mind. In fact, it's a pretty good checklist for anyone (and everyone) interested in delivering good quality to their beneficiaries.

Have a look:

Functionality - A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.
Suitability
Accuracy
Interoperability
Security
Functionality Compliance
Reliability - A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time.
Maturity
Fault Tolerance
Recoverability
Reliability Compliance
Usability - A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users.
Understandability
Learnability
Operability
Attractiveness
Usability Compliance
Efficiency - A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions.
Time Behaviour
Resource Utilisation
Efficiency Compliance
Maintainability - A set of attributes that bear on the effort needed to make specified modifications.
Analyzability
Changeability
Stability
Testability
Maintainability Compliance
Portability - A set of attributes that bear on the ability of software to be transferred from one environment to another.
Adaptability
Installability
Co-Existence
Replaceability
Portability Compliance

Bookmark this on Delicious

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

Policy, doctrine, and protocols

2011-07-31T07:00:00.014-04:00

From time to time, we really do need to write a few things down in a plan, writing actual sentences of all things. One such plan that comes to mind is a risk management plan.

Now, I'm no fan of boilerplate, that generic stuff that planning authors seem determined to impose on the reader (although most of us just skip by), so I propose that most plans can get away with four content categories:

Policy--actionable direction. What is to be done; who (or what) is affected; why are they affected, and who has the responsibility and authority for policy implementation?
Doctrine--the principles and beliefs that inform the policy and
Protocols--the rules (and could also be the tools) for policy implementation
Governance--authorization and escalation rules; decision rules

Let's try one on to see how it might work. How about "risk identification"; what's the plan for that one?

Risk Identification Policy:

It's the policy of Project X that every manager (project, cost account, and work package) will proactively seek risk identification on a continuous basis in order to forestall surprise and enable more predictable forecast of outcomes

Affected managers have a responsibility to ensure identified risks are submitted to the project's risk management process.

Risk Identification Doctrine:
Anyone can identify a risk
Everyone has a responsibility to seek risk identification
Messengers are not at risk for bearing the message
Every identified risk deserves consideration in the risk management process

Risk Identification Protocol:
Continuously assess the circumstances of identified risks to ascertain if revisions, modifications, and additions are required
Maintain a 360-surveillance of the external threat environment; bring new threats to the RM process
Maintain a current forecast by analysis, simulation, or model to reveal new risks to project completion
Elicit expert opinion to formulate risk descriptions
Formulate a Risk Breakdown Structure to categorize risks as affecting the baseline, or not ('on or off' the baseline project plan). In other words, be a Bayseian.
Relate identified risks to the Risk Breakdown Structure by affected WBS, schedule, budget, performance, quality, or other risk register attributes
Governance
Impact decisions follow the project's funding and expenditure authority
Timeliness is of the essence; urgent assessments will be handled within a business day
Risk assignments in the Risk Breakdown Structure follow the projects WBS assignment protocols

There now! That wasn't so bad. A Risk Identification plan in less than a page. What a concept!

Bookmark this on Delicious

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

Governance or error?

2011-07-29T07:00:00.000-04:00

Take a look at this:

Is this pilot error or a violation of governance? I'm not the first to ask the question. Our friends at Dark Matter first raised the point.

Could be either, or neither: it could be mechanical.

How to know? And, does it matter the motivation?

Well, actually yes. Governance is in the wind these days, what with agile and all. On the one hand: all hail initiative and daring! On the other hand: who's got the big picture in mind?

Certainly the 'captain in command' is the ultimate team leader. No central authority can intervene, short of shooting him down (I assume a lady is not in command, but she could be, of course).

And, I'll bet he's not reading the flight manual either! Improvisation is the paradigm.

Trust is what it is about at this point. All concerned, especially the two ground observers, are bound to trust the judgment and skill of the captain.

But motivation is still on the table. The motivation for more agility in governance is to lean out the overhead and concentrate all energy on throughput, that is: governance that actually promotes deliverable output that leads to mission outcomes. Insofar as our daring captain is motivated for the right reasons, I say: yea verily!

Bookmark this on Delicious

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

Where you stand

2011-07-27T07:00:00.000-04:00

Where you stand depends on where you sit

Richard Stengel
Editor, Time Magazine

Amen! When it's not your money, independent action looks pretty good. But, if the the independents are spending your money, governance looks a little different and perhaps a little better!

Actually, Stengel's point is that when you're outside the tent, and don't have responsibility for the consequences of your decisions, it's a lot easier to be a rebel. Inside the tent, things are a little different.

And, if you're an outsider who then finds themselves on the inside and responsible for lives and fortunes, things play a little differently.

It's easy to say "I'm the decider", but it only matters if in the deciding you are also taking responsibility for outcomes and consequences.

Think about it. Where you stand may well depend on where you sit.

Bookmark this on Delicious

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

Eliyahu Goldratt

2011-07-25T07:00:00.049-04:00

Eliyahu Goldratt, a truly innovative thinker, passed away last month, too early by 20 years at least.

Goldratt gave us "Theory of Constraints" and "Critical Chain", two really good ideas useful everyday in our business. TOC--as explained in his book, The Goal--gave us a working paradigm for optimization focused on throughput, the stuff that matters and is valuable to customers/users. He worked hard to convince everyone that optimizing department metrics does not optimize for the business; indeed, it's counter optimization. From TOC, we have the underpinning for Lean, and "throughput accounting", a good concept for the agilists.

From Critical Chain we learn that to protect the critical path and avoid 'merge bias' that destroys schedules, including agile schedules, we buffer to make parallel paths look tandem (serial, finish-to-start). CP uber alles was his mantra. And, Goldratt recognized the cumulative error of putting reserves at the task manager level; his idea: the PM should control reserves, buffering the whole project.

We should all take a moment and remember Eliyahu Goldratt.

Bookmark this on Delicious

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