Herding Cats

Never Ask a Question If You Don't Know The Answer

As a project or program manager, your job is to ask questions. These questions appear in meetings, as a result of reports and data, from observations on people, processes, and technology.

But just asking questions is pretty a waste of time if you don't know what the answer is going to be. Or the choice of answers is goint to be.

This is the role of the PM, to know the possible outcomes of the work effort for the project. These possiblities are defined in the Integrated Master Schedule. The Work Packages in the IMS define the outcomes of the work effort, along with the Techncial Performance Measures for this work effort.

So when the PM asks:

We have this coming due deliverable in the next 3 weeks, can someone tell me the probability of completing on or before the planned date?

The possible answers need to be in the head of the PM, so there are no suprises when the answer comes back.

Quote of the Day

Money is what people without talent use to keep score - Jeremy C. Epworth

This is common in many domains, where the underlying technology or work processes are beyond the comprehension of management. I have direct experience with this in the Earned Value Management consulting business. When management does not "walk the walk," with some form of hands on experience with the tools and processes of getting the CPR out the door every month.

The result is manage turns to dollars as the measure of performance. Having dollars is an outcome of performance not the measure of performance. In the consulting world, the conversation goes like this - how many hour did you guys bill this period? If we billed the planned hours, then management is happy. In the EV paradigm this is the indicator of naïve thinking. This starts with the question what was our actual cost this period, rather than what is our "performance" this period. This performance is the "earned value."

The "value" earned during the period against the "planned budget" for that planned performance. This BTW is the factual definition of EV - EV earns it's budgeted cost - BCWP = BCWS x Percent Complete.

What these means against the quote, is when management or anyone measures "value" by asking how much something cost or how much money is involved, the value returned from this actual cost is lost in the conversation.

This is the basis of the Steve Jobs paradigm of delighting the customer and the revenue will come. If we delight the customer the billable hours will come, the continued work will come, and the customer satisfaction will drive revenue.

Quote of the Day

An error of commission is unfortunate
An error of ommission is unforgivable

Nicholas Pisano, Navy Commander - Retired, US Navy

Nick is the President of Safran North America. I'm a member of the Safran team working a US Army BioPhrama program getting ready for ANSI-748-B system validation of the Program Control system. This includes all the cost, schedule, budgets, deliverables, risk handling strategies, activities traced to the SOW, CDRLs (Contract Data Requirements List), and all performance measurement information.

If these artifacts are in error, they can be corrected. If they are missing, the credibility of the program is suspect. This seperation of the techncial artifacts from the programmatic artifacts is a critical success factor for all non-trivial projects, for the simple reason:

Measures of physical percent complete come from assessing the tangible evidence of progress compared to the planned progress. This is the basis of all agile software development. In Scrum the planned deliverables from the iteration compared to the actuall - working - deliverables is a measure of progress.

It is also the basis of Earned Value Management as defined in ANSI-748-B

But since Agile provides no means to capture and measure cost, andEarned Value does, we need to couple Agile with Earned Value to form a match made in heaven.

 

If It's Opinion and Personal Keep It To Yourself

There are almost unlimited opinions in the project management world that are personal opinion, ancedotes from personal experience, and applied to a specific domain and a context in that domain. This is all good, it's a source of information and a conversation starter.

But without the proper labeling, it's difficult to tell where this information comes from.

This information has two attributes:

1. It's subjective (opinion) - it is an opinion that may be based on a collection of observations over some period of time, but can't be traced to a credible set of verified processes to produced those observations.
2. It's verifiable - there is statistically sound evidence that this piece of information is validated or validatable in a named domain and context in that domain, and can be observed in the absence of the speaker. 

There are two intended audiences:

1. It is for Personal consumption - meaning this is an opinion shared between individuals (or small groups) in private or restricted group. Some place like a cocktail party, standing on line at the bank, or chatting with stangers at the tennis court, or in the lunch room of the office.
2. It is for Public consumption - meaning this information has been vetted to have some sort of credibility that makes it interesting to strangers. For verified information you need to provide references, a bibliography, the underlying data, the analysis processes of this data that resulted in this informaiton - so the listener can do the same validation as well to confirm that you're not just making this !@#$ up or worse pawning off your personal ancedotes as actual fact outside your personal experiences.

Quote of the Day

Conceit is the quicksand of success — Arnold Glasow

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.

 

Running a Project Status Meeting

Lynda Bourne has a nice post on managing meetings. While there are lots of reasons for meetings, a critical meeting is the weekly project status meeting. In this meeting the project team determines if they are on schedule, on budget, and on technical performance.

In order to do this is a short time, there must be a scripted set of processes. These process come from my experience in the aerospace and defense business and most importantly from Rocky Flats Environmental Technology Site (RFETS) and the recent case study Making the Impossible Possible: Leading Extrordinary Performance, The Rocky Flats Story.

By the way, this book is mandatory reading for anyone interested in how modern management principles are applied to complex, high risk, high reward projects. It is a description of the practices of project, people, and process management in the presence of uncertainty, emergence, and conflicting forces. All the management book writers need to read how those tasked with producing success actually did it.

One critical outcome of the RFTES experience was the Plan of the Week and evenutally the Plan of the Day. But first we need to start with the end in mind.

The principle role of Project Management is to avoid surprises. You can be late, you can be over budget, the gadget youare building can not work yet. But it can't be a surprise.

Next comes the actual Plan of the Week

• The Plan of the Week (PoW) is a framework for planning the work and working the plan.
• The PoW is derived from the Integrated Master Schedule (IMS).
• Coming due items for the 3 week look head (moving window) are extracted from the IMS for each CAM to discuss.
• These include the planned starts and planned finished during the period. This report is produced on the Thursday prior to the weekly Program Review.
• Each Control Account Management (CAM)(a project manager in the PMI sense) discusses those coming due items and speaks to the confidence that they will completed on or before the due date – either started or finished. With this information, the CAMs can then have a conversation among themselves of the commitments needed for the interdependencies between their planned work.

These coming due items are taken from the Integrated Master Schedule. This data is extracted after the schedule is statusted the previous week. In our case that is the Thursday prior to the Tuesday Project Status Meeting

This list is the items that:

• Are planned to be started in the coming 3 weeks
• Are planned to be finished in the coming 3 weeks.

With this list the Project Status meeting can now start. This meeting is broken into 3 segments.

First 15 minutes

• the Program Manager (or Project Manager) reviews all the coming dues from the extracted report from the prior weeks status. This status is the physical percent complete update from the owners of the work. This status is the basis of the Earned Value updates to the Work Packages and the flow up to the Control Accounts.
• The Program Manager will review the collective coming due data and provide a summary of the high points, major risks, and discussion topics for the remainder of the meeting.
• During this first 15 minutes of the Plan of the Week the PM will all report the activities scheduled for the coming weeks that require senior management action.
• If there are items planned for the week that are not on the spreadsheet they will be noted and added AFTER the first 15 minute phase of the meeting.

Second 15 minutes

• After the Plan of the Week items have been reviewed by the PM and the CAMs  to confirm they have everything for the next 3 weeks 
• Additions, changes, or deletes made, we can move to “new business,” which will include items that:
  • Did not complete when promised 
  • Have been rescheduled for the coming period 
  • Have been moved to future date
• Items not completed as promised will be called out for corrective action.

Last 30 Minutes

• Each CAM will walk through the coming due items and confirm that the dependencies required for success to that deliverable or completion items are in place.
  • Planned to start in the next 3 weeks
  • Planned to finish in the next 3 weeks
• External dependencies
  • Each CAM will confirm with other CAMs owning that external dependency that the required items will be available when needed.
  • If not, then the supplying CAM must state when that item will be available.
