Measure data that incentivizes behavior that moves you towards your goals.

Measure data that incentivizes behavior that moves you towards your goals.

The are three basic goals for measurement. The first goal is to drive change in an organization. The second goal is to use measurement as an enforcement tool. And the third is to provide data for other processes or decisions (estimation, for example).  The third of these goals is the most mundane and is the easiest to implement, therefore is where metrics implementations start.

Metrics programs that are part of a goal to drive change are considered of having reached the pinnacle of metrics program value (goal one). Metrics programs reach this level when they participate in identifying opportunities to make changes by data analysis.  Sifting through data, identifying potential changes and using measurement to guide change is a strategic  for organizations that want to evolve toward higher levels of capability. Unfortunately, most metrics programs do not have the time to follow this evolutionary approach. Organizations find it difficult to achieve the constancy of purpose required to gather the data and wait for the amount of data to reach the threshold needed for solid statistical analysis and data mining.  A second approach is to follow a more aggressive strategy. The intent of this approach is to go looking for areas or groups in pain.  When you identify a group in pain, use measures and metrics to help them find and prove the change that would remove their pain.  This is a opportunistic approach to measurement that links measurement with process improvement to create valuable change.

The second goal, measurement as an enforcement mechanism, is a bad idea.  Avoid being forced into this role.  Making measurement personnel into process police will politicize measurement and requires tons of effort for little value.  This usually happens in organizations where line management is spread too thin to actively manage people and processes. Measures are often used to answer the questions:

  • Are changes being adopted?
  • Are changes providing the expected rate of return?
  • Who is playing, and who is not?

Metrics programs spend the majority of their time and effort supporting the gathering and supporting other processes and decisions (the third goal). While important, the support role is the least obvious to the decision making portions of an organization. Metrics groups that only service the data needs of other groups in the organization are apt to be viewed as overhead, not as strategic assets.  The question will always be asked whether measurement over had can be cut therefore the measurement team will all be at risk.

Bottom Line:  Metrics programs deliver the most value when they are focused on finding and actively participating in delivering change within organizations.  When metrics programs are the measurement arm of the process police or just supporting other, more valued teams (like estimators) they can easily be branded as overhead.  All metrics organizations need to work on refocusing their efforts at getting involved in change, while supporting other process.  Being branded as overhead is dangerous for your career.

Essay from SPaMCAST 58 (short and sweet)

Relevance is power

Irrelevance is desperation

Relevance is perceived

So is Irrelevance.

CMMI, ITIL, Six Sigma, agile, waterfall, software development life cycle and extreme programming . . .what do all of these terms have in common?  They are models.  In a perfect world, models are abstractions that we find useful to explain the world around us.  Models work by rendering complex ideas more simply.  For example, both a road map and picture rendered in Google Earth are models.  Two very different types of models:   an abstraction of a set roads, buildings, parks and plants that exhibit can provide more information than rendering.  Real life is complex, Google Earth is less complex and the road maps are the least complex.  Simplifying a concept to a point allows understanding while too much simplification renders the concept as a pale reflection.  Oversimplification can lead to misunderstandings or misconceptions, for example the conception that agile methods are undisciplined or that waterfall methods are bureaucratic.  Both of these are misconceptions (individual implementations are another story).  According to Kenji Haranabe, software development is a form of communication game.  Communication requires that groups understand a concept so that it can be implemented.  Communication and understanding requires finding a level where common understanding based on common words can occur.  Words provide the simplification of real life into a form of model.  Unfortunately it is difficult to determine when enough simplification is enough.  Oversimplification of ideas can create scenarios where trouble can creep in.  Oversimplification can water down a concept to the point that it can not provide useful information to be used operationally.  An example of a very simple model is the five maturity levels commonly connected to the CMMI.  The maturity levels build awareness but provide little operational information.  I do not know how many times I have heard people talk about an individual maturity level as if the name given to that level was all you needed to know about a maturity level.   The less simplified version with process areas, goals and practices provides substantial operational information.  ‘Operationalizing’ an overly simplified model will yield unanticipated results and that is not what we want from a model.  I once built a model of the battleship Missouri that had horrible directions (directions are a model of a model), I used three firecrackers to remodel the thing I ended up with (which was not a very good model).

Models abound in the world of information technology.  If we don’t have a model for it t we at least have TLA (three letter acronym) for it and are working on a model that will incorporate it.  The models that have lasting power provide structure, discipline and control.  They’re also used as a tool to guide work (tightly or loosely depends on the organization) and as a scaffold to define improvements in a structured manner.  Models are powerful; molding, bending and guiding legions of IT practitioners.  The dark side of this power is that the choice of models can be definitional statement for a group or organization.  Selecting a model can elicit all of the passions of politics or religion.  Just consider the emotions you feel when describing Six Sigma, CMMI, eXtreme Programming, waterfall or agile.  One of those words will probably be a hot button.  The power of models can become seductive and entrenched so as to reduce your ability to change and adapt as circumstances demand.  A model is never a goal!  Define what your expectations are for the model or models that you are you using in business terms.  Examples of goals I would expect are of increased customer satisfaction, improved quality or faster time-to-market rather than attaining CMMI Maturity Level 2 or implementing daily builds.  Know what you want to accomplish then integrate the models and tactics to achieve those goals.  Do not let the tool be the goal.

Models are powerful, useful tools to ensure understanding, they provide structure and discipline.  Perform a health check.  Questions to ask about the models in your organization begin with:

  1. Is there is a deep enough understanding of the model being used? – With knowledge comes the background to operationalize the model.
  2. What are your expectations of value from the model? – Knowing what you want from a model helps ensure that the model does not become the goal and that you retain the ability to be flexible.

There are many other questions you can ask on your heath check however if you can’t answer these questions well stop and reassess, re-evaluate, re-train and re-plan your effort.

CMMI, ITIL, Six Sigma, agile, waterfall, software development life cycle and extreme programming. . . powerful tools or a straight jacket which is it for you?

As a leader of people is easy to become weary to your bones after trying to convince a reticent organization team, team or person to become a butterfly when all it seem to wanted to do is to stay in its nice safe cocoon. The forces lined up against you can be daunting. Don’t work against yourself by making your attitude part of the problem. Your attitude is one of your primary tools that can be used to lend credibility to your message and convince people to engage and befriend you. I would suggest that there are three attributes you need to consider managing immediately: defeatism, sarcasm and partisanship.

Negativism is a habitual attitude of skepticism or resistance to the suggestions, order or instructions of others. This includes change and the belief that change is warranted or even possible. Leading change requires that you believe that you can succeed to motivate yourselves and those you are trying to influence. Without a belief that you can succeed it will be difficult to get up in the morning and impossible to motivate others. I must at admit that I sometimes find that it is easy to confuse being highly rational with negativism. In the wee hours of the night make sure you evaluate which side the line you are on and make corrections if you have strayed.

Behavior such as sarcasm might be acceptable amongst friends, close friends that is (and I would suggest that overuse is wearing even on them). The impact of sarcasm is even less predictable when people do not know you or might have a different cultural filter are involved in the conversation. How many time have you heard “hey can’t they take a joke?” The answer is maybe not if it is apparently funny to their point of view. Frankly just dropping sarcasm from your portfolio of communication techniques might be the best idea.

Another critical mistake that can be traced back to attitude is a need to have an enemy to strike against. Creating a “we/they” environment creates barriers between groups will make finding common ground more difficult. I would suggest that rarely are the benefits of process improvements maximized when one side is forced to capitulate to another (difficult to compromise with someone you view as the enemy). Your must recognize that as a leader and a negotiator your goal is to find the best solution for your organization.

Sarcasm, negativism and partisanship will minimize your effectiveness as a leader in the long run will add to the burden you need to shoulder in order to make change happen. Leading change is not an easy job. Don’t make it harder than it needs to be. Your attitude can either a simple powerful tool or concrete block to tow behind you.

All organizations try to walk the fine line between what is perceived as productive activities (deliver product) and activities that are perceived as overhead. The line is razor thin and horribly difficult to recognize. Part of the reason that it is difficult to recognize is that no one actively pursues adding overhead to a project or process just for the sake of adding overhead. Overhead is added to meet specific perceived needs. Needs like time accounting, billing, status or the knowledge of when work will be delivered and how much it will cost. All of these needs are rational. The problem starts when you pile these types of information needs up. Each requirement draws time from somewhere such as from the time needed to create the output of a project or process or that other part of the day when you are not supposed to be working.

