Meet Minimum Requirements: Anything More Is Too Much

Commit to a project plan that only includes essential function, with a "closet plan" for nonessential function.

by Neal Whitten, PMP, Contributing Editor

Does this conversation between a project manager and a project outsider sound familiar? It’s a Y2K project, but it could be any project.
Outsider: "Will your project complete on time?"
PM: "We have no choice."
Outsider: "I didn’t ask if you had a choice. I asked will you complete on time?"
PM: "This is an important project. There’s a lot riding on the success of this project. We must complete on time."
(Translation: "No, we won’t complete on time. Anybody with any project experience knows this.")
Is this a Y2K-unique problem? No—it’s common on most projects. The primary reason it’s so common on Y2K projects is that most of the project managers and other project leaders on these projects were trained on pre-Y2K projects. Let me explain.
One of the most common problems with projects is taking on too much work—attempting to exceed requirements rather than meet minimum requirements. This contributes to a plethora of ill effects, including late deliveries, budget overruns, low morale and poor quality. Attempting to cram the proverbial 10 pounds into a 5-pound sack is a common occurrence.
One solution is to build products that meet minimum requirements. You may be thinking that such a product would have low appeal to your client or customers, but it’s not what you think.
"Meet minimum requirements" means give the client what he or she needs to be successful; but don’t provide unessential function. Additional function is what future releases and future business opportunities are all about. It is important to earn the reputation for being reliable in meeting customer commitments and then be trusted to continue to upgrade on a routine, predictable basis. This is good business.
You say you always only provide essential function? For most of us, most times, that’s not true. Have you ever faced slipped delivery dates and chosen to remove some of the function originally planned? When the project began, everyone swore that all the planned function was essential. Yet, as the project progressed—and got further behind schedule—some of that essential function no longer looked so essential.
We’ll use a Y2K project as an example, because Y2K projects are at a heightened focus these days—and, interestingly enough, the No. 2 problem with Y2K projects is that they are taking on too much work (the No. 1 problem is that too many projects are starting too late). Here’s what should occur.
Let’s say you’ve identified 100 functions (enhancements or changes) that need to be made in your company’s programs. You know that all 100 functions are desirable, but you recognize that your limited resources won’t allow all the functions to be ready by the hoped-for date. You find that 40 functions fall within the high-priority category, 30 as medium and 30 as low. You build a project plan to implement only the 40 high priorities. Why? Because you don’t want to jeopardize the timely completion of these 40 by building a plan to include the other 60 functions—all of lesser importance and, for purposes of illustration, deemed nonessential.
You might be thinking that you should build a plan with all 100 functions and later, if (actually, when) the project gets into trouble, you can always back out of lesser-priority function. Don’t go there! This foolish plan requires spending valuable time, dollars and resources working on other-than-the-most-important functions. Moreover, when you back out, it costs again. What needs to be done is to build a plan that significantly reduces rework. This means the original plan must be only essential function.
What about the other 60? You carefully look these over and put work-arounds in place that, although not optimal, can get you through until more substantial actions can occur.
But there is something else you do. You decide on the most important of the 60 functions—maybe it’s all of the 30 medium functions or some subset thereof—and you create multiple, independent small projects with any and all resources you can muster. I call these small projects collectively a "closet plan." These small projects are managed with the same care and attention to quality as the primary project. If any of these small projects can complete by a predetermined date (e.g., system test) and the risk to the primary project is judged to be acceptable, then the completed small projects are merged in with the primary project. There are many advantages to this technique: from reducing risk to the primary project, to motivating the members of the small projects to complete by a predetermined date, to setting customer expectations that are most likely to be met or exceeded.

MOST OF US have been conditioned to believe that "meets minimum requirements" is unexciting and noncompetitive. I believe it to be the opposite. Deliberately practicing meeting minimum requirements helps an organization or company to be first-to-market, earn increasing credibility from their client(s), and strongly posture their enterprise for taking on new business opportunities. Adopting the concept of meeting minimum requirements can set your organization up for exceptional performance.

Neal Whitten, PMP, president of The Neal Whitten Group (www.nealwhittengroup.com), is a speaker, trainer, consultant, mentor, and author in project management and employee development. His books include The EnterPrize Organization: Organizing Software Projects for Accountability and Success and Managing Software Development Projects: Formula for Success.

This material is reprinted from PM Network magazine (September 1998) with permission of the Project Management Institute Headquarters, Four Campus Boulevard, Newtown Square, PA 19073-2399 USA. Phone: (610) 356-4600. Fax: (610) 356-4647. Project Management Institute (PMI) is the world’s leading project management association with over 50,000 members worldwide. For further information, contact PMI Headquarters at (610) 356-4600 or visit the web site at www.pmi.org. "PMI" and "PM Network" are trademarks of the Project Management Institute, Inc. © 2000 Project Management Institute, Inc. All rights reserved.

ARTICLES | HOME | TOP