• Wrap up
  • All CAMs and the PM concur that the planned start and planned finish items will take place on or before the planned date.

This is the shortened version of the script for the Plan of the Week. But the time frame is always the same. The primary purpose of the PoW is to assure ourselves that we are not violating any of the root causes of project failure which are described below.

There are more casues of course, but these have been shown to be the most important from the program controls side of the management processes. We'll assume there is a good set of requirements, all the stakeholders are behaving properly, and all the other softer issues are being handled. If not, you've got a much bigger problem on your hands.

A Final Reminder of the 5 Immutable Principles

As always these project status meeting processes fit into a larger context.

All the management theories and next generation principles aren't going to get you anywhere if you don't know the answers to those 5 Immutable questions.If you can't control the sources of project train wreck all the "next generation" team building and management won't help. You must have tangible evidence that the project is making progress according to plan.

That has to be credible of course, but with the plan you must be able to see if you're going in the right direction toward DONE.

Now using Lynda's advice, add the mechanics of conducting the project review weekly meeting.

 

Project Breathalyzer

Long ago there was a large program, the Worrld Wide Command Control and Communications Systems, that was supposed to replace the AutoDIN. After many billions of government dollars, there was no Dial Tone. From the after action report the Software Project Managers Network was founded in 1992 by Norm Brown. From that organization came Little Books. One of the book is titled Project Breathalyzer, October 1997. These are the tests to determine of your project can pass the test.

1. A credible activity network supported by a WBS, Control Account, Work Package structure.
2. A credible schedule and budget for all the identified activities?
3. What deliverables you are accountable for.
4. Your top 5 risks.
5. Your cost, schedule, and technical performance margin.
6. The estimated cost for each deliverable.
7. The external dependencies and how they drive your cost, schedule, and technical performance measures and how you are going to manage them.
8. Your staff has sufficient technical expertise to accomplish the planned work.
9. You have adequate staff to maintain your planned schedule, cost, technical performance measures.

We've used these tests in the following way:

1. Have the project staff answer these questions every week.
2. If there are not credible answers, then go get the answers.
3. Once you get the answers, assess how these answers impact the cost, schedule, and performance of your project.

No matter the answers, you need to ask and answer these.

Quote of the Day

“All men can see the tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved” - Sun Tzu, Chinese Philosopher

I'm starting a new engagement to triage an Army program that has "gone off track," and needs to be put back to GREEN. The kick off of the 10 week effort, before the Government comes in June to surveil the systems, people, and processes designed to keep the program GREEN.

The start of the engagment always starts with a wall of truth that contains the work activities. There is a large wall in the conference room, with butcher paper, swim lanes, and sticky notes. The swim lanes are:

• People - who is doing what, when
• Processes - what is being done, by whom, when
• Tools - how is this done, when

This people, processes, and tools catch phrase is usually just that, a catch phrase. We need to turn this into actionable outcomes.

• People - in the best of worlds, you get to pick the people on the team. Try as hard as you can to do this. If no, have a strict screening process. Hold each person accoutable for their contribution. By tough on those not meeting those commitments. It's NOT about the self actualizaiton of the staff - at least as the first priority. It's about project performance. Self actualization comes for performance. Projects are team sports. Teams as assembled to win.
• Processes - process is king once you have the right people. Following the process is how teams win. The process can be loose or strict. The process can be agile or it can be full DoD 5000.02. The notion that agile is not formal, strict, and structured is of course nonsense. Doing Scrum - right - requires more discipline and rigor than some open ended PMBOK style processes.
• Tools - are nice. Tools remove tedium from the project. But tools only work is you have a process and people who follow the process.

Quote of the Day

Eminence based medicine — The more senior the colleague, the less importance he or she placed on the need for anything as mundane as evidence. Experience, it seems, is worth any amount of evidence. These colleagues have a touching faith in clinical experience, which has been defined as “making the same mistakes with increasing confidence over an impressive number of years.” The eminent physician's white hair and balding pate are called the “halo” effect. — from "Seven alternatives to evidence based medicine," British Medical Journal, 18 December 1999.

When I hear about new and innovative processes, technologies, or theories of how to cure the world's ills - from energy to new management techniques, I start my quest with the question...

Ya got any evidence your idea actually works in the domain I'm currently working in?

No? Well go get some and come back, I'd love to see it work here. Many times I never hear from them again.

Pearl Tree

I've used several approaches to collecting and managing ideas over the years. There were URL browsing capture tools that put links into folders. There is of course each browsers ways of saving links. There is MindJet which can do this on your computer and then you can publish the Mind Map to the web. The are several mind mapping tools, The Brain is one that I tried for awhile.

But now I've found what I was looking for, with a few missing features. It's call PeralTree. Not that snappy a title. But it does what I need. Captures web content and arranges it into "trees" that can be navigated with a Flash PlugIn. You can share nodes in the tree with others.

It needs some more work.

• Interface with Outlook for emailing links to locations in the Tree
• A way to cross link, so navigation can move between nodes. That would make it a network navigator

But so far it fits the bill for the perfect idea organizer.

Verifying Recommended Practices - You've Got To Show Me the Data

If we're ever going to move away from the anecdotal style books, we're going to need experiments that show the recommended changes actually work. The material to the left, Code of Best Practice: Experimentation is one place to start.

 

In the beginning of Agile it was all anecdotal. Strong push back came when there were questions about applying those practices outside of personal experience. It is a trait of many disciplines that the early developers have a good idea, but resist attempts to have others assess and verify their ideas. Just try it you'll discover what I discovered. That's good when the project is low risk. But when you're using someone else's money, it's a bit harder to just try it.

Same situation in the business process management domain. Listing all the problems is possibly good, but I doubt many are unfamiliar with all the problems. Listing solutions to those problems in the absence of a domain and a context in that domain, mean the anecdotal information is stuck in the domain and context of the author.

In order to move - credibly move - to another domain, an experiement is needed to show the suggested solution methods will actually work.

This is another aspect of popular books, they are usually missing that experiment in another domain.

Here's my working example

Agile development in the form of Scrum has been around for a long time. It is used in many domains.

There is conjecture that it can be applied to government IT programs. There are conferences about this topic. I've spoken at several and introduced the idea that the Federal Acquisition Regulation (FAR) and the Defense version (DFAR) have much to say about how you manage a program and what methods are used.

The work now is to connect the two ideas - Agile and FAR/DFAR/Earned Value - so both can work in the ways they are supposed to work.

So Back To Business Processes

We've got lots of suggestions on how to un-stick business management. Got any experimental evidence that any of those suggestions actually work? No? Then we're at the same place we were when XP started. You gotta try it before you can say it doesn't work. Not likely when someone else's money is involved.

 

Another View of Agile

Power to the Edge: Command and Control in the Information Age, speaks to the integration of traditional management with complex systems in the presence of agility, emergence, and variability of the real world.

This is a book about managing in the defense systems domain and the technology advances that push the decision making processes to the edge of system.

This is about architecture of the system. The human system, the techncial system, the operational system, and the governance system, and the environment in which these systems are embedded.

While the book is focused on military systems, it is applicable to other complex systems. Military systems have many if not most of the attributes of business systems.

They have strategy, emerging requirements, adversaries who want to put you at a disadvantage, limited budgets, limited time to deploy the solution, conflicts internally and externally that conspire to have your efforts fail.

The notion of centralized planning and decentralized execution has merit in modern software development processes and the business they support. Planning is NOT used in the way agile software developers use the word Planning - wrongly BTW. Planning in the defense domain, for defense processes, and the programs that deliver the systems used in those processes means Strategy Making.

