Project Management Operational Problem Solving Implementation & Change Management Strategy & Alignment

Frank Patrick's Focused Performance Business Blog
This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.

Wednesday, March 26, 2003

Dependencies - Violent Agreement -- Laurent Bossavit, in comparing my comments on project planning with those of James Grenning [pdf] (an XP advocate)...
"...can't decide whether James and Frank are in complete contradiction or in violent agreement."
From where I'm standing, I'll say "violent agreement."

Or maybe separated by different uses of a common language.

Reading Laurent's blog, I think I bruised my forehead when the heel of my hand thumped it and a Homeresque "DOH!!!" escaped my lips. It (the blog, not the forehead-thumping) helped me expand on my view of the source of the dilemma in the use of heavyweight WBSs in traditional project management. Read on.
"One all too common way of planning a software project does involve breaking down the work into technical components (as opposed to features). So many weeks for the persistence framework, so many for the domain model, so many for the "presentation layer". The required features of the system are supposed to "drop out" of the integration stage when the components are assembled."
(...with heavy details for each of these pieces, but with little useful information about their real interdependencies; hence the "whoops's" or "aw-s#!t's" in the execution of the project.)
"Many Agile processes recommend breaking down the work exclusively according to "features" - new capabilities available to end users."
This is where my "a-ha" starts to come together. Agile's "features" are directly related to the "deliverables" of Critical Chain Dependency Network's starting point of "objectives, deliverables, and success criteria." The focus of CCPM planning is first on the whats (at the end, and in terms of what is needed to be handed-off along the way), and only then on the hows, and then only if assumptions about how those hows are needed to be narrowed down to understand cross-task whats. (Yeah, read that last sentence again; it's ugly, but it does reflect what I'm trying to say.)
"Extreme Programming recommends that technical dependencies should play almost no role in planning the work to be done. It seems to me that if this is the case, business dependencies (in the form of priority ordering of features) will be reflected in the planning."
Yes. Very often when I go into a client, the first order of business is to get rid of the existing, over-planned, over-detailed schedules and plans that reflect an attempt to micro-manage the efforts of resources and teams, with strings of tasks reflecting pseudo-handoffs from A to A to A to A, without input or outputs to B (or anyone else). These kinds of plans only serve the paranoia and distrust of the PM when tha PM thinks s/he needs to "control" the details of the project.

Instead, PMs should be focused on the dynamics of the project. Tasks in Critical Chain are defined by handoffs between resources, and if, in an agile/xtreme/etc. environment, those resources are teams or pairs or whatever, the technical aspects of the project -- the "hows" are, to a very large part, embedded in the tasks. In CCPM, as in the agile methods, these are managed by the resources and their technical managers and only require (for Critical Chain's Buffer Management process) reporting out to the project manager status of expected time to completion or actual completion. This minimal reporting is necessary so that successors can be ready to run the next leg of the relay race and so that management can maintain confidence in the larger, meaningful promises of the project. Of course, some understanding of the impact of these tasks needs to be taken into consideration up front so that big-picture promises can be made, but the "range estimate" process of CCPM makes that a comfortable and quick aspect of the planning exercise.
"If we are to understand a software project as "a system of interdependencies supporting the project objectives" - a chain of mutually supporting, intermediate objectives in pursuit of a larger, farther off, overarching obective - then technical dependencies are mostly irrelevant...."
I'm glad to see the word "mostly" in there.   -)
The objectives of a software project are usually not technical, i.e. the software is not built for the sake of building the software, but to achieve some other business objective. So I'm pretty sure that it's not technical dependencies which are worth focusing on in a project plan. I'm less sure how well XP, or various software development processes, measure up to handling business dependencies"
I may need a bit of additional clarity on Laurent's/XP's use of the term "technical dependencies," however, because in the context of promising the necessary aspects of a project, there may be a need to model dependencies between the "hows" of features that have inter-dependent predecessor/successor relationships. But on the other side of the coin, if certain features/deliverables have no interdependencies (other than maybe the use of common, shared resources), and they are truly useful in a standalone delivery, there is no reason not to model such deliveries separate from and prior to the end of the larger project (or even manage them as separate projects in a larger program or portfolio). In CCPM, we do that all the time with "deliverable project buffers" for such situations.

oooh...That's a good word..."model."

(Please forgive this stream of consciousness. I hope it isn't rambling too much.)

If agilistas have a problem with the word "plan" as it might be associated with non-CC "heavyweight" project management, laden with rigid (but irrelevant) dates and milestones, I think they might be more comfortable with the Critical Chain concept of the dependency network and schedule as a "model" of anticipated dependencies and expectations that support the ability to promise uncertain outcomes within an acceptable range of certainty.

I really have to thank Laurent for helping me refine what I've been trying to say on the subject. These weblog interactions can be a true learning process.

[ Warning! Blatent commercial mode engaged]

Now, if there are any agile managers out there interested in overlaying CCPM on their efforts, bring me on in, and we'll make your agile promises happen together.

[Standard pseudo-non-commercial mode re-engaged.]

posted by Frank - Permanent Link - |

Current Posts (Main Blog Page)

Previous Posts

It is a common delusion that you make things better by talking about them. - Dame Rose Macaulay

What's this XML thingie all about?

View Frank Patrick's LinkedIn profileView Frank Patrick's profile


FP's Recommended Reading
- From the FP Bookshelf...

...from My AStore

...and some ideas from Amazon...

Best of the FP Blog Archive
- The really good stuff...

Strategic Thinking and Improvement

Enterprise PM - It Starts with Strategic Interdependence

Face Reality

How to Think With Your Gut

Hugger-Mugger and Helter-Skelter

Managing for Murphy, Satan, and Yourself

More of the Same (Local/Global)

PMI Congress Notes: Using Risk Management for Strategic Advantage

Tell Me How You'll Measure Me and Ah, But What to Measure?

What's in Your Strategy?

Why Can't We All Just Get Along?

Why TOC Works
Project and Multi-Project Management
Critical Chain and (not or) XP

Defining Project Success (But for Whom?)

Down 'n Dirty w/TOC and PM (Part 1 of 5 consecutive posts)

End of Project Review

If Project Management is the Answer, What's the Question?

In Defense of Planning

It Ain't the Tools

Lessons Learned, Revisited

Predicting Uncertain Futures

Project Conflicts

Project Determinism (and other myths)

Project Portfolio Management

Promises, Predictions, and Planning

Removing Bottlenecks - A Core Systems Design Principle

Stage Gates and Critical Chain

Ten Top Sources of Project Failure (The Executive Version)

The Meaning of "Schedule"
Leadership and Change Management
Consistent Leadership Behavior

Invisible Dogma - Perpetuating Paradigms

Nothing But Value

On Assumption Busting

Personal Productivity - An Excuse?

The Psychology of Change Management

FP's Blogroll
- Other weblogs and sites I read

FP's Ryze Page

FP's Technorati Profile
- Click the pic

Who links to FP?

For Your Charitable Consideration:

Give Something Back Foundation

Global Virtual Classroom

FP's Link List
- Selected Sites and Resources

Critical Chain Discussion Group

Lilly Software: Visual DBR

Sciforma PS (Critical Chain Software)

Spherical Angle (Critical Chain Software)

Synchrono Supply Chain Planning Software

FP Blog Archives
- All the oldies, but goodies...

10/09 | 09/09 | 08/09 | 07/09 | 06/09 | 05/09 | 04/09 | 03/09 | 02/09 | 01/09 | 12/08 | 11/08 | 10/08 | 09/08 | 08/08 | 07/08 | 06/08 | 05/08 | 04/08 | 03/08 | 02/08 | 01/08 | 12/07 | 11/07 | 10/07 | 09/07 | 08/07 | 07/07 | 06/07 | 05/07 | 04/07 | 03/07 | 02/07 | 01/07 | 12/06 | 11/06 | 10/06 | 09/06 | 08/06 | 07/06 | 06/06 | 05/06 | 04/06 | 03/06 | 02/06 | 01/06 | 12/05 | 11/05 | 10/05 | 09/05 | 08/05 | 07/05 | 06/05 | 05/05 | 04/05 | 03/05 | 02/05 | 01/05 | 12/04 | 11/04 | 10/04 | 09/04 | 08/04 | 07/04 | 06/04 | 05/04 | 04/04 | 03/04 | 02/04 | 01/04 | 12/03 | 11/03 | 10/03 | 09/03 | 08/03 | 07/03 | 06/03 | 05/03 | 04/03 | 03/03 | 02/03 | 01/03 | 12/02 | 11/02 | 10/02 | 09/02 | 08/02 | 07/02 | 06/02 | 03/02 | 02/02 | 12/01 | 11/01 | 10/01 | 09/01 | 08/01 | 06/01 | 02/01 | 01/01 | 12/00

Powered by Blogger

If you are interested in adding an easily updated weblog to your site, I would suggest you look into the free service provided by Blogger.

Who is FP?
Contact Focused Performance