Performance, Productivity, and Results Defined

February 8, 2009

While you can argue that the terms “performance” and “productivity” are synonymous, I’ve chosen to put some strict bounds around the use of these terms. My main premise is built around the following sentence:

A distinction needs to be drawn between measuring productivity and what goes into achieving productivity.

Building on this premise, obtaining great results is a function of prioritizing work to provide the highest possible value. Otherwise, you run the risk of working on all the wrong things the right way.

A picture is worth a thousand words. The following illustration captures my thoughts on defining performance, productivity, and results:
The "Development Organization" box defines the company or business unit that is responsible for creating and delivering the software. External to the development organization is the customer, the entity that helps determine what the software should do and the one who expects to derive some benefit – value – from the use of the software. The arrow signifies delivery of this value to the customer, with everything flowing with, and an intrinsic part of, the total delivery picture.

The customer surrounds the development organization, not only receiving value but also participating at the beginning of the process, making the business case for pursuing a given project and providing valuable input that helps to shape the overall direction.

This is why the arrow starts and ends outside of the development organization box, and why the customer is viewed as surrounding the entire process. In practice, there should be an active partnership between the customer and development organization.

Starting at the bottom left and moving in the direction of the arrow, the Performance category captures the knowledge, skills, and abilities of individuals. Without good, capable, competent people, nothing else matters. This is input helps to drive the next category in the flow: Productivity.

Productivity is about orchestrating and leveraging peoples’ collective abilities and activities through teamwork, processes and tools. Teams comprised of skilled, collaborative people who are working efficiently can realize greater productivity than those working independently.

Ultimately, results are delivered. How much value that is obtained is a function of the return on investment. Ideally, people and teams should be focusing on and delivering work that provides the greatest possible value, and striving to deliver that value as efficiently and effectively as possible. Poor results can be a function of many things, such as performance and productivity problems that drive costs up, or even a consequence of working productively on all of the wrong things.

The arrow gets bigger as the flow progresses towards final delivery because there is a compounding effect as work flows. If the effects are positive in nature, the flow increases in size. If they are negative, flow is constricted and the arrow would shrink in size, gating your ability to be truly productive or deliver highly-valued results.

And there are other factors that affect productivity. Organizational culture is one example. A command and control, task-oriented, metric-heavy organization is not conducive to innovative thinking and can place limits on what an organization can achieve.

The framework that I’m discussing here is broad in scope, but each area can be defined and examined (and my intent is to do so in future posts). The following are some immediate thoughts that come to mind:

  • The business objectives that focus on delivering the highest possible value. How well-defined and communicated those objectives are, how well they match the organizational objectives in terms of providing value – or the potential for profit.

  • The organizational context that the development organization is a part of. Organizational norms, reward/recognition systems, communication and collaboration mechanisms between the development organization and the customers all influence productivity.

  • The knowledge, skills, and abilities of the people working in the development organization. This includes managers, project managers, quality assurance, developers, documentation, build and release engineers – anyone that is a part of the organization that delivers the final software product. Asessing and managing individual performance is a vital area, and often done poorly.

  • Processes and tools used to monitor and facilitate the work. Regardless of what process you use, examining how well you are executing and whether there are impediments that need to be addressed is an on-going process.

  • Metrics to measure and compare yourself against industry norms or an internal baseline are important. You can’t know how well you are doing without some measurements in place.
As always, I welcome your comments and invite anyone to contribute to this blog if you feel so inclined.