jump to navigation

Success Criteria: Software Department July 30, 2009

Posted by Tim Rodgers in Management & leadership, Process engineering, strategy.
Tags: , , ,
trackback

My philosophy of effective leadership hinges on the idea that teams need quantitative performance measures that are aligned with higher-level business objectives. At the most basic level, each team within a business consumes resources (e.g. salaries, other labor costs, direct expenses) while making some kind of positive contribution (adding value) to the overall enterprise. If the team can add more value while consuming the same or fewer resources over the same period, then that team has clearly helped the business become more successful. It’s fairly easy to measure the expenses associated with a team, so the challenge is measuring the value added, ideally in an unambiguous way that the team can directly control through their own actions, and aligned with higher-level objectives and strategies.

Here’s an example of how that works, from my recent experience leading a software development department. This team was responsible for design and delivery of embedded software as a component in a capital equipment product used in semiconductor manufacturing. At the time, the software was not sold as a separate component, and therefore did not directly contribute revenue, although we believed that the software contributed to the overall customer-perceived value of the product. In addition, software could be delivered and easily installed on previously-sold products through existing service contracts, providing an opportunity to add incremental post-sales value.

The software team’s contribution to the business was therefore based on our ability to deliver value to the customer, either as software-specific features or support for other high-level product features and specifications, and to deliver that value in a timely fashion by meeting new product introduction schedules and enabling/driving rapid deployment into the installed base. That translated into four high-level success measures:

  • Value-added software: support for new product features that meet customer needs, both at the basic “hygiene” level needed to maintain market share, and at the “wow” level needed to justify premium pricing.
    • Key performance indicator (KPI): Estimated dollar contribution of software. This is obviously a subjective estimate, but I really believed that our customer-facing sales and support organization could help us here.
    • Needed: Better understanding of customer needs to target high-value features.
  • On-time delivery: software available on-time to meet announced dates for new product availability and customer evaluation schedules
    • KPI: Actual checkpoints vs. plan. It’s especially important here to get an early indication of delay vs. plan while there’s still time to catch up.
    • Needed: Disciplined development processes, an architecture that supports design of incremental features, and high quality to ensure smooth customer qualification
  • Fully deployed software: rapid introduction of new features, replacing old software
    • KPI: Penetration, percentage of installed base using new software after introduction
    • Needed: Tighter collaboration with field support to drive change orders
  • Quality
    • KPI: Escapes, defects reported by customers, especially those that prevent the customer from qualifying and deploying value-added features
    • Needed: Relentless dedication to zero defects and elimination of variability

Obviously the value contribution will be different for other teams in other businesses, but I think this approach can be generalized. What product or service does the team deliver? How do others value that product or service? What can the team do to add more value?

On the cost side, I wanted to look at two things:

  • Operating expenses: those monthly reports from finance on how much money the department spent vs. budget
  • Operational efficiency: how much time is wasted on non-value added activities?
    • KPI: Percent of time spent by the team fixing their own mistakes, specifically defects found and fixed internally
    • Needed: Value chain analysis to identify sources and eliminate waste

I think these six measures were sufficient to express the contribution of the software team, track changes over time, and, maybe most importantly, ensure that proposed actions and changes would lead to improvements that benefit the business.

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: