Over the past weeks I’ve come in touch with several companies with the same exact challenge.  Though, to be sure, it’s nothing new.  I encounter this challenge several times each year.  Perhaps, even following Pareto’s principle, 80% (or more) of the companies coming to me for improved processes have a variant of a form of distress that accounts for no more than 20% (or less) of the possible modes of distress.

In particular, the challenges are variants of a very basic problem: they want things to change but don’t have an objective performance capability to aspire towards.  Put another way, they can’t articulate what it is that their operation cannot currently accomplish that they’d like their operation to be able to do once the changes are put in place.

I’ve mentioned “SMART” objectives before.  Here’s another application of those same objectives, only now, they show up at a higher level within the organization. 

Choose the right objectives.

Executives of the organization often confuse “SMART” objectives with “fuzzy” objectives.  By “fuzzy” I mean objectives that appear to be “SMART” but aren’t, and, the fuzziness obscures the situation so as to over-render the truly uninspiring nature of the objectives as being substantial accomplishments.  In fact, fuzzy objectives are not actually objective (lacking a solid way to measure accomplishment), or, are easily “gamed” (data or circumstances can be manipulated), or, are very deep within their comfort zone – or the opposite – are ridiculously unreachable (achievement is too easily attained or excused for not attaining), or, are indicators of task completion rather than indicators of actual outcome changes (don’t actually achieve anything but give the appearance of making progress), or, aren’t tied to actual increased capabilities/performance (don’t cause anything to change that anyone cares about), or, are dubious achievements that can be accomplished by simply “rowing faster” (working harder by working longer hours or assuming too much risk or technical/managerial debt), and so on. 

These same “fuzzy” objectives are frequently couched in deceptively goal-esque achievements such as achieving a CMMI rating, or “getting more agile”, or getting ISO 9000 registered.  What I noticed among the recent crop of companies with these issues is that they shared a particular set of attributes.  They were after “improvements” but didn’t know what they wanted these “improvements” to enable them to do in the future that their current operation was preventing them from accomplishing.  Sure, as in the case of CMMI, achieving the “objective” of a rating would enable the company to bid on work they currently can’t bid on, but that’s a problem addressed in two separate posts (here and here) from a while ago.

Digging a little further, I uncovered a more deeply-seated challenge for these same companies.  In each case, they could not articulate what they actually wanted to be when they “grow up”.  Closely related to not being able to explain how they wanted to be able to perform that their current operation precluded them from performing, they also couldn’t say whether they wanted their company to be leaders in:

• product innovation,
• operational excellence, or
• customer intimacy.

According to Michael Treacy and Fred Wiersema, in The Discipline of Market Leaders, every company must decide the ordering of the above three values and how to organize and run the company to pursue the value they’ve chosen as first, followed by the second, etc.  Furthermore, and most seriously, leaders in the companies I visited were having serious issues.  Sometimes in more than one area: delivery, quality, scaling, proposal wins, proposal volume, cost pressure, and so on.  In none of the distressed companies were they looking at the performance capabilities of their operation.  And, in none of the companies did they have metrics that gave them insight into the performance of their operation or helped them make decisions about what to change or how.  In other words, they weren’t connecting their challenges to their lack of performance to the role their operational system of processes plays in that performance.

One thing that could help these companies climb out of the mud they’re in would be to simply and clearly define how it is they’d like to be able to perform that their current operations don’t facilitate, and, to define this capability in terms that represent an actual shift in how the operation functions.  Changes for improved performance is not about adding more work, adding more bureaucracy, or making people work harder.  Often, “working smarter” is easy to say but lacks substance.  “Working smarter” actually shows up as changes in the operational and managerial systems that carry out the performance of the operation.  A company that wants to perform better doesn’t need to add more work, or crack the whip louder, it needs to change how its operation runs.

More about this is in my upcoming book, High Performance Operations, available now for pre-order and due out at the start of October 2011 or earlier.

A more appropriate title would have been "counting changes" but it would have hardly been as interesting. 

