Simple and Effective Process Tool

This month’s post is about a simple, effective, and often overlooked process mapping technique tool called the Trans Interaction Diagram also called a sequence diagram.  I have been using these diagrams for more than ten years with great success, especially when there is a software development element to the process improvement project.  Trans interaction diagrams are great facilitation tools and they can pack a ton of useful information into a simple to understand document.  Trans-interaction diagrams are rarely taught in Lean Six Sigma classes which is a shame.  I teach all Black Belts that I mentor how to use the trans-interaction diagram and without fail, they find it to be a useful tool in Defining, Analyzing, Designing, and validating improved processes.  Trans-interaction diagrams are particularly useful in documenting structure document centric processes and structured projects.  I believe anytime software is being developed to take an organization paperless or to automate a document/project flow with a finite number of statuses the item can enter and exit, the trans interaction diagram should be used.

Trans-interaction diagrams are made of a series of vertical bars that represent the “states” in which a document or project can reside.  For example: draft, technical review, legal review, financial review, pricing, clarifications, cancelled, approved, archived.  These are all answers to the question “What is the status of the document? (e.g., application, proposal, order)”.  The vertical bars are connected by transition arrows that indicate the paths the documents can follow from one state to another.  Below each state, you can pack in loads of information relevant to software developers, policy writers, and managers.  You can include information such as who has read and write access at each state; the owner; time metrics; system actions; decision criteria; and rules.  A simple example of the trans interaction diagram for a generic paperless document system is shown below.

 

You can easily see how the trans-interaction diagram communicates a wealth of information about the document or project.  Personnel in your organization should be able to answer the basic questions answered by the trans interaction diagram, such as what is the status of my request?  What happens next? How long does it take? Who can help me?

The trans-interaction diagram is also a great way to facilitate people in your organization toward consensus on how things should be processed and what rules should exist in the processing.  By asking people what can happen next who can do it, why, and so forth, staff can quickly see the paths documents can take as well as the impact of not doing things right the first time.

If it is decided to automate your process using a COTS system such as SharePoint, a BPM tool, or custom software, developers can get a great start on understanding what you want as your final product through review of the trans interaction diagram and you can use the trans interaction diagram as a QC tool to ensure the developers created the software as specified.

I hope you find this tool helpful for improving your business processes.  For more information or support in using this tool, send me an email at gsieber@msi6.com.

Using Lean Practices in IT, Big Savings and Performance Improvement

It has been a busy 2012 for everyone, It seems everyone I know is like me, working harder than ever, hoping the economy picks up and that our Government gets budgeting and contracting plans set and in motion.  While weathering the current economic storm, I had the opportunity to work with a client in the first quarter of this year in one of my favorite environments – IT.  I have found myself in various IT positions and consulting roles throughout my career, picking up technical skills as well as experience with ITIL, CMMi, and various development methodologies.  I have in many cases applied Lean and Six Sigma in conjunction with IT best practices to help organizations improve performance and save money.  Recently, I helped an organization shave millions in annual operating costs while significantly improving performance by applying agile work cells and leveraging a few simple Lean techniques such as one-piece-flow.  This article summarizes three methods nearly any IT support organization can use to drastically cut costs and improve performance.  Given the current economic and budget environment, this may be a timely read for some of our followers.

******

A graduate school professor assigns a software development final class project to teams of five students each.  All students on each five person team will receive the same grade and it accounts for 50% of the final grade for the class.  Team 1 (Sally, Jack, Dan, Tom, and Ken) and Team 2 (Bill, Dave, Will, Cindy, and Beth) take two different approaches to tackling the project. Team one assigns requirements to Sally, Design to jack, Development to Dan, testing to Tom, and presentation of the product to Ken.  Each person will perform their respective part of the project and then hand their work to the next until all work is complete and the final product is handed off to Ken who will present the final product to the professor and his assistant and the grade for the project will be determined.

Team Two decides that they will tackle each task from requirements through final presentation together, but take turns as the task leader based on the strengths of each team member.  The members of team two do not completely trust each other and want to make sure the project progresses on schedule and with high quality since it can cause them to fail the class if done poorly.  They also want to make sure they are all at the presentation to the professor just in case something goes wrong.

Which team would you want to be on? On team one, you know your part of the work, you can focus on your piece and the roles and responsibilities are clear.  On team two, the roles and responsibilities are blurred and everyone on the team will be pounding away the entire time to create the best product possible.  Anyone that has been to graduate school knows that almost without exception, students inherently adopt the collaborative approach of Team Two.  Why do these young minds, yet to be trained by corporate master-minds and molded by policy, politics, bureaucracy, and standardization take this collaborative approach almost every time.  It is because they still have “common sense” and they feel a true sense of urgency and commitment to excellence.  They know their future is on the line with each major project.  They also know that the deadline cannot be changed, resources are constrained, and quality cannot be sacrificed.  Common sense brings them together into what Lean experts call a work cell and software professionals call a Scrum team using an agile approach.

