Book Review: Subliminal Persuasion

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?

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

 

Making Tangible The Intangible

Making Tangible The Intangible

Thomas M. Cagley Jr

An audio version of this blog post can be found on SPaMCAST 37 (www.spamcast.net).

It is a rare that the ideas espoused by an interviewee end up affecting me to the point that I need to incorporate them into the essay that accompanies their specific interview.  The gestation period is typically longer at least by a week this stuff was just way to powerful.  The essay for this cast reflects concepts espoused by Phil Armour in SPaMCAST 36 and Kenji Hiranabe in SPaMCAST 37 (the current cast for those of you reading this on my blog).  The confluence of concepts that so moved me begins with the Kenji’s comments on the intangibility of both software and the processes (the process being both intangible and opaque) used to create software unless, of course, you are in the IT business.  In SPaMCAST 36 Phil Armour put forth the thought that software was a container for knowledge.  Knowledge is only tangible when demonstrated or, in software terms, executed.   All of this discussion boils down to a product built to harness knowledge, using what is perceived to be an intangible process. This process is only full recognizable for the brief period that it executes.  On top of all of that, there is every expectation that the delivery of the product will be on-time, on-budget, have high quality and be managed and orderly.  No wonder IT managers have blood pressure issues!

Intangibility creates the need for managers and customers to apply controls to understand what is happening in a project and why it is happening.  The level of control required for managers and customers to feel comfortable will cost a project time, effort and money that could be better spent actually delivering functionality (or dare I say it, reducing the cost of the project).  Therefore finding tools and techniques to make software and the process used to create software more tangible and while at the same time more transparent to scrutiny, is generally a good goal.  I use the term “generally” on purpose. The steps taken to increase tangibility and transparency (boy, doesn’t that sound like an oxymoron) need be less invasive than those typically seen in command and control organizations. Otherwise, why would you risk the process change?

Agile projects have leveraged tools like WIKIs, standup meetings, big picture measurements and customer involvement as tools to increase visibility into the process and functional code as a tool to make their knowledge visible.  I will attest that when well defined agile processes are coupled with proper corporate culture, an environment is created that is highly effective for breaking down walls.  But, and as you and I know, there had to be a “but”. The processes aren’t always well defined or applied with discipline and not all organizational cultures can embrace agile methods. There needs to be another way to solve the tangibility and transparency problems without resorting to draconian command and control procedures that cost more than they are normally worth.

In his two SPaMCAST interviews, Mr. Hiranabe has laid out two processes that are as applicable across the perceived divide defined by waterfall and agile projects.  Last year in SPaMCAST 7, Kenji talked about mind mapping.  Mind mapping is a tool used to visualize and organize data and ideas.  Mind mapping provides a method for capturing data concepts, visualizing the relationships between them and in doing so making ideas and knowledge tangible.  In the current SPaMCAST Kenji proposes a way to integrate kanban into the software development process.  According to WIKIPEDIA,  “Kanban is a signaling system to trigger action which in Toyota Production System leverages physical cards as the signal”.  In other words the signal is used to indicate when new tasks should start, and by inference, the status of current work.  Kenji does a great job at explaining how the kanban can be used in system development.  The bottom line is that the signal, whether physical or electronic, provides a low impact means of indicating how the development process is functioning and how functionality is flowing through the process. This increases the visibility of the process and makes it more tangible to those viewing from outside the trenches of IT.

Code that when executed does what was expected is the ultimate evidence that we have successfully captured knowledge and harnessed it to provide the functionality our customer requested.  The sprint demos in SCRUM are a means of providing a glimpse into that knowledge and to build credibility with customers.  However if your project is not leveraging SCRUM, then daily or weekly builds with testing can be leveraged to provide some assurance that knowledge is being captured and assembled into a framework that functions the way that you would expect.  You should note that demos and daily builds are not an either/or situation.  Do both!

The lack of tangibility and lack of transparency of the process of capturing knowledge and building the knowledgeware we call software has been a sore point between developers and managers since the first line of code was written.  We are now finally getting to the point where we have recognized that we have to address these issues; not just from a command and control perspective, but also from a social engineering perspective.  Even if Agile as a movement was to disappear tomorrow, there is no retreat from integrating tools and techniques like mind mapping and kanban while embracing software engineering within the social construct of the organization and perhaps the wider world outside the organization.  Our goal is to make tangible what intangible and visible that which is opaque.

 

Groups (Draft, Part 1)

Hey this is a work in progress and I would be happy for comments, corrections or any other reactions! ****

