Labor Productivity: An Excerpt From The Metrics Minute

Definition:
Labor productivity measures efficiency of the transformation of labor into something of higher value. Labor productivity (typically called productivity) is a fairly simple manufacturing concept that has been found itself useful in IT. Productivity is the amount of output per unit of input; an example in manufacturing terms can be expressed as10 widgets for every hour worked. Labor productivity is a powerful metric, made even more powerful by it’s simplicity. At its heart, productivity is a measure of the efficiency of a process (or group of processes). That knowledge can be tool to target and facilitate change. The problem with using productivity in a software environment is the lack of a universally agreed upon output unit of measure.

The lack of a universally agreed upon, tangible unit of output (cars in an automobile factory, steel from a steel mill) means that software processes often struggle to define and measure productivity because they’re forced to use esoteric size measures. IT has gone down three paths to solve this problem. The three basic camps to size software include relative measures (e.g. story points), physical measures (e.g. lines of code) and functional measures (e.g. function points). In all cases these measures of software size seek to measure the output of the processes and are defined independently of the input (effort or labor cost).

Formula:
The standard formula for labor productivity is:

Productivity = output / input

If you were using lines of code for productivity, the equation would be as follows:
Productivity = Lines of Code / Hours to Code the Lines of Code

Uses:
There are numerous factors that can influence productivity like skills, architecture, tools, time compression, programming language and level of quality. Organizations want to determine the impact of these factors on the development environment.

The measurement of productivity has two macro purposes. The first purpose is to determine efficiency. When productivity is known a baseline can be produced (line in the sand) then compared to external benchmarks. Comparisons between projects can indicate whether one process is better than another. The ability to make a comparison allows you to use efficiency as a tool in a decision process. The number and types of decisions that can be made using this tool are bounded only by your imagination and the granularity of the measurement.

The second macro rational for measuring productivity is as a basis for estimation. In its simplest form a parametric estimate can be calculated by multiplying size by a productivity rate.

Issues:
1. The lack of a consistent size measure is the biggest barrier for measuring productivity.
2. Poor time accounting runs a close second. Time account issues range from misallocation of time to equating billing time to effort time.
3. Productivity is not a single number and is most accurately described as a curve which makes it appear complicated.

Variants or Related Measures:
1. Cost per unit of work
2. Delivery rate
3. Velocity (agile)
4. Efficiency

Criticisms:
There are several criticisms of the using productivity in the software development and maintenance environment. The most prevalent is an argument that all software projects are different and therefore are better measured by metrics focusing on terminal value rather than by metrics focused on process efficiency (artesian versus manufacturing discussion). I would suggest that while the result of a software project tends to be different most of the steps taken are the same which makes the measure valid but that productivity should never be confused with value.

A second criticism of the use of productivity is a result of improper deployment. Numerous organizations and consultants promote the use of a single number for productivity. The use of a single number to describe the productivity the typical IT organization does match reality at the shop floor level when the metrics is used to make comparisons or for estimation. For example, would you expect a web project to have the same productivity rate of a macro assembler project? Would you expect a small project and a very large project to have the same productivity? In either case the projects would take different steps along their life cycles therefore we would expect their productivity to be different. I suggest that an organization analyze their data to look for clusters of performance. Typical clusters can include: client server projects, technology specific projects, package implementations and many others. Each will have a statistically different signature. An example of a productivity signature expressed as an equation is shown below:

Labor Productivity=46.719177-(0.0935884*Size)+(0.0001578*((Size-269.857)^2))

(Note this is an example of a very specialized productivity equation for a set of client server projects tailored for a design, code and unit testing. The results would not representative a typical organization.)
A third criticism is that labor productivity is an overly simple metric that does not reflect quality, value or speed. I would suggest that two out three of these criticisms are correct. Labor productivity is does not measure speed (although speed and effort are related) and does not address value (although value and effort may be related). Quality may be a red herring if rework due to defects is incorporated into productivity equation. In any case productivity should not be evaluated in a vacuum. Measurement programs should incorporate a palette of metrics to develop a holistic picture of a project or organization.

