Many large organizations lack process documentation.  But how do you solve the problem of too much documentation, and not enough organization?  We suggest implementing a Process Catalog.

Process awareness is growing across the company with which I am working and business units are focusing on process modeling and improvement efforts.  However, this work is typically initiated by mid-level managers and neither methods nor deliverables are standardized across the company.  I am working on a pilot program in a small business unit, approximately 7 departments and 50 people, to create a Process Catalog as an aid to their more detailed process modeling and improvement efforts.  This and subsequent articles will chronicle the experiences and learning as this effort progresses.   

It is common place to find managers of complex, high risk, and business critical processes, making operational decisions using data gathered and manipulated within a series of spread sheets that have grown organically over a period of time.

Technology is clearly not a pre-requisite in developing and maintaining good processes. However, when it is used, I believe that a BPMS should be the first choice for managing processes rather than spread sheets.

Limitations of Spread Sheets

Spread sheets were designed to support modelling and they are fantastic for this purpose. They were not intended to manage operational processes where the requirement is to track task assignment and completion versus targets (granted that many managers would disagree with this). They present a number of key challenges when they are used in this way, including:

Should we use flow charts, swim lanes, value stream mapping, proprietary software notation, or BPMN?  Yes, there a number of notations you could use, and you want to pick the right one for your organization.

The first question to ask is what is the purpose of the process diagramming notation?  Since there are several purposes for process diagramming at different stages of a BPM/ process improvement project, you may switch to one type of notation or another at different times.

Purpose 1:  A high level map to scope the project and as part of the charter.  Here I suggest using a simple flow chart with 6-10 steps using rectangle for activities/steps, diamond shaped decision diamonds and directional arrows.  You could actually create it in PowerPoint, but I usually do it in Visio.  The purpose of this map is to get people understanding what a process looks like. 

A high level process map is:

This article covers an issue within Business Process Management (BPM) redesign which is often not fully discussed. Frequently, development groups are eager to get the team fully engaged as quickly as possible. Looking at “as is” situations (examining, modeling) may receive slight attention as being “bygones” – “Let’s start with a clean slate.”  The issue is deciding how quickly to begin computerized development after a project or analysis has been scheduled. 

There are different aspects of business growth and development.  One faction may wish to apply technology to change its business as quickly as possible, while another may prefer to proceed cautiously and methodically, moving only after research and through using a well-tested methodology. Which is correct? The classic answer is “It depends.”

Except for natural disasters such as earthquakes, floods, or hurricanes, all risks are man-made.  This article is a synthesis of three past Harvard Business Review articles.  The bibliography is at the end of the piece.  Project Managers (PMs) usually have very little control of the risk circumstances in which they are placed. Taken together, viewing risk from the combined perspectives of the authors cited should help PMs assess risk in their own environments. Summarizing the titles as follows: “Right Risks,”  “Is it Real?” and “Hidden Traps” will help us consider the contribution of each, and then meld them into the PM’s decision process.

The Right Risks