This blogpost is a continuation of my previous blogpost “project management is an #BPM application” (see http://improving-bpm-systems.blogspot.ch/2014/01/is-project-management-bpm-application.html ) and it outlines the use of various coordination techniques (found in BPM) in the portfolio and project management.
Recently, I have updated my list of coordination techniques in #BPM ( see http://improving-bpm-systems.blogspot.com/2014/03/coordination-techniques-in-bpm.html ). One, fundamentally new, technique was added – cascade – in three forms: decomposition cascade, assembling cascade and combined cascade.
Decomposition cascade
Decomposition cascade is a dynamic decomposition of something “big and complex” into “smaller and simpler” components. Such decomposition is often recursive. Typical examples are modelling of business processes ( http://improving-bpm-systems.blogspot.com/2013/07/bpm-for-business-analysist-modelling.html ), architecting of systems, designing of solutions. It is not possible to present decomposition cascade as a “normal” process templates because new business activities are created depending on results of previously completed activities. For a decomposition cascade, its total duration and planning of resource allocation are barely predictable.
Another example of the decomposition cascade is the planning of an action chain “strategy directions-> business initiatives -> business capabilities -> technical capabilities -> portfolios -> projects” (See “IT Strategy” blogpost -- http://improving-bpm-systems.blogspot.ch/2013/04/enterprise-patterns-strategy-to.html ). Note that such a decomposition cascade is not a strict hierarchy, but a directed graph or even a “forest”. A few strategical directions will be implemented in many projects and some projects may contribute into more than one strategical direction.
In the nature, decomposition cascades are lightening, particle decays, etc.
Assembling cascade
Assembling cascade is opposite to decomposition one. The former is the construction of something “big and complex” from “smaller and simpler” components. Typical examples are building of a bridge, assembling a piece of furniture, implementing changes, cooking a meal, etc. Although assembling cascade can be presented as a “normal” process template (with duration and roles for each activity) such a template is very simple and unconditional – only activities and parallel gateways. For this reason, a simpler notation – Gantt diagram – is very popular. For the assembling cascade, its total run-time and planning of resource allocation are strongly predictable.
Another example of the assembling cascade is a typical result chain “output -> outcome -> impact” – many small outputs contribute into a few big impacts. It can be depicted as “value and essences basin” (see the last illustration in http://improving-bpm-systems.blogspot.ch/2011/02/explaining-ea-business-architecture_19.html ). Another presentation is Ishihara or fishbone diagram (http://en.wikipedia.org/wiki/Ishikawa_diagram) which is a pure hierarchical and can be considered as goal-based coordination as well. Yet another presentation is “result-based logical framework" ( see http://improving-bpm-systems.blogspot.ch/2013/03/result-based-logical-framework.html ).
Civil construction projects as example of the combined cascade
In typical civil construction projects, decomposition and assembling cascades co-exist, but explicitly separated. Any civil construction has three major phases –
a) Architecting to produce a blueprint for producing components (or construction blocks) and to build a house, a bridge, etc.
b) Provisioning (by producing or procuring) all construction blocks in accordance with the blueprint.
c) Building to construct an object in accordance with the blueprint.
In these phases, “building” and “provisioning” are the assembling cascade and “architecting” is the decomposition cascade.
Because of the potential conflict of interest, laws in some countries regulate that architecting and building must be done by different legal entities. Building may expose some problems with architecture and architecture must oversight the building.
Note that the blueprint does not specify particular dates and particular people for building and provisioning – the blueprint just indicate approximate duration and required skills/resources for each activity.
At one moment (usually before phases b and c), the blueprint must be converted into an actual plan by assigning concrete dates and concrete people to each activity (of course, depending on the availability of resources). This is usually done by a foreman from a building company ( see http://improving-bpm-systems.blogspot.ch/2013/06/entarch-basics-in-for-dummies-style.html ). Also, any actual plan is not fixed forever and it must be adapted depending on the progress during its execution.
The mentioned above three phases maybe grouped in three major variants.
- The client chooses a prefabricated house that should be just built.
- The client chooses a standard model house that should be provided and built.
- The client chooses a custom-design house that should be architected, provided and built.
Typical use of various cascades in IT projects
Majority of IT projects are similar to the variant #3 mentioned above, but they often have the implicit mixture of decomposition and assembling cascades. As the result, initial planning is very approximate. Below, there are different combinations of decomposition and assembling cascades.
Classic project management (e.g. waterfall) – decomposition cascade (shown as a particle decay) and assembling cascades (shown as a Gantt diagram) are carried out sequentially.
Agile project management – many almost independent pairs of decomposition cascade and assembling cascades. These pairs are shown together as SCRUM’s sprints because the use of decomposition cascade is very implicit. Up-front architecting was, even, replaced by an idea of ”emerging” architecture. I think, this world is lucky not having “emerging” architecture in cars and planes.
Architecture-based agile project management (archibagile?) – decomposition cascade for architecting during the (almost) whole project and, in parallel, assembling cascades are initiated for brunches in the decomposition cascade which are ready for “provisioing” and “building”. Typical use – platform-based architecture cases ( see – http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html and http://improving-bpm-systems.blogspot.ch/search/label/PEAS ). Note that the project (or solution) architect is responsible for overall technical coordination and the project manager is responsible for administrative coordination. Who is “more” important? All depends, as usual. Any technical modifications must be approved by a solution architect.
Complex cases
Archibagile is implicitly used for country- and continent-wide development programs. Such programs define desired impact (end of the result-chain), sectors or regions or countries develop their strategy papers (top-level-architecture) and many projects to be defined (middle-level-architecture) and initiated (when the funds are available). Each project must come up with its clear projects plan (decomposition cascade) and its contribution into the result chain (assembling cascade).
Typically, sectors or regions or countries strategy papers is revised after several projects contributing into those strategies. Thus, there are three types of governance activities:
- Program monitoring
- Strategies evolution (finishing of projects, emerging events, etc.)
- Project management
- Post-project evaluation (to evaluate its results in accordance with the result-chain)
How does archibagile affect project procurement?
With archibagile, project procurement looks slightly different from the classic one. For example, a company wants to add a video conferencing system to its communication (with local offices) environment. Instead of running an open bid for any video conferencing system, archbagile instructs the procurement office to run an open bid for services to provide an installation of a video system which is fully compatible and easy integratable with the existing environment. (Sure that enterprise architecture guides solution architects see http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-patterns-ear.html )
Thanks,
AS
Posts
No comments:
Post a Comment