The interview in the SPaMCAST 94 features my interview with Ivar Jacobson covering the Software Engineering Method and Theory or SEMAT initiative. The interview is part of a set of three interviews that I had with Ivar, Bertand Meyer and Richard Soley. The three luminaries are leading an effort to pull together a common core for software engineering and then to provide a framework for integrating new ideas. A very ambitious and somewhat controversial task. All three interviews were incredible and together provide a broad foundation to understand and interact with SEMAT.

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing has hit the bookshelves! According to Robert C. Anderson, Director, Process Development and Quality Assurance, Computer Aid, Inc, “Mastering Software Project Management is a masterpiece of clarity, organization and depth of practical knowledge.” If you a project manager or know project managers buy yourself a copy and a second to lend co-workers!

Contact information for the Software Process and Measurement Cast
Email: spamcastinfo@gmail.com
Voicemail: +1-206-888-6111
Website: www.spamcast.net
Twitter: www.twitter.com/tcagley
Facebook: http://bit.ly/16fBWV

Codes of ethics are a compilation of individual statements of ethical principals into a framework to guide behavior.  Most every human being embraces a code of ethics by default whether it is provided by religion, society, their work or organizations and associations.  I recently asked friends I work with how many codes of ethics they are bound with and after a bit of discussion the average was four.  Examples included IFPUG, PMI, IEEE, SEI, society and religions.  Kevin Brennan, Vice President for Professional Development of IIBA, twittered me that codes of ethics are expected for a group to define itself as a profession and required for certification bodies under ISO 17024. 

I would be the last person to suggest that codes of ethics are a bad idea.  The combination of proliferation of codes combined with their relative complexity however does give me pause.  Example of the complexity of common of codes of ethics is demonstrated below

Examples

• IIBA: Code of Ethical Conduct – 22 items
• PMI : PMI’s Code of Ethics and Professional Conduct – 36 items
• IEEE: Software Engineering Code of Ethics and Professional Practice – 80 items

I have read these codes carefully.  All three are good however I doubt very few people can recall any of these codes verbatim which reduces their overall effectiveness.  Layer on top of association codes, corporate codes like the great code of ethics from Lockheed (approximately 17 items found at www.lockheedmartin.com/data/assets/…/ethics/setting-the-standard.pdf) and the complexity level goes up.  I said all of this complexity gives me pause; pause because I would like to see process improvement professionals embrace a code of ethics but I do not want to increase the level of ethical complexity unless it has value.  I think we can keep this deadly simple.  The code I am proposing is

Process Improvement Code of Ethics

1. Treat others as you would like to be treated  (Golden Rule)
2. Follow a process to create and maintain processes (eat your own dog food)
3. Meet the commitments you make (do what you say you your going to do)
4.  Avoid personal conflicts of interest
5. Only pursue changes that benefit the organization
6. Make decisions as transparently as humanly possible

I would suggest that this code is simple and to the point.  Note, I make the assumption that you’re adhering to laws and that lying, cheating and stealing your neighbor’s Butterfinger are not on the table, based on other codes of ethics. 

What is missing? If you adopted these ethical guidelines how would they affect your projects?  How would they affect your professional life?   I am looking forward to your input, reactions and suggestions.  I would also like your opinions on whether ethics and process improvement should be discussed in the same context.

Project and Process Improvement Ethics:  A Primer
Part 1: What are ethics and why do care?

 I recently overheard an offhanded comment that went something like, “if you aren’t cheating, you are not trying hard enough.”  This was after watching a handball in the goal at the recent World Cup soccer tournament and then having a soccer coach suggest that kids are taught that technique to defend against a sure goal through the use of a handball.  These are issues of ethics.  What are ethics?  What is the purpose of ethical frameworks?  Why should they matter to those who manage process improvement? 

 The definition of ethics founds in Wikipedia[1] states that ethics is a branch of philosophy that addresses questions about morality—that is, concepts such as good vs. bad, noble vs. ignoble, right vs. wrong, and matters of justice, love, peace, and virtue.  Hardly the stuff of project management or process improvement, however there is a branch of ethics called applied ethics (doesn’t that sound much more practical) that seeks to address our daily business lives.  Applied ethics seeks to identify the morally correct course of action in various fields of human life; business ethics are a form of applied ethics.

 Interest in ethics waxes and wanes over time, they tend to wax when things go awry.  Obvious examples abound such as Enron when things went up in flames ethics became a hot topic, at MCI during their accounting debacle and even during the BP Oil well crisis but there are less obvious examples such as the spin to under play a risk in a status report or when someone occasionally conflates effort and progress when a project is behind.  Each of these examples is a matter of ethics and unless a framework or code is in place to highlight these transgressions, large or small, and so they are noticed and discussed nothing can be changed.

 What purposes do ethical frameworks (groups of ethics that have been consolidated into laws, codes of conduct, and codes of ethics) serve?  I would suggest that most ethical frameworks serve two common purposes.

 The first purpose is to guide behavior so that it is predictable.  Codes provide a path to guide both the organizations actions and the individuals within the organization actions (to an extent they can be different).  Codes of ethics, codes of conduct and the effort to enforce them help to identify deviant behavior before it can injure the organization.

 The second purpose of codes of ethics is as announcement to the larger world the set of higher order rules an organization intends to follow.  Codes of ethics gengerally reflect the rules and norms of the larger external society the organization interacts with. 

 Why should ethics matter to those who manage process improvement?  I suggest that ethics evolve to guide behavior and provide all affected parties with an understanding of how people (and people proxies) should act.  Rules, laws and manifestos (statements of principles and ethics) are how ethics are applied in the real. The rule, “Thou shall not install un-unit tested code” creates a set of expected behaviors and a set of obligations on all parties.  Living up to the rule is a matter of ethics.  The translation of ethics into codes of conduct, rules, laws or other codes provide a line in the sand so that you can judge whether an action is ethical or not.  The more black and white the ethics rule is the easier it is to follow in real time.

 Most corporate codes of conduct or ethics (a set of rules that describe the behavioral expectations of employees) do not address some of the more specific issues with which a project manager of a process improvement projects will need to wrestle.  What can be done? 

 I have recently begun each of my process improvement projects by establishing a process improvement manifesto.  The exercise has many benefits; however the primary goal is to help empower the team to make the decisions without having to get permission.  The manifesto acts a basis to form very specific code of ethics to shorten the decision making loop which will improve efficiency for normal IT projects and process improvement projects.

 Part 2 – Suggestions for a Process Improvement Project Manifesto

[1] http://en.wikipedia.org/wiki/Ethics

Five attributes determine whether collaboration will work and deliver the value you expect. 

Ability is the first of the five to understand.  Ability describes the group of attributes that are required to actually describe and/or resolve the problem. In the category of ability I would include attributes like knowledge, expertise, and ability to learn, listen and analyze to name a few. A group without the capacity to tackle a problem or without the skills to be able to learn to tackle a problem will fail more times than not.

 Authority describes the power or right to give orders or make decisions.  Collaborative teams must have the appropriate level of authority to make the choices required to deliver, to meet their commitments. I would suggest the authority delegated to the team provides the tools to leverage the resources needed to deliver.  The team must have clear directions on the level of authority they have been granted and what processes must be used to gain approval for decisions that are beyond their levels of authority.  As Mike Burrows (@asplake on Twitter) pointed out when discussing the difference between control and authority, “When you delegate authority you demonstrate to all that you trust someone (or some team) to get the work done.”

 Trust is a term that has many layers.  Teams must trust each other’s motives.  Solving the problem, meeting the goal must be the paramount goal of all of the members of the collaborative team.  When members believe someone has an ulterior motive, they will tend to ostracize that member or at the very least de-value their contribution.   In many instances groups use team-building exercises to build this trust; however trust isn’t about exercises is about understanding motives.  Macavelian politics and collaborative groups are not good bed fellows.

 Commitment is a sense among two or more individuals that they will do what it takes to deliver the project and that level of effort will be matched by the others. Commitment is a multilayered concept; commitment can be assessed against the goal or the success of the team.  Interestingly I would suggest that even though commitment to goal and commitment to team are different concepts they have the same end effect.  All of the members of the collaborative team must embrace one or the other.  Commitment is the fuel that keeps the group moving forward. 

 Another type of commitment is the commitment of the organization to support the collaborative team; in essence, the commitment is to having the problem solved.  This is more than management support. The whole organization will need to change.  Many collaborative teams fail because they do get the support they need from the organization.

How important is commitment?  As note in “User Commitment and Collaboration:   Motivational Antecedents and Project Performance,” commitment is so important that the level of commitment to the goal is predictive of the success of collaborative efforts.  The research strongly suggests that commitment is critical for both making collaboration happen and the ultimate success of the collaborative effort.   When commitment falters, trust will also, therefore leaving a group of competing humans rather than a team.

The final attribute of successful collaborative teams is recognition – at the very least anticipation that they will be recognized before they deliver and the realization of that recognition when they do.  Without the anticipation of recognition, commitment will falter.  Recognition is the motivator that pushes a team toward a goal.  It is the brass ring off in the distance.  Without recognition you have to rely on the pure altruism of the team or individual political motivation.  Organizations as diverse as NASA and CISCO have gone as far as incorporating recognition of collaboration into their bonus programs.

Summary

Collaboration is a nearly ubiquitous problem-solving technique used in today’s business environment.  As a tool it is not perfect; it can be slower than individual strokes of genius; at times it can deliver watered down solutions; and collaborative teams can lose their ability to think outside the box.  On the other hand, collaborative efforts can marshal many points of view to create solutions no individual stroke of genius would be able to deliver.  Given the power of this technique, it is important to have the knowledge of what it takes to actually make a collaborative effort work.  Synthesizing a group of individuals into a collaborative team requires a combination of ability, authority, commitment, trust and recognition.

Collaboration: The New Duct Tape Part 2
Thomas M Cagley Jr.

For all of the good points of collaboration there can be drawbacks. I would like to highlight four of the most prevalent in an attempt to immunize your collaborative efforts from failure.

The first potential issue is speed. Collaboration can deliver slower than other problem resolution techniques. Why? In any type of team effort, you need to balance multiple points of view which means collaboration can be slower than a single stroke of genius or insight. The need to balance multiple points of view will require spending the time and effort needed to hear and understand all parties. When using collaboration techniques I strongly suggest monitoring against analysis paralysis to ensure decisions and interactions are focused on being efficient. A sweat test (e.g. set a specific amount of time for considering options) can be used to decide on a cutoff when a team can’t coalesce.

A second potential issue stemming from the same root is the potential for a watered down solution being delivered. The process of coalescing on a solution based on multiple points of view might mean that the solution is more than the sum of the parts or watered down due to compromise. One rule to remember is that all parties don’t have to agree with the solution you deliver but rather be able to live with the solution. It has been said that the camel is a horse designed by committee (or vice versa). One important mechanism to use to keep the team focused is to make sure the goal is crystal clear. Ensure the expectations for results have been defined to ensure the team hits the mark and has a yardstick to judge the solution the put forward. Developing an under optimized solution is a failure.

Teams can become stale. One indication of a staleness is a team exhibiting the “all problems are a nail if you have a hammer syndrome”. In other words a team that constantly reuses the same set of solutions rather than innovating. Constant investment in bringing new ideas, concepts and experiences to the team is required to ensure the possibility of delivering new and innovative solutions. The word investment does not necessarily mean spending money; rather many times it means the investment of time for learning or exposure. Building an environment of continuous exploration and learning is critical for long-term health of the collaborative team. Stagnation is the single largest reason for collaborations to fail over time. Stale is bad whether you are dealing with potato chips or teams.

Strong personalities are a requirement for leaders of all types. Collaborative teams must embrace strong personalities but not at the expense of allowing the strong personalities to drown out or overwhelm all other inputs. I suggest that all teams be trained in moderation and that the team set expectations for collaboration. Teams with a single voice are not collaborative.

Most of the drawbacks are not inherent in collaborative techniques rather the drawbacks tend to surface when collaboration is done poorly or incorrectly.

Part 3: “What makes collaboration work?”

Kanban: Successful Evolutionary Change for Your Technology Business

By David J. Anderson

A Review by Thomas M. Calgey Jr.

Kanban is not a household word in the information technology world.  That fact, however, might be about to change because of David J. Anderson’s new book, Kanban: Successful Evolutionary Change for Your Technology Business.  Mr. Anderson has provided the IT world with a very assessable treatment of a concept that has been embraced by many organizations in the manufacturing world but has made slower progess in the IT environment.  In a progressive series of steps, Mr. Anderson walks the reader through how Kanban works with real life examples.  The mixture of theory and practice provide the reader with food for thought and practical advice that can be applied the real world.

