One of my art teachers regularly commented that making the first brush mark on an empty canvas should not be rushed and that it requires consideration as it will form the foundational reference for any subsequent brush marks. Analogous to this is where to place the first process symbol on the empty ‘process canvas’. Some start with all the stakeholders in a room and after a number of iterations (and some heated arguments), believe they have found the common ground and proceed from there with the process development effort. After a lot of effort and stakeholder time spent on its development it is found that these processes are incomplete, do not fully address the particular business area and cross multiple capability boundaries.

However, starting with an empty ‘process canvas’ is not as daunting as it sounds. Simply use a Capability model to determine where to place the first process symbol. It is advisable to follow a few basic principles when developing a Capability model. Some of the principles are:

A capability should be defined only once (e.g. Project Management should exist only once in the model).
It should not have any organisational structure bias.
It is independent of business processes, product offerings, and Information Technology assets.
A well-structured and stratified Capability model provides the scope, context and high level content required for business process development.
A recent example was for the development of Portfolio, Programme, and Project management processes for a major power utility in Africa. By developing the Portfolio Capability model upfront (prior to the definition of processes) a clear scope can be created that can form the ‘hanger’ for the subsequent business processes workshops. Although usually focussed enterprise wide, a Capability model can be made specific to a particular capability area and include various best practice principles and components (in this case PMBOK, PRINCE2, etc.). Now that a solid foundation has been created the development of the business processes can begin. Spending some time upfront in defining the scope certainly has its benefits and a lot less effort and time is spent in subsequent workshops trying to get all participants to agree.

The processes developed from these well-defined foundational capabilities have a number of other benefits:

  • It provides structure to the workshop participants and avoids the usual arguments over scope.
  • They are singular in nature in that they only refer to the specific capability and there is a clear boundary or separation from other capabilities in the same domain and other domain processes.
  • Re-useability of business processes leading to an agile business that can adapt to changing market conditions.
  • The importance of establishing a solid foundational Capability model is the core for any further architecture model development and should not be understated. By following such a recipe of first developing the Capability model (the hanger for the business processes) one can reduce process development effort by as much as 50%.

Author
Johan Hall