All Planning is Strategy Making. So when you here an agilest say Responding the Change Over Following The Plan, they should really be saying following the schedule. The irony of course is even the formal DoD Earned Value Management world, there is a nice little form titled BCR (Budget Change Request) and its used all the time to make changes to the cost and scehdule baseline. Whym beacuse things change. But if we're changing our Strategy all the time, then there's a much bigger problem to solve.

Calculating Outcomes

To follow on a recent theme of what's wrong with populist book? is shown in this example. Integrating Air, Land, and Sea Operations, which speaks to integration of complex systems into a System of Systems that behaves in ways not definable in the beginning. This is done through intelligent agents at the nodes of the network. This is called network centric warfare.

The Integrated Master Plan (IMP) is a Strategy for the successful completion of the Program. Like all strategies, a set of hypothesis are needed to test the strategy. With these hypothesis testing processes, there is no way to known if the strategy - the Plan - will work.

This is a sample of a book where popular ideas are presented and at the same time actionable outcomes are provided.

Tell Me It Isn't True

When there are statements like this, in the absence of a domain and a context of a domain, it just reinforces why I don't recommend you read any populist books on a topic if you have any skills at all of getting to the first level of actual technical context for that topic.

Taken from a recent blog post on "complexity thinking" with 4 populist management book references

 

So let's start here with a survey of the topic from the non-populist point of view - that is actionable. That is from the point of view of people who want to calculate something, make a decision on the outcomes from that analysis.

 

Nothing wrong what so ever with those populist approaches. But one test that has served me well over the decades is can I calculate something with this person's product (book, paper, or article)?

No? Then I may not be able to calculate something directly from the author's work, but I'd better be able to find out how to do it in an appendix or a reference.

Still a No? Then is there something there that will lead me to the next level of understanding where I can start to see how I can calculate something. Here's the recent example about Moving Beyond Populist Books.

What's this means is that while the populist books may be informative to many - and we need a lot more informed people than we have now - these populist books and materials quickly run out of steam when we want to actually make a decision that involves money, time, resources, risk, commitment of someone else's stuff. In other words we need to know quantitatively and analytically what the probability of success will be if we follow that authors advise.These populist books play a role of starting the conversation, but fail to complete the conversation - in many cases - with actionable outcomes. They point out the problem but not the actions need to create the solution. Knowing the problem is necessary but not sufficient.

I can hear the populist authors squawking now.

What! How dare you critize my popularizaiton of this critically important topic with your lame need to actually apply this idea in a quantifiable manner. 

But their role is to popularize a topic, not necessary do the calculations needed to solve problems with the popularization.

So if you look at the reading list of the paper above, you'll see books, papers, articles that DO provide actionable outcomes. Once you've digested the populist ideas, take a tour of those to see if there is anything there you can put to work on your own complexity management problem.

Don't get me wrong. Populist books are fine. But they are just that populist not the engineering books I need to work the problems in front of me.

For some more background on complex systems in the world I work see:

• NDIA Human Systems
• Verification and Validation in Complex Adaptive Systems
• Cybe Space: The Ultimate Adaptive System and the Operationalizing Agility 
• The Agility Advantage: A Survivall Guide for Complex Enterprises and Endeavors. This eBook will freak out the agilest who don't understand the notion of Command and Control is mission critical paradigms, where agility must operate in the presence of 100% Mission Success.

What Does Complexity Acheive?

With all the wrangling around simple systems, avoiding complexity, emergent order out of complexity, we need to ask what does complexity achieve.

In a paper titled, Complexity and Robustness J. M. Carlson, Department of Physics, University of California, Santa Barbara, CA 93106 and John Doyley, Control and Dynamical Systems, California Institute of Technology, Pasadena, CA 91125 , they tell us ...

 

 

 

 

 

Complex Adaptive Systems

When I read something like..

Self-organization is the process where a structure or pattern appears in a system without a central authority or external element imposing it through planning.

I get a smile on my face. The populist (like that above) definition of a CAS is clearly designed to inform the general public and establish a basis of discussion around the notion that organizations and the people who populate them are subject to forces outside of their control and management must act accordingly.

Good advice. But it's one of those good pieces of advice based on a naïve understanding of the underlying principles. In this case the Lagrangian of the individual elements that interact with each through a combined set of ground rules. In the mechanical systems domain, gravitational, electromagnetic, the strong, and weak forces - your choice.

But First Some Background

A vision shared by most researchers in complex systems is that certain intrinsic, perhaps even universal features capture fundamental aspects of complexity in a manner which transcends specific domains. It is in identifying these features that sharp differences arise. In disciplines such as biology, engineering, sociology, economics, and ecology, individual complex systems are necessarily the objects of study, but there often appears to be little common ground between their models, abstractions, and methods.

From Complexity and Robustness, J. M. Carlson, Department of Physics, University of California, Santa Barbara, CA 93106 and John Doyley, Control and Dynamical Systems, California Institute of Technology, Pasadena, CA 91125.

It's for this very reason that statements found in the first quote - in the absence of a domain and context - have little use outside of popularizing the notion of Complex Adaptive Systems. They best serve those seeking words without the underlying tools for analysis.

It is this little common ground where the popularizations have difficulty. They want to state ideas without out all the wrangling about the details, the semantics, the gory mathematical complexities. They are popular and therefore readable in the absence of the details.

Failing to acknowledge that popularizations are just that, popular for a reason, creates issues when it comes to making calculations or decisions using other peoples money.

Back to the Populist Approach

Who cares if the statement above is based on naive principles, if it works? Well clearly those reading and writing general management books are not concerned with the underlying details. Their job is to inform the populace not provide tools to calculate solutions.I'm reminded of the advice to Stephen Hawking when he was writing A Brief History in Time. He was told sales of the book go down by ½ for every equation he used. Compared to The Large Scale Structure of Space-Time, (a graduate text I still have on my shelf), where every page  of the 381 pages is as dense like the clip to the left of this paragraph. (Click for full size)

Motivation for the Underlying Principles

Let's look beyond the simple definition for some understanding of CAS. But first let's look for some motivation...

As a physician, I learned to think from a biological perspective. When I went into management, traditional organizational theory seemed artificial, foreign to my experience. So when I started studying complexity, I was stunned. Here was a way of thinking about organizations that compared them to living things. That makes sense to me, intuitively." Richard Weinberg, MD, Vice President, Network Development, Atlantic Health System, Passaic, New Jersey

This intuitive understanding is critical for many reasons, not the least of which is to convey a broader understanding of the problem space to the general public to gain their interest in further discussion.

So here's a succinct definition from the Santa Fe Institute focused on the social aspects of CAS.

Definition: A Complex Adaptive System (CAS) is a system of individual agents, who have the freedom to act in ways that are not always totally predictable, and whose actions are interconnected such that one agent's actions changes the context for other agents. Examples of complex adaptive systems include: the stock market, a colony of termites, the human body immune system; and just about any collection of humans such as an industry, a business organization, a department within an organization, a team, a church group, a family, or the Rotary Club.

In this definition of CAS these agents act according to their own rules. These rules are defined for specific classes of agents in the system. Either one rule for all or a single rule for each of agents, or any combination.

The behavior of the resulting system emerges from the interaction among the agents executing their rules of interaction. In this case the Central Authority is the collection (one or many) Ground Rules for how these interactions take place. This is subtle but critical to the next step, when CAS is applied to business.

There are always Ground Rules. To not have ground rules defies the laws of physics. But these ground rules may be flawed. When they are, the outside observer would say the system is broken. That is the system behaves in undesirable ways. But those ground rules that central authority is still in place. It is always in place.

In order to return the system to its desired behavior, those ground rules of interaction must change.

The CAS exhibits novel behaviors resulting from the interactions. The interactions defined by the ground rules covering all objects in the system, or "N" Ground Rules one for each element, result in fundamentally unpredictable behavior. It is not a question of better understandings of the agents, better models, or faster computing; as we have come to believe erroneously, based on the machine metaphor. We simply cannot reliably predict the detailed behavior of a CAS through analysis.

