December 24, 2009 § Leave a comment
Most organizations that start out on the road toward software process improvement (SPI) using the Capability Maturity Model (CMM) for Software have no clue what this endeavor means. Most managers get sold on the idea based on competitive practices within the industry—”keeping up with the Joneses.” This article discusses some common misconceptions about the torturous path to achieving a maturity level.
“What, me change? You’ve got to be kidding!”
Managers think the CMM focuses on changing the way the developers work. What happens is that the CMM forces management to change the way it manages projects. By requiring the development team to collect project data and report it to management, management becomes more aware of the project management process. In some organizations, managers do not want to know in detail what is really happening on their projects. The idea that someone would report to them actual schedule slippages and try to determine a standard deviation becomes incomprehensible. It is not uncommon to shoot the messenger.
What the CMM really provides is the ability to shape your own destiny. By generating procedures to do work, you control your work environment. If management understood that, they probably would not start CMM activities.
“We can’t do this. We have to support our users.”
It is amazing how often supporting the users is used as an excuse to not do CMM work. The CMM absolutely advocates supporting your users. That is why we are in this business. In case we have forgotten—no users, no work. Ultimately, by following CMM guidelines, supporting the user becomes easier because the ground rules have been established.
Change involves not only the developers but also management and the user community. No matter your position, your attitude plays an important role in SPI. For example, the way you do work in your twenties should be different from the way you do work in your forties, or at least it should be based on learning. If you are still doing things the way you always have, you need to re-examine your work and probably your life—and you are probably not the best person to be put in charge of the improvement effort. CMM work is all about change, something such people apparently know nothing about.
Users also need to change. Your users do not have the right to kill you, but that is what they are doing to our aging work force by creating unnecessary stress that contributes to heart attacks, cancers, and other ills. Control is the real issue. People who believe they have some control over their lives tend to be happier and live longer (so say the psychologists). So, to gain control of your project, you must control your users. Why should you accept an “emergency” request at 4 p.m. Friday that will keep you at work all night? Especially when it turns out that that particular user always turns in an “emergency” request at 4 p.m. on Friday and does not need the information until later the following week? Those users need to be trained in becoming pro-active and basically getting their act together. If everything is an emergency, nothing is an emergency. This sounds like an area in need of improvement.
“Standards? We don’t need standards!”
Nowhere in the CMM does it say that standards are required. The CMM does not absolutely require anything. The model is not a step-by-step how-to model—it is a framework, a guideline. It tells you what you need to do but not how to do it. However, the CMM presupposes that you have standards and are trying to follow them. The standards they presuppose you already have are for products like coding standards, templates for a requirements specification, or test case scenarios.
Following standards institutes a basic structure within an organization. So, if you do not have any standards, get some. One place to search is Department of Defense (DoD) military standards, even if you are not a DoD organization. Start searching the Web for military standards as well as for the methods used to implement SPI. They are available, and they are free.
Just do not be anal when you interpret this information (see item 10, “Keep It Simple”). And all standards should be tailored for use in your organization. Do not think that you can use the same standards you used from the place you used to work in your new workplace. They do not fit. They cannot be used. They can be used as a target, but you will need to tailor them.
“Everybody knows what the process is. What’s the big deal?”
Everybody knows what a process is until they try to define it in detail and write procedures that describe how to follow the process. Then, they shift back to documenting who needs to do something rather than on how that something is done. They also fall back on product standards (a form for documenting defects found during peer reviews) instead of process standards (how to perform the peer review, how to detect defects, and how to complete the form). Telling me that “it is the project manager’s responsibility to determine schedule estimates” does not tell me how that manager is supposed to derive those estimates.
“Collaborative and achieving consensus …”
CMM teams usually try to work collaboratively and make decisions by consensus. This concept is great and fosters buy-in and ownership but is extremely time-consuming and expensive. Consensus is not majority rules. Consensus means that everyone can live with the decision—they may not love it, but they can live with it. This way of working takes time. If you are on a tight schedule, (CMM work always is) you may need to stop the philosophizing and touchy-feely stuff and steamroll some folks. You will never get 100 percent buy-in from everyone. Take what you can get, and get those procedures written down.
“The CMM requires that a good process be in place.”
No. It requires that a process be in place that is documented and followed. At first, your process could be awful. That is where the “continuous process improvement” concept comes in. After you hammer out a process, it is piloted, and projects start to use it, refinements will be made until (it is hoped) the process becomes “good.” But to start, get something down on paper and use it. Clean it up as you go.
“We need to model our as-is process in order to create our to-be process.”
Yes, but I find that organizations take up to a year to do this, only to find that their processes are too ad hoc to be used as a baseline of good practices and lessons learned. I suggest doing a software capability evaluation (which is now done for internal software process improvement) or a CMM-based Appraisal for Internal Process Improvement. These assessment methods can quickly determine consistent practices across the organization as well as strengths and weaknesses. Measurable action plans can be generated based on the results. Tracking progress can also be measured. The thing to remember before starting CMM activities is to determine ahead of time how to measure success. Modeling current processes is great—but will you ever see a return on that investment?
“Tie CMM activities to your business objectives.”
Of course. There are some things in the CMM that may not make sense for you. For example, having a separate group to do software quality assurance (SQA) may not work if you only have 10 people in your company. The challenge is to figure out a way to perform quality assurance reviews and oversight in an objective, independent manner. And do not confuse “organization” with “company” or enterprise. An organization achieves a maturity level rating—not one project, not an entire company. Without going into detail, an organization generally consists of three to eight projects reporting to the same person, like a director or a division head—not an entire company (like IBM).
Do not get stupid about “business objectives.” Ultimately, most organizations’ business objectives are to achieve Level X by a certain date. If you are not currently doing SQA and do not want to do SQA (because of the cost and because it is overhead) yet you must achieve the level, do not try to be clever and tailor SQA out of the CMM process. Any certified evaluation team will catch you.
“Better, cheaper, faster.”
This really irks me. When the CMM was written, most organizations had not yet begun the downsizing frenzy. Nowadays, however, organizations have cut their staff to the bare minimum. Management loves the maxim “better, cheaper, faster” and eventually, you will be able to turn out software of better quality, more quickly, and less expensively—but not at first! The average time to obtain your return on investment is three to five years.
SPI is expensive. Most organizations either hire outside consultants to start the journey or build it from the inside. Even if you are not hiring consultants, taking people away from coding, i.e., “real work,” and having them do SPI costs you time, money, and schedule slippage. So management instead assigns SPI work in addition to existing work to an organization with extreme resource constraints, and it fails. You cannot squeeze additional effort from people who are already overworked. And having these people “work weekends, holidays, I don’t care what it takes” violates the CMM principle of establishing and following reasonable plans.
“Keep it simple.”
I like this one. Most organizations start off believing that they can keep their procedures simple—until they try to do it. Writing procedures that are simple and easy to follow, yet are thorough and complete, is extremely difficult. That is why the people on your teams need to be able to write and like to write as well as have a technical background and knowledge of the organization.
Managers in organizations today seem to feel that one person can wear many hats, i.e., a Powerbuilder programmer can also write procedures for how to write a requirements specification. Do you know what happens when you ask that unfortunate “techie” to do that? He breaks out in a cold sweat. Although some people are adaptable and can do many jobs, not everyone can do everything well. Different skill-sets are required for different jobs.
Another problem is that teams often catch the improvement fever. They want to improve everything. The challenge is to stay focused and use the CMM for software as your guide, but do not attack more than you can handle at one time. Remember: SPI is continuous improvement. It is iterative. Do what you can do in the time allotted, then go back and pick out more things once you have been allocated more time to do them.
Although there are other points to ponder when attempting this journey down the CMM path, these are the most frequently found errors made that I have documented. Good luck on your journey.
December 18, 2009 § Leave a comment
Well don’t we just have it all at our fingertips these days?
Mobile telephony, satellite monitoring, wireless go anywhere internet connection, SMS and ‘always on’ email straight to our palm devices.
As soloists, there’s no excuse for failing to stay in touch with our work (and our clients) regardless of where we are or when. The marketers of course, would have us believe this is all good.
Sure, some of it can be good and at times it is very convenient, but the worrying trend is that always available may become the workplace norm.
A quick glance at how these new services are being marketed and you’ll see imagery depicting young, happy executives tapping away at the keyboard while at the beach or in the garden. In the distance we see friends and family supposedly playing and communing happily.
Everyone is doing what they love. How nice.
Let’s now consider the reverse scenario: Friends and family playing happily in the office while you work. Do you reckon you’ll get much done? Nope. Me neither. You’ll be distracted and certainly won’t be concentrating on your work.
Relaxing with friends and family isn’t a totally passive past time. You need to participate if you are to give and receive. It’s called ‘being present’. If you’re not joining in, all you’re really doing is moving the office to a new location…and one where nothing terribly meaningful is achieved.
Let’s look at other implications of the always available trap.
Remember the good old days when you took a day or two off and were pleasantly surprised when everything ran smoothly in your absence? The times when your clients and associates rose to the challenge of management and decision-making and showed themselves much more capable than you had given credit?
Why would anyone risk making a decision about anything now, when you’re just a moment away?
On the other hand, if you want to make every micro decision (er, control freak!) then carry on, you’re doing just fine.
While some soloists may quite rightly say that being always available and in-touch is wonderful for their business, a survey on our site suggested over 72% of you would be more than happy if a surprise law banned mobile phones. Chances are partners and friends are sure to agree!
The answer to this is not that complex. Being available can most certainly be good, but we have to establish boundaries with our colleagues and clients.
If you don’t stay in control of your involvement in your business, you’ll forever be its prisoner.
That doesn’t sound like a good recipe for loving your work does it?
December 16, 2009 § Leave a comment
Imagine you went out to dinner.
And the wine was just superb; the bread roll with the exact crunch molecules and texture; and the service so impeccable and knowledgeable that you can’t remember when you had service so good.
Oh and yeah, the fish you ordered for the main was a bit too salty.
What would you remember from this experience?
Most of us would react in exactly the same way. We remember the salty fish. And not surprisingly the business owner or the employees are trying to fix the “salty fish”.
Don’t fix the problem. Fix the experience.
As I sat down to eat a meal at “Two Fat Indians” in Christchurch, my meal was a bit late. And out of the blue, a set of starters was placed in front of me.
I protested, of course, as I hadn’t ordered the starters. I was assured they were complimentary. It had been twenty minutes since I ordered my meal (they were counting on their computer system, not me), and though the meal was just a few minutes away, they offered me a set of starters absolutely free.
They fixed the experience. And the problem.
Most businesses do the wrong thing. When a customer mumbles and grumbles, they try to fix the problem. They see your fish is too salty. They offer to get the chef to cook you another fish with less salt.
Or lets say your hotel room was too noisy. They give you another hotel room on the same floor, or a different floor. Or maybe your website system fails and the client doesn’t get the download you promised. Well that’s easily fixed by sending the client the download, right?
No. No. No. And no.
Yes you need to fix the problem, but first you need to fix the experience. The experience I had at Two Fat Indians stood out, not because I can remember what I ate two years ago. It stood out because they fixed the experience.
By the very same token the experience I had at “Pacifica” (on Napier’s Marine Parade) will stick in my memory like a hornet’s nest. Because Pacifica refused to fix the experience, insisting they’d listened to my feedback and done their best to fix the problem.
Correct. They had done just that. They did everything they could to fix the problem. And they completely missed out on fixing the experience.
Ironically, crappy businesses don’t need to fix the experience
When you run into a shoddy business, you get products or services that are full of holes. You rarely expect any kind of experience from crappy businesses. It’s when you’re dealing with the absolute “Rolex” of businesses like Pacifica or Two Fat Indians that your expectation increases exponentially. And what is expectation but the ‘experience?’
You can’t ever fix the problem
Let me give you an example. Last week a client wrote to us saying she hadn’t received some course materials we’d sent out. To our defence, we’d already sent out the material. We’d done our ‘job.’ And yes, we’d pop another batch of materials in the mail, and yes, that would be that, right?
It’s like a Humpty-Dumpty moment.
You’ve somehow dropped the ball. Whether you’re writing a book, selling a sofa, sending out course materials or serving Monk fish as a main meal, you’re going to get someone upset. And all the ‘kings horses and all the kings men’ can’t fix that Humpty Dumpty moment. You can try to fix the problem the best you can, but hey that’s part of your job.
That’s what the customer paid for. You’re not doing them a favour when you fix the problem. But you are doing them a favour when you fix the experience. And so it’s the experience you must focus on—and not the problem.
To sum up: How do you fix the experience?
Step 1: You recognise the problem; you apologise and you fix the problem.
Step 2: You then fix the experience.
So Step 1 is really easy. Or should be. You recognise the problem. You fix it. And top notch businesses usually do this. They don’t waffle, they don’t shuffle. They instantly spring to action by apologizing (often profusely) and then they seek to fix the problem.
Step 2 is where things fall apart. And the way to fix the experience is to give the customer something that’s not related to the problem at all. It should be something of an add on.
If the course materials get lost in the mail, apologise, and then give the client a free consulting session (at your cost). If your keynote presentation offended some people with an off-colour remark, then apologise and then send them a box of chocolates. If the fish is too salty, try to fix the fish at first, but if the client persists on eating it (which I did), then go ahead and fix the experience. Be warm and gracious and give the client a free coffee, or a warm, chocolate dessert.
This article may read as if it’s about how to handle feedback.
It’s not about feedback.
Most of us bust our guts out to provide an outstanding experience to our clients. But the Humpty Dumpty moment still shows up, no matter what. And our natural response is to get defensive. To justify our actions. To fix the problem. But the client wants more than just for you to fix the problem.
But you know better.
You’ve got to fix the experience. Then fix the “fish”.