Most organizations have a major blind-spot when it comes to definition; they either try to bypass it or they get stuck in it. Why is this and how can project architecture help? The early part of a project, before it even becomes a project, is characterized by ambiguity, misalignment, vague assertions, multiple variables, and circular discussions that always seem to dead-end in the same familiar places. Technically oriented people find this state of affairs appalling, and often jump to design and implementation, only to suffer an 'ambiguity ambush' later in the project when it can be fatal.
We use a little architecture and a lot of facilitation to tame this ambiguity, straighten the circular talk, and cut down the number of variables in a project.
When we provide a plan for the definition stage of a project, people often extrapolate that X amount of definition will drive Y amount of design, which will in turn generate Z amount of delivery cost. Unfortunately, in our commodity-driven world, the completely passive and detail-oriented approach that is often used in the definition stage can actually allow this to happen. Our definition approach is highly pro-active, focused on clarity, rather than detail, and we find the opposite relationship between definition, design, and delivery. For a given scope (the scope that turns out to be truly necessary in the end) design and delivery cost goes down as the definition output goes up. Definition should identify ideas, requirements, and suggested features that are not true priorities, and challenge the designers to design to a cost objective, rather than just asking everyone what they want and blindly building it. We use a set of prioritization and scope control sessions to accomplish this and we always look for incremental design and delivery opportunities that accelerate the realization of value.
Our approach is not for the timid; we believe that a well informed decision to cancel or delay a project is a completely valid outcome of proactive definition.