Herding Cats

If We're Going To Make Improvements, We Have To Be Able To Calculate Real Numbers

There are nearly unlimited sources of advice on how to make improvements to nearly anything we could imagine. Not just personal improvements, but business improvements, management improvements, project improvements, technical improvements, world improvements.

I have a bias here shared by many of my colleagues. This bias stems from our domain, for the simple reason, we work where measurement dominates the conversation. We share a World View that performance performance improvement or even performance sustainment starts and ends with measuring things.

Measurements we'd find in the work we do, include but are far from limited from some basic questions that very person accountable for spending someone elses money must ask:

• When will we be done and what is the confidence in that number?
• How much will the thing we're building cost when we're done and what is the confidence in that  number?
• How many people do we need to finish this work on time?
• What can go bad and how are we going to avoid the consequences when it does?
• What can go bad and how are we going to prevent it from going bad?
• When we're done, when will we break even on our investment and what is the confidence in this number?

But that are other measurements in our domain too.

• If we switch from this business system to another business system what will be the tangible evidence we made the right decision?
• If we adopt this new and supposedly innovative method of managing people, what will be the tangible evidence that things have improved and what is the unit of measure of that improvement?
• If we hire a training firm to improve our communication skills, how will we recognize we earned back our investment?
• If we change our organization structure and even our organization how are we going to know we made the right decision?

These questions come about because we work for people who spend either their own or other peoples money. If you're spending your own money (not someone else's) the importance of these questions is less, maybe even nonexistent. It's your money, spend it as you please. But the people that hire us almost always spend someone else's money. Many times they spend the money of a sovereign - the governments money.

The starting point for a look into this world of being accountable for other peoples money, is the book Making the Impossible Possible: Leading Extraordinary Performance, The Rocky Flats Story. This title contains the essence of our World View - Heliotropic Abundance and Positive Deviance and how Complex Projects in the presence of complexity, are managed using this paradigm.

When we say complex projects (or programs) and management at the same time, there is a specific set of meanings to these words. These words are based on Systems Engineering paradigms and the complexities of systems. System is defined in the context of a product or service provided to the people whose money is being spent. Of course this system has boundaries, relationships between its components and of course the relationships between the people working to produce the system or working in the system to produce something.

And also of course the system includes the people building the product or service. But it is the product or service that comes first. Otherwise why are we spending other people's money. Certainty not to increase the self actualization of the people working on the system. That may be a by-product, but rarely do strangers pay us to increase self actualization of our staff. You had pretty much better come fully funtional on the self-actualization front, before starting work on our programs.

All systems - at least all non-trivial systems - have complexities. They may even be complex. There is a science context for these words and a business context as well. In the domain we work, disorganized complexity is rare, for a simple reason. The firms we work for would have been eliminated from the gene pool if they could get the disorganized complexity under control. The systems we work are complex and have complexities.

Now We Get to the Hard Part - and there is Always a Hard Part

In the domain we work, we calculate things all the time. That's what we do, we calculate. We calculate Cost, Schedule, Technical Performance, Labor utilization, investment return, effectiveness of a process, effectiveness of people in their roles, effectiveness of the organizational structure and its behavior.

We calculate suggested ideas for improvement. We ask how would we know? How would we know the suggestion will actually going to work? How would know that the person making the suggestion actually has had success outside of personal experience? Is there are any tangible evidence that the suggestion is actually applicable to the problem we are facing?

So what happens when those making those suggestion don't have this evidence? Do we proceed? Maybe, maybe not. Remember it's other peoples money. We usually start by asking annoying questions - questions that we hope will produce answers in some unit of measure meaningful for our decision making processes

In the absence of these answers that have measures in them - numbers - we tend to lose interest quickly. This was the original problem with Agile. Just Try It works great when it's your money. When it's someone else's money, it's a bit more difficult to proceed with an experiment, without the full acknowledgement that it's an experiment.

When the problem to be solved is a people and organizational problem, the path forward in the absence of some unit of measure is more difficult. We need something that provides increased confidence that is we proceed it'll turn out all right. This can be case studies, reference processes, working prototypes. This is how Agile got going. Small examples of success, that started to scale. But Just Try It is probably not the basis of the decision.

So Here's The Suggestion

When you hear, read, or see a new and exciting approach to an existing problem, first buy and read Beyond The Hype. Then and only then, come back to the suggestion to see if those making the suggestion fall into the category of reprocessing ideas in a new language and passing it off as new.

Now there is great value in repackaging ideas. It may make the ideas clearer, more understandable. But usually anything that has a common name with a 2.0 or 3.0 behind the name should be suspect. Of course all thoughtful managers (or anyone for that matter) should be eager for and open to new ideas. They should also be just as skeptical that the latest sure-fire solution to what they realize are eternal problems that must be constantly managed, is just possible an old idea in new cloths.

They learn, either by instruction or by hard knocks that all suggestions must be actionable, measurable, and connected to tangible outcomes from the suggestions. It's that annoying measurement part.

So proceed with care. Beware of the Hype. Be-aware that problems are constant and pretty much unchanging. The same problems. There are rarely new problems, just old ones that have come back. New and innovative approaches to these old problems need to be tested. But while listening to the 3.0 version of the solution to the 1.0 version of the problem, ask some hard questions:

• Has the suggested approach worked outside of personal anecdotal experience?
• Has it worked in my domain? With the size of the problem I have?
• Have the benefits be verified? Independently verified?
• Has the return on investment been verified? Independently?

And don't listen to that Einstein quote about “You cannot solve a problem from the same consciousness that created it. You must learn to see the world anew.” That was about general relativity and the missing math (Rieman spaces).

Remember - everyone lives by selling something (Robert Lewis Stevenson). Find what they're selling before you buy. Ask those pesky annoying questions about how can I measure what you're selling in units meaningful to me. Don't buy the Hype, buy the outcome.

Content of any credible project performance measurement system

Any system that claims to measure perform of a project needs to provide:

• Planning of all work scope for the project to completion
  • For traditional projects this means a master plan and master schedule for the planned work, the sequence of that work, the dependencies between the sequenced work.
  • For an Agile project this means some way of knowing what done looks like in terms of User Stories or Use Cases bounded by a period of time. The planning of an Epic or a Release can be that bound.