Change happens.  And often.

In particular, when a product is in its operation and maintenance ("O&M") phase, changes are constant.  (Note: O&M is frequently called "production", and this simple choice of words may also be part of the issue.)  But, too often, changes to products are handled as afterthoughts.  When handled as "afterthoughts", product features and functions receive far less discipline and attention than warranted by the the magnitude of the change were the new or different feature/functionality have been introduced during the original product development phase.

In other words, treating real development as one would treat a simple update just because the development is happening while the product is in production is a mistake.  However, it’s a mistake that can be easily diffused and reversed.

O&M work has technical effort involved.  Just because you’re "only" making changes to existing products that have already been designed, does not mean that there aren’t design-related tasks necessary to make the changes in the O&M requests.  Ignoring the engineering perspective of changes just because you didn’t do the original design or because the original (lion’s share of) design, integration and verification work were done a while back doesn’t mean you don’t have engineering tasks ahead of you.

In O&M, analysis is still needed to ensure there really aren’t more serious changes or impacts resulting from the changes.  In O&M, technical information needs to be updated so that they are current with the product.  In business process software, much of the O&M has to do with forms and reports.  Even when creating/modifying forms, while there may not be any technical work, per se, there is design work in the UI.  The form or report itself.  And even if you didn’t do that UI design work, you still need to ensure that the new form can accept the data being rendered to it (or vice-versa: the data can be fit into the report).

It’s frightening, when you think about it, how much of the products we use every day — and many more products that we don’t know about that are used by government and industry 24/7 — are actually "developed" while in the "O&M" phase of the product life cycle when the disciplines of new product development are often tossed out the door with the packing material the original product came in.  Get that?  Many products are developed while in the "official" O&M phase, but when that happens they’re not created with the same technical acumen as when the product is initially developed.

(I have more on this topic, and how to deal with business operations for products in the O&M phase, in this Advisor article from the Cutter consortium.)

In a sadly high number of operations I’ve encountered, once a product is put into production, i.e., is in O&M, the developers assigned to work on it aren’t top-notch.  Even in those organizations where such deleterious decision-paths aren’t chosen, the common experience in many organizations is that the developers are relied-upon even more for their intimate knowledge of the product and the product’s documented functionality — as would have otherwise been captured in designs, specifications, tests and similar work artifacts of new product development.  In these organizations, the only way to know the current state of the product is to know the product.  And, the only way to fix things when they go wrong is to pull together enough people who retain knowledge of the product and sift through their collective memories.  The common work artifacts of new product development are frequently left to rot once the product is in O&M, and what’s worse is that the people working on the new/changed features and functionality don’t do the same level of review or analysis that would have been done were the functionality or other changes been in-work when the product was originally developed.  Of course, it’s rather challenging to conduct reviews or analysis when the product definition only exists as distributed among people’s heads.  Can you begin to see the compounding technical debt this is causing?

I’ve actually heard developers working on legacy products question the benefits of technical analysis and reviews for their product!  As though their work is any more immune to defect-inducing mistakes than the work of the new product developers.  What’s worse is that without the reviews and analyses, defect data to support such a rose-colored view seldom exists!  It’s entirely likely, instead, that were such data about in-process defects (e.g., mistakes in logic, design, failing to account for other consequences) to be collected and analyzed, it would uncover a strong concentration of defects resulting from insufficient analysis that should have happened before the O&M changes were being made.

Except in cases where O&M activities are fundamentally not making any changes to form, fit, feature, appearance, organization, integrity, performance, complexity, usability  or function of the product, there should be engineering analysis.  For that matter, what the heck are people doing in O&M if they’re not making any changes to form, fit, feature, appearance, organization, integrity, performance, complexity, usability or function of the product?!

If anyone still believes O&M work doesn’t involve engineering, then they might need to check their definition of O&M.  Changes to product are happening and they’d better be counted because if not, such thinking fools organizations into believing their field failures aren’t related to this.  Changes count as technical work and should be treated as such.

