Archive for the ‘organization’ Category

The Cart Before the Horse

Tuesday, February 21st, 2012

For more than the last 10 years I’ve been thinking a lot about CMMI.  Many of these thoughts have been ruminating on the ideas of how to incorporate CMMI in ways that add value, demonstrate effectiveness, and don’t disrupt the operation.  I’ve even opined much in this blog (in too many ways) on the need to know what your processes are before you can use CMMI to improve them, and that for many operations, CMMI isn’t even appropriate.

A few recent discussions and experiences put a particularly fine point on the extent to which CMMI is really the ‘cart before the horse’ when applied within an operation that has yet to clearly discern its process, and here’s why:

Most operations I’ve encountered are not ready to use CMMI because they are unclear on exactly how they make money.

Obviously, I’m not talking about the accounting process of billing out invoices and depositing checks.  And, I’m not even talking about the voodoo around figuring out how to ensure that internal costs (salaries, equipment, etc.) are less than what they charge clients for the work they do.

So, I must be talking about something more subtle.  I wish I were.  And, this is what’s both frightening and sad.  I’m merely talking about the relationship between capacity and demand.  For that matter, I’m not even worried much about demand, which is another matter.  I’m mostly talking about capacity.

What is capacity?

According to some, capacity is a measure of volume of work.  Throughput, for instance.  According to others, it’s the wherewithal to do the work.  Either way, too many operations don’t know what their capacity is. 

What does it actually take to get work done?  And, along with that, can it be reasonably expected of the operation to reliably and predictably continue to run how it runs (not knowing exactly how it runs) and to have any right to greater-than-zero confidence that they will continue to run as it does?

For one thing, many operations run outside of reasonable tolerances. In particular, people put in many many hours of unpaid over-time [in the US this is common for salaried employees].  This is an "out-of-tolerance" condition.  It is unreasonable to expect an operation’s greatest source of working knowledge to continue to work nights and weekends.  Furthermore, it is risky to do so.  One client said he couldn’t be away from the office for 5 minutes before product would stop shipping.  Eventually he will get married or his wife will have a child, or, heaven-forbid, he may take vacation! 

What’s worse is the extra time he and his team put in is entirely unaccounted-for.  His employer merely estimates, contracts, and bills enough to cover his and the team’s salaries, not what it actually takes to get work done.

Another reason true capacity is obscured is because more work going into the operation than there’s product (or services) coming out.  The most common cause of this is the misperception that work started = work completed, but this is an incomplete equation.  But a better equation to work with is work worked-on = work completed.  The key mistakes is the assumption that started = in-work.  That’s true for maybe 50% of the actual started work (often less).

This next reason for the lack of insight into true capacity (or capability, really) is that so many operations don’t account (either in their estimates — which sort-of makes sense — or in their capture of time-spent — which is unforgivable) for the time to correct defects, time to perform rework, time for paying-down technical debt, or time and effort to tracking-down the causes of defects and rework to avoid defects, rework, and technical debt in the first place!

I’ll end with one of the toughest, most sensitive observations of the last few months.  Some of my best clients (from the perspective of having their act together) have strong confidence in functional competence and, admittedly, weaker confidence in their programmatic credibility.  And, to put it plainly, by "programmatic" I mean their ability to have the same confidence in the rationale for their estimates and plans as they have in their ability to produce what their clients want. 

In these operations, I’ve found fundamental disconnects between how work is estimated and why clients should trust the technical competence of the operation.  In other words, they build trust with their prospects and clients on their ability to do the work and build the products, but in order to get the work in the first place they have to use a lot of hand-waving and breath-holding when it comes to their estimates.

A more-or-less summary way to describe all of this is as follows:

Most operations have Built a way of working that they’ve managed to Capitalize.  Over time, they’ve found that their Build*Capitalize approach is tough to Sustain.  Try that they might, whether it’s CMMI or something else, they’re looking to "fix" the equation on the "Sustain" side.  The problem is that CMMI *does* operate on the Sustain side, but the problems with the operation aren’t in the "Sustain", it’s that their approach to Capitalizing on what they Built is no longer Sustainable.  What needs to change is on the Build side.  Occasionally, there’s a need to revisit the Capitalize component, but most often it’s the Build that needs refactoring.

Hence, applying CMMI to an operation whose "build" is broken is putting the cart before the horse.  While it’s possible to build CMMI practices into the operation’s way of working, this is an activity of the "build" side of the equation, the sort I noted above contrasting from applying CMMI to the sustain side.  If CMMI is to be truly about improving the processes of the operation in a "sustaining" sort of way, and not defining them, the operation must understand what’s going on, and that means it must know its capacity.  Because unless it knows its capacity, it doesn’t really know what’s going on.