Once implemented the steps needed to collect the data, evaluate or monitor the process rarely go away at least until the process implodes and it is re-engineered. True re-engineering is rare because it is politically difficult and takes time away from the task at hand. The answer? Bite the bullet and re-engineer more often? Just say no and ignore the information need? Buy a tool? The envelope please . . . I would suggest a simple process.

1. Establish a philosophy that that has two primary tenants:
a. All process changes that can’t be directly tied to delivering the expressed
output of the project or process must be viewed as suspect (not bad or evil
just suspect).
b. All processes must be changed as organizational needs and environments
change (no process is ever perfect).
2. Review every suspect step or activity to ensure it that it is really needed not
just nice to have and whether the data might be available elsewhere.
3. Repeat the mantra “simple, simpler, simplest”. Anything that needs to be added
or changed in a process must be implemented in the simplest form possible that
fits the requirement.
4. When adding tools consider human usability not just the sales brochure.
Test to see whether the tool works well in the technical and cultural environment.
Investigate whether any suggested tool can be linked to other tools used in the
environment. Finally determine whether automating the work doesn’t add different
kinds of work somewhere else that might cancel the benefit.
5. Periodically re-engineer the process and any supporting business processes.
Remember your mantra. Consider starting with a blank page (zero based
process engineering) every other time you re-engineer the process.

A simple but powerful process.

Playing ostrich and ignoring information needs is rarely a good idea in the long run but neither is making indiscriminate additions to any process. Challenge all needs that add steps to your process to ensure they actually solve the specific problem. Once convinced (be rational and not obstinate) use the process described above to ensure an effective path is chosen. The line between required overhead and productive work is a fine line, step back occasionally and review which side of the line you’re walking on.

Compound The Interest In Process Improvement
Thomas M. Cagley Jr.

Audion version can be found on SPaMCast 43 (www.spamcast.net)

Sometime near the beginning of process improvement time W. Edward Deming documented his 14 Points for Management. One of those points struck me as I reviewed the course of software development and process improvement. The principle in question was constancy of purpose. Controlled changes are hard for many reasons but not staying the course once you begin a change is tops on my list of mistakes. Change usually begins with great fanfare and acclaim. Over time, events intervene (the famous stuff happens) which diverts attention and resources. Deming suggested that for change to have a positive impact, management needs to have constancy of purpose. Stated another way management must stay the course. This is not stay that once started a change program can never be modified, changed or abandoned. They all must evolve to meet changing needs but generally needs change slowly (unless financial derivatives are involved).

A time comes in every process improvement program or new development methodology deployment when interest wanes and the perceived value begins wane to a degree that something new begins to be planned. The point at which planning for the next big thing starts is a tipping point that marks the half-life of the process change. Every change has a half life. Your job as a leader is to extend the time it takes to get to the tipping point in order to maximize the value derived from any individual change. Keeping your customers interested in your program is a crucial tactic to delay the investable tipping point.

So who is responsible for stoking the fire of interest? Simply put the person or persons that are managing the change program. The role of maintaining interest is a blend of cheerleading, sales and guru-dom. Many process improvement leaders believe these tasks are beneath them therefore assign a staff member or decide that the purity of their vision should be enough to ensure movement toward the bright light of the future. That bright light in reality may well be the light to be an oncoming train. Quoting Colin Powell, “Leadership is solving problems. The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership.” Interest is your problem, your roles is to lead.

One of the reasons interest wanes is that other events overtake the initial burst of energy and rational. Without someone to act as a town crier, memory fades. You must refresh both managers and practitioners’ memory as to why the change is important, what the change is, what is in it for them and what pain the change seeks to solve. A coherent story requires that you have a good handle on why you are doing the project.

You must understand the pain you are trying to solve not just what you are going to deliver (one tends to be a reflection of the other). I suggest that to effectively communicate, begin by crafting a message around how you are solving your client’s pain. Then measure the results you are delivering to prove you are actually delivering on the promise of your solutions. Finally, talk to your clients (management and practitioners) about how you are solving their pain (at the same time validate that the bar has not changed). I also suggest soliciting testimonials from your clients. Testimonials coupled with your message are excellent tool support continued change.

