Enterprise Integration & IT Strategy bloggers
Ashu Bhatia (21)
Gregg Powers (3)
Mark Benedict (1)
Tom Finneran (5)
Tom Marrs (1)
Enterprise Integration & IT Strategy blog archives
March 2009 (1)
April 2009 (3)
May 2009 (4)
June 2009 (5)
July 2009 (5)
August 2009 (3)
September 2009 (3)
October 2009 (1)
December 2009 (1)
January 2010 (1)
February 2010 (1)
April 2010 (1)
May 2010 (3)
June 2010 (1)
become a CIBER practical innovator
We are always seeking talented and innovative people. We have IT careers open all around the globe.
Practical Process Improvement
Mark Benedict, Director of Quality Assurance and Testing Services : 06 May 2010 / 11:57 AM : 3 
Process Improvements are routinely needed everywhere in the IT and IS worlds. But no matter what the process is that needs improvement, the technology that needs to evolve or the new methods people need to use the overarching story is the same: We need to do this, but we just don't have time to do it. We're too busy working.
Even in organizations that have it all figured out, it comes down to this one last thing. Making the change. And that's where the worst resistance in any organization hits your best intentions with a sucker punch.
Recently I've gotten calls from several organizations that have done all the right things from Root-Cause Analysis with all the right people and points-of-view involved, realistic process re-engineering, the creation of new roles, templates and checklists, and have even held mandatory training sessions. But nobody is using the new methods! When they leave the special sessions and go back to work, everybody just does what they've always done and cause the same problems they've always had.
Remember: It's not an improvement if it doesn't make things better.
Process Improvements that become shelfware are pointless. To get put into use, the improvements really do have to be practical. And they have to be implemented in a down to earth way.
The good news is that it's easier than you'd think.
Here's the 1-2 punch on how you put good improvements to use.
#1: It has to be made to be part of the job.
#2: It has to be enforced by leadership.
Let's take a closer look at what that means.
#1: It has to be made to be part of the job. That means it is necessary. That you couldn't do your job right without it—otherwise, why would we be making this 'improvement'? Not only does somebody say you have to do it, but they won't sign-off or accept your work if it is not evident that it was done the right way. And that proof should be evident in the accomplished work, or as a by-product of doing the work the right way. It is easy to spot when the wrong templates are being used. It is easy to see when the new pieces are missing, don't fit, don't function, or simply fail. It is easy to tell when it's wrong – so do something about it.
#2: It has to be enforced by leadership. Today's businesses don’t have an extra budget outside the funded projects, but each major stage of any project has its leads and the projects usually have a manager. These are the people who have to make sure their projects do the right thing. Quality is NOT something you can tack on at the end, but something that has to be designed-in and built-in from the beginning. The quality of the project is the responsibility of its leadership. Every lead has both the right and the responsibility to enforce standards and inspect results. Doing the right thing is not the responsibility of a separate department, it is not in a separate budget... it's in your hands. As a lead, as a craftsman, as a doer.
How to do it right. The first 5 to 8 minutes of EVERY meeting of EACH project is when the leadership of that project or lead of that stage needs to reinforce the change. It's as simple as this:
- Overview of where we are in the process/project (a simple drawing)
- Spotlight on the task at hand and how it is being changed NOW
- Emphasize what's different this time
- Hand your team the pieces they need to use now (tools, templates, checklists)
That simple drawing you start every meeting with is the key. It's visual, it makes it real, it’s the big "You Are Here" in all this confusing mess.
How do you know it's working? One of my colleagues and I were leading a major change effort at one of the big five telecom companies a while back, using the first five to eight minutes of every meeting to do the Overview >> Spotlight >> Emphasis >> Hands-on method to keep things moving along. One day we were participating in another project's meeting in a different capacity and there we saw one of the developers on one of our projects walk up to the whiteboard, draw our drawing and put the spotlight on what they were doing on that project.
That's how you know it's working. When other people use your methods. The most fun version of seeing this happen was when we went to an executive management meeting and somebody interrupted the host right at the beginning, saying, "We can’t have this meeting till somebody shows me a picture of where we're at in the process, and shows me what I need to be focusing on right now."
Posted in Enterprise Integration & IT Strategy on 06 May 2010
More by this author 
Tagged: Change Management Governance Risk and Compliance IT Planning IT Strategy Knowledge Management Lifecycle Controls Organizational Change Management Process Improvement Project Management Project Methodology Quality Assurance Quality Control Quality Management
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Comments
Tom Finneran : 06 May 2010
Could you send a sample diagram?Mark Benedict (author) : 06 May 2010
We were implementing several changes across the entire lifecycle and needed the usual way of doing things to be looked at and thought of in a whole new way. Consistent use of the same pictures help us do that.
This drawing makes Configuration Management “the hub” of the lifecycle with Change Control acting as “the wheel” and the lifecycle work products standing as “the Spokes.” (Yes, there were quite a few “Thus spake Zarathustra” jokes....)
The big things we were changing were
a) placing ALL lifecycle products under Configuration Management Control (not just code), such that any component changing in the lifecycle was traceable to versions (using classic CID+VID [Configuration Item ID + Version ID])
- note: EACH individual Requirement has a Version ID (NOT “some document”). That alone was a HUGE change.
b) using the CM Hub as a means of communicating changes as they happened
- CID+VID changes triggered auto-notifications to pre-planned distributions – including listing key items to be examined in the Quality Gates
c) Inserting Quality Gates between Lifecycle Phases (by applying T-Model reviews)
- These two examples show how T-Models “take one step to the left and two to the right” of the item under review/acceptance to determine who needs to be involved.
- Requirements under the T-Model review (EACH individual Requirement is reviewed [NOT a document])
i) Marketing is looking to see if the Requirements clearly and accurately represents their needs,
ii) Testers are trying to see if they could figure out how to test each Requirement, an
iii) Developers are trying to figure out if they could Design from that information (Requirement + Test Case). - Issues or Defects arising from a Model-T Review have to be addressed/closed within two Quality Gates
- T-Model Reviews are done virtually. (These are NOT 1980s Fagan Inspections, but an evolution from them.)
Interesting dynamics came out of this “Configuration Management as the hub” way of doing things, including Test Plans informing Design Changes (which ultimately led to a realization that Test-driven Development could actually be possible!) and that Production Methods & Procedures needed to have Test Cases associated with them. Which, of course, developed a two-way dynamic in that Production M&Ps were impacted by Code and that Code sometimes could not be allowed to impact Production-grade M&Ps no matter what somebody thought they wanted when they wrote the Requirements. And this method was used to draw the cognition back around the wheel and stopped it in the Design! Thus preventing Production Defects, because evolving underneath all this was that trace-ability of impacts. Eight times around this newly re-connected lifecycle populated the enterprise-wide Configuration Management Data Base (the CMDB). [If your familiar with ITIL and Governance Models, then you know why that’s important: it’s the knowledge base that let’s Governance manage change in an informed manner.]
As you can see there was a lot going on (like creating a CMDB), but by continuously reinforcing the big picture “you are here” Hub and Wheel we could get people doing things the new ways by letting them see day-by-day what in their jobs was changing, why we were doing it this way, how it was different, and what was expected.
So, in way, you could say that building a corporate CMDB does take reinventing the wheel.
Larry Crane : 11 May 2010
Thanks for including the diagram. It is very helpful. Good article.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Post a comment