(I have more on this topic, including how to help treat O&M and development with more consistent technical acumen in this Advisor article from the Cutter consortium.)

I learn so much from failure it’s hard to ignore the good that comes from it.

This week I parted company with a client long before their goals were reached.

Sadly, I knew from the start they would be a challenge and made the mistake of ignoring the warning signs.  Never again.  Honest!

This entry is as much for coaches and consultants as it is for teams, staff, management and leadership.

There are several tell-tale indicators of success and/or failure.  In our own ways and in their own contexts, experienced coaches and consultants know what these indicators are.  Well-rounded, experienced, and seasoned practitioners within companies know them too.  In fact, most people know them instinctively, somehow.  I can therefore safely say that whether it’s through experience or instinct, we all know many of the same indicators.  In fact, we can probably sum-up every indicator in one word: Attitude.

So, yes, Jeff Keller’s famous self-help book, "Attitude is Everything", applies as well.  In organizations, "attitude" is frequently interchangeable or encompassed by company "culture".  And yes, attitude is a derivative of culture.  But sometimes culture is harder to pinpoint than attitudes.  Attitude shows up in your interactions with the company from the very start of your prospecting dance.

Here are some attitudes you may encounter and whether or not they spell greater odds of success or failure:

Failure-prone attitudes:

• Hassling about price/cost/time but expecting the same scope and performance outcomes.
• Focusing on deadlines and schedules instead of real results.
• Not owning the work and expecting off-site outsiders to invent working approaches.
• Shallow goals that aren’t S.M.A.R.T.
• Mistaking a task for an outcome or goal.
• Ignoring, denying, and filtering information that indicates problems.
• Poor communication (which often starts with poor listening skills).
• No allocation of explicit time and/or resources to make improvements.
• Failing to recognize the importance of the right people in the right roles for the right reasons.
• Delivering materials for review with no lead-time for turn-around.
• Persisting in propagating bureaucratic policies despite the obvious lack of value-add.
• Executives who are mostly (if not exclusively) involved in decisions involving budgets but not in making changes.
• Repeatedly using external influences as excuses to not make important changes.
• Assuming a victimization attitude instead of owning up to their circumstances.
• Failure to learn and apply new ideas — even after being presented with the benefits of those ideas.
• Management by motivation 1.0 or 2.0

Success-leading attitudes:

• Focus on results not the cost of getting them.
• Clear, S.M.A.R.T. goals.
• Executive involvement and ownership of leading the changes.
• Respect and appreciation for everyone’s contribution and effort.
• Active concern for overtime, unplanned work, and defects.
• Accounting and planning for everything that takes time by everyone involved.
• Taking full ownership for all the work (irrespective of the “divisions of labor” as seen by the customers).
• Clear-eyed view of effort and not planning around "best case only" scenarios.
• Ability to appreciate the need for non-technical, non-managerial skills in the roles of leading change.
• Seeing beyond the surface: A desire to learn and understand the meaning behind the work, not just following the specific language of the work.
• Dealing with people as people and not numbers.

My best clients have always had direct, clear and unambiguous evidence of two things:

1. S.M.A.R.T. Goals, and
2. Executive involvement in making the changes happen — not just lip service and budget authorization.  This usually took the form of the top leader (or 1-step away) taking personal involvement in not just setting direction, but in working through the best way to make things happen with the people who will be most affected.  (What does NOT count is a “top” leader with a purely administrative role and no executive accountability or responsibility.)

In experiencing the failure with this client, I admit to learning about at least one critical oversight on my part (there were others but this one takes top spot).  As we were interviewing each other, I failed to interrogate the leaders of the company for specific improvement goals.  The only "goals" they came to me with was to make their processes "leaner" and to attain a CMMI Maturity Level 3 rating with leaner processes.  Which turned out to really mean little more than to replace their heavy-handed compliance-oriented approach with a set of processes more projects could comply with more easily.  Again, note that they were still about "compliance".

