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.

Friday, March 21, 2003

Requirements Churn -- A Question of Ends or Means? -- In a comment to a recent post (What is a Project?), someone who signed in as "DP" asked...
"I wanted to see if you'd comment sometime on how you'd handle "requirements churn." The heavyweight process that the agilists want to unseat start from the assumption that there is a well defined set of requirements (or that one is possible) and proceed logically from there. This is probably proper for most kinds of physical deliverables, but it fails to address the "softness" of software. I think this is one of the main reasons those non-agile processes fail so often in software. In my experience, the project promises are almost exactly as stable as the requirements - the whole notion of a moving target."
My immediate response (and this is an immediate, "rough draft" response, so please spare the flamethrowers for now...although I would like to engender a discussion on this with those who are more deeply involved in software development, so please make use of the comment feature below if you are so moved by what I have to say) is that this issue of requirement churn is embedded in a confusion of means and ends. When I advise clients on developing project plans, the starting point is the endgame...the objective, key deliverables, and success criteria that define the reason and output effects of the effort defined as the project. The output of a "software project" is not just "working code," but rather it is either A) a software product that is sold, installed, and solves some problem for a customer to the degree that they are willing to pay for it, or B) a combination of a system and business process change that enables the oganization to do something of value that it isn't able to do without embarking on the project. From my point of view, the objective -- the "ends" -- must be defined sufficiently so that a reasonable plan to achieve it can be devised, and promises can be made to the market, to shareholders/owners, and to other stakeholders.

When we move into the realm of software projects, "requirements" are seen as the basic link between the "ends" and their "beginnings" -- the design of the necessary work to produce it. What confuses me, as someone who has been exposed to just enough software-related projects to be dangerous, is to what extent requirements are "ends" or "means." The project objective is a very high level "requirement," one that if it is allowed to churn indicates serious management problems beyond the realm of project management.

I would suspect that there is a second level of requirements that remain quite stable once determined, probably related to basic/core functionality and user requirements associated with the objective. If these are allowed to substantially change, there had better be a darn good reason for it -- more than just the excuse of "softness of software." That said, a robust project management methodology, combined with good task mangement practices that I associate with my passing knowledge of agile development methodologies, should be able to highlight when those deviations are occurring and the impact on the original project promise. Good change control practices, tempered with an awareness of the potential for real added value, and supported by a planning/scheduling process that allows flexibility for such things deal with these.

The third set of requirements that I suspect is the source of concern about churn are probably in the details. It's my sneaking suspicion that these, even more than the second set, are related to the means of achieving the ends of the project rather than being ends themselves. Yes, they relate to the ends of tasks, but only as stepping stones to the complete system. Programmers and engineers focus on them, rightfully, but they are only local components of the larger effort, and must be dealt with as such. (There is also the "good enough" rule, and its propensity to be broken in tech/software projects. Sometimes, there is pressure to change a requirement to address some new technology or to make the solution more "elegant" or "perfect," when, to meet the needs of the customer, the original plan is "good enough." Sometimes I think tech/software projects are overly susceptible to such self-induced churn, unnecessarily. But that's a whole 'nother topic.)

A project can be planned with good enough results based on an overarching view of the system, probably at the level of the second level of requirements. The detail requirements, taking a cue from both lean manufacturing practices, and the process of network building associated with Critical Chain Project Management, are planned to occur "just in time," when needed to support the rougher view of the project. And if the schedule is a Critical Chain Schedule, the duration/effort uncertainty of the higher granularity pieces of the project are already taken into consideration and deviations from expectations do not become cause for undue concern; the schedule and the promise associated with it is buffered to absorb such deviations.

Fix the core requirements that define the ends, monitor the intermediate requirements for risks or opportunities, and develop the detail requirements (the means) when needed, and not before. Promise the effort based on a robust respect for risk and uncertainty, and don't worry about deviations along the way until and unless they threaten the project promise.

So asked whether to fix requirements up front or let them slide loose until more details are known about the project, my answer is a resounding "yes". That may sound like a bit of fence-straddling, but then, where I come from -- Critical Chain land -- is, I believe, a place that lies on the border, straddling the fence between "heavyweight" and "agile," and therefore gets minimal respect from either.

One of these days, that will change.

(Again, I need to refine my thinking on this, so comments are heartily solicited.)

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



Google
Web focusedperformance.com


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

Current
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