Why is interest important? A lack of focused interest is a risk because the IT landscape can be described as needs chasing resources while the resources get squeezed putting process improvement personnel and process improvement budgets are at risk. Salespersonship and marketing are critical roles when managing a process improvement project. These talents and roles support both the initial process of making a change and also when you are sustaining a change. Recognize that like skin moisturizer, sales and marketing can extend the life of change program only if applied early and often. Further the program you are trying to focus interest on must deliver value. Your mission is not only to be a leader but a cheerleader, salesperson and a communicator.

Is Project Management Changing?
Thomas M. Cagley Jr

This is also included in the Software Process and Measurement Cast at http://www.spamcast.net

According to WIKIPEDIA project management is defined as:

the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives.1

In any definition of project management you will find the word planning is prominently identified as one of the critical roles of a project manager. Planning serves two major goals. The first is control and the second is risk avoidance. How are tools like texting and instant messengers affecting the planning and risk component of project management?

In order to answer the question we need to understand in general how planning and risk avoidance is accomplished classically. In many projects, planning is accomplished through the process of identifying activities and tasks at some level of granularity, the order these tasks are to be done, assigning resources, predicting how things might go wrong, how to avoid what might go wrong, and generally involving as many people as possible or at least as many as the budget can absorb. All of the activity, at least conceptually, will diffuse and avoid risk. Almost all of the activities attributed to project management are accomplished using formal meetings for consensus, templates to validate all bases are touched and documents to ensure knowledge is captured. In my opinion, for some types of projects and organizational cultures these methods make sense but for others they are complete madness.

The advent of tools for instantaneous communication has the possibility of rewriting complete swaths of project management. This is especially true for the project coordination and control components which foreshadow accelerating projects. Just shifting from the typical tactics for planning and risk avoidance/diffusion to a model of instant coordination and risk impact avoidance instead, will be a tectonic shift. The pattern shift changes the analogy we use to describe projects from a manufacturing model to an exploratory model. Creating an exploratory bias suggests that risk is not to be avoided at a wholesale level but rather the team takes risks then seeks to dampen the impact if something goes awry, using instantaneous distributed communication.

Projects with an exploratory bias need space to test boundaries which translates into a requirement for less direct control. Standard project planning, monitoring and control techniques are replaced with a loose framework to guide the project rather than a detailed schedule and risk management plan. They use intimate communication techniques (e.g. collocation, texting and instant messaging) rather than formal meetings. It can be perceived that these changes in process reflect a move to replace long term planning with instant coordination. I would strongly suggest that the two concepts are a false dichotomy and that a balance is required in the real world. Instant, personal communication at the project level can have great benefits. Communication drives innovation and if used as a replacement for formal meetings it can shorten the project cycle purely just by reducing overhead expended on scheduling meetings. Further instant coordination suggests that the level of granularity required from planning will be lower which will reduce the effort required from project managers. This means that a manager can focus more time on removing barriers. Instant coordination is not a panacea. Using informal communication tools can expose teams to cliques or run away personalities which complicate communication and coordination rather than facilitate it. A second potential issue is that not all projects are exploratory requiring innovation (continuous improvement is a different topic), rather many projects are fairly rote and need a focus on standardization to affect efficiency.

How can a leader decide which path will yield greater benefits for any single project? I would suggest that adopting one path to the exclusion of the other is a bad idea. Having a pallet of approaches allows leaders to match process to the project versus fitting the project to the process. If we consider the spectrum between exploratory and rote projects as a continuum with both ends being less than absolute, I believe we have a path to gaining the benefits of both models. Striking the balance will be the hard part however instant communication is here to stay and finding a way to accommodate and use what you can’t control is good management.

To quote Neo in Matrix Revolutions:

I know you’re out there. I can feel you now. I know that you’re afraid… afraid of us. You’re afraid of change. I don’t know the future. I didn’t come here to tell you how this is going to end. I came here to tell how it’s going to begin. I’m going to hang up this phone, and then show these people what you don’t want them to see. I’m going to show them a world without you. A world without rules or controls, borders or boundaries. A world where anything is possible. Where we go from there is a choice I leave to you.

