Defining Requirements
In a previous Musing we discussed the issue of consensus versus consent in connection with a project on which we have been engaged for some months now. The value of this project's product is distinctly abstract and this environment has an impact on how the project should be properly managed. This time the team's hot issue was the best way to determine "stakeholder requirements".
So-called "modern project management" proposes a series of three or more (typically four) sequential phases ("stages" in some domains). In building construction, for instance, phase 1 identifies the concept and its feasibility; phase 2 deals with planning and design; phase 3 deals with construction; and phase 4 deals with commissioning and transfer. A more generic version has phase 1 establishing the problem and conceptual solution and phase 2 develops the project's definition, which includes collecting the stakeholders' requirements. In phase 3, the definition of phase 2 is implemented, while phase 4 sees the transfer of the product into the hands of the customer.
Except for those life cycles that go round in circles, or otherwise spiral
(out of control?) the serialization of the main phases enables clear executive
management decisions at the end
of each phase. Management can determine whether or not to proceed and invest
the necessary time, resources and money on the succeeding phase. This approach
enables careful planning, a higher degree of certainty with the outcome, i.e.
reduced risk, and efficiency in implementation. It is particularly appropriate
for buildings and civil infrastructure works where the major expenditure is
in project implementation. This is essentially the systems view of project
management and we've been teaching project management like this for years.
Therefore, in our particular case conventional wisdom had it that we should go out and collect all of our stakeholders' requirements, and have them sign off on statements that truly reflected those requirements. Then, and only then, should we proceed to assemble the (intellectual) product. After final assembly, we could roll out the product and, since everyone had signed off on the requirements, everyone would be happy. Sounds simple, right? But anyone who has tried to collect requirements for, say, a software project, even the interface requirements, knows that it is not as easy as it sounds. (For a discussion of "Software Development and Linearity" see our corresponding articles in the Papers department.)
The serialization of the major activities, sometimes referred to as the waterfall approach to the project life cycle, appears particularly attractive since it is easy to understand and seems easy to manage. However, where intellectual work is involved leading to abstract value, as in software, decades of experience has shown that this approach is likely to fail. Why is abstract product value so different from tangible products? Because the sequential logic of intellectual work is much less rigid than that of trade work, and the cost of demolition of unsatisfactory work is minimal compared to building construction. The problem with the method is that it does not reflect the problem-solving, non-linear nature of software development projects.
The fact is, that in these types of project where the product is subject to "look and feel", few people can express their "requirements" in definitive terms. There are just too many variables. The only approach is to do a mock-up (an early iteration, in software terms) and try it out on the stakeholder-customers and get their feed back. This process may well take several rounds or iterations as the product continues to advance towards the final version.
Some suggest that this approach is necessary because management of these types of project have not yet reached "maturity" in the industry. That may be true to some extent, but come to think of it, how does a building architect satisfy his or her client's needs? By drawing several "artists renderings" of
building alternatives, as well as key functional areas within the building.
How does a developer decide on the décor and furnishing of hotel room suites?
By assembling a "show" room for approval. How do car manufacturers determine the acceptability of new models during development? By building a full-scale mock-up and, subsequently, a prototype. So the idea of "iterations" is far from new, although the number and frequency might be.
Is it more costly? Compared to the once-through-only approach, most likely. However, consider the difficulty of really collecting those original requirements, and then consider the risk of failure as a result of "requirements" that are subsequently discarded or, worse, misdirect the project by proving to be just plain wrong. From this perspective we suggest there is just no comparison.
According to Murray Cantor of Rational Software Corporation:
"The systems engineering approach is based on assumptions that do not apply very well to software development [because] systems engineering assumes the requirements are stable and the interfaces can be specified adequately before implementation.
"Systems engineering efforts are driven by formal documents that are developed by engineers and implemented by developers. The problem is that the documents are never correct. The systems engineers rely on their ability to make the document correct. They focus on creating specifications that, once approved, are adequate for determining the design of each subsystem. Any change to the document is managed by a cumbersome change control-board system."
Cantor goes on to say:
"Using the systems engineering approach, subsystems are developed to completion, and then they are integrated at the end of the project. Modern software development calls for ongoing integration of the partially completed subsystems throughout the implementation phase. This ongoing integration accommodates change better and provides a method for managing project risk."
All of which just goes to show that maybe it's time we began to learn from the software industry. Maybe we should start rethinking our systems approach to project management and start presenting a better methodology.
|