Kanban, which means signal card in Japanese, has been a staple in auto manufacturing through its application in the Toyota Production System (and in lean manufacturing environments).  Fitting kanban into product development and systems engineering has been more problematic.  More typical IT processes work through a process of pushing work through IT processes with work piling up at bottlenecks.  Kanban works by pulling work though the development value chain (David points out that any workflow that involves a division of labor can be defined as a value stream) rather so that work-in-process (WIP) is minimized.  Kanban is a simple concept but its application can challenge many of our previously held notions of how IT organizations should work.  Here is an example of a concept that is presented in Mr. Anderson’s book:  The concept of kanban forces you to reconsider the definition of a project.  Kanban creates a predictable flow of individually prioritized work items coupled with periodic releases which doesn’t fit the common definition of an IT project.  This is a potentially heady discussion but David provides a step-by-step approach that will leave you wondering why you haven’t integrated Kanban into your shop sooner.

Kanban as a concept and methodology is not for the faint of heart, but if you want to wrestle with effectiveness and efficiency, if you want to minimize work in process with the attendant reduction in risk and overhead then. Kanban: Successful Evolutionary Change for Your Technology Business by David J. Andersen is the place to start.  Kanban might not be a household word today but tomorrow will be another story.

Collaboration: The New Duct Tape
Thomas M. Cagley Jr.

The economic crisis of the past few years has caused organizations great and small to actively chase innovation.  Just what exactly innovation is and how it can be measured is are hotly debated topics.  Even though everyone wants to be an innovator, we will ignore the definition of innovation for the time being and focus on one of the primary tools being leverage in the pursuit of innovation, collaboration.  We will focus on collaboration because done correctly; collaboration is the duct tape of the business world. 

Collaboration is typically defined as two or more people working together to solve a common problem or in pursuit of a common goal.  Two components of the definition get to the crux of what makes collaboration work.  The first is the phrase “two or more people” because you can’t collaborate by yourself.  Without different points of view much of the power of the technique is lost.  Second is the phrase, “common problem” or “common goal”.  The common goal acts as the focusing mechanism for the overall process.  Combining these two concepts means that collaboration works through social interactions focused on a common mission.  Done correctly collaborative efforts deliver synergy, addresses complexity and fosters involvement.

The makeup of the team is a major component of the success of any collaboration.  Rogers and Hammerstein combined scores and lyrics into fantastic songs, creating something greater than the simple sum of the parts.  Great sports teams attain championships when they combine complementary skills which allow them to tackle problems that they are not capable of addressing individually.  In brainstorming we are taught to build on the ideas of others; to dovetail ideas.  Combining and building on the ideas and thoughts of the team is synergy.

Businesses don’t create collaborative teams to tackle the simple problems.  When was the last time you formed a collaborative team to decide when you were going for lunch?  Never?  But there probably was a group created (hopefully collaborative) to decide where the entire office would go for the last holiday lunch.  Collaboration is a reflection of the maxim that two heads are better than one (on different people).  Many times multiple points of view are required to solve problems that can’t be easily described or solved individually.  Collaborative groups allow problems to be viewed from multiple points of view which allows the team to describe problems and solutions in a more robust manner which is one technique for dealing with complexity.

Collaboration can used to build buy in for the solutions that are generated.  Naomi Karten in her book, Changing How You Manage and Communicate Change, said “that even a minimal sense of control can go a long way towards easing the stress that people feel.”  Collaboration is one means of providing a means for participation yielding a sense of control.  Each voice on the team is a representative of a constituency that is being voiced as the solution is crafted.  As part of implementing the solution it must be expected that the individual representatives support and sell the solution to their constituencies. 

Part 2 –Attributes of Collaborative Teams

From one of SPaMCAST’s great supporters! 
Pat has just released a new eBook which I am in the process of reviewing (short story – I got a lot from it)  but I wanted to let everyone know about the book while I wordsmith the review.

FOR IMMEDIATE RELEASE:
STRATEGIC BUSINESS DECISIONS, Inc. eBook on how technologists can avoid becoming a commodity

Montclair, NJ – May 15, 2010 – Technologists are feeling the crunch. What they loved to do is diminishing in actual pay. The world of work is changing rapidly and it is time to dust off some skills and make Engaging With People Not Like You a priority to survive in this global world.

A Technologist’s Guide To Performing & Surviving In The New World (Parrotology: Stop Being A Commodity & Become Irreplaceable) is now available. An eBook that points out the truths of how the business community views technologists. An eBook that provides tips that can be incorporated into a technologist’s daily actions and be noticed by those with impact. Topics include:

• How to be someone of value to those around you.
• How to be a trusted advisor to powerful individuals.
• How to be a linchpin between different perceived groups facilitating positive action.
• How to be creative, inspiring, and proactive in accomplishing great things.
• How to take personal pride in achieving something greater than oneself.
• How to personally connect with individuals and groups that do not think or act like you.
• How to become indispensable to all of the different communities on the business side of the company.
• How to be someone others go out of their way to spread good words about you.

It is up to the technologist. Visit the Parrotology Launch Pad to learn more! Download the free Self Assessment and see how good you really are at engaging. Individual sections are available for $4.00. The entire 291 page eBook can be purchased for $10.00.
 

About Pat Ferdinandi. Pat calls herself a Chief Thought Translator (aka Business Architect and President of SBDi) due to her ability to communicate effectively with those not like her with a touch of realism and levity. The purpose of everything Pat does is to assist with architecting and translating business ideas. Her goal is to lead clients to a path of greater profitability through becoming better educated and equipped to meet the relentless cycle of change.

About Scarlet. Scarlet is the underlying ghost squawker for this eBook. She is a beautiful parrot that is smart, witty, and playful. Why the correlation to parrots? To add levity to a sensitive topic. Because parrots learn how to get their needs met by using human speech…the same way business users try to get their needs met and try to use (incorrectly most of the time) techie speak.

Contact: For more information, contact Pat Ferdinandi, Chief Thought Translator, Strategic Business Decisions, (973) 509-9427, info@SBDi-Consulting.com, www.SBDi-Consulting.com.

Reflections on Podcamp Cleveland
Thomas M. Cagley Jr

Preparing to giving a speech, even one that should easy, is a time to reflect on your audience and what connects you with that audience. It is a time for reflection and introspection.  As I prepared to give the “rock star” speech for Podcamp Cleveland last weekend ( May 1, 2010), I spent a while talking with my wife about the types of people we had met at the numerous podcamps we had attended in the past three or four years.

I suggest that Podcampers fall across a continuum bound at one end by hobbyists and at the other by professional marketers. All connected by content and all struggling  to find a way to use content for branding whether personal branding or product branding is both material and immaterial.  While I suggest that the extremes define the center, the core of value of an unconference is that everyone brings something to the table that is useful.  Podcampers can use that knowledge to begin to define their personal brand (just ask the unemployed project manager why brand is important) or to hone well defined branding programs which brings me back to the rock star speech. 

I do not know whether Christopher Penn and Chris Brogan knew the movement they began would unite all social marketers or not.  But they did know that we are all rock stars.  We are all rock stars because we can change the world, whether our own world or the wider world is merely a matter of degree.

As many of you know, I interview Cheryl Jones on the SPaMCAST 82 – Cheryl Jones, PSM, Optimism .  If you are interested in PSM specifically and measurement general I would suggest checking out 14th annual PSM Conference.

PSM 14th Annual Users’ Group Conference, 26-30 July 2010
New Orleans, Louisiana

I want to invite each of you to attend our Practical Software and Systems Measurement (PSM) 14th Annual PSM Users’ Group Conference.  It should be a terrific conference!  The theme this year is “Ensuring the Integrity of Measurement Information”.  We will discuss how to making measurement information useable for decision makers.  Presentations will cover implementing and using fact-based information, measurement to support improved life cycle decision making in an evolving environment, business intelligence using fact-based measurement and risk management information, using measures to improve efficiencies and guide performance improvement, measuring affordability of systems and software, and measurement at the enterprise, organization, and project levels.

The conference is being held at the New Orleans Marriott at the Convention Center in New Orleans, Louisiana this year, a venue that provides great opportunities for networking in a relaxed and fun atmosphere. This is a fabulous city, and all participants will receive a reduced hotel rate of $89 per night (this is less than the per diem rate). There are many nearby attractions including the French Quarter. The registration form is available on the PSM web site, under “Events”.

Please note – you will receive the reduced conference rate if you submit your registration and hotel reservation by June 18th.

At the conference, there will be keynote presentations, as well as a series of presentations by measurement practitioners and users, with a focus on actual implementations and lessons learned.  We will also host a series of interactive workshops to explore various measurement topics. Workshops are being considered in the areas of: Decision Making in Engineering Management, Organization/Enterprise Measurement, Risk Management and Measurement, Advanced Analytical Techniques, Sample Measurement Specifications, Systems and Software Estimation, Measurement for Service Management, Measurement for ERP systems, and Maintenance Measures.