Is this really the best approach?  Many managers will say “this approach is a waste of labor.” “By taking team one’s serial approach they can have multiple projects underway, or Work In Process (WIP) with the same labor pool, while the team two approach limits me to one project at a time with the same resources.”  This is a logical pitfall.  Managers should focus on level of effort in value adding activities and throughput while minimizing WIP.  The Team Two approach on the other hand ensures a “connection” among tasks and essentially eliminates rework within the process.  It also eliminates work waiting in queues and mitigates risks associated with single points of failure in your labor pool.

Lean/Operations Research people call this one-piece-flow in a cellular work cell system.  This article is not a lesson in Lean.  It is a message that assembly line type of thinking is simply wrong in diverse IT environments as proven by the many successful Lean/Agile Scrum implementations.  Yet, this thinking is still prevalent and still the dominant approach to tackling IT projects in most organizations.

I have worked with numerous IT organizations from the largest telecommunications companies to start-up software companies and internal IT shops and can tell you with certainty, that a serial assembly line approach is almost always the wrong way to complete IT projects.  I remember clearly how one of the telecommunications firms I worked with, rooted in old school Bell Corps thinking insisted on breaking the work of implementing new equipment at their Points of Presence (POPs) into a serial approach of power installation, rack installation, equipment installation, wiring, configuration, test, and turn-up.  They would go round-and-round trying to get vital services running with each step of the process pointing fingers at the other. Projects usually made their way to some ridiculous phone conference where the bosses of the various technical teams would accuse each other of various sins until someone higher up would finally tell them all to get their technicians to the site at the same time and don’t leave until the service is working.  In other words, they pulled together a collaborative work cell to get the job done.  The technical leads would declare victory after working nights and weekends to get the service running. This scenario would play out over and over, but the process never changed. That was well over a decade ago and I would like to believe things have changed, but from what I hear, they are only a little better.

To avoid these same inefficiencies, to improve quality, and to drastically cut costs there are three simple methods we recommend.  We call this the “Lean Agile Work Cell Approach”.

  1. Align your IT work force to customer value propositions (a.k.a. value streams)
  2. Implement a Lean centric, pull based cellular work cell approach.
  3. Adopt a unified process automation environment

Aligning your work force to customer value propositions is actually very simple.  Think in terms of the services your IT organization provides to the end customer.  For example, enterprise software projects and support, desk applications and support, and printer support.  You can also think in terms of Service Oriented Architecture (SOA).  You need to understand the Voice of the Customer (VOC) for each line of value.  You need to quantify the key metrics for satisfaction, performance, cost, etc.  You then need to align your teams and processes to these value propositions and measure everyone in them against the key metrics.

Agile work cells aligned to the customer value proposition

Creating pulled based cellular work cells is partially explained above.  As an example, consider the process of deploying new desk top operating systems in your enterprise.  If this process is done in a serial process, disconnected from the customer, you get a situation in which technical details and requirements are gathered for months, then handed off the a integrator that has to figure out the requirements and then develop integration scripts, which are then handed off to a testing team who will then get into a series of re-work loops with the integrator and after many months of testing, the operating system push will be sent to some type of distribution team that will then blindly launch the distribution process.  Alternatively, a series of small work cells containing integrators, testers, distributors, and customer technical liaisons can work together on a focused integrated project team to integrate, test, and deploy operating systems in a rapid order.  By testing at an incremental level and developing deployment scripts with an eye for testing and distribution at the same time, cycle time is significantly reduced and defects essentially eliminated.  This approach also allows for the operating system deployment team to learn from each iteration and get better with each operating system project from customer to customer.  In my firm, we have implemented similar work cells in various organizations with profound improvements in both effectiveness and efficiency.

Lastly, adopting a unified process automation platform is a powerful way to significantly reduce your IT license costs, maintenance costs, and software support costs while improving process performance.  For the last ten years, these tools have been called Business Process Management (BPM) and for the organizations that have adopted them and implemented well, great savings, process improvement, and transparency have been recognized.  The process automation environment becomes a process centric integrated development environment eliminating the need for custom software development, institutionalizing processes, but raising the need for proper IT Governance and enterprise architecture.  Today, process automation tools are available in cloud computing platforms and costs are falling precipitously.

In summary, the Lean Agile Work Cell approach to information system management creates agile work cells working in alignment with customer needs that are developing new software and managing their own work within a common process automation/development environment.  This is bad news for custom software development shops and great news for the CIO with a shrinking budget and pressure to show results.

<span>%d</span> bloggers like this: