65. Co-Education
,
Copyright: Dmitriy Shironosov/iStockPhoto
The project’s stakeholders understand that each has much to learn from the others.
When a project is formed, its purpose is to change the state of some system, piece of work, product, or service. That much is obvious.
However, when a project starts, it is unrealistic to expect that any one person, or group of people, knows precisely what the desired future state is to be.
For example, it is unrealistic at the start of a project for builders to expect consumers to recite all of the requirements completely and accurately. Similarly, consumers can barely expect builders to understand the requirements before studying the situation. Without an understanding of the requirements, attempts at change are almost certain to founder.
The usual problem is that stakeholders don’t understand that they have to learn from each other. What’s required is a co-education effort between consumers and builders. Each must teach and learn from the other.
Let’s look at this a little more closely. The requirements gatherers have to learn the consumers’ work in order to specify an effective product or service. However, three obstacles may block the consumers from imparting their knowledge to the builders. First, the consumers may know their work so well that it seems obvious—they may fail to mention details they assume the builders already know. Second, the consumers are not necessarily equipped with great communication skills and may become reluctant to volunteer information that would otherwise help the builders. Third, the consumers may have difficulty identifying or envisioning their future needs. It is difficult, if not impossible, to know what we want until we see it.
Consider the experience of browsing in a bookstore and finding yourself interested in a book on a subject you’ve never considered before. Or if you don’t often browse for books, imagine discovering an exciting item while shopping in your favorite category—maybe it’s a snappy electronics gadget or a dreamy item of lingerie. (Readers will have to determine their own gender preferences for that last sentence.) Simply put, we most likely have to see or experience something before we can know whether it fits our needs and wants.
So, if builders must deliver to consumers a product or service that is as delightful as that book, gadget, or lingerie—without knowing in advance the qualities of that product or service—a two-way co-education must take place. Unfortunately, there are some obstacles that usually prevent meaningful learning from taking place between consumers and builders: the signed-off specification, the misguided solution, the learning lockout, and the absence of a common language. We discuss these below.
Some organizations insist that the requirements specification must be signed-off before any development can commence. This signing usually falls to the chief consumer. Since he will be held accountable for the specification, he naturally decides to dictate it. This reduces the role of the requirements gatherer to that of a stenographer, precluding the discovery and learning process that would be fostered by early prototypes and exploratory models.
Co-education may also get blocked by the proposal of a misguided solution. Some stakeholders take the stance that they know what they want, and, by George, they are going to get it. In such cases, what they want is some perceived solution to an immediate problem. However, that solution rarely addresses a multitude of larger needs: those of the work situation, of the organization that houses the work, and of the stakeholders outside the organization. In this case, it is the problem itself that everyone needs to understand—the solution will come in time.
Learning is best started early. As a project progresses, ideas harden, expectations become more firm, talked-about solutions become more anticipated, and it becomes progressively more difficult for both builder and consumer to break out and learn something new about their intended product or service. When this early opportunity is not taken, the traditional roles of requirements provider and requirements gatherer become entrenched, making it tougher, much tougher, for innovation to flourish.
Each of the stakeholders knows something—usually quite a lot—and typically each of them knows something different, so they have to teach each other. However, for parties from different backgrounds to co-educate each other effectively, they need a common language—a project Esperanto, if you will. Most often, a modeling language serves best. Co-education entails a certain amount of trial and error, and modeling is the ideal vehicle. People are less likely to argue vociferously for their pet features—and more likely to think about lessons learned—when they know that everyone regards the models under discussion as disposable artifacts of the learning process.
If the right products and services are to emerge from a development project, then the needs of the consumers—and the features to support those needs—must be well understood. This kind of understanding comes when consumers and developers learn the requirements from each other. The hardest part is realizing the need for a concerted co-education effort.