OUM is Flexible and Scalable
- by user535886
Flexible and Scalable
Traditionally,
projects have been focused on satisfying the contents of a requirements
document or rigorously conforming to an existing set of work products. Often,
especially where iterative and incremental techniques have not been employed,
these requirements may be inaccurate, the previous deliverables may be flawed,
or the business needs may have changed since the start of the project. Fitness for business purpose, derived from the Dynamic Systems
Development Method (DSDM) framework, refers to the focus of delivering
necessary functionality within a required timebox. The solution can be more
rigorously engineered later, if such an approach is acceptable. Our collective
experience shows that applying fit-for-purpose criteria, rather than tight
adherence to requirements specifications, results in an information system that
more closely meets the needs of the business.
In
OUM, this principle is extended to refer to the execution of the method
processes themselves. Project managers and practitioners are encouraged to
scale OUM to be fit-for-purpose for a given situation. It is rarely appropriate
to execute every activity within OUM. OUM provides guidance for determining
the core set of
activities to be executed, the level of detail targeted in
those activities and their associated tasks, and the frequency and type of end
user deliverables. The project workplan should be developed from this core. The
plan should then be scaled up, rather than tailored down, to the level of
discipline appropriate to the identified risks and requirements. Even at the
task level, models and work products should be completed only to the level of
detail required for them to be fit-for-purpose within
the current iteration or, at the project level, to suit the business needs of
the enterprise and to meet the contractual obligations that govern the project.
OUM
provides well defined templates for many of its tasks. Use of these templates
is optional as determined by the context of the project. Work products can
easily be a model in a repository, a prototype, a checklist, a set of
application code, or, in situations where a high degree of agility is
warranted, simply the tacit knowledge contained in the brain of an analyst or
practitioner. For further reading on agility, see Balancing Agility and Discipline: A guide fro the Perplexed.
