No is easy

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

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

...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

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

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

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

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.