The Concept of Expectations Management
By Jeff Gainer
(Author's note: This essay originally appeared in the 08 November 2000 issue of the Cutter IT Journal E-Mail Advisor.)
If it weren't for the outrageous demands of customers, we wouldn't have some of our greatest challenges.
Too often, the customer presumes that the development community understands their requirements or, more deeply,
their needs. Or, perhaps more dangerously, we presume that the customers really do know what they need. More than
once, after a brief preliminary meeting, I have been asked, "So you know what we want, right?"
Let's face it: as an industry, we don't manage requirements well, we don't test well, we don't manage quality well, or at all, and our products are almost inevitably late. And while we try to manage our schedules, our people and their work, we don't actively manage our customers. Instead, we regard customers as loose unmanageable cannons. We take the cards they deal us, as it were, and play our sorry hand. Change requests, creeping requirements, compressed schedules, well, we take it all in stride, meekly apologizing when we miss the unrealistic schedule.
Expectations management is the key to successful project outcome.
Rather than fumbling along and discovering expectations along the way, it is more prudent to determine measurable
quality expectations at the beginning of the project and monitor and report progress against these goals throughout.
Expectations management is very similar to requirements management--but the crucial difference is that we are managing
the customer, not the product.
In the traditional waterfall lifecycle, products were clearly, unambiguously defined long before the requirements and architecture phases, and we had a choice of development platforms other than the stockholder-mandated platform described simply as "e-commerce," or only slightly less eloquently as "the Internet." The act of development was merely a matter of translating the requirements into code. Then the code was tested against the ironclad requirements and the product is deployed and everyone lived happily ever after. And in this magical land, which is, incidentally, also occupied by fairies and unicorns, the requirements never changed. This scenario never really existed, of course, since even in the most orthodox traditional waterfall-based projects, stable requirements never really existed. Then, as now, the very act of developing software forces us to question and further define requirements, additionally, we learn more about a task as we do it. And besides, as Watt Humphrey humorously observed, "…a software perversity law seems to dictate that the firmer the specifications are, the more likely they are to be wrong. "
In the brave, new, and chaotic world of eCommerce, iterative prototyping, RAD, extreme programming, and the spiral software development model have unquestionably supplanted the traditional waterfall model. These new models can work well in the early stages of a project to more clearly define what a product should be when requirements are not yet stable or are still in flux. Determining requirements in such an environment is often a process of discovery. Yet, if the customer and stakeholders do not understand the gravity of such change, this process can even encourage requirements creep. It is essential that a project manager thoroughly understand the development lifecycle model the business uses, but just as importantly, he must be able to explain these complexities to the customers and stakeholders in conceptual, rather than technical terms.
It is essential to remind your customers of the ironclad interdependencies of interdependencies of functionality, schedule, and quality. Typically I introduce this with the example:
"Do you want:
· Low Cost
· Fast Delivery
· No bugs"
"Now pick two and we'll talk…."
This flip example, however, doesn't show any flexibility. If the customer is ignorant of what happens in a development process, he will be equally ignorant of what happens on submitting new requirements. Indeed, it is only natural to assume that a process that invites revision, redefinition, and refining invites such. So, at this point, it is a good idea to introduce the concept of "good enough" software. Popularized in the mid-1990's, the "good-enough" software approach presumes that software can't be perfect, and that it can ship with an acceptable number of defects, which is, in turn, determined by the time the product must be deployed. The concept of "good-enough" software postulates that there is an inflexible interdependency between schedule, quality, and functionality. The "iron triangle" is an excellent example to use to communicate the concept. Once the customers see how the three aspects are related, it will be far easier to negotiate change requests.
It is the responsibility of the development managers to educate the customer on the intricacies of the partnership of producing the product that meets their needs. Never forget: we must not only ask customers what they want and need, we must educate them as well. Before, and during, not just after the development of a product, educating the customer is essential.
(c)2000 Cutter Information Corp. All rights reserved. This article has been reprinted with the permission of the publisher, Cutter Information Corp., a provider of information resources for IT professionals worldwide.
This article originally appeared in the Cutter IT E-Mail Advisor, a supplement to Cutter IT Journal. www.cutter.com/itjournal
Return To jeffgainer.com.