The Community Blog for Business Analysts

Mike Cunningham
Mike Cunningham

Upside down Procedures and Processes


Are we looking at it all wrong?

Do you ever get the feeling that you are seeing something very different than the other guy? I don’t just mean the glass half full/empty outlook on life, but fundamentally are we looking at things the wrong way?
I sometimes get that feeling when dealing with projects that involve processes, and all my projects are about processes! Take the following scenario, the stakeholder or client has a problem; they know they need to improve some processes in the organization, but are not sure exactly where to begin.
As the designated Agent of Change we provide them with guidance to determine goals and objectives to scope out the next steps. For example:
·         Need to document existing processes accurately
·         Train existing staff how to follow these processes
·         Be able to standardize the process for quality and efficiency
Before I continue, let’s go back in time …
Back to the Future

In 1770, James Watt pioneered the use of drawn-to-scale engineering plans for the manufacture and installation of industrial products1[. These were used to assist in the successful deployment of his products; steam engines for factories driving the industrial revolution. Over time these plans evolved from crude drawings to assist an experienced engineer to more detailed plans that were created by a junior draftsman. This was the forerunner of today’s Computer Aided Design]2[ world. Detailed, precise instructions permitted products to be manufactured without the need for hugely skilled labor, and a bridge was created between design and production engineering.
In many ways the Subject Matter Expert/Project Manager takes the same role today as those early engineers. Understanding in detail what needs to be done, and translating these complex processes by way of underlying skills, experience and well established methodologies.
The time may be right to go back and look at a different way of doing things; one that may change industry again.
Looking at the pie instead of the ingredients?

When an expert looks at a problem they often want to show off their skills. Look at me I am smart, indispensible, letters after my name, better than you … got the idea. Now all project managers are not this way, but there is a tendency to want to show off our skills versus others in the project.
One way this happens is we often/always start looking at process FIRST. Because we are good at seeing the big picture, grasping the complex, overanalyzing the simple; so we habitually start with the complete process.
As a result we are often way ahead of where the client/stakeholder is in the project. Being ahead a few steps is probably OK; being so far ahead they can’t see your dust creates distance, misunderstanding and communication problems. They may not feel that you are on the same wavelength, and we all know where that leads. We don’t want to go there.
Start with the tasks, not the process.

Recently, I have been examining this problem with some precision. I know Business Process Management has the word process in the middle, and is therefore important. However, every process is full of tasks, activities and decisions. The client/stakeholder may not yet see how all these tasks are intertwined to make up their own work processes, but they understand the basis of all processes are tasks. So why don’t we start by capturing the tasks first? Good idea!
A task centric approach has several advantages over process first. These include:
1.       It’s easier to get the client/stakeholder to capture precise information about roles, ownership, guidelines, resources, timeframes, frequency etc. on a task basis
2.       Once you have all the important tasks documented it’s easier to then order them for the “as is” or “current state” of operations
3.       Get everyone on the same page for the process documentation project
4.       Builds a base of foundation data for the project
Once this task library has been created, we can return to the process view. However now we have the details we need to build on our “Discovery” phase of the project. If you have used Excel or a similar product to capture this information, it will be easily sorted and can be then categorized for the process capture stage of the project.
Conclusions

Just as we learn the alphabet, words, sentences, grammar before creating great prose; we need to apply the same principles to our Process Management activities. Taking logical steps to breakdown the “Discovery” process into tasks and then build the jigsaw puzzle that is the process makes sense.
Given the potential for re-use of tasks in best practice models, this approach may have much merit in Process Improvement methods.
 
Copyright 2011 Michael J. Cunningham


]1[ NMSI. The Production Process. May 20, 2011. http://www.ingenious.org.uk/Read/Seeing/Drawings/Theproductionprocess/.
 
]2[ Wikipedia. Computer-aided Design. May 20, 2011. http://en.wikipedia.org/wiki/Computer-aided_design.
]
This entry was published on Jul 27, 2011 / Mike Cunningham. Posted in Project Management, Business Analysis, Leadership & Management, Getting Started as a Business Systems Analyst, Technical Topics. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  31 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

 




Copyright 2006-2024 by Modern Analyst Media LLC