This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.
For requirements to succeed, they must be clearly defined and enough time must be allocated to complete them. This is crucial to preventing team clashes and to creating a positive work environment. Writing the correct requirements and following them, is the key to producing a quality product. In this StickyMinds.com column (may require free registration), Becky Winant explains why properly assigning requirements is important to creating project deliverables. In the piece, she mentions three way in which "requirements become suspect.."
"We believe in miracles. Ever hear a story about how some genius sold his idea based on a napkin sketch? I think sometimes we expect our analysts to do the same. Hey, once the sketch is down, we're done! Time to hand the napkin over to production.
"We get carried away by sports analogies. In some organizations, the requirements stage feels like the warm-up before a game. We spend just enough time to loosen up, because we are saving time for the real work. So, requirements becomes all about establishing the customer relationship and maintaining a friendly mood.
"We believe in components. This is good, because once we really have requirements this could buy us time and produce reliable results. Without clear requirements, we risk assembling a van instead of the sedan that was requested. We heard "vehicle for the family," started thinking about which components to use, and went to work."
She goes on to provide some reasonable advice on the subject, which, to my mind, can be related to many kinds of projects, not just the software-centric ones to which the issue of "requirements" are usually considered.
That said, I want to add that I particularly resonate with Winant's third source of problems -- belief in components. The common use of a detailed WBS (work breakdown structure) is one way of trying to deal with it, but, as many of those involved in agile methodologies like to point out, a lot of those details are unknown and unknowable in the early days usually associated with planning. In addition, even if one could lay out a detailed WBS to define the project, its local, partial, component-focused nature can easily lead those assigned to work on the individual components to think and work within a too narrow range of focus. The hierarchical, "leggy" nature of a WBS makes it too easy to miss dependencies and opportunities across the legs, and therefore make project promises (as well as requirements) suspect.
This is why, in the Critical Chain community, if a WBS is used at all, it is only used to one or two layers of detail to define high level objectives, deliverables, and success criteria. The typical critical chain planning process quickly moves to the building of the project's dependency network, so that, even if details of how components are to be delivered are fuzzy, at least the required interactions between components can be defined. In this way, the project is understood not as a sum of components, but as a system of interdependencies supporting the project objectives.
posted by Frank - Permanent Link -
|
View Frank Patrick's profile