• Breaking down program work scope into finite pieces that can be assigned to a responsible person or organization for control of technical, schedule, and cost objectives.
  • For traditional projects this means a Work Breakdown Structure (WBS) for the elements in the final deliverables.
  • For Agile projects this means some decomposition during the planning session of higher level customer needs into Stories or Use Cases.
• Integrating work scope, schedule, and cost objectives into a performance measurement baseline plan against which accomplishments may be measured
  • For Traditional projects, this means a resource loaded schedule, with milestones or Program Events, the needed accomplishments, and the exit criteria for each Work Package in the schedule.
  • For Agile projects, this means a stable development team, some means for forecasting the Story Points that can be produced each iteration.
• Controlling changes to the baseline
  • For traditional projects, this means some form of change control where cost, schedule, and technical performance are assessed on the baseline budget and schedule.
  • For Agile projects, this means some for of customer communication on the productivity of the Agile team as a result of the change request.
• Using actual costs incurred and recorded in accomplishing the work performed
  • For a traditional project, this means capturing costs for labor and materials and measuring these cost against the budgeted cost for the work.
  • For an Agile project, this means knowing the cost of the Agile team over it's period of performance, and collecting the for non-labor activities to confirm the project is meeting the owners budget expectations.
• Objectively assessing accomplishments at the work performance level
  • For Agile projects, there is a built in advantage - working software
  • For traditional projects, defining the tangible evidence of completion is necessary for success.
• Analyzing significant variances from the plan, forecasting impacts, and preparing an estimate at completion based on performance to date and work to be performed.
  • When we create a credible plan, with tangible evidence of progress to plan, the measures of variance are always in the same units as the plan.
  • With this variance information, the project team can now take actions to get back to GREEN.
• Using this information in the company’s management processes.
  • In order to manage anything we need variances.
  • Management now needs to take action and correct the work processes that have created the variances.

Performance Based Management

There was a question posed to me on Twitter from another post. The question was what should I read to learn about some of the things you talk about here?

Let's  go back to the top and start down the list. But let's start with some first principles.

Five Immutable Principles of Project Success

1. Do we know what the project is supposed to produce, the recognizable deliverables, the measures of success for those deliverables, and most importantly, the units of measure of the success that are agreed to by the decision makers?
2. Do we have a plan and a schedule to execute that plan? The plan tells us what we are supposed to be doing? The schedule tells us when we should be doing this work. Both a Plan and a Schedule are needed. But the Plan and NOT the Schedule and the Schedule is NOT the Plan. This a a fundamental failure mode for most projects outside the government program management domain. Look at the IMP/IMS Preparation and Use Guide for an overview of this paradigm.
3. Do we have enough resource to complete the project on time, on budget, and on specification? This means there must be a resource utilization plan. A resource loaded schedule is the best starting point. In many agile projects, there are fixed resources, so resource loading is simple. But in agile domains, rarely are there discussions of schedule margin, cost margin, or technical performance margin, so those approaches are swapping one set of problems for another.
4. Do we know the risks in the project and their Risk Handling responses? If not, the risks are still there and will turn into Issues and then you'll be late and over budget, and the outcome will probably not work.
5. Do we know that we are actually making progress? In agile projects working software is the tangible evidence to progress to plan. The plan being the series of stories to be produced. In traditional projects Earned Value is a good way to measure progress. In agile EV might be useful, but since the capacity for workis fixed, the outcomes  become the independent variable. Burn Down charts are used, but Burn Down Charts are NOT EV - useful but not a replacement for EV.

With these 5 Immutable Principles, we need a process to put them into a work process to actually increase the probability of success of our project.

5 Processes of Project Success

1. identify the capabilities that are needed by the stakeholders of this project. These are not the requirements, that comes next. A capabilities is an objective or the particular end state identified by Measures of Effectiveness (MoE) and Measures of Performance (MoP). These capabilities can be defined through scenarios from the customer point of view in units of measure of meaningful to the customer. The Concept of Operations (ConOps) is an example of defining capabilities. Capabilities answer the question what are we going to with the outcomes of the project to earn back the business value?
2. What are the technical and operational requirements needed to provide the capabilities for the stakeholders? This is where we map a requirement to a capability? This is a critical success factor of the project. This asks the question why do we need this feature? What capability is provided by this feature? How can business value be traced to the features that are being developed? This means each requirement is traceable to a needed capability. Each requirement is traceable to other requirements - usually in an N-squared matrix. The Design Structure Matrix (DSM).
3. Once we know what we need to do in terms of delivering capabilities to the stakeholders that they can put to work fulfilling their mission and vision, we need a Plan and a Schedule. By The Way - the notion that Earned Value is not interesting because it is not business value is of course nonsense. Earned Value is embedded in the Performance Measurement Baseline. Business Value is connected to the delivery of capabilities. These are mapped in the DSM. But both are needed.
4. With the Performance Measurement Baseline, the project participants need to execute the plan. This means taking each chunk of work and performing the defined activities. If this is an Agile project, these are stories. If it's a traditional project, it's Work Packages and their activities. The order of the work may be important or not. But the measure of performance must always be Physical Percent Complete. The details of how to do this take books, so this is just a simple overview.
5. In each of the previous 4 processes, Continuous Risk Management (CRM) must be applied. There are several paradigms for applying CRM. A good starting point is the Software Engineering Institutes, CRM. DoD has a paradigm as well. Pick something. DO NOT make this up.

Summary

I'll start a list of resources next. But for now this the framework for managing any project. By any I mean any, no matter the engineering development method. This means Scrum and similar methods, are just that Software Development Methods. They can be integrated with Project Management Methods, they can replace some project management processes.

In the mean time here's a collection of posts on Project Management Books.

Staying in Control of the Project

In the commercial and military flying business there is a term controlled flight  into terrain. This means that the pilots flew the aircraft into the side of a mountain or the ground with intent. That is they were in control of the aircraft when it hit terra-ferma.

This happens many times in the project world as well. The project performance management system says you need to spend a specific about of money each month to keep on schedule. This is a absorption rate for the touch labor. In agile this would be the number of story points.

But the bigger - actually biggest - question is what is our capacity for work? In the federal project management domain, this is answered by the Basis of Estimate (BoE) for the Work Packages and Control Accounts. This is developed from a variety of estimating techniques. Once these numbers have been developed, they are risk adjusted for Management Reserve and the Deming variances that are needed for the cost, schedule, and technical performance.

