Bob Lieberman's Blog

Tools For Initiating and Managing Change

Taming Product Development

Product development is a wild animal. It's unimaginably powerful, but you have to make sure it knows who's in charge – at every moment. Oh, and it might bite your head off anyway.

This is true whether we're talking about software, media, or tangible commercial products. And the most common complaint I've heard from leaders is that development is out of control. Here are some telltale messages from the development team:

"We'll be done in 2-3 weeks"
Translation: We're working on things as they come up

"We need a little more money"
Translation: We're working on things as they come up

"We've found a few last things that need to be fixed"
Translation: We're working on things as they come up

Do you see a pattern? When leadership abdicates responsibility for direction and management, development teams fill the vacuum. Surprisingly, the leader's remedy is simple: decide what's important and only permit work on that. Unfortunately, many senior executives don't know how to carry out that remedy in practice. For those of you who meet that description, I'm providing the following simple template for controlling development work. It has two components, knowledge and guidance.

Knowledge means that you must know both what it important and what is going on. Do you?

Know what is important
  • What are your specific business objectives for each release, rollout or edition of the developed product?
  • What release sequence fits those objectives?
  • Which release's objective does each product function serve?
Know what is going on
  • How much work remains for each function, defect, or enhancement?
  • What functions are the development team currently working on?
Guidance means that you must direct what is going on (towards what is important). This can require confrontation with technical experts, something that non-technical people tend to avoid (although they may not all admit it).

Direct what is going on
  • Be ruthless about postponing work that isn't in the next release, rollout, or edition
  • Update your knowledge daily
Retention of the knowledge you'll be accumulating requires a recording system. Here's one I've used recently with one of my clients. It involves four spreadsheet tables, one each for Functions, Scope, Releases, and Defects/Enhancements. The columns are listed below the table name.

Functions
  • Capability (the name of a group of related functions to which this function belongs)
  • Function phrase (for identification)
  • Hours of development work remaining
  • Development status (in progress, etc).
  • Hours of testing work remaining
  • Testing status
  • Target release name (for identification)
  • Justification for including the function in the target release
Scope
  • Function (same phrase as above)
  • Brief description of features included
Releases
  • Release name
  • Business and/or market significance of the release
  • Target delivery date, if known
Defects/Enhancements
  • Brief item description
  • Hours of development work remaining
  • Development status (in progress, etc).
  • Hours of testing work remaining
  • Testing status
  • Target release name
  • Justification for including the item in the target release
That takes care of identifying the minimum knowledge you'll need to record. I'll leave it to your spreadsheet expertise to build a little system that is most useful to you.

As for guidance, that simply requires asking for information and redirecting work as necessary. Of course it helps if you have the authority to do so.

Oops, I almost forgot to mention leadership. Without it, you stay mired in the current mess. Leadership is what supplies the motivation and vision to see the way out and get the ball rolling. I think I hear someone calling your name.