But this does not mean there is no control system in place. This control system is distributed among the elements of the system. When the phrase...

where a structure or pattern appears in a system without a central authority

...is used it begs the question - what is the definition of Central? Most populist approaches fail to make this subtle and important distinction. This is why they are populist. To make these distinctions requires deep analysis and the introduction of more complex mathematics. The analogy used in the original quote suffices for the discussion at the populist level. It works, so let's move on.

But of course, we'll want to calculate something one of these days. Say the forecast close of the Stock Market tomorrow, given any non-disruptive events. While we cannot predict the precise closing value of the Dow Jones Industrial Average tomorrow, we can estimate (with a confidence interval) the market trend as bullish or bearish and take appropriate action on this estimate with a known confidence.

Note the qualifier of any non-disruptive event. This approach provides some confidence in understanding human based systems. But care is needed to not over-estimate the ability to predict what will happen outside the error bounds of our forecast.

It is popular to say ...

In a CAS, control is dispersed throughout the interactions among agents; a central controller is not needed.

Notice the difference between control and controller. The controller is distributed among the agents. But there is control, just not in a single entity.

In the end the business writers are right, but for the wrong reason.

Trying to apply external control, or a single internal controller leads to disappointment. But there is control and that control must be in place for any system to work and not turn into a dispersed set of agents flying off into the universe. This is the definition of Chaos.

The Take Away

The ground rules of the independent controllers that make up the control algorithm of the system must act in ways that produce beneficial outcomes. It is the correction of the actions of the individual (or collective) controllers that make up the control algorithm that must be the target of management processes.

Not the naive belief that there is no control needed and the control will emerge from the group of agents. There is always control at some level, be it microscopic or macroscopic. But it is always there. If it is microscopic we may not be able to see it or have any influence on its outcomes. If it is at too high a macroscopic level we are likely not going the like the outcome either.

In the end it is the semantics that are important, especially when we want to calculate something - say the probability that it will rain tomorrow on the Front Range of the Rocky Mountains. Since the weather on the Front Range is a CAS - all weather is a CAS - doesn't not remove our ability to make forecasts of it's behavior in the very short term and the long term - Global Circulation Model scales. And especially when we want to make MANAGEMENT decisions in the presence of CAS, these populist descriptions fail to provide much guidance.

Self Organizing Analogy Only Works when the Domain is Defined

