what I call the Bernard Rules of Architecture. The order is important:
the problem - as given/stated by the problen owner
the problem context and its constraints
- validate the
problem with what the problem owner wants to achieve - not always the
same as the problem
- develop one
or more candidate solutions
- assess the
solutions against the problem and its constraints
- revisit the
problem and determine if, by varing the problem, a more
optimum solution is possible
- agree the
problem and solution with the problem owner
- based upon
the solution, develop a set of requirements that defines the details of
- make sure
the PM implements the solution you have defined, not what they think
should be implemented.
- the solution defines project requirements, not the other way round.
- the combination of problem/solution is optimised, not just the
rules apply to a range of problem types, not just Information Technology.
- don't confuse a reduction in cost with an increase in efficiency.
Robertson-Dunn, 22 June 2010