The conference will begin with a 1-day training session, for those who are new to PSM, and a 1-day session for PSM trainers, to review the revised training course.  A preliminary agenda with presentations and workshop descriptions will be posted on the PSM web site (www.psmsc.com/events.asp), as plans are finalized.

If you are interested in providing a presentation, or hosting a workshop, please review the call for speakers that is available on the PSM web site, and send in an abstract.

For more information, contact the PSM Support Center at PSMUG2010@psmsc.com, Dave Morris at 703-405-2191, or Cheryl Jones at 973-724-2644.

Outsourcing:  Metrics and Governance
Thomas M Cagley Jr.

Successful outsourcing arrangements require that all parties pay continuous attention to the goals of the arrangement.  The phrase ‘continuous attention’ is nearly an oxymoron given differing corporate cultures, short attention spans and competing channels of information.  Outsourcing contracts often contain one or more tools intended to focus attention (typically as a portion of the governance convents). The tools currently in vogue include metrics, service level agreements, balanced scorecards and the prescription of CMMI®[1] maturity levels.   In many cases these tools are used as weapons to interrogate and control the parties in the contract.

The goal of governance is to manage and reduce risk. A better practice is to construct governance covenants so that they build and strengthen the capabilities of both parties. CMMI, metrics and scorecards done correctly can fall in this category while at the same time mitigating risk. The choice of tool and the construct of the governance convents are as critical as the financial portions of the contract. All too often, the development of the governance processes is by contract personnel without a through understanding of process or metrics. The lack of process or metrics knowledge is exacerbated when the idea is championed by parties on one side of the table or other (Note: Someone has to champion the concept or most outsourcers will run, not walk, away from the idea.  Each side of the negotiation needs to have a metrics counsel.). These scenarios lead to agreements governed by convents that incent unbalanced behavior, that do not add capabilities or strengthen the relationships between parties to the contract.  Examples can be found across a range from contracts which pay penalties and bonuses on a single metrics (typically indexed productivity or time-to-market) to contracts with scores of embedded metrics which sap time and effort from delivering value. Soliciting input from and the involvement of your organizations process and metrics personnel (or consultants if you do not have these capabilities) is a best practice that does not find its way into many contract negotiations.

There are many techniques that can be used to facilitate developing a balanced approach to using metrics in the governance process. Goal driven metrics techniques are processes for developing useful metrics for the core of contract governance.  A few of the techniques that have been found useful include:

1. Goal, Question, Metric (GQM)
2. Practical Software Measurement (PSM)
3. Goal-Question-Indicator-Measurement (GQIM)

 

A basic tenant of all of these techniques is to begin with an understanding of your business goals. A through and honest appraisal of the reasons why you are outsourcing will allow you to build a set of measures that have a chance at allowing you to know whether those goals have been met. The set of measures will also provide a filter to discriminate between what data will provide information and which will provide extraneous noise (this requires a careful and thoughtful understanding of data analysis).  Without the use of goal driven approach it is possible that the contract will incent behavior that does not accurately reflect the goals, targets and objectives of executive management (an old adage points out that you get what you measure).

As noted earlier the two worst-case scenarios typically are a focus on a single goal (cost reduction, increased productivity or better quality) or the development of scorecards with too many contributors (if you need an econometric model to understand the impact of metric you certainly have gone too far). Kaplan and Norton’s work on the Balanced Scorecard has certainly driven the point home that a single view of performance is at best not very useful and more than likely dangerous.  At the same time balanced and overly complex do not have to be synonymous concepts.

Dashboards and scorecards are excellent summarization techniques however they are not adequate to develop knowledge or to direct action. A granular level of detail will provide organizations with the facility to have event-centric and experience-based interaction with data in order to generate actionable insights rather than to rely purely on personnel interactions. Granular, query-able data will allow you to develop mechanisms to defeat the tyranny of average, which looses the ability to identify special cases (both good and bad).

Continuous attention does not have to be an oxymoron.  It does mean all parties in an outsourcing arrangement must decide on what is important when the contract is being framed (and have the guts to change when the business dictates). This process provides a basis from which to develop a well-grounded metrics program that will let you know if you are attaining your goals while increasing capability and value.

[1] Capability Maturity Model Integration® and CMMI® are registered trademarks of Carnegie Mellon University.