Humans seem to have a need to classify people as either being inside their group or outside.   We humans then use that classification to determine how we will treat both insiders and outsiders.  From a critical point of view it would be easy to claim to be shocked at this behavior (but only when other exhibit it)  however the tendency to divide people into groups can be used as a tool when implementing change.  Marketing types call this segmenting your markets.  Each segment will have differing needs and will react to change differently.  Developing an implementation plan that embraces the positives components of classifying people into groups (let’s call it process improvement segmentation) will maximize chances of developing an implementation approach that is focused rather than omnidirectional.  

 

One application of grouping was recently suggested by the Process Improvement Philosopher.  He suggested a continuum of groups as a tool for discussing how different groups would react to change.  In terms of the behaviors exhibited toward change the continuum ranges from a group we will call the adopters to a group that would be best classified as resistors.  While we could forecast that this type of model would have these types of bi-polar opposites, I would suggest that the motivations of the groups that inhabit the middle groups are more interesting to understand and define.    

 

In the next installment we wrestle with the middle ground! 

 

Why Should You Care What Is Driving Change?

Why Should You Care What Is Driving Change?
Thomas M. Cagley Jr.

What are the pressures driving process change in your organization?  I ask the question because I believe that people, teams or even whole organizations don’t wake up in the morning with the idea that they need to change.  There has to be a trigger, a reason that helps provide the motivation. That reason will create pressure that change will relieve.   

 

Process improvement champions must understand why change is being pursued or risk failing.  Knowledge of the rationale behind change and the urgency of that rationale is an important component to actually making change happen.   There are numerous reason why knowing the “why” of change is important.  One reason is that knowing “why” will help you select the proper solution for the proper problem. A good think right?  A second reason and the focus of this paper is that knowing “why” allows you to communicate the rationale to those affected.  Communication is one of the core tools for reducing resistance and promoting buy-in.  

 

Communication is important because left to their own devices every person impacted by a change will develop their own opinion as to why the change is occurring.  Those opinions will range from the rational (change will help us become more efficient or change will help us increase market share) to the scary (change is a precursor to outsourcing, change is a precursor to downsizing).    The hopes, fears and paranoia’s of each individual affected will be represented when the rationale for change is left to assumption.  Opinions influence the level of effort and commitment applied toward the change (the negative side is resistance).  Communication and actions are required as a part of a coordinated organizational change management plan. 

 

Organizational change management, communication and their kissing cousins marketing and sales tend to be tough subjects for most IT project managers.   Perhaps this is because they are discussions of emotions rather than deterministic tasks.  A good dose of sales training or training in how counsel teams ought to be required as part of every project manager’s CV. 

 

In change programs of any size, communication will range from mentoring, cheerleading through persuasion (perhaps in the same conversation).   Knowing why any specific change is needed and how important that change is will allow you to engage with your customers in the most reasonable and honest manner possible.

 

As a leader of change, you are responsible to know why the change you are pursuing is needed.  If you do not know, find out.  If you can’t find out, think about saying no until you find out. Bottom line, effective change requires effective communication and if you do not know the rationale for the change you are pursuing you will not be effective. 

 

 

 

 

 

Shirts and Process Improvement, A Difference?

I have a favorite shirt.  The shirt has a cool gray tweed color and is made of a cotton fabric that feels like it has a hint of silk.  The only problem is that it does not have a pocket.  The lack of a pocket reduces the utility to the point that I actually have to think about whether I should wear it or not.  Software processes are typically designed to have all the bells and whistles so that customers will not have to think about whether to wear the shirt with a pocket or not.  If this story ended it frankly it would not be worth of blog entry.

 

The problem is that most process is to look more like a cargo pants replete with every possible pocket and utility compartments.   Adding all the bells and whistles cause process bloat which generally increases the amount of effort required both when using the process as well as to use the process.  Bloat is a major reason words like bureaucratic and red tape are used when describing processes. 

 

Fighting bloat needs to become an obsession for anyone involved in developing processes and procedures.   One of the best tactics I have seen for insuring only what is needed is built is to take a minimalistic purview.  Build the base process, the process that everyone will use then build extensions that can be used to handle the extras.  Regardless of the tactic you choose to right size your processes keep in mind that overbuilding can be as problematic as under building.  

 

 

PS – I saw someone with MY shirt and they have a pocket.  Darn!  Someone has found process improvement heaven or is it is it just shirt nirvana.

 

A Quick Thought On Innovation

