The law of diminishing marginal returns
I recently had a
bit of a debate with a technology consultant friend who knows I am big
on content and detail within project planning and the contracts that
support a technology deal. We found ourselves talking about that
principle of economics called the law of diminishing marginal returns.
His point was that for project owners who are in the midst of planning a
new project-gathering requirements, fleshing out specifications,
polling user preferences, etc.-the law of diminishing marginal returns
sets in much earlier than they realize. The resources spent during the
initial planning stages produce some hefty returns. But soon after,
spending the same amount of resources again, and the next time after
that, will produce smaller and smaller chunks of benefit. When you are
caught up in a planning process, it is often difficult to identify the
point at which your cost-benefit curve has begun to flatten.
What
my friend was saying seemed plausible, and because I did not have any
evidence to the contrary, I just accepted his theory. Then I thought of
a possible consequence of his theory, and I said, "You're not going to
go out and start spreading this thought around the technology community,
are you?"
Threatened evangelist
My fear was this.
Here was I, this evangelist of content and detail, and across the table
was a fellow who could undermine the past and future progress of my
mission by telling folks they actually need less planning and critical
thinking for their technology projects and not more. Project owners'
planning and thinking are, after all, what generate the content and
detail I crave and have come to respect.
Well, we talked some
more, and my friend added some clarification. As it turns out, he was
suggesting mainly that project owners not waste time and money planning
what cannot be planned effectively at a particular point in time. Made
sense. I was still squirming, but now a bit relieved.
Obvious example
You
have decided to use a staged or iterative approach for your next
project. You will buy some Off-The-Shelf software and customize it a
fair amount. Phase 1 might involve extending a discrete element of
existing functionality and then wiring up to a live database for some
testing.
In this example, there is really no point to thinking
through the details of Phases 2 through 5 or estimating costs within
those phases, except in either case at a very high level, because: 1)
unless Phase 1 is completed smoothly and with an acceptable cost, you
will never get to the subsequent phases; and 2) you have not yet tested
your assumptions about costing within Phase 1. Indeed, you probably
chose an iterative approach for this project because of your inability
to plan your project effectively from start to finish.
Less obvious examples
My
friend and I talked some more, and we moved beyond the obvious
examples, the ones that are easy to accept. My natural reaction was to
resist any further extension of his theory because I knew he would be
cutting closer and closer to the bone, threatening the very foundation
of my evangelist mission. However, sitting before me was a bright
person and a clear thinker, with nearly two decades of experience with
technology. I had to listen (nervously). "When the student is ready to
learn, the teacher will appear."
Requirements gathering - A
good thing, no doubt, and something the experts have been encouraging
us to do more of over the last ten years. "Insufficient requirements
development cited as leading cause of project failure." When it comes to
requirements, we have been led to believe that more is not enough.
Surely there is a point at which more requirements are not helpful (and
may even be detrimental), but the experts have not told us how to
determine just when we have turned the corner.
Specifications development - Same story. Develop specifications thoroughly now or risk project failure.
User preferences - Same story. Involve your users in your planning process. Otherwise, "If you build it, they won't come."
We
have heard so much preaching on these topics that each of us can rattle
off a number of clichés for each topic. The advice has been mostly
good, but we are hammered with it by speaker after speaker, in article
after article.
Reconciliation
As much as I resisted
the flow of this discussion with my friend, I have to admit that what he
was saying made perfect sense to me. But now I had to find some way to
reconcile two divergent concepts: on the one hand, my long-held belief
that more project planning and critical thinking should always be one's
aspiration, and on the other, my realization that you truly can have too
much of a good thing.
Ultimately, I found the reconciliation I
needed with just one insight. It occurred to me that, with all of the
speakers and literature out there telling us to engage in more best
practices for our technology projects and more often, we have become
conditioned to believe that more is not enough-in fact, because of the
nature of the beast, more can never be enough. We have been doing more
and more, and the incremental improvements we have witnessed, together
with the new articles we read, encourage us to keep doing more and more.
Of course, our intention is good, but when can we stop doing more?
When should we stop doing more?
It's all relative
I
think it all boils dnwn to relativity-your relative sophistication as a
technology buyer, and the relative nature of your particular project.
If you started heeding the experts' advice many years ago, your approach
to buying technology may be fairly sophisticated by now. You may be
doing an appropriate level of planning for your projects, and maybe you
occasionally do too much. Other organizations are just now opening
their eyes to a better way, perhaps prompted by a recent problematic
project.
Second, when enough is enough depends on your particular
project. Your goal is to plan effectively and thoroughly for all
aspects of your project, but be mindful that your present need or
ability to plan certain elements may not yet exist. Further, even if
you have the present need and ability to plan a certain aspect of your
project, do not overdo it. For example, do not continue to add more and
more requirements to your requirements basket as if quantity were your
only goal.
On this last point, remind yourself that requirements,
specifications, user preferences, and every other item on your
project-planning list have at least one thing in common. Once you have
thought of them and cemented them into some spreadsheet, they have a way
of hanging around for the duration of your planning process, and often
through completion of your project. Instead of waiting to whack some of
these hangers-on toward the end of a phase or at the end of your
project ("backward creep" of scope or deliverables), attempt to
prioritize them at an early stage of your project. You will not even
open Requirements Container 2 until the high-priority requirements in
Container 1 have been exhausted (satisfied or deliberately discarded). A
prioritization approach could save you time, dollars and other
resources.
[Continue reading...]