Despite claims to the contrary, I didn’t fully realize until well into the engagement that compliance was still their primary attitude — at least among the people who were charged with overseeing the process assets for the entire organization. 

During the engagement, I repeatedly worked to identify meaningful improvement goals that being "lean" could help them attain.  I then created a strategy that would bring them closer to these goals and presented it to the majority of the executives.

Despite wide agreement on the goals and the strategy, when it came to rolling out the necessary changes, it was met the same-old resistance to change and fears that I knew spelled doom.

Nonetheless, I had high hopes for this organization so I decided I would bring them around by modeling the behavior I was trying to help them see.  A few people caught on but, alas, not the people who held sway in the organization.  Our mutual falling-out began early when it became apparent that desire among the leadership to achieve a maturity rating without upsetting the apple cart was overshadowing the desire to actually reach the performance goals being a leaner organization would achieve.

Notwithstanding, there were other tell-tale signs from the list above that this organization didn’t have the attitude to make the changes necessary.  I won’t belabor you with the complete saga.  Instead, I’ll return to my point about this entry.
You as coaches, consultants, and staff can’t want to better than your leadership is prepared to be.  The signs are all around you.  Pay attention to the signs early.  You will save yourself a lot of time, heartache and frustration.  If you believe you don’t have enough experience to justify your powers of observation, then trust your instincts.  Is the organization defensive about their entrenched position on their circumstance?  Do they make excuses instead of setting goals?  Are the goals devoid of any real results? 

You don’t even have to go that far.  How are you treated as a person, as a professional, is about all you really need to know about whether or not there’s a hope that things can get better.  If you’re not appreciated, if your organization is willfully blind to the things that cause you grief, if you see signs that tell you the organization lacks "class", you don’t need 20 years of experience telling you you’re right to know you’re right.  This organization is doomed to mediocrity.  Is that the kind of organization you want to be associated with?

I don’t, and, I won’t ever be again.

Your people with prior CMM/CMMI experience are probably worse than worthless, they’ll probably cause you to fail.

Why?

Because what they (or you) think they (or you) know is probably wrong and the advice you’re getting, the expectations being generated are entirely off base.

It all goes back to the many ways in which CMMI can be done poorly and the few, simple, but hard work ways in which it can be done correctly.

Every time I meet with a new prospect I’m confronted with reams of inaccurate assumptions and assertions about what it will take to implement CMMI and how am I expected to “do all that” and still claim to be “agile”.

My simple answer: I’m not going to do all that.  And, you shouldn’t be doing it either.

Seriously, you’ve got to wonder about executives who will force their company into doing stupid things for the sake of a rating instead of doing their homework to learn about CMMI before they head out on an implementation journey.

A recent client didn’t know any better.  They hired a consultant and an appraiser to evaluate their work against CMMI and to help them prepare for a SCAMPI appraisal.  Unfortunately, they got as far as the appraisal only to realize they weren’t going to get the target Maturity Level.  (I won’t get into some of the inappropriate behavior of the firm they hired.)

However, when this client was confronted with:

1. Do something stupid, or
2. Find a better way to do something smart.

They took option B and found a consultant and an appraiser who understood their context and found how to both be on a disciplined improvement path while also remaining true to their own business.

Fortunately for them, this client had a strong engineering backbone and knew what they did worked and were confident in their processes.  Many companies have a while before they can claim that much.

Next week:

Picking a Lead Appraiser:  “Dammit, Jim!  I’m a doctor not a bricklayer.”

What turned out to be a failed meeting with a far away  prospect reinforced lessons I learned a while ago…. 


About what it takes to be successful in business, with Agile, with CMMI, and about creating a culture of excellence.


Can’t wait for the lesson?


Here’s the bottom line:  the discipline to improve shows up all the time, everywhere and in every action.  Failure to respect time, respect what people know, and the experience/expertise of your subordinates are all BIG CLUES that your organization doesn’t have the culture or discipline to succeed.  Even when you’re in the middle of hiring someone to help you get it.