This concept is not always discussed in software projects, even on agile projects. Phrases like, we can  deliver this project for 120,350 hours with a ± 8% variance margin, so we'll need that ± 8% in our MR bucket to cover any overruns or schedule slips.

Projects without these buffers end up flying into the side of the mountain, killing even one on board and making a big smoking hole where the project was. Having been in the military aviation business in the 70's there was a box on the accident report form, titled BBR. This was checked when the condition of the remains were burned beyond recognition.

Don't let the BBR box get checked for your project. Keep the basis of estimates credible and executable. By executable it means Plan the Work and Work the Plan. For all projects, not matter the product development method, there MUST be a plan and this plan has to be a credible set of steps needed to land softly on the end and not fly into the side of the mountain, while still in control of the project.

 

Positive Deviance

There is lots of talk around about changing the world, replacing traditional management with "new and improved" management, creating a new paradigm for managing organizations. Much if not most comes from theorist or one-trick pony advisors.

Here's a concept that was reverse engineered from observed successes.Positive Deviance, is the basis of Helotropic Abundance. HA is the reverse engineered observed success factor for Rocky Flats Environmental Technology Site's (a great market word for one of the worlds most contaminated nuclear weapons plants). This case study and other materials is described in Making the Impossible Possible: Leading Extraordinary Performance: The Rocky Flats Story. This book should be the starting point for anyone wanting to understand how to make changes in the organizaition. But most importantly this book should be read to anchor the untested and unverified theories of how to make change. This book is a narrative of how change was made, the reasons for why that change was successful, and how those reasons might be applicable to other domains. It is not a theory book, nor an ancedotal experience book, but a book about how 10's of 1,000's of people changed their organization.

There are four elements of Positive Deviance

1. Collaboration - how people and prcess collobrate for the mutual benefit of the organizaition, project, program, or shared outcome.
2. Creativity - where ideas for success come from, both internal and external.
3. Control - how to avoid undirected effort, poorly directed effort and assure mutual accountability is in place for the shared outcome, even in the presence of individual motivations.
4. Competition - how to motivate success through mutual accountability of the shared outcome, while maintaining positive outcomes.

All 4 are needed for success. All four are in conflict - as all good process improvement processes are. These conflicts MUST exist. Without conflict there can be not push away from the status quo. Without this push there will be no change. There will be talk of change, but no change. The only outcome will be the echo of the original idea fading off into oblivion.

Conflict is first needed to keep in check the unsubstantiated claims of those proffering the solution. Conflict is next needed to balance the complex and conflciting needs of any organization. No organization is going to change without conflict. Managing the conflict is a waste of time. Using the conflict - in the framework of Heliotropic Abundance - is the key to success. It's managing in the presence of conflict.

Collaborate

To collaborate we must establish relationships, acquire human capital, and installation a collaboration process between these elements. Collaboration means developing this talent, building strong relationships, and fostering trust between all parties based on:

• Culture
• Collaboration
• Credibility
• Human capital and social relationships

Creativity

Create a vision, innovative and symbolic leadership, by articulating and reinforcing the vision of what can be in contrast to what has occurred in the past. This is done by:

• Forging a clear and shared vision of the future in words that describe capabibilities of the organization not just technical and operational requirements.
• Installing symbolic leadership in support of the changing mission through actions of the leaders.
• Discovering innovative and creative ideas for the work processes based on both leadership and follow-ship.
• Instilling a new sense of meaning and importance to the work activities through the other 3 aspects of Positive Deviance.

Control

Control is needed to establish stability, discipline, and process outcomes. Control must be grounded in virtuousness and extended beyond just doing well, but developing the mechanisms for producing extraordinary results. This take place through:

• Goal clarity through precise definitions of what done looks like in units of measure measingful to the decision makers.
• Agreements between producers and suppliers of information, services, and products through a shared definition of measures of effectiveness and measures of performance.
• Planning and objective measures with accountability of the shared outcomes.
• Stable support and funding for all work efforts with risk adjusted schedules, budgets, and techncial performance measures.

Competition

Competition means installing incentives and rigorous performance standards, through aggressive actions, external constituents, market forces, performance measures, and obtaining measurable results using:

• External stakeholders, such as customers, governance and oversight, suppliers and consumers
• Managing internal relationships for all interactinf elements of the organization.
• Taking bold actions to brerak the cycle of failure or under-performance
• Incentives for measurable progress, not just measuring progress or incentives. Both incentives and the measures of progress are needed.

This all comes together in

All work here is summarized from Making the Impossible Possible: Leading Extraordinary Performance: The Rocky Flats Story, the seminal work describing how to put Positive Deviance to work.

Some more reading

1. Richard Pascale, Jerry Sternin, and Monique Sternin, The Power of Positive Deviance: How Unlikely Innovators Solve the World's Toughest Problems, Boston: Harvard Business Press, 2010.
2. William Seidman and Michael McCauley, Harvesting the experts' “secret sauce” to close the performance gap, Performance Improvement Journal, Jan. 2003, vol. 42, no. 1, pp. 32–39.
3. A. Gawande, Better, A Surgeon's Notes on Performance, New York: Henry Holt, 2007.
4. B. E. White, Complex Adaptive Systems, IEEE International Systems Conference, Montreal, Canada, Apr. 2008.
5. R. Stevens, Engineering Mega-Systems: The Challenge of Systems Engineering in the Information Age, Boca Raton, Fla.: Auerbach/Taylor & Francis, (2011), pp. 118–120.

Most Exciting New Results Are Wrong

There are many new and exciting results in the world of science - physics is my area of knowledge. But many turn out to be wrong. There are examples from the world of physica science. And social scientist want to be called scientist, they are subject to the same scrutiny as a physicist.

Giovanni Schiaparelli's canals on mars, Professor Blondlot's n-rays (1903), Piltdown man, the English answer to the Neanderthal man and the Cro-Magnon man discovered on the continent. These are not unique in the world of physics. Polywater, Cold Fusion, pentaquarks. Cancer has been cured so often it is a surprise that any cancer cells are left.

Beyond Physics There Is Lots of Hype About New and Exciting Things

So why are so many exciting results wrong? to be exciting means, almost by definition, that the results have a low prior probability of being correct. The discovery that our dog hs been storing beef bones in the backyard is not very exciting. But if I found a gold vein that leads under the 16th green behind our house, now that'd be exciting - except I don't own the mineral rights!

