Productivity Project

For the last six months, a team with members from both Sun Microsystems’ Software Group and from the Chief Technologist’s Office has been working on a new system to measure software engineering team productivity. This grew out of discussions about the Global Engineering Cost Tool, an internal process and web-based tool developed two years ago in a collaboration between Sun’s Chief Technologist’s Office, Human Resources, Workplace Resources, and Finance.

The Global Product Engineering Cost Tool provides high-level cost comparisons of Sun’s Global Product Engineering (GPE) locations. The Cost Tool provides a reliable and easy to use application that is available long-term, providing the same data about each site, using the same assumptions and updated on a regular schedule. The tool provides a planning vehicle to compare GPE sites. The information in the Cost Tool is static in nature (estimates) and does not reflect the real actual cost. Information is only included if reliable and consistent data is available.

When we contact the Cost Tool users and stakeholders for satisfaction ratings and suggestions, their need for additional non-cost information has often been raised. We finally put on the Cost Tool home page

“Quantified costs do not include many key factors which need to be assessed when considering the advantages of a site. Availability and quality of talent, ease of doing business, ability to distribute team/work, productivity, and other factors must also be evaluated.”

Of these non-cost areas not in the Cost Tool, productivity information seems to be most requested.

After the Cost Tool signoff meeting last December, Tanya Jankot and I got into a discussion with one of our executive stakeholders about productivity. After much talk, we realized that productivity is a high-level measure that is a function of many distinct and often unrelated factors. Without general agreement on the influence factors, success measures, and costs that contribute to productivity and their relative correlation to it, it is impossible to measure and influence productivity effectively. There is a need to understand the factors that contribute to productivity which can be controlled so that it will be possible to begin to measure, analyze, and influence components of productivity.

We first did a great deal of research on what productivity information and systems were already available. We considered the writings and ideas of Barry Boehm, Frederick Brooks, Alistair Cockburn, Geert Hofstede, Walt Scacchi and many others. We then started talking with Sun executives. After reviewing publications from business, government, and the academic world, plus holding dozens of interviews, we came to some conclusions:

  1. The type of work a software team does has a strong influence on how its productivity is measured. That is, if a team is fixing small bugs to order it might be measured in terms of lines of code or function points but if a team is creating a new feature or engaged in innovative software research,
    the measurements are different.
  2. There are more and more widely used systems for measuring productivity in teams working at the level of fixing bugs to order than for teams doing software research.
  3. Whether a software team is all in one location or is split between locations and whether their manager is located with them or is working at a distance has a strong influence on their productivity.
  4. There does not seem to be an existing system that can easily measure productivity in the full range of types of software projects.

25 October 2013 – formatting and links updated

1 Comment

Filed under Mentoring & Other Business

One response to “Productivity Project

  1. One other complication: different factors affect productivity at the project and site levels. For example: starting up a large project in a site that has hitherto hosted multiple small projects may increase overall productivity at the site, because of improved visibility, role models, learning opportunities, etc. In such a situation, it’s hard for individual managers to disentangle the micro from the macro and identify things that they can do within their own project.Of course there’s one productivity enabler that is so obvious that I shouldn’t have to mention it (but unfortunately….). Anyone managing a remote team should be required to visit that team regularly, and to meet with site management when they do so. And “expense” is not a valid objection: the cost of such travel should be factored into the original budgetary analysis for establishing a remote team.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s