Each time I publish one of these articles, I get a flurry of e-mail from folks who agree with my position, disagree with my position, or want to share a horror story of their own related to the topics or experiences. Historically, one of the first e-mails that I get is from a close friend Raj. Raj's feedback usually taken the form, "I really liked what you said, but I thought you were going to take the article in this direction..."
When I approached Raj about co-authoring an article, I piqued his interest by telling him that I would write the opening and set up the situation, but allow him to take it in whatever direction he felt appropriate.
The reason I mention this is that I want all my good friends (and any potential clients!) to know that I love to express myself over and over again to makes everyone life easy & more organized so that we could achieve the similar things more effectively & efficiently. So keep it up & I am happy to receive any comments / suggestions. So I'd suggest that you kick your shoes off, pour yourself a nice cup of tea or coffee and enjoy this article.
In many parts of the colder countries, the winter months provide inhospitable conditions for running outdoors, so the majority of runners begrudgingly rely on treadmills to rack up miles. Being a consultant who spends 90% of his time traveling on business, most of my treadmill miles are accumulated in hotel exercise rooms. Typically these facilities are sparsely equipped, have inadequate air conditioning, and provide a television that always seems to be stuck on the Home Shopping Network. The only good news is that you usually have the room to yourself – except when the “January Effect” kicks in.
At the beginning of each new year, hotel exercise rooms enjoy renewed popularity. Wearing their brand new Gortex running suits, the New Year’s resolution crowd tries to look buff as they plod along on treadmills while reading their newspapers. The only part of this ritual that I truly enjoy is when the programmed cool-down period starts and the treadmill actually speeds up. Two or three weeks later, the January Effect ends as abruptly as it started, and I once again have ample treadmill access.
Many software development organizations exhibit these types of January Effect behaviors in their quality improvement initiatives, believe me this is very true, although they’re more aptly named “Quality Infatuation Cycles,” (we can call them "QUICs") . Last year they tried TQM, but that didn’t work; two years ago QFD turned out to be a big disappointment and some even remember the failed attempt to implement Quality Circles several years back – what a joke that was! This year, they’ll try “doing CMMI” and after seeing how flawed that is, they’ll try the Aglie or the Empowerment Initiative for Enabling Improvement in Organizations – any similar approach.
And how do organizational personnel respond to QUIC cures? A few exhibit passionate advocacy – they are the “Done QUICotes” of the current quality crusade. Most others elect to sit on the sidelines and enjoy the infatuation while it lasts. Just as I am amused when the treadmill speeds up during the cool-down period, they derive perverse pleasure from watching spring romance inevitably turn to summer boredom. Finally, a vocal minority relish in the pleasure of superior ITYS wisdom (I Told You So). Most organizations have tried so many QUIC cures that personnel are sick of acronym alphabet soup.
As a youth, I loved alphabet soup with a passion - not only was it good to eat, but it was fun to play with. I liked eating alphabet soup so much that I kept eating more and more of it, sometimes twice and three times a day. Then one day, as I raised the spoon to my mouth, I found myself nauseated by the smell, and I've never eaten alphabet soup again. Just as I lost my passion for alphabet soup through overdose, groups on the QUIC path to improvement eventually give up on all the quality B.S. (“Bullets of Silver”).
Whether starting a quality initiative or an exercise program, the secrets to early success are realistic expectations, gradual buildup of capability, and perseverance. Don’t overstuff everybody with the nutritional promises of alphabet soup, but prepare them for a few false starts, a few setbacks, and even a few injuries along the way. Runners have the motto, “No pain, no gain,” reflecting the realization that even minor improvement takes hard work. If an organization is not going to exhibit stick-to-itiveness, they may be well advised not to even start down the improvement path. Rather than raising, then dashing the hopes of the afflicted, those contemplating yet another QUIC solution may be better off following the anti-runners’ motto, “No pain - no pain!”
Let's move a bit on the management side of the story & try to understand view point of the subordinates & learn what should be the report contain .
If a tree falls in a forest, but no one is there to hear it, did it make a noise? If management tells you to do something, but never asks anything about it, did they really care? What questions are asked by YOUR management team and, more importantly, how are those questions interpreted by the troops? Ponder these questions as you read this article further , "Do Ask Different Questions."
My wife used to work at well know college as a manager on the administrative Staff. In one position, her responsibilities included generating the agenda for, participating in, and distributing the minutes from the top bosses (then- executive body etc) staff meetings. One of her biggest regrets is that she started in that position a few months after the management changes. If only she would have been there during that period, the book would be written, Oprah would have endorsed it, and we would have retired rich! But I digress…
Being a freshly-minted MBA sitting in a board room, she was constantly amazed at the power of the executive questions. If, while discussing international truck sales, seniors happened to ponder, “I wonder how many 4x4s jeeps sold in south Africa in 1993?”, she would inevitably detect some Executive Vice President jotting a note and subsequently assigning a Harvard MBA to conduct two weeks of research that was then packaged into a colorful, chart-filled report for the Chairman. She was equally confident that the particular boss didn’t have a clue why he received this particular report or what he was supposed to do with it.
The point I am trying to make here is, employees exhibit bizarre behavior in an attempt to please executives – or at least to stay out from under the microscope of executive scrutiny. When presented with data that, on average, projects were spending about 50% of their time testing and fixing, an executive asked if it would be possible to reduce it to 35% by the end of the next quarter. The challenge successfully motivated the organization to change its behavior and accomplish the objective – not by changing how much time they spent testing and fixing the software, but by changing how much time they reported that they spent testing and fixing the software.
“Executive questions” provide insight into organizational priorities. It’s nice that the Process Improvement Sponsor asks process-related questions in the monthly Steering Committee meeting, but what kinds of questions is the senior management team asking in project reviews. Some still growl things like:
“Whose fault is it that the project’s behind schedule?”
“Who do I chew out/demote/fire to fix these problems?”
“Given the state of the project, why didn’t I see many cars here on Saturday?”
Although these questions may reflect senior management’s REAL concerns, the executives need to start asking questions that reflect their new and improved process-oriented view of the world. The kinds of questions that senior management should ask are things like:
“How could the process be changed to avoid these problems in the future?”
“How can issues like this be identified when they’re still just risks, and subsequently mitigated?”
“How do we communicate the painful lessons identified on this project to benefit others?”
Admittedly, when faced with a crisis, senior management must act decisively to contain the situation. After all, when a man is drowning, it’s no time to teach him to swim. But once the man is safely on the beach, rather than chastising his stupidity, it is usually more beneficial to explore how a similar situation might be avoided in the future – and then discuss how the efficiency of the rescue operation might be improved.
Bottom line: senior management influences behavior based on the questions they ask. Furthermore, they change behavior when they insist on getting the answers. The executive question is a powerful tool that can be used to send a strong signal that expectations are changing…or it can be wasted getting answers like 257, right ? do ponder on this especially all Sr. Managers.
Do Separate Process Documentation from Procedures
Early in the life of a new project, systems analysts are often frustrated when customers mix business requirements and implementation detail. “Tell me what the requirements are, not how to implement them” is the oft-heard chant that reflects the analysts’ frustration. “Why can’t customers ever distinguish between what’s and how’s?” is the accompanying mental lament.
A similar comment would probably be heard about the EPG if the software personnel ever took the multi-volume set of process documentation off the shelf and tried to use it. Last month I suggested that you extract the training components from your process documentation; this month I’m suggesting that you further de-bulk it by extracting the procedural components as well.
Similar to business requirements, process focuses on what you are expected to do. Analogous to implementation detail, procedures describe how you are expected to do it. This distinction is often blurred because documented processes and procedures typically include many of the same elements: purpose, roles, inputs, entry criteria, activities/steps, outputs, exit criteria, etc. The real difference between processes and procedures is found in the “degrees of freedom” provided by the documented component.
For example, let’s start with a basic common element a Work Product Review process may have the following activities:
1.Prepare for the Review.
2.Conduct the Review Meeting.
3.Address the Defects and Issues.
4.Verify Defect and Issue Closure.
The tasks associated with “Prepare for the Review” activity may be:
1.Verify that the work product is ready.
2.Select the review team.
3.Assign review roles.
4.Plan the meeting logistics.
5.Invite the review members to participate.
6.Pre-publish the work product.
Note the lack of “implementation detail.” There is no indication of how these steps should be performed. For example, the work product could be pre-published by attaching it to an e-mail, by sending it out via company mail, by walking around and dumping it on each person’s chair, etc. Most likely, this process step does not warrant procedure-level instruction; process-level guidance should be sufficient.
So why am I splitting my last few hairs about the differences between process and procedures anyway?
OK, here’s the punch line - CMMI maturity level 3 is all about establishing organizational consistency at the process level, not at the procedure level. What a maturity level 3 organization does on each project should be consistent; how various projects execute these process steps may be vastly different. By co-mingling processes and procedures, many EPGs encounter enormous resistance because they over-constrain their projects, sub-optimize project performance, and make maturity level 3 a lot harder to achieve than it needs to be.
So what do you do? Well, if you’re just setting out on your process improvement journey, avoid this trap from the outset by segregating training, procedural, and process components. However, if your shelves are already bulging with a complex blend of these three ingredients, “decomplexification” is probably warranted. It may be painful to untangle this jumbled web, but it’s probably a heck of lot less painful than trying to achieve maturity level 3 by telling people how to do things rather than what things need to be done.