I woke up this morning pondering creativity and innovation and whether they could be learned or exercise therefore I wrote the following short blog entry to see whether I could sort it out or create a discussion!   Are creativity and innovation enhanced by volume?  Do more chances at the innovation well lead to a greater likelihood that any single idea will hit the jackpot?  There seems to be a belief that volume at the very least helps the process and may well increase the chance of finding a diamond. This of course can only true if you assure that all people or groups have at least one good idea in them and I would like to suggest that is probably not true.  Another assumption that might make volume valuable is that creativity or the process of being creative and be strengthened by exercise.  Bottom-line are creativity and innovation learned skills or just “tuned up”?  I would suggest that developing a process helps, exposure to new inputs help and these things can be learned and tuned up but repetition and volume only count is there is a spark that can be fanned.

 

Good Numbers Go Bad: Mistakes Excerpt!

Section 2: Oops!  Mistakes Can Make Good Numbers Go Bad.

 

Mistakes can come in many flavors, errors of commission and omission; calculation mistakes or errors in mathematics (wrong formulas, logic or just ignoring things like co-variance), and just plain stupid mistakes.  The group as a whole is the single biggest reason Good Numbers Go Bad.  Mistakes by definition occur by accident and are not driven by direct animus. The grace and speed in which you recognize and recover from a mistake will determine the long-term prognosis of the practitioner and his/her program (assuming you don’t make the same mistake more than once or twice).  Ignoring a mistake is bad practice; if you need to make a habit of brazening out the impact of mistakes, you should consider a new career as you have lost the long term battle over the message.

 

Collection Mistakes:

 

Collection mistakes are a category that covers a lot of ground ranging from gathering wrong data to erratic data collection.  While collecting the wrong information can lead to many other kinds of mistakes, we will explore credibility issues in this section.  Recognition and the recovery from collection errors which lead to credibility issues will be explored in depth in this section.

 

“In order to capture metrics, the procedures, guidelines, templates, and databases need to be in sync with the standard practices.”

— Donna Hook, Medco

 

Data collection errors typically represent errors of omission (data not collected); however, occasionally the wrong information is collected or data is not collected at all.  Collecting the wrong data (or data you do not understand) will create situations where your analysis will be wrong (garbage in) with the possibly that you won’t know it (gospel out).  Someone will usually discover this error at the worst possible time, leading to profuse sweating and embarrassment.  Gathering the wrong or incomplete data is a non-trivial mistake which makes Good Numbers Go Bad.  However, what you do about it will say a lot about your program.  Begin by making sure you have specified the data to a level that allows you to ascertain that what you collect is correct.  Audit the collection process against the collection criteria periodically helps to make you collect the correct data and collect it correctly.  Create rules (or at least rules of thumb) that support validation.  Rules of thumb will help you to quickly interpret the data.  Did you get the quantity of data you expected?  Has the process capability apparently changed more than you would reasonably expect? 

 

Erratic Collection:

 

Measures and metrics can be perceived to be so important that panicked phone calls are known to precede collection.  Equally as interesting are the long periods of silence that occur before the panic.  Erratic data collection sends a message that the data (and therefore the results) are only as important as whoever goosed the caller (or slightly less important to whatever the caller was doing right before he/she called).  Inconsistent collection leads to numerous problems including rushed collection (after the call), mistakes and an overall loss of face for the program (fire drills and metrics ought to be kept separate).  Consistency spreads a better message of quiet importance that can supplant the urgency of yelling.

 

Mathematical Mistakes:

 

“We accidentally used one number instead of a correct value.  Now our stakeholders ask for a second source.”

— Rob Hoerr, Fidelity Information Services

 

“Mathematical mistakes happen! We are all human!” The excuses are anthem, which means all measurement programs must take the time and effort to validate the equations they use.  Equations must be mathematically and intellectually sound.  Inaction in the face of mistakes in the equations or results makes Good Numbers Go Bad.  If a mistake is found, neither results nor equations should be ingrained to the point of freezing your project into inaction.  This places a lot of stress on the need to create measurement and metrics specifications.  Once the specification, (specifications include data like a description, formulas and definitions) is created, it is easier to make sure you a measuring what you want and that you get the behavior you anticipate.  The spec provides a tool to gauge the validity of the math, the validity of the presentation, and, by inference, the validity of the analysis.

 

Liars, Damn Liars and Statisticians:

 

