A Simple Matter of Software

Seven things to keep in mind when making course corrections

In previous post we have discussed the value of metrics and measuring progress against the plan.  Obviously measurement is not enough, acting on that measurement is also required.

It should be a basic part of your leadership MO to measure progress and take decisive corrective action based on what you see.

However, there are a couple key points to keep in mind in implementing this practice:

1) Don't flip-flop via overcorrection.

Take a lesson from fuzzy logic implementations such as the speed control on the Tokyo monorail and the automatic headlights on your car.  In the automatic headlight example you wouldn't want an implementation that flipped the lights on and off as you drove through brief patches of shadow.  When the light sensor tells the embedded controller that the darkness threshold has been exceeded, you probably want it to wait a little bit to see if that trend continues and is sustained before flipping the lights on.

2) Have a graduated series of corrective actions, starting with paying more attention

Usually the most extreme corrective actions are very disruptive and can have negative side-effects with the law of unintended consequences causing surprising blowback.  Often you want to have a series of corrective actions with less disruptive actions implemented first. 

The very first corrective action (and often the most productive one) is simply to pay more attention to the problematic area.  Once you see a metric going off the tracks, dig in and research further, ask questions, get opinions from others.  Mechanically implementing a predefined corrective action is usually not the right thing to do.

3) Recognize the difference between corrections and resets

You could argue that this difference is just a matter of degree.  Yet it is an important difference.

"Corrections" are changes that are disruptive to varying degrees, but don't change the fundamental direction and don't require a complete re-examination of all assumptions and decisions.

"Resets" on the other hand  are more  fundamental changes  that are  in essence defining a new plan, that may reuse some elements of the previous one but is really a new project.

It is normal to implement multiple corrections during the course of implementing a project.  Most of the time you don't implement a reset to a project.  If you do implement a reset you will only do it once per project as the result is in essence a new project.

One failure mode for ventures is to have the "meantime between project reset" be less than the "meantime required to complete a project".  In this case you will rarely complete anything.

4) Help people see it coming.

There are always a few metrics that involve sensitive data that can not be widely shared.

However, as a rule it is better to share your metrics and measurements broadly within your own organization and with other teams that you work with closely. That sharing should occur as a matter of course before any corrective action, and not just as a justification when actions are announced.

A primary benefit to broad sharing is that it means people are more supportive and less surprised when you do need to change things.

Other benefits include that others may recognize issues in the data that you have overlooked and that people will often self-correct on their own initiative for that subset of items that is within their individual control.

5) Understand downstream impacts.

When considering corrective actions it is natural to focus on the impact within your own organization.  However the downstream impacts on other teams is often as great or greater.  Therefore you need to be conscious of those impacts and often bring folks from those teams into your decision making process.

6) Understand the human impacts.

People are disturbed by change: it knocks them out of their comfort zone, it can make them less productive, if mismanaged it can make them leave the company.

Therefore, in thinking through any changes to the plan you need to consider not just the project management perspective, but the human and emotional considerations.  Those factors should not freeze you into inaction.  However, they may impact your decision on what action to take, and they certainly should impact how those actions are communicated.

7) Explain the "why" of your decision.

Related to the above is the need when announcing a change to explain not just what action is occurring, but also why.

                                                                                copyright 2007 Kerry Champion

Addition Through Subtraction

Every gardener knows that thinning and pruning is just as important as planting and growing.

The same is true in software. Sometimes the best way to add to your results is to subtract some negative elements.

When faced with some problem the natural thing to do is to increment on a new element: a new hire, or a new process, or a new project.  It is typically  easier to stay in everyone's comfort zone by adding rather than subtracting.  But putting some short term stress into the system is often the right path to get a better long term result.

Consider this scenario:

• Dozen person team working on company critical software project:  Software Architect, VP Engineering, and ten engineers
• Have first generation product that clearly does not provide functionality/performance required for company to succeed.  Now need to architect and code second generation product.
• Architect is really really smart guy who has very quickly implemented very difficult coding assignments both at this company and previous company.
• Engineers other than Architect have the normal mix of skills including both "competent but will never be a star" and "really skilled, could be a star with right support and opportunity".
• Architect is adamant that fundamental design changes are required to deliver second-generation.
• Architect has non-traditional design approach that worked at a previous company and he wants to try again here.  Architect is serenely confident that this approach will achieve all goals and be implemented very quickly.
• Management feels intense pressure to get competitive product to market and is pushing hard to get team going on "coding"
• PROBLEM 1: Even after several weeks of work on the detailed module design and initial coding, it is clear that the Engineers do not fully understand the design being advocated by the Architect. 
• PROBLEM 2: Beyond the specific issues of rolling out this particular design, it is clear that Architect is weak communicator in general and has trouble working with people who "are not as smart he is".

Those are some serious problems and the project and company are on a clear path to failure.  Lets consider some potential solutions.

Problematic solutions via addition:

• Add Person
  
  • Hire another layer of management by hiring an Engineering Manager.  Have this guy modulate and manage the communication between the architect and the rest of the team.
  • Makes you feel good that you are doing something
  • Since it will take a long while to hire the person and for that person to learn the score, it puts off the real day of reckoning
  • Inefficient in terms of resources, adds expense and bureaucracy that is not needed yet.
  • Will mask the issue for awhile but will almost certainly fail to address the fundamental issues.
  • There will be some unintended consequences (better known as blowback) as the new manager will certainly start doing more stuff (beyond managing architect to team communication) to justify his existence.
• Add Process
  • Create a new set of processes that force the required communications and design reviews
  • Similar issues to above.  Masks problem for awhile but does not really solve it.  Also unneeded processes create general slow-down and lethargy.
• Add Project
  • Create an isolated greenfield project that will build the second generation product.  Put the architect and 1 or 2 simpatico engineers on that.  Leave the rest on maintenance of the first generation product.
  • If 2 or 3 people is the right number to have on this project for its whole life cycle then this solution may be a good one.
  • However, if 2 or 3 is just enough to get started and you really will need a dozen to finish the project, then you have put off dealing with the problem, created an us-them dynamic on the team, and have 75% of your team underutilized while the problem festers.

None of the above sound very appealing the way I stated them.  However, I have seen similar solutions implemented in the real world, they were just wrapped up with a nicer sounding rational.  In the scenario we gave the fundamental issues are really painful and uncomfortable to deal with.  In which case it is very natural for folks to talking themselves into a "solution" that does not address the real issue.

Promising solutions via subtraction:

• Subtract person
  • Move architect to a supporting position. 
  • Accept the fact that he is very likely to leave us a result.  But get what value you can out of him before he goes. 
  • Preferably develop 1 or 2 of the existing engineers to take architecture responsibilities.  If that is not possible, fundamentally re-set the schedule and look outside for help.
• Subtract process
  • In this scenario there is not a good opportunity to solve the problem via removing process.  However, surprisingly often this is an option.  Processes tend to accrete over time like plaque in your arteries.  You should always look for opportunities to simplify.
• Subtract project
  • Test your premises about the fundamental nature of the project.  If possible avoid adding a new project and evolve the existing effort instead.
  • Do you really need a brand new project and fundamentally new design to achieve your goals?
  • Can you achieve your goals by killing that "rebuild it all" project and defining an incremental approach (that relies less on your architect's  communication skills and non-traditional design)?

Obviously the best solution will depend on the specific circumstances of the project and sometimes the right solution is via addition.  However, there is a consistent inherent bias to not consider solutions via subtraction.  We need to push ourselves and our teams out of our comfort zones and seriously consider those solutions.

                                                                                       copyright 2007 Kerry Champion