Information Technology Blog

 

The law of diminishing marginal returns

 

I recently had a bit of a debate with a technology consultant friend who knows I am huge on content and detail within project planning and the contracts that support a technology deal.   We found ourselves speaking 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 individual preferences, etc. —the law of diminishing marginal returns sets in much primeval 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 refer 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 doable consequence of his theory, and I said, “You’re not going to go out and begin spreading this thought around the technology community, are you?”

 

Threatened evangelist

 

My fear was this.   Here was I, this evangelist of content and detail within apiece information technology project, and crossways the plateau 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 can't 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 purchase some off-the-shelf software and customize it a clean 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 finished 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 selected an iterative approach for this project because of your inability to plan your project effectively from begin to finish.   

 

Less obvious examples

           

My friend and I talked some more, and we moved beyond the obvious examples, the ones that are simple to accept.   My natural reaction was to resist any further extension of his theory because I knew he would be slicing closer and closer to the bone, threatening the very foundation of my evangelist mission.   However, sitting before me was a bright mortal and a clear thinker, with almost two decades of experience with technology.   I had to listen (nervously).   “When the student is ready to learn, the instructor 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 stipulations 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 stipulations are not helpful (and might 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 apiece of us can rattle off a number of clichés for apiece 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 prefabricated 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 ideal 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 down 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 might be evenhandedly sophisticated by now.   You might 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 superior way, perhaps prompted by a current 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 capability to plan certain elements might not yet exist.   Further, even if you have the present need and capability to plan a certain aspect of your project, do not overdo it.   For example, do not continue to add more and more stipulations to your stipulations basket as if quantity were your only goal.

           

On this last point, remind yourself that requirements, specifications, individual preferences, and apiece 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 inactivity 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 primeval stage of your project.   You will not even open Stipulations Container 2 until the high-priority stipulations in Container 1 have been fatigued (satisfied or deliberately discarded).   A prioritization approach could save you time, dollars and other resources.

 

Conclusion

           

For many of us, it might be ideal not to let go of our conditioned response to project planning and critical thinking—not just yet anyway.   The conditioning represents an overall positive motivation, its underlying purpose is producing results, and our technology procurement process, including its planning element, might still have plenty of room for improvement.   The more sophisticated technology buyers among us might want to place the brakes on the conditioned response a bit.  

 

Regardless of what camp you are in (and until further notice from the experts!), be at least mindful of the fact that there is such a thing as too much project planning.   I, for one, am now a believer.

 

 

 

 

 

 

© 2008 All rights reserved.  Nuckles Law Firm

Related posts:

1. Green Cell Technologies – Revolutionary LED Tritechnology? illuminates the Green House Project has open revolutionary initiative Huntingdonshire District Council, Green Home Project...

Related posts brought to you by Yet Another Related Posts Plugin.