The next installment on the changing project management environment will opine on how to strike that balance while avoiding both the right of infinite appeal and the totalitarian regime.

1 http://en.wikipedia.org/wiki/Project_management, September 3, 2008

Vitamins, Aspirin and Viagra
Thomas M. Cagley Jr.

This post has been released in audio on the Software Process and Measurement Cast at http://www.spamcast.net!

Why do some products make a bigger splash than others? I recently heard an analogy which explains why some products have naturally higher market demand than others. The analogy uses vitamins, aspirin and Viagra as a metaphor for products that avoid problems, solve a specific pain and provide new functionality. Gaining an understanding of this analogy is an important tool to guide how we conceive and implement process changes within our organizations.

One of the failings of many software process improvement programs is that they are framed as means of avoiding a problem and that by avoiding the problem the future will be rosier. I call this the futurist point of view. The futurist point of view translates to the “vitamins” for the organizational change world. If I asked you directly I am certain that you would understand the need to take precautions so that the future we will be better. The big unvoiced “however” in your answer would be that it is hard get motivated to make a change now for a nebulous payoff in the future. Just remember the last time you toyed with the idea of starting an exercise program. The linkage between a current change in behavior (taking vitamins) and future benefits is just not direct enough to create a groundswell of acceptance. Bottom-line: Selling potential benefits in the future is it best of times a difficult proposition.

I have recently taken sales training (and I am proud of it). I learned how to identify pain during the training program. Ask any professional salesman or woman and they will tell you that an immediate pain is an important motivator to making a sale, maybe the most important motivator. At least 99.9% of the people in the world want pain to go away when they have it which is why an aspirin is an easier sale. The “gotcha” is that pain initially expressed is usually not the root cause of the pain (there are a lot reasons for this behavior but that is topic for another day). The art of persuasion, sales and requirements gathering is the ability to peel back the layers until you can expose the root cause so the pain can be solved not just masked. The ability to successfully navigate the “pain” conversation to get to the root cause and not irritate person feeling the pain is a skill not consistently found on IT project teams. Bottom-line: I highly recommend a course in salesmanship for all project managers and requirements analysts, make sure your process improvement program solves current problems and always carry aspirin.

I have been shocked and amazed at how Viagra became and stayed such a block buster drug. Going back to our analogy, Viagra represents products that deliver additional functionality. The Viagra of process improvement projects deliver the ability to either do something that was not possible before, provide greater flexibility in how work is done and/or greater flexibility in the decision making process. I believe that most IT personnel have a bit of a libertarian streak which allows us to perceive flexibility and choice as functionality when it comes to process. IT personnel are problem solvers, solving problems is central to our Id. Process improvement projects that deliver functionality which make it easier (or even possible) to deliver solutions to IT’s customers, addresses the core needs of IT developers and IT leaders. Bottom-line: Make sure your process improvement projects make it possible to do work that could not be done before or at the very least make work obviously easier to do.

The analogy of vitamins, aspirin and Viagra frames a discussion that many process improvement leaders do not have when choosing process improvement projects. I suggest that to survive when budgets are being cut process improvement programs must deliver real benefits NOW, to solve pain IT organizations have NOW but to be true to our nature changes must provide for a better future. These considerations are not just packaging or salesmanship, addressing these considerations is central to providing real value NOW and in the future.

PS: Take your vitamins, carry aspirin and if you have process improvements that last more than four hours seek medical attention immediately.

Book Review: Subliminal Persuasion

Dave Lakhani

John Wiley and Sons, 2008

Bottom line:Unless you are dead you will be able to use this book!

I believe we all sell our ideas to others therefore persuasion is a topic of interest.Dave Lakhani’s book titled “Subliminal Persuasion” provides the reader with a pallet of tools for persuasion.The eleven chapters of the book clearly layout a set of tools and tactics to be a persuasion machine then adds a clear way for you to put what you have learned into action.In the first chapter Dave said “my publisher wouldn’t publish the book I wanted this to be because it was too edgy, too dangerous” well whether edgy or dangerous you should not be scared away.This book is clearly valuable and should be added to your library . . . maybe get two, one for the library and one to uses as a well thumbed reference.