The Cart Before the Horse

Sunday, February 19th, 2012

For more than the last 10 years I’ve been thinking a lot about CMMI. Many of these thoughts have been ruminating on the ideas of how to incorporate CMMI in ways that add value, demonstrate effectiveness, and don’t disrupt the operation. I’ve even opined much in this blog (in too many ways) on the need to know what your processes are before you can use CMMI to improve them, and that for many operations, CMMI isn’t even appropriate.

A few recent discussions and experiences put a particularly fine point on the extent to which CMMI is really the ‘cart before the horse’ when applied within an operation that has yet to clearly discern its process, and here’s why:

Most operations I’ve encountered are not ready to use CMMI because they are unclear on exactly how they make money.

Obviously, I’m not talking about the accounting process of billing out invoices and depositing checks. And, I’m not even talking about the voodoo around figuring out how to ensure that internal costs (salaries, equipment, etc.) are less than what they charge clients for the work they do.

So, I must be talking about something more subtle. I wish I were. And, this is what’s both frightening and sad. I’m merely talking about the relationship between capacity and demand. For that matter, I’m not even worried much about demand, which is another matter. I’m mostly talking about capacity.

What is capacity?

According to some, capacity is a measure of volume of work. Throughput, for instance. According to others, it’s the wherewithal to do the work. Either way, too many operations don’t know what their capacity is.

What does it actually take to get work done? And, along with that, can it be reasonably expected of the operation to reliably and predictably continue to run how it runs (not knowing exactly how it runs) and to have any right to greater-than-zero confidence that they will continue to run as it does?

For one thing, many operations run outside of reasonable tolerances. In particular, people put in many many hours of unpaid over-time [in the US this is common for salaried employees]. This is an “out-of-tolerance” condition. It is unreasonable to expect an operation’s greatest source of working knowledge to continue to work nights and weekends. Furthermore, it is risky to do so. One client said he couldn’t be away from the office for 5 minutes before product would stop shipping. Eventually he will get married or his wife will have a child, or, heaven-forbid, he may take vacation!

What’s worse is the extra time he and his team put in is entirely unaccounted-for. His employer merely estimates, contracts, and bills enough to cover his and the team’s salaries, not what it actually takes to get work done.

Another reason true capacity is obscured is because more work going into the operation than there’s product (or services) coming out. The most common cause of this is the misperception that work started = work completed, but this is an incomplete equation. But a better equation to work with is work worked-on = work completed. The key mistakes is the assumption that started = in-work. That’s true for maybe 50% of the actual started work (often less).

This next reason for the lack of insight into true capacity (or capability, really) is that so many operations don’t account (either in their estimates — which sort-of makes sense — or in their capture of time-spent — which is unforgivable) for the time to correct defects, time to perform rework, time for paying-down technical debt, or time and effort to tracking-down the causes of defects and rework to avoid defects, rework, and technical debt in the first place!

I’ll end with one of the toughest, most sensitive observations of the last few months. Some of my best clients (from the perspective of having their act together) have strong confidence in functional competence and, admittedly, weaker confidence in their programmatic credibility. And, to put it plainly, by “programmatic” I mean their ability to have the same confidence in the rationale for their estimates and plans as they have in their ability to produce what their clients want.

In these operations, I’ve found fundamental disconnects between how work is estimated and why clients should trust the technical competence of the operation. In other words, they build trust with their prospects and clients on their ability to do the work and build the products, but in order to get the work in the first place they have to use a lot of hand-waving and breath-holding when it comes to their estimates.

A more-or-less summary way to describe all of this is as follows:

Most operations have Built a way of working that they’ve managed to Capitalize. Over time, they’ve found that their Build*Capitalize approach is tough to Sustain. Try that they might, whether it’s CMMI or something else, they’re looking to “fix” the equation on the “Sustain” side. The problem is that CMMI *does* operate on the Sustain side, but the problems with the operation aren’t in the “Sustain”, it’s that their approach to Capitalizing on what they Built is no longer Sustainable. What needs to change is on the Build side. Occasionally, there’s a need to revisit the Capitalize component, but most often it’s the Build that needs refactoring.

Hence, applying CMMI to an operation whose “build” is broken is putting the cart before the horse. While it’s possible to build CMMI practices into the operation’s way of working, this is an activity of the “build” side of the equation, the sort I noted above contrasting from applying CMMI to the sustain side. If CMMI is to be truly about improving the processes of the operation in a “sustaining” sort of way, and not defining them, the operation must understand what’s going on, and that means it must know its capacity. Because unless it knows its capacity, it doesn’t really know what’s going on.

A real "class act"

Wednesday, March 2nd, 2011

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.