Statistics has long been a staple of graduate business schools, which instill the belief that numbers can prove anything.  Numbers, however, require a sensitivity to the equations that flies in the face of this mentality.  When simple relationships are ignored to make a point Good Numbers Go Bad.  Examples of questionable math can include graphs with the same variable (in different forms) on both axes presented with linear regressions lines driven through them.  The created co-variance goes unrecognized, leaving the analysts speculating on what the line means without the recognition that the relationship is self-inflicted.  Developing a simple understanding of the concepts of co-variance, ‘r”-squared values and standard error are easy steps to help sort out basic conceptual errors.  A corollary to this is that the knowledge of statistics will not necessarily stop the mistake of adding the wrong EXCEL cells together, but it can’t hurt.  Always check your equations, your statistics, and never fail to check the math!

 

 

A Touch of Philosophy

 

Life is an epic adventure even when it seemingly is a series of unrelated events.  So while I wax a bit philosophical, I suggest that this thread of thought is important to process improvement personnel.  Important because when process improvement and measurement personnel view life as an adventure I believe they will be far less likely to view the day to day grind with a victim mentality.  I classify an outlook as a “victim mentality” as a point of view that classifies outcomes as outside of your control.  Therefore in other words “stuff happens” is a mantra.  This point of view is very easy to fall into when you are trying to influence people and organizations without direct authority.  To combat this deadly (from a professional point of view) I would suggest that process improvement and measurement personnel need to embrace life, need to look for the possibilities in all situations, and seek opportunities to increase the impact they can have on their organizations as well as their personnel knowledge base.

Not a new revelation but sitting in the Malaysian Airlines lounge in Kuala Lumpur reviewing events past, present and future left me with the message that we all must grasp each new experience as set of new possibilities.  New possibilities to deliver value and possibilities to increase our personal knowledge base.  We are challenged to look for ways to make every experience work for our self and for those around us.  We must leave the world around us in a better position than when we originally touched it.

 

Estimation, Planning and Goals: All Different I Say!

Estimation, Planning and Goals: All Different I Say!

Thomas M. Cagley Jr.

Audio - at www.spamcast.net!

 

Before we dive into this essay I must admit that I have been influenced with a high degree of immediacy and urgency by the interview with Phil Armour that begins in this Software Process and Measurement Cast.  The impact may be due to my long-term issue with a how words are used and misused, false levels of precision or just the fact that the process relating to the software engineering disciplines like estimation continue to prove to be difficult to implement regardless of the development method used.  In a nutshell you will see an influence and I must say a hardy thanks to Phil for the interview and to Bob Ferguson for connecting us.

 

Mention the topic of estimation to a group of project managers and software engineers and you will attract attention and maybe not positive attention.  The topic of estimation elicits a wide range of emotions, opinions, and definitions and expectations. Unfortunately words are sometimes used loosely and estimates, plans and goals are used as synonyms.  The expectation of the actions each words of evokes and their definitions are intertwined but they are not the same.

 

At a basic level I believe that everyone in the software development world understands that an estimate is an approximation of a future based on uncertainties and therefore inaccurate when compared to the final result of the project.  Estimates are notional rather precise therefore as Phil Armour in the interview for the Software Process and Measurement Cast 34 states, “the words accurate and estimates are a mismatch”.  Why then do we strive for estimation accuracy?  The answer is that we are more interested in planning accuracy and because we have used the words as synonyms the water has been muddied.  While related estimation and planning are not the same. 

 

Adding a bit of complexity to the picture of estimation and planning lets toss a pinch of managerial aspirations.  Managerial aspirations are better known as goals.    Goals are can be interpreted as commands in strongly hierarchal organizations or as inspirational from a leadership point of view in others.  In organizations where management has set a goal for a project (I want it by Thursday for five dollars) and that goal is interpreted as a command activities shift from the need for an estimate to the need for a planning.  Planning activities include developing lists of tasks, allocation of resources and defining the order in which work will be done.  Depending on where in the project life cycle planning is attempted it may well be termed estimation although it is a fundamentally different process with different outputs.  As noted before in their basic form, estimates are built from data that is imperfect and or in some cases nonexistent.  Plans are built on the premise that processes and the outputs they create are deterministic, if you do steps A, B and C with Joe, Frank and Cynthia you will end up at point D with output Y.  Goals, estimates and plans are not the same.  All required, but at different times and with different players, levels of emphasis and different paradigms.

 

Recognizing when and why a goal is needed, that an estimate focuses on the top line answers to how much it will cost and when it will be done and a plan is a roadmap of how the work will be done will make life easier.  Software development, especially early in the life cycle isn’t in the least deterministic if for no other reason than that projects have large swaths of unknowns.  So let’s stop confusing the terms and let’s remember you can’t have a plan that says “….and a miracle happens here” and early in the project life cycle you can’t have enough information to avoid that necessity.  Goals, estimates and plans are not the same.