Just How Badly Do You Want A Number?

Thomas M Cagley Jr.

An audio version of this essay can be found in the Software Process and Measurement Cast 38 (www.spamcast.net)

Every project begins with a prediction of how much it will cost and when it will be delivered. Project managers, as a rule, admit this behavior delivers results that are a mistake, can lead to perception problems and might actually warp space and time. Most projects I see begin with this sort of incantation. Why? The rationale for this seemingly irrational behavior is generated by many competing forces. It might be a reaction to a market deadline, a requirement to secure funding or based on the mistaken impression that the project team actually knows what they need to know to complete the project. Every IT manager I know understands the fallacy of the initial estimate, however I know very few if any that will actually stand up and just say no. This behavior causes cognitive dissonance (stress caused by holding two contradictory ideas simultaneously), but it is assuaged by continuing to look for a solution to stop the insanity (or by giving up and embracing the dark side).

Why, if we all know this type of behavior is wrong and that the outcome of the behavior is rarely effective, do we continue to do it? Why do we feel compelled to act in a manner that is non-nominal? Do Information Technology (IT) managers and project managers have a touch of a victim complex? The driver for this behavior begins at the interface between IT and finance known as the budgeting or funding process. While not the root of all evil, financial procedures and thinking are at times at odds with many standard ideas for planning and estimating a project. Concepts like ROI and tax accruals have precise predictable financial definitions and calculations. Financial control and analysis requires a level of precision in reporting project data. The problem is that the level of precision is generally at odds with initial project estimates. There will always be a mismatch between finance’s needs and IT’s data needs, unless projects are being actively measured and are using mechanisms to continually access they need to know to complete the project.

Agile methods such as xP and Scrum attempt to make peace with the initial estimation conundrum by breaking projects into small bites and only making promises for each small bite prior to beginning the work for that bite. In Scrum terms, the sprint planning exercise is an operational illustration of how agile methods have used a short term planning horizon to address the ‘how much’ and ‘when’ questions. This does not address the need to know when the overall project will be done and how much it will cost. You will encounter the same problem we began this essay with if you extend the short term planning windows to the entire known project backlog by counting the number of sprints or iterations runs. .

Non-agile shops have been adopted other tools to deal with the vagaries of early estimation and the perceived need for precision. The estimation funnel is an example of other strategies. An estimation funnel helps enforce the understanding that the variance of any prediction is larger earlier in the project and reduces as project team learns what they need to deliver and how to deliver it.

In the end however, nature, our society, finance and our fellow project managers betray the quest for abandoning the initial fixed estimate. Nature’s betrayal comes in the form of the belief that Sir Isaac Newton had something to do with project management. We believe that each action has an equal and opposite reaction, or that if we do step A then outcome B will magically appear. Remember that the combination of humans and physics does not a straight line make. Projects are human ventures, and therefore are more akin to herding cats than the laws of physics. Society’s betrayal is driven by ingrained consumerism. As a consumer, you and I have an expectation that if we’re going to buy something, regardless of complexity, someone will tell us for how much to write the check. An example of this type of behavior can be seen in the general hullabaloo that occurs when NASA overruns a cost estimate for the space station, despite the incredible level of complexity. How can anyone know exactly how much a project of this type will cost when it begins? The finance department’s betrayal is through their need to plan, secure funding and to understand cash flow. Making a significant mistake in the financial arena will have disastrous consequences for any company’s value and potentially its ability to make payroll. Most importantly, project managers let themselves down by saying “yes” and giving the number to whomever asks. Why? They feel they must, if for no other reason that there is always someone who wants the job badly enough to say anything and managers want a number badly enough to believe the lie and drink the Kool-Aid. Failure to play the game is seem to be career limiting.

I believe we need to rethink our concept of initial estimates. To drive this change we will have to change both our vision of the world and that of other constituencies within our companies. We need to de-link estimation from other non-estimation behaviors (we are not shopping for an HDTV), we need to change how estimation the process works, we need to measure projects which means embracing concepts such as function points for size and a proxy for functional knowledge. But most of all we will need to set a standard of behavior for ourselves and our fellow project managers and follow it.

Recognize these issues? Leave a comment or drop me an email at spamcastinfo@gmail.com

Next Page »