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 realise. 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 customise 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 realisation 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 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 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 organisations 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 prioritise 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 prioritisation approach could save you time, dollars and other resources. Conclusion For many of us, it may be best 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, may still have plenty of room for improvement. The more sophisticated technology buyers among us might want to put 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.