While watching the AFC West playoffs with our beloved Broncos v. New England (they lost bad, were outplayed, and couldn't stop Brady), it dawned on me how defining the domain is critically important to any discussion around a method. This is connected to the popular statement in a well known agile management book...

A football team self-organizes within the boundaries of the playing field and the rules as they are laid down by the football association.

The first thing to recognize in American Football, when watching the game in the family room, is the coaches call the plays. A world class quarter back may decide on the line to change the play with an audible, but the offensive coordinators see the field from the top of the stadium and call plays from the  play book - the strategy for winning the game. The game is NOT self organizing on the field. Maybe the company picnic flag football game.

The coach calls plays from the side line, with the advice from the coordinators - offense and defense.

The is how professional football works. Similar processes take place for Volleyball, pre-planned plays. Baseball not so much, since the play evolves from the pitch, but once the ball, if hit, the processes for getting the out are practiced and practiced and all the palyers know exactly what to do. Same for Volleyball - having played in college.

Don't tell me you're game is on, you do it in practice first - Brady to Gronkowski

The 3^rd TD Brady to Gronkowski, where he was ½ step ahead of the defender and the pass landed in his hands without missing a step. This is not self-organizing on the field. That pass had to have been practiced 500 times. Every step, every shoulder turn, every motion practiced. That's called execution excellence.

Hockey executes rehearsed plays, soccer executes rehearsed plays. Once in awhile there is a broken play, but not often. I don't know of any field sport where the game evolves on the field guided by rules defined by some external body. Even professional cycling has a strategy for every portion of the course. Watch the Tour and the coaches in their cars talking to the riders,reading from the play book for the race, guided by the course and the specific responsese to the action developing in front of them.

I know of no successful complex activity that can succeed through self directed action by the player(s) on the field in the absence of a Plan and a set of practiced Plays needed to execute the Plan. There also must be plans for handling the unexpected once the game is underway.

The next popularized statement is ...

Self-organization is the process where a structure or pattern appears in a system without a central authority or external element imposing it through planning.

This of course violates the laws of physics of any system of interactions in the known universe. Human systems of course appear to operate in this way, but only because human systems are complex in ways not understood by other humans. So if the domain of human systems in the presence of poorly understood interactions had been used, then maybe the statement would have merit.

Here's What Has To Be In A Plan For Success

So let's look first at the processes needed in the presence of human systems to establish a central authority and an external planning process. Both are present in all human systems. The central authority, in our program management domain is usually called The Ground Rules. Having ground rules prevents chaos from breaking out on day one. Re-imposition of the Ground Rules can recover the human system from chaos.

I'm working a program now where chaos reigns, because the Ground Rules for managing the project have been abandoned. And this Blog is about managing projects, so we'll stick with the management of projects domain, even complex projects involving complex human behaviour.

So here some Ground Rules for project success in the presence of possibly chaotic human behaviour, whether we're playing a team sport or building the next manned space flight machine.

1. The team has to know what done looks like, so they can recognize done when it arrives.
2. They have to know how to reach done, usually along multiple paths, since the plan never goes according to plan.
3. The have to have the right resources, skills, experience, capabilities, intent, and capacity to execute the plan.
4. The impediments to success must be recognized, handled, and reduced (retired) within the planned budget and schedule. It's easy to handle risk when you've got more money and time than you planned.
5. And finally to succeed you've got to measure your progress in units that are meaningful to the decision makers. In the Pro-Football paradigm, it's not just the scoreboard (well it is in the end) along the way. There are dozens of metrics used to measure progress toward that win. This is the case in any sport and it is certainly the case for projects using other peoples money.

So the football paradigm popularized in the quote above is not actually how American Football, Soccer, or any other ground rules based team sport works unless it is just jungle ball as we would say about the company picnic volleyball game - which I learned long ago never to participate in.

Quote of the Day

There is no act that is not the coronation of an infinite series of causes and the source of an infinite series of effects - Jorge Luis Borges ”La flor de Coleridge”, in Otras Inquisiciones 1952.

When we seek to produce a credible plan, schedule, cost, or technical performance estimate, we must know the causes of variance and the impact of that variance on the acceptability to sustain successful  outcomes from our work efforts.

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.

Hierarchy of descriptions of DONE

The Five process areas of a successful project or program are.

There is a hierarchy for applying of these principles:

1. Needs, Goals, and Objectives - business direction based on higher level objectives.
2. Business Unit requirements - structure, relationships, governing principles, and inter-business unit mission linked to the accomplishment of the needs, goals, and objectives.
3. Business Unit Requirements - high level requirements flowed to the program to carry out the strategic and architectural direction including programmatic and technical aspects for initiation of specific projects in the business unit.
4. Program Requirements - detailed requirements for a Program to implement the Program Plan and flow downs to requirements allocated to specific project elements.
5. Project Requirements - detailed requirements for a Project implementation allocated to the technical and operational elements.
6. System Requirements - detailed requirements allocated from a Project to the next lower level of the system elements.

This approach builds a line of sight traceability from the lower level technical elements to the Mission of the Program to produce needed capabilities.

Some would suggest that emergent requirements are the way to go, with self directed team. But when spending someone else's money, the answer to why are you doing this needs an answer connected to the desired capabilities resulting from the work effort.