It is the unexpected that is exciting and gets hyped and over hyped. The pressure to come up with something new is tremendous in our internet world. As well you want to get it widely distributed so you get the credit. This leads the pressure to not checking your results, confirming they are actually new and exciting and not just a rehash of an old idea you had not encountered. This also means you may not be as careful as one should,to check the results are in fact applicable outside you our anecdotal experience.

When we hear of "Something 2.0" or even better 3.0, and rush off to buy the book, read the web page, attend a semniar, then we've fallen into the Hype process. It's driven by the marketing engine of book publishers who have to get you hyped for the new and exciting idea that will - save the world, put your firm back on track, provide you with unimaginable skills to solve problems that have never been solved before.

So Before We Bite

So before we rush off and adopt the latest new and exciting anything - especially in the business worls, where there is no way to have a double blind test of the claimed outcomes, have any theory to explain why we should be seeing this results, and have any chance or replicating the outcome - at least ini short order - outside of the claimant of the outcome - we need ask and answer some questions.

• Has the outcome been verified by a third party observer. In other words has anyone else seen this work?
• Has this claim been tested somewhere else with similar outcomes in similar situations?
• Is there some basis for accepting the outcomes as anything other than just good practice that was not in place in the first place?
• And finally, can this beneficial outcome be reproduced in some other business or technical domain, like where I work and and claimant doesn't - or again is this just good practice?

So when you see 2.0 or 3.0 behind a common term, think twice. Have you seen this idea been somewhere else, maybe when the author was in short pants as they say in the UK. For example much of the agile process were in place and being used years before they were hyped in the software development world.

Heliotropic Abundance

In the #Stoos discussion on LinkedIn there is suggestion that "people based" management is the next new thing. Of course that's unlikely. Beyond the Hype: Rediscovering The Essence of Management is a good place to start the conversation.

The book Making the Impossible Possible has been mentioned here before. Here's a quick  summary of the paradigm based on Heliotropic Abundance.

Making the impossible possible

View more presentations from Glen Alleman

The key here is the conflicting - but mandatory - processes needed for project success. Much of the discussion arund improving management  is based on theory and anecdote. The Making the Impossible Book, is based on field research from an actual project. I was a participant in that project, as a minor participant (VP,Program Management for a small set of programs).

When there are suggestions of way to improve management processes, always ask - where have you made this work before? And why do yu think it will work for me?

Management of Complex Programs Through Change Management

The book Making the Impossible Possible is a case study the management of Rocky Flats. Rocky Flats was the most contaminated nuclear weapons plan in the country. It was a environmental disaster and the site of rampant worker unrest. Although estimates projected that cleaning up and closing the facility would take 70 years and $36 Billion, the project was complete 60 years ahead of schedule and $30 Billion under budget, and most of the site is now on its way to becoming a wildlife refuge.

The book describes how this amazing feat was accomplished and how other organizations can apply the same methods to achieve breakthrough levels of performance. The authors discovered that Rocky Flats leaders used a  distinctive abundance approach identifying and overcoming difficulties. 21 specific leadership practices and key techniques were fundamental to this innovative approach.

This researched case study provides a complete guide for anyone wanting to better understand and apply lessons of this remarkable, history-making acheivement.

Here is the top level structure of those practices and techniques. This structure organizes improving performance into the typical 2x2 matrix, with tensions between each necessary for the extraordinary performance. This tension, simultaneous opposites, and paradox have been shown to be the source of success (Cameron, 1986). I'll post on Positive Deviance and Abundance approaches that underpin this success and how these can be generalized to any project-based domain and context.

But here's the quick summary:

• Most leaders of change look for issues and ways to close gaps. Leading change focuses on overcoming these gaps in their path to change. (Kotter 1996).
• Abundance does not replace this approach. Abundance supplements it by focusing on the gaps between acceptable performance and spectacular performance, with emphasis on positively deviant accomplishments instead of just normal accomplishments. The focus is on poistive possibilities not the closure of deficits.

 

For anyone proposing organizational change in the domain of project based work, this framework should be considered a must read. For all who propose management change, these extensively researched working examples show how theory can be turned into practice. Without the means of connecting theory with practice, those suggestions are simply unfounded conjecture.

(Cameron, 1986) - "Effectiveness as paradox: Conflict and consensus in conceptions of organization effectiveness," Management Science, 32: 539-533.

(Kotter 1996) - Leading Change, John P. Kotter, Harvard Business Review Press, 1996.

 

Management Improvement - A Project or Operations View

Jurgen Appelo has posted about the #STOOS Network and its focus on management improvement. I followed a link to Steve Denning's materials. All good stuff at the principles level. What came to mind through these voices is the difference between a project focused organization and a process or production focused organization. It seems Denning speaks to the issues of found in process or production organizations, where the mission is to keep the system running.

I work exclusively in project focused organization. I've come to this position through a career of building products with other peoples money. Either government money, external customer money, or internal funding from the firm I work for.

When I read the materials from people like Steve Denning, I've started to understand that many of the things we take for granted in the project focused organization are missing from the process oriented organizations.

I have several experiences with Enterprise IT in process focused orgs, where no clear mission, defined set of needed capabilities, and tangible measures of "DONE" are present. I learned recently (in the past 5 years) that I don't fit well in environments where these are missing. I came to this through some painful experiences, where I learned that in the absence of mission and vision, definitive capabilities connected to those mission outcomes, hard high level requirements, a fixed schedule and budget, and technical complexity, people tend to focus on the interpersonal aspects of the project. The self actualization for their own needs and desires. The softer side of project management. All important stuff, but only secondary connected with the production of products.

The seminal example of the opposite of production can be found in manned space flight, weapons systems development, and my crucible experience - Rocky Flats Environmental Technology Site (RFETS). RFETS was a wonderful marketing term for retiring a nuclear weapons plant.

The book shown above is the case study for that program. Here are some contents of the book that I now live by and may add value to those of you working in the process focused business domain where people focus on their self actualization and not on the outcomes of those efforts.

The book's principle is Heliotropic Abundance (HA). After reading the book (long after I worked there) I had an understanding of how my bosses performed inside the context of HA and how I learned how to manage projects.

HA is the counter to conventional management principles. The tables below describe the differences between these two approaches, along with quotes from the book by the participants that I use in my our approach to managing projects, programs, and portfolio.

• One key role of top management is to ensure that effective leadership is present throughout an organization.
• We can have a great plan, we can have the money to implement the plan, but if we don't have the human commitment and the will to execute the plan, it all falls apart.
• There are three (3) leadership roles needed for change to occur: (1) Idea champion, sponsor, and orchestrator (in Developing Management Skills, Chameron, 2005)
• Idea champions are often the most visible leaders. They are the ones who receive most of the credit for success.
• Sponsorship acquires resources, but are seldom recognized for their contributions.
• Orchestrators bring individual together for implementation of the vision or idea.

The successful leadership of extraordinary change require the pursuit of simultaneously conflicting strategies

• Effective articulation of a motivating and inspiring vision is always dependent on visual images and symbols.
• One of the most significant symbolic events was the announcement that a substantial portion of the profits ... would be shared with the work force.
• If you don't like problem solving you won't like working here.
• ... an attitude of try it, find a way, and learn from mistakes.
• Being told no opened a door so that we could do something else that woudl be successful.

• The idea of following through on commitments - at almost any cost - was driven by top management from the very outset of the project.

• Challenges and opportunities must be created that make the current culture appear inadequate and incapable.

• Proactively, not reactivity ... in sharing performance news build trust.
• Small wins and small problems should be surfaced quickly and early.

In the end having a clear and concise goal, derived from a mission and vision establishes the basis of success. We all knew what done looked like on a daily basis. Early in the project the Plan of the Month was used to develop our work efforts. Then the Plan of the Week and finally the Plan of the Day.

I've used the Plan of the Week many times, sometimes with success sometimes without. The idea of the PoW is to state upfront what will be accomplished at the end of the week by the team. These accomplishments MUST be in tangible units of measure meaningful to the team. Never I'm going to make 4 sales calls or I'm going to work on the marketing brochure for our new offering, or I'm going to work on getting the new baseline back to GREEN in the EV Engine. This is called Level of Effort, Train Watching and measuring it is a waste of time.

The outcomes at the end of the week must be tangible, move the project forward in its maturity, reduce risk, stay on budget and generally contribute to the increasing probability of success.

The goal paradigm at RFETS was...

If your work doesn't do that, you need to look somewhere else for employement

Thanks to my supervisors (CFO, VP Programs) for teaching me that in an environment of Heliotropic Abundance.

I hope the efforts of Jurgenm come to the same conclusion.

Changing the World? Let's Hope So

I'm not a big fan of the Let's Change the World school of management. But Jurgen Appelo's efforts at the #STOOS Gathering are of interest to me for several reasons:

• Management processes are my profession
• Change processes are hard, and I'm interested to see if there is success here that I can use
• Jurgen has a unique take on the world and I'm interested to see if he has something I can use

The ideas and suggestions are here

 

Stoos Gathering

View more presentations from Jurgen Appelo

 

I've gathered a few ideas from this that are worth commenting on:

• Page 2: Never doubt a small group ... can change the world - Margret Mead. Good stuff, but those small groups always had an actionable outcome. This is one of the failings of the OWS, no actionable outcomes.
• Bob Marshall (Page 3) hits it again - no actionable outcomes
• Paul Boos (a kindred military aviator) - Page 9 - has good advice. The current military small unit structure is a good example of management principles in action that coudl be used in business
• Erika Anderson - viral processes work. Yes they do, but they work because they are effective for the problem at hand. So what is the problem at hand and who has this problem?
• Page 19 has an important message. We are motivated by autonomy, mastery, and purpose. But to suggest most CEO don't get this has no merit, since most is not defined. The CEO's I know and the very few I've worked with ALL have this drive. One problem is too much generalization is the norm when it comes to these sorts of things - changing the world things.
• Page 20 is Steve Jobs and Apple. There's an example.

Lot's more, but you can read them yourself.

Here's my contribution (that not surprisingly didn't make it)

• Define the problem in units of measure of success outcomes. Meaning I want to achieve this outcome. I need possess this capability and need to make these changes to do so. This is called Capabilities Based Planning.
• Look for working examples of success in firms around the world that have accomplished what you are looking to do. There are plenty of them. A literature search is the first step in any development process. Why do all the work if someone else has do it for you.
• Put those successes in some type of taxonomy that makes sense for your domain.
• Look for principles and practices in that taxonomy that can be put work in your domain.
• Look for research of others that has shown the problem and the solutions, and the reasons for less than expected results.

Making the Impossible Possible is a starting point. Heliotropic Abundance is the basis of the processes used at Ricky Flats (the book and place I worked as a Program Manager).

Positive Organizational Scholarship is an approach that might inform the conversation. Look to places where it is working (what ever it is) and determine if how they got it working can be moved to your domain.

 

We need better analogies

Jurgen Appelo has a nice post about the efforts to speed up the change in the management processes. While I don't share their goal for several reasons, it's still a good goal in principle.

My experience is that management processes in mature domains are well suited to service the needs of the domain. In inmature domain, management processes are good targets for improvement.

In building launch vehicles, manned space craft, weapons systems, commercial aircraft, the management processes are tailored to the need. They are disciplined, rigorous, methodical, and may appear to outsiders to be slow and plodding. These domains have heavy software requirements and many of the agile principles are in place, along with the management processes to get maximum benefit for them in the context of formal contracting.

In this domain, we get in trouble when we DON'T flow the processes and try to skip steps, replace known working methods with new and untried ones.

But there are many domains where management needs to be overhauled, and Jurgen and company are on a quest to do just that.

The Analogy Trap

Jurgen mentions the "attractor" as the analogy of the management processes that need to be changed.

That management is Attracted to a set of processes and those processes need to be changed. The picture above is labeled an attractor but it is in fact a picture of the path followed by the underlying equations of motion of a dynamic system. It is the artifact of this dynamic system.

Why is this an issue? Well it's simple. Jurgen mentions changing the attractor - replacing it with a new attractor.

It is NOT the attractor that needs to be changed, but the underlying equations that create the attractor that must be changed to produce a new attractor. These equations represent the dynamics of the system. When the analogy is flawed, we loose the ability to actually drive the change. We give away the connection between cause and effect. And then we're disappointed when something doesn't happen.

The garden as a self organizing system is one such analogy that produces less than expected results of good tomatoes, when we let them do their own thing.

In systems (complex or not) the equations of motion that produce a set of paths when captured over time produce pictures like the one above. These equations are deterministic, they are complex, they can emergent, and they are almost always represented in some space other than our familiar 3 dimensional world of X,Y,Z coordinates. The sample picture is in phase space not Euclidean space.

A simple example is the spherical coordinates of our world - the surface of the earth. If we were to start walking in a direction and hold our heading - or flying would be better - we'd end up in the same place we started. A spherical coordinate system returns us to the same place in the coordinate system after a 360° transformation - a 2π rotation.

The picture above is in a Phase Space, rather than a geometric coordinate system. The generation of the path in phase space is a common method in physics for showing complex relationships between the processes - a nice approach for management processes.

But the attractor does not attract in the sense of a force, pulling on an object - in the classical physics sense.The statement in the Wikipedia link is technically not correct. ... points that get close enough to the attractor remain close even if slightly disturbed. Those points follow their equations of motion they don't know that they are creating a pretty picture of the attractor, they are just following their deterministic path, guided by their equations of motion.

This is the key concept that should invert the analogy of Jurgen for the betterment of his quest. There is not attractor there are equations of management that must be altered.

The attractor is the path followed by the particle (in Jurgen's case, managers and management processes) while traveling inside the system (the management system). The picture is a plot of the path of the object moving, guided by the equations of motion. In the field I grew up in, the Path Integral describes how particle move between two locations guided by the forces that act on them.

So Back To The Analogy

For an analogy to work - or at least work well enough to be useful - it needs to inform a new understanding from previous understandings. But it has to be correct in the original space. The suggestion that a new attractor should be sought needs to be replaced with the search for a new set of equations of motion to generate the attractor - the picture above.

I got a book for Christmas, Feynman, Ottavini & Myrick. It's a graphic book of the life and accomplishments of Richard Feyman. Feyman was the father of a particle physics theory that won him the Nobel prize. He has great advice (starting on page 157) about when speaking about sticking to the real science when trying to explain something in populist terms. Once you bend the real science in an attempt to explain it in populist terms, the explanation looses its integrity and the resulting understanding looses its integrity as well.

My favorite no integrity populist book is the Tao of Physics, which was a wildly popular in the 70's trying to explain the parallels of particle physics and Eastern Mysticism and was based on completely crap (I was a particle physics grad student at the time).

Why the quest for integrity in the analogy? Once the underlying integrity is lost, the resulting benefit of he analogy is lost as well. That's the point.

Jurgen's analogy between management processes and attractors is useful - and has integrity - for management transformation. But it needs to be inverted to be useful. The underlying equations of motion are (or may be) flawed in the domain Jurgen seeks to improve. The attractor is just the  picture of the path taken by those equations over time. Change the equations - get a picture of the new attractor. Changing the attractor requires changing the equations. Not the other way around.

Seek new equations and the picture will change.

If the picture becomes more attractive in the populist sense, then mission accomplished.

Replacing Google Reader Link with Twitter

Google used to have a really nice feature in the Reader. You could use a Chrome plugin to post a link to the Reader, make some comments, and then connect that submission to the Reader in this Blog. This was great way to share information and - this is most important - keep a record of these finds for future reference. It was like a post-it note board or like the pages I have in my notebook where I keep ideas for future work.

But Google removed the feature, has some less-than-obvious way to do (not do actually) the same (close to the same) in Google+. Which I don't use and can't actually figure out why I would.

I poked around with TypePad. They haven't figured this out yet. Then I saw some Blogs and web sites , with a streaming twitter window. Ta Da, got it.

I moved all (or most) of the Google reader entries to this Blog through a gadget in Twitter. Now we're back to finding cool things, tweeting them, and capturing them in the Blog for future reference. There  is lots of flak for Google doing this. Maybe another example of Google misreading the users. I see no reason to have removed the feature. It was useful, handy, and cleaver. It's gone and have a dissappointed user.

Enjoy and workaround.

Fail Forward

I was reading a Bloomberg News article while stuck at the airport heading home. Waiting for the inbound flight Denver where they had 2 feet of snow today. The artilce used the term fail forward. The concept is around innovation and the culture of innovation.

There were example of famous lack of innovation stories. The Western Union internal memo stating This telephone has too many shortcomings to be considered as a means of communication. The wireless music box has not ... commercial use, was the response to David Sarnoff's request to investing in the radio.

These may be urban legends, but Edison did hire dozens of "inventors" to helo him fail forward and share what they learned from these failures.

What Does This Mean For Projects?

It an obvious tennet of agile to fail early and fail often. But that is just a buzz word phrase in practice. It's of no real value in the absence of a PLAN for failure.

Remember a Plan is a strategy for the successful execution of the project. And Strategy is a hypothesis that needs a test to move forward. This is where the fail forward takes place in an actionable manner.

One program I've worked is a BioPharma contract with the US Army for an anti-virus. The Integrated Master Plan has multiple steps to fail forward in the development and testing of a molecule that is the basis of the drug. The researchers are seeking failure in a sense. They having paths they are taking - with intent - to fail forward.

So what this means is:

• We need a risk buy down plan - this plan performs specific work to buy down or retire the risk that the outcome of the project will not be reached on time or on budget. The outcome must of course be compliant with the Technical Performance Measures, otherwise no one will call the project a success.
• We need specific Measures of Effectiveness (MoE) and Measures of Performance (MoP) for the increasing maturity of the product or service the project is producing. These measures have been described before

So the fail forward paradigm must define how you are going to perform work the actually moves the project forward. Edison did not randomly go try out things in his search. He had a Plan and Strategy. It was not a random walk in the woods looking for the solution.

There were 1,000's of trials. 10's of 1,000's of attempts to invent Radar as described in the book Tuxedo Park. All the processes were fail forward, not self organized, self actualized, self guided. But structured, organized, intent of the command efforts to discover something that was not discoverable without failing forward.

This is were the agile approach is at its most powerful.

We know what Done looks like - a blub of light, a radar systems where non existed before. Richard Rhodes The Making of the Atom Bomb describes similar efforts to Fail Forward.

The critical concept, many times missed or mis-used in the agile world, comes from the MoE paper referenced above.

The design of a system is an ill-posed problem that has no solution without a set of criteria to guide choices.

Without this set of criteria to guide the choices, the project wanders aimlessly in the forest of all options. This is the role of a Capabilities statement. The role of a Strategy for fulfilling those capabilities.

The agile notion of Epic provides this. It shows what done looks like in units of measure meanigful to the decision makers. It shows how the fail forward in the pursuit of DONE.

So ask the simple question

What is the Plan that shows the sequence of processes or activities we are going to need to fail forward?

 

Your recovery Plan is Not Thorough and Not Credible

When I encounter a triage situation, like the one starting in January, I'm always surprised at how many steps it took for the program to get to the ditch. Small, simple steps that led them over the cliff without even knowing it.

The discussion usually starts with blaming the tool. In the program management and program controls business PROCESS IS KING. Many decades ago, we used to do the program perform by hand with a quadrille pad and a pen. So tools only make the work effort more efficient, not necessarly more effective.

When we're managing a program we need both thorough and credible processes for the plan to

GET  BACK TO GREEN and KEEP THE PROGRAM GREEN

Thorough Processes

For the GET TO GREEN plan to be thorough it must:

• Identify and classify sources of all data and the variances for that data. This means that measures of Physical Percent Complete must be used for all work activities at the Task level.
• Assure all related systems and processes have bi-directional traceability between the work being performed and the data the provides visibility into that work.
• Identify underlying / system-related cause(s) of gaps in this data traceability.
• Continuously focus on opportunities to improve systems, processes, and people, and if none are apparent, can explain why.
• Define a plan to address any and all opportunities to improve or explains why the organization isn't addressing those opportunities.
• Explain — when improvement plans are justified — who will carry out the plan; when that person(s) will carry out the plan; and the methods for measuring result.

Credible Processes

For the GET TO GREEN plan to be credible it must:

• Involve people closely associated with all aspects of the systems and processes under review.
• Receive support, authorization, and encouragement from senior leadership.
• Present findings that are consistent and whose conclusions the Root Cause Analysis developed during the triage process.
• Consider relevant external examples of working systems, processes, and people skills needed to keep the program GREEN. No need to invent something new.

The challenge them becomes how to KEEP THE PROGRAM GREEN. Again Process is King. Know working management processes are available for any program or project domain. If the processes are not applied correctly, consistently, thoroughly, and credibly, then the project or program will be back in the ditch soon.

I have a colleague who has a phrase he uses on troubled projects. In his best southern (below I-10) Louisiana accent, he says...

How do ya know you'rer in the ditch? The weeds are hitting the windshield. Turn the wheel to the left and get out of the ditch. From then on try and keep the car between the white lines.

Quote of the Day

One approach to control optimism is to have an unassailable understanding of the facts.

When there is optimism in the air, then asking and answering fact based questions clears the way to understanding if that optimism is founded in fact.

There is no better place than on a project to seek a fact based discussion. This starts with the planned description of physical percent complete.

One this day we plan to have 40% of all the database interface code complete, integrated, tested, and checked into the source cde control system. By tested we mean tested against the pre-planned Unit and Integrated test procedures. By checked in we mean the code is complete and ready to be put to use by others.

Come that day, we can check to see if what we planned to do, we actually did.

If yes, we get 100% credit for spending our planned budget. If no, then we can't be on schedule, on budget, or compliant with the technical performance plan.

Only tangible evidence of physical percent complete is a credible indicator of progress to plan.

Idea Farmers

I just discovered a nice phrase from Jurgen Appelo. IDEA FARMERS.

When someone asks what is my contribution to the profession, the project, the problem, or the situation, I can usually come up with something in short order.

Either through:

• Direct hands on experience - having done it this year with my own efforts applied to the solution. This is a "touch labor" approach the solving the problem.
• A bit of research in the archive - having done it in the past 3 years. Again with a touch labor effort, but the gory details are starting to fade. But are artifacts remaining, reports, data, charts, etc. to show what was done, and what resulted that benefited the customer.
• A deeper search in the archive - having done in the past 5 years. The artifacts are there, but the details are starting to fade.
• Knowing how to do it from the principles - trained, certified, participated in the solution.
• Knowing someone that I know that has done it - the "golden Rolodex" of trusted source of help. This is a critical point in supplying the solution. Someone else provided the solution, but how they did it at the detail level may be different than I would do it. So absolute trust is needed to proceed.
• Knowing where to look - "Google" is our friend - look it up, read guidance, look for example.
• have a book on the shelf - read, study, connect the dots.
• pure intuition - it makes sense to do it this way.

The notion of a Thought Leader is bestowed not stated. So Idea Farmer is better. I tend to associate with Idea Farmers. When presented with a "situation," good Idea Farmers can come up with something quickly, test that idea against the reality of the situation, and get started toward the eventual solution with that guidance.

But there are of course issues with the Idea Farmer aprpoach.

• The ideas have to be credible - the result has to work in some way useful. The means any olde cocka-mamy idea won't work. The notion of Hey let's try this isn't going to produce credible results. There are many ideas otu there that "sound" good on paper, in a book, or at a seminar. That are in fact bad ideas.

Hey let's fill the cracks in the elevator door with a can of that sealant. OK sound good let's put 20 cans around the door. Opps, the sealant goes exothermic and catches fire.

• The ideas have to be actionable in ways useful for the problem at hand - having a idea that is a principle is nice for bar room conversation. Having an idea you can take out into the shop as we would say in the spacecraft business is needed.It has to be out to work to produce some kind of result that can be tested to determine if the idea is a good as we think it is.

Let's introduce agile development to our $200M ERP roll out project. Yep sounds good lots of people are saying this is the way the world is going. Hey anyone here ever done agile on a $200M ERP roll out before? Nope, well let's learn how to do this quickly because the big bosses think it's a good idea too.

• The ideas have to be provably correct to some level of fidelity - once there is some first level test that the idea might work, we need some way to prove it can be scaled to meet the actual solutuon demands.

The outcomes have to be know to some level of fidelity before we start committing other peoples more. Hey, why don't we switch from this application to this other really nice application I saw in a demo last week? What are to "show stoppers" in that application? Gee I didn't really hear any from the sales person when they were demo'ing the product at the trade show.

In the end the Idea Farmer has to possess several attributes for success:

1. Done this before in the problem domain
2. Have demonstrated success with the idea in the presence of all the problem that exist in the current problem.
3. Have measurable success in units meaningful to the decision makers.

From an upcoming Quote of the Day

Remarkable Claims Require Remarkable Proof

If you've got an idea that you've farmed from somewhere else, you'd better be able to show it'll work in the current problem. Otherwise the idea farmer may be useful for collecting ideas but not that useful for solving problems that someone is interested in solving.

This separates the educator from the practitioner. The educator is a powerful introduction to the topic. The practitioner may also be an educator - possibly not as good or well versed in the art of teaching and motivating the students - but can get the job done, while mentoring and coaching others along the way.

What Does A Master Schedule Look Like?

When we speak about "master" schedules in the space and defense business, this is what they look like. These types of "pictures" are all too common in the commercial world. In the defense business they look notional, but they are build from the underlying Integrated Master Plan and Integrated Master Schedule.

There are several tools that can make these charts from the Integrated Master Schedule. This approach ensures that the dates, dependencies, and top level process flow is represented correctly all the way down to the Control Accounts and Work Packages that on in the Performance Measurement Baseline.

There is no issue with having these types of Program Master Schedules for any project as long as they are connected to real baselined data.

Baloney Claims

There's the normal wave of un-informed opinions floating around again. I was reminded to look back a paper that explains how to sort out the claims that would be considered baloney.

How Reliable is the Source of the Claim?

Self pronounced experts often appear credible at first glance, but when examined more closely, the facts and figures they cite are distorted, taken out of context, or occasionally even fabricated. In many instances the statistics, numbers, or supposed facts used to support the claims are weak or poorly formed. Relying on surveys, small population samples, classroom experiments, or worse anecdotal evidence, the expert extends personal experience to a larger population.

Does this source often make similar claims?

Self pronounced experts have a habit of going well beyond the facts and generalizing the claim to a larger population of problems or domains. Many proponents of method make claims that cannot be substantiated within a broader framework. This is the nature of early development in the method world. Of course, some great thinkers do frequently go beyond the data in their creative speculations.

Have the claims been verified by other sources?

Typically self pronounced experts make statements that are unverified or verified only by a source within their own belief circle, or who's conclusions are based primarily on anecdotal information. We must ask, Who is checking the claims, and even who is checking the checkers? Outside verification is crucial to good science as it is crucial to good methodology development.

How does the claim fit with how we know the world works?

Any specific claim must be placed into a larger context to see how it fits. When people claim that a specific method results in significant benefits, dramatic changes in an outcome, etc. they are usually not presenting the specific context for the application of their methodology. Such a claim is typically not supported by quantitative statistics as well. There may be qualitative data, but this is likely to be biased by the experimental method as well as the underlying population of the sample statistics.

Has anyone gone out of the way to disprove the claim, or has only supportive evidence been sought?

This is the confirmation bias, or the tendency to seek confirmatory evidence and to reject or ignore dis–confirmatory evidence. The confirmation bias is powerful, pervasive and almost impossible to avoid. It is why the methods of science that emphasize checking and rechecking, verification and replication, and especially attempts to falsify a claim, are critical.

Does the preponderance of evidence point to the claimant's conclusion or to a different one?

Evidence is the basis of all scientific theory confirmation. The problem is having evidence alone is necessary but not sufficient. The evidence must somehow be "predicted" by the theory, fit the theoretical model, or somehow participate in the theory in a supportive manner.

Is the claimant employing the accepted rules of reason and tools of research, or have these been abandoned in favor of others that lead to the desired conclusion?

Unique and innovative ways of conducting research, process data, and "conjecturing" about the results are not scientifically sound. In almost every discipline there are accepted mechanisms for conducting research. One of the first course taken in graduate school is quantitative methods. This course sets the ground rules for conducting research in the field.

Is the claimant providing an explanation for the observed phenomena or merely denying the existing explanation?

This is a classic debate strategy—criticize your opponent and never affirm what you believe to avoid criticism.

If the claimant proffers a new explanation, does it account for as many phenomena as the old explanation did?

This concept is usually lost on "innovative" researchers. The need to explain previous results is mandatory. Without this bridge to past results, a new theory has no foundation for acceptance.

Do the claimant's personal beliefs and biases drive the conclusions, or vice versa?

All claimants hold social, political and ideological beliefs that could potentially slant their interpretations of the data, but how do those biases and beliefs affect their research in practice? Usually during the peer-review system, such biases and beliefs are rooted out, or the paper or book is rejected.

These guide lines come from a Scientific American Essay in November of 2001. IN the current domain and time such baloney claims include:

1. I'm doing earned value with a system that could be validated by the DCMA, but I've got my own way of doing this using Excel.
2. Lots of the agile baloney claims have disappeared, but my favorite is earned value is worthless for IT projects.
3. You can manage projects using social media like FB and Twitter, you don't need all those fancy and annoying charts and tables.
4. And of course my favorite - the Standish Survey. No sample size numbers, no non-respondent numbers. No variances within the sample bins. In many cases such "variances" show large overlaps.
5. And another favorite how to lie with statistics

Systems Engineering Body of Knowledge (SEBOK)

On several programs I've worked there is a phrase for the first 180 days everyone is a systems engineer. The concept of Systems Engineering is missing from most IT projects I've been on. Systems Engineering is a mandatory role on every defense, space, DOE, and similar programs I've on.

The Systems Engineering Body of Knowledge (click image to retreive) is the current gudiance to applying SE to projects.

This approach is a critical success factor in ways not always understood in some project domains.

1. The source of the story backlog in agile is not well defined. Systems Engineering and Capabilities Based Planning are this source. In agile they come from the customer. But where does the customer get them? Without a method to properly define these capabilities, their related requirements, and the systems elements of the project, the backlog is just a list. The integrity of the list has no way to be verified.
2. Projects are systems. Management of the project means managing the elements of the projects - the elements of the system. Here are those elements.

The identification of the needed capabilities is the focus of Systems Engineering. Development of the system is the focus of engineering disciples - software development methods are in this role. Agile Software Development is an instance of the class of development methods. Managing the Systems Engineering and Systems Development processes is the role of project and systems management. My Master is in Systems Management. This was the traditional aerospace and defense management path degree starting in the 1980's at the University of Southern California (USC).

 

 

Four Answers To Any Management Question

I was on the phone this morning with a colleage from a Canadian Bio-Tech firm. His firm was recently bought. The consolidating owner has an intensive business management process that flows down to managing projects. This firm has a simple approach to management. There are four answers to any question possed by a manager, be a business manager or project manager:

1. Yes
2. No
3. A Number
4. I'll get back to on this day with the answer to 1, 2, or 3