Herding Cats

Another Bad Analogy

The use of analogies is some common that we pay no attention most times if they are correct, useful, or even appropriate. Remember the cockamamie garden analogy, where gardens are best left to emerge by themselves. Don't know about your part of the work, but that's called a weed patch here in Northern Colorado.

A common one that I've heard for the past 2 weeks on a Balanced Scorecard engagement for an IT organization is fire fighting.

We spend all our time fighting fires, and don't have any time left for this IT Strategy stuff.

We can't really stop for a strategy process because we spend all out time fighting fires.

You've heard this, you've probably even said it.

But what do fire fighters do most of the time? By most of the time I mean the majority of the time?

They Don't Fight Fires

If they did, they'd be exhausted in a month, have broken all their equipment, run through all their consumables, and pretty much wrecked the fire department.

No fire fighters PREVENT fires from happening. That seek to remove the source of fires. It's called Fire Prevention.

So what's the equivalent of Fire Prevention in the IT project management world? Well it starts with realizing that running around putting out fires is a REALLY bad strategy for running an IT department, in exactly the same way it is for a City Fire Department.

The Fire Chief Boulder Fire and Rescue would be appalled when the station Captain reported that there was a fire everyday that was preventable, but we decided its was better just to fight the fires, than figure out a way to prevent the fires from starting. Imagine using the excuse for the Fire Chief that you have heard used for IT - man we're so busy putting out fires, we can't possibly stop to figure out how to not work so hard.

Right

Think again, your job as a PM, developer, operations person is to prevent fires from happening. I came to this by reading the ITIL Foundation V3 guide. I'm not at my core an ITIL guy, but it should be mandatory reading for anyone working in IT. So when you hear the phrase we're fire fighting, you should break out in the loudest laugh you can conjure up. Then ask when is the Fire Station going to burn down, because is you keep doing what you are doing you are next.

Quote of the Day

Round numbers are always false - Dr. Johnson

Without knowing the variance, the underlying probability distribution function that generates that variance, all numbers used for decision making are suspect.

We Have Found The Enemy and He is Us

In working a project to produce a Balanced Scorecard for a public agency built around ITIL V3 I've come to an understanding I did not possess before. In executing this project, we apply our Deliverables Based Planning^® project management method. In this approach (DBP^®) there are five process areas:

• Define the needed capabilities in terms of scenarios and their Use Cases
• Define the technical and operational requirements that implement the needed capabilities.
• Define the Performance Measurement Baseline to guides the development activities to implement the requirements (Deliverables, Schedule, Cost, Resource Assignments, Budget controls, ...).
• Execute this Performance Measurement Baseline (Cost, Schedule, Earned Value, Technical Performance Measures, Measures of Effectiveness, Measures of Performance, Resource Management).
• Perform Continuous Risk Management (CRM) using a formal method.

These activities are arranged like this.

The connection to the PMBOK^® Knowledge Areas - the assumed knowledge required to manage a project looks like this:

So Here's My Epiphany

Most of the activities in PMBOK^® are actually Level of Effort. As we say in the space flight business you're doing things that don't fly to orbit. PMBOK produces lots of documents. Documents are fine, that's not the point. But documents don't fly, so what ever document you produce had better be only one level removed from flying machines or what ever your project calls DONE, a hole in the ground (construction), a screen to log on to, or a vehicle your can drive away in.

The success of a project management method, any method, MUST be that it produces a defined set of deliverables, on or near the planned time, and at or near the planned cost, and more or less compliant with the needed capabilities, technical and operational requirements.

THIS IS THE CHALLENGE OF PMBOK^®

PMBOK doesn't say HOW to do this. How to produce the deliverables.  It's not supposed to say how. It's not designed to say how. But without some guidance on How, the readers are left to their own devises to figure out How.

Prince2^® says how, ITIL^® Foundation V3 says how, DoD IMP/IMS Development and Use Guide says how, DOE O413 series says how, even the DoD version of PMBOK says how.

Without HOW it's hard to know if what you doing is actually going to work. If you have answers the five immutable principles of Project Management.

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

 

How to Manage in the Presence of Uncertainty

In the act of creating, people argue. They have heated dialogue. They get upset! Without real exchange, you can’t create knowledge. Knowledge creation is a human activity. - Ikujiro Nonaka

You cannot have an execution culture without robust dialogue – one that brings reality to the surface through openness, candor, and informality. This is called “truth over harmony. - in Execution: The Discipline of Getting Things Done, Larry Bossidy and Ram Charan.

These are two of my favorite quotes, along with Jon Katzenbach's definition of a team of A group of individuals holding each other mutually acocuntable for a shared outcome.

Seems these days we focus more on the avoid of conflict and the touchy feely aspects of managing projects than actually getting the delievrables out the door.

Quote of the Day

To speculate without facts is to attempt to enter a house of which one has not the key, by wandering aimlessly round and round, searching the walls and now and then peeping through the windows. Facts are the key.

- Julian Huxley, Essays in Popular Science

Finding the Reasons for a Project

When I hear discussion around the management of projects and the management of a portfolio of projects I come back to a foundational question - Why Is This Project Being Done?

This question usually has some simple answer, because someone told us they wanted it. Or, It is needed by the business. Or something like that.  

The result usually doesn't impact the developers themselves, but it certaintly impacts the development organization and all of IT. The impact is simple

There is more demand for work than there is capacity for work

If anyone is looking for one killer answer to why we need Project Mangers in IT or software development, this is it. Who manages the demand? Who manages the capacity?

Demand and capacity management is part of any business and technology governance process. Managing demand is Project Management. Managing demand is business management. Managing the day-to-day work is the responsibility of the Work Package Manager on the largest (multi-billion $) defense programs we look after, so the IT shops should be able to figure out how to do this - I know, let's use Scrum!!

But How Do We Manage Demand?

Demand management is a systems engineering discipline in the corporate IT world. Demand management is part of forecasting, budgeting, and performance management. If we look at a general business definition of demand management it says,

In order to manage planning, production and delivery, any properly run business has to be able to balance orders for its products and services (i.e., demand) with its ability to produce them in terms of resource and scheduling constraints (i.e., supply). Otherwise it might produce too little of what is required, too much of what is not required, or deliver late, or have problems with product quality or customer satisfaction.

But for IT there is not this clear delineation of products and services. So one starting point is to build a Balanced Scorecard for IT. The Balanced Scorecard is a means of identifying Why things are done in IT. Why are we doing this project? Look at the BSC to see the Strategic Initiative that is supported by this work. Here's a notional view of a page from the Balanced Scorecard showing the Vision, Strategic Objective, the Performance Goal, the Critical Success Factors, and Key Performance Indicators for the project.

This page answers many questions around the project, so when someone comes by and asked what are you working one? Or, what have you done for me lately? You can whip out the BSC page and shown them.

But this page needs a home. That home is the Strategy Map. This Map connects the dots between the business and technical strategy of the organization and the projects that implement that strategy.

Developing the Strategy Map is another topic and is built around IT governance, IT and Business Strategy and the management of a Strategy Focused Organization (SFO).

But for today, the connection between Why we're doing something, and What we're doing and How we're measuring the success of that What can be done through these types of pictures.

The Cult of DONE Manifesto

What does DONE look like? is the starting point for the 5 Immutable Principles of Successful Project Management. I came across a wonderful post with a notion that is usually lost in many projects that are struggling.

The Cult of Done Manifesto

Bre Pettis says it all. Read this, print out the poster, practices the 13 steps. Build a plan that says what DONE look like, provide all the  resources needed to get to DONE, remove all the impediments to DONE, measure progress toward DONE in units of measure meaningful to the decision makers - Physical Percent Complete, with Cost, Schedule, and Performance measures. Forget all the touchy feely crap first, that doesn't say what DONE look like, produce a Plan, provide Resources, remove impediments, or measure progress. It is necessary but VERY FAR from sufficient for getting to DONE.

Quote of the Day - Connectivity Complexity in Large Scale Systems

The mystery of their intentions lies only in their terms - Thomas Vaughan

The terms "complexity" and "chaos" are often times used to describe something that is not understand. But that has nothing to do with the "understandability" of the thing being described. The same is true for the next generation of anything - Management 3.0 and Project Management 2.0 are two examples based on the terms "complexity" and "chaos." Neither of which are based on the foundations of the actual science of complex systems. Instead are based on the "populist" notions without the benefit of the underlying mathematics of how complex large scale systems actually work.

So  when there is a quote like "it takes complexity to handle complexity," it's not exactly clear what kind of complexity is being talked about.

One of the most pervasive an least well-defined concepts today is the notion of a "system." In a vague. personal way, almost everyone who thinks about it can visualize what a system is. Sometimes they can even verbalize this image, "elements" interacting in a "complicated" manner in order to achieve some fuzzy "objective."

Sometimes two separate descriptions actually overlap within enough in common to have a meaningful discussion or collaboration. But more often huge gaps appear - intellectual, professional, and cultural. Gaps too great, communications breaks down despite good intentions and all the parties.

Mathematical Descriptions of Systems

There are many different descriptions of systems and their complexity. They include:

• Compactness - a mathematical description can eleminate fuzzy or ill-thought-out notions that may not be apparent in a lengthy verbal description.
• Clarity - by associating a symbol in the mathematical description with a known aspect of the process being studied, clear interrelationships between the various process variables can be revealed.
• Computability - once the mathematical description is agreed to, this description can be manipulated using the rules of logic with nontrival results. This model provides the basis for various computational studies as well, with the hope of a predictive outcome.

Schools of System Descriptions

The principle types of mathematical descriptions of systems include:

• Internal descriptions - since the time of Newton, these are standard mathematical descriptions of a dynamic process using differential equations. These describe the time evolution of a system in tyerms of their variables - position, velocity, temperature,  etc. The key here is these descriptions are local. The equations describe the process in the local neighborhood of the current state. While this works in the realm of physics - for the most part - it does not work so well in areas like social science or economics. Before Newton the concept of local was unheard of. Physical processes were dominated by Aristotelian views "in the order of Nature the State is prior to the household or individual. For the whole must needs be prior to its parts." Modern physics does exactly the opposite. The whole is explained  in terms of the elementary (local) parts.
• External descriptions - this is the common system found in experimental sciences - the input-output relationships. This description is the opposite of the local description, since all the local information is masked "inside" the system and only the Inputs and Outputs are visible to the observer.
• Finite State descriptions - are a class of system analyzed  by algebraic means. The number of dimensions in the system is replaced by the number of "states" in the system. The states are finite and are processed by a "finite state machine."
• Potential and Entropy Functions - are an alternative to the internal and external descriptions.

Complexity

One of the most overloaded terms in software development is "complexity." This term is used in a variety of ways, "complex systems," "degrees of complexity," "complex problems," ad nausium. But there is usually very little to indicate the authors really has any true understanding of the principles of complex systems beyond repeating the words from populist books and magazine articles. By populist I mean texts that have abstracted and obfuscated all the mathematical underpinings of "complex systems" theory.

Like the concept of time everyone has an opinion of what it means, until it is necessary to actually define it in the absence of analogies and words. There is much folklore around "complex systems," and "complex adaptive systems." Even famous names mentioned in support of this folklore.

Quote of the Day

This is indeed a mystery, [remarked Watson]. What do you imagine that it means? I have no data yet. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suite theories, instead of theories to suit facts.

- Sherlock Holmes

Why do we insist on listening to those who conjecture about a topic in the absence of tangible evidence that their conjecture is based on facts? Speculative statements about the favorable outcome of one method or another. Uninformed opinions about the usefulness or not usefulness of a technique?

5 Immutable Principles

I've spoken about this before. There are 5 Immutable Principles of successful project management. No matter what method used to manage the project, develop the product, or what ever technique you want to use for getting to the end, these principles must be in place.

 

1. What Does Done Look Like? What capabilities are needed to fullfill the stakeholders business needs.
2. How do we get there? We need a Plan and a Schedule. The Plan is the strategy for the success of the project. The Schedule is the sequence of work needed to implement the Plan. Both are needed.
3. Do we have enough of everything to get there? This means a  resource loaded Schedule, with labor and Other Direct Costs (ODCs)
4. What impediments will be encountered along the way? Risk Management is how adults manage projects.
5. How do we know we're making progress to plan? Earned Value.

 

Plans Are Meant To Be Changed

Plans are meant to be changed. Otherwise it wouldn't be a Plan. Plans are Strategies for the successful completion of the Project.

A Strategy is a hypothesis that needs to be tested. This test is the feedback received from the execution of the project, the gathering of the Measures of Effectiveness (MoE), the Measures of Performance (MoP), the Critical Success Factors (CSF), the Key Performance Indicators (KPI), and the Technical Performance Indicators (TPM).

These measures provide visibility into how our Strategy is working. These measures provide feedback needed to take corrective actions for the Strategy.

Once we have the Strategy and have the means of testing the hypothesis, we can produce a Schedule that implements the Plan - the steps needed to produce the deliverables in the Plan, in the order they are needed.

This schedule can be changed as well. It has to be changed. It can't stay fixed for the simple reason that the tests being performed against the Plan produce new information. Steering Information for the strategy.

Buyt this steering information needs to come from the predefined MoE, MoP, CSF, KPI, amd TPMs. Sure there is new input that is received from the external domain. But that external input needs to find a home in the existing Plan based and Schedule guided framework.

No making things up as you go

You can certainly use the agile approach of capturing all this input through planning and confirmation processes. Putting sticky note on the wall or entering the items in an Agile software management tool. But in the end you need to answer those 5 pesky Immutable questions:

1. Where are we going? - the Plan tells us that
2. How do we get there? - the Schedule tells us that
3. Do we have enough of everything we need? - the resource loaded schedule and any other external dependencies tells us that
4. What are the impediments along the way? - the Risk Management Plan tells us that.
5. How are we measuring progress to plan? - Earned Value, or any measure of physical percent complete that ensures compliance with all the measures - MoE, MoP, CSF, KPI, and TPMs.

Yes that last items says compliance. Compliance within the upper and lower limits of the metric at the time of measurement. Without this measurement the project is in fact self guided, going where ever those watching the project see emerging toward

Along with these is the other pesky item - change control. Anyone who tells you we don't need change control has never managed an "emerging" project. Changes cost money. Changes impact schedule. Changes impact this that have already been done. Dried concrete, released databases, User Interfaces that have the training manuals already written.

So with those 5 immutable principles, all the stakeholders still need to know a few more things:

1. When will this project be done?
2. How much will it cost when we are done?
3. How do we know the stakeholders will be happy, or as happy as they could possibly be?

Quote of the Day

The test of a good procedure is how well it works, not how well it is understood.

- John Wilder Tukey

The notion that processes must first be understood before being useful is just that notional. This approach seeks the lowest common denominator for those using a procedure or a process. It's the race to the bottom, or it's the dumbing down of our work force.

Tukey reminds us:

No catalog of techniques can convey a willingness to look for what can be seen, whether or not anticipated. Yet this is at the heart of exploratory data analysis. The graph paper - and transparencies - are there, not as a technique, but rather as recognition that the picture-examining eye is the best finder we have of the wholly unanticipated.

My first "real" program I ever wrote from scratch by myself was a the Cooley-Tukey Fast Fourier Transform algorithm. It was in Macro-8, running on a PDP-8M, with 4K Words of Core memory. Yes, that's correct 4K. What the Fast Fourier Transform (FFT) did was sample analog signals, convert that sample stream through the Fourier Transform into a "spectrum" of frequencies, and store this accumulated signal specturm in memory. This is the basis of digital signal processing used in everything from music recording to cell phones. Of course today this is all done at the silicon level.

The message here is that seemigly complex process are effective for the purpose. The FFT algorithm source code has long been lost, but if it were here today, in MACRO-8 format, printed on "green bar" paper, I doubt anyone on the planet would be able to figure out what it did. This algorithm was transferred to the PDP-15 and rewritten in FOCAL.

The result of this effort was a Spectrum Analyzer for signals coming off laser back scattering experiments - Mie Scattering. Which, along with Rayleigh Scattering is why we see rainbows, cloud colors, and other atmospheric colors.

Another Bad Agile Analogy

When we use analogies to convey a concept, care is needed on several fronts: The analogy is actually correct. The analogy is connected to the problem or issue we're trying to convey.

This is called The Misuse of Analogy Fallacy, and goes like this - logical error is committed when someone assumes - without any transition of explanation or verification of the facts of the starting proposition - that the same laws pertaining to one situation are equally true in application to any similar situation, as when the descriptive nature of scientific laws (natural laws) is confused with the prescriptive nature of societal or physical laws.

There is an upcoming agile presentation on the PMI Agile Community of Practice, titled "A Dolt's Guide to Self Organization." One of the slides there suggests that Agile PMs are like Gardener's, they let self organization (anarchy) do useful work while steering the system toward value results.

This is course is makes no sense for anyone who is a serious Gardner. Let's take the English Garden for example - a Garden that is VERY hard to grow here in Colorado - the picture at the top is our typical landscape. The English Garden is:

• Highly engineered to look like it is completely natural.
• Intentionally organized to with specific color selections, plant positioning.
• Has the appearance of free flowing plants are of course structured to look free flowing, that the vary essence of English Gardens.

All gardening is organized, engineered, and structured. Some better than others. But for the English Garden the outcome is the appearance that it is not organizaed, engineered, and structured. Too bad the analogy used in the agile talk is not true for many Gardens.

We garden as best we can here in Colorado. Our neighbor is a Master Gardener with her certificate from the Colorado State University Master Gardner Program. Having come from California a few decades ago, where Gardening is a competitive sport, and garden stores have not only Master Gardner's and Landscape designers, they have contests for the best looking garden. Successful gardens are anything but anarchy and self organizing.

I'm not that good at flowering plants, but I have had moderate sized vegtable gardens in California and here in Colorado, with enough plants to feed the neighbors, with nearly everything that can be grown by amateurs. I'm here to tell you, if I let my vegetable garden "self emerge" we wouldn't be eating much of anything.

The only plants we have that require no tending are sunflowers. All others require special soils, precise watering schedules, tending the branches and buds at the proper time during the year, and careful development of soils.

A self-organizing garden is called a weed patch. In any urban setting weeds grow much better than ornamental plants and vegetables. There are examples here in the west of natural wild flower landscapes, beautiful prairie grasses settings (in the photo taken on the road to our neighborhood in the introduction), natural forests all with eye popping outcomes. Only there is there no intervention by mankind. That's the true "self organizing" garden, but it's not called a garden then, it's call nature.

But once you introduce the Gardner into the equation, trying to control the arrangement of plants, then engineering is required.

So if you're willing to live with the true self organized garden, the prairie grasses behind our house, between our back fence and the 2nd cut of the rough on the golf course, then what you'll get is what grows in Colorado High Plains, Buffalo Grass, and native plants. But this is NOT gardening. This a natural plants as they existed before the arrival of the local Boulder County residents, some 150 years ago.

But once you start to shape the landscape in any small way, the unnatural tendencies of weeds, invasive species, and nature destroying your efforts is the result. You must continually shape and reshape the landscape to maintain the desired outcome. An English Garden is rare here, because of the weather and land. Fully engineered natural landscape are the result. This picture looks amazingly natural, but it is not. Here's where to start to learn how to "shape" the landscape to look natural, emergent, chaotic, while also being beautiful.

Agile PMs are like Gardener's, they let self organization (anarchy) do useful work while steering the system toward value results.

Really, been to a Master Gardner class lately? Tried to construct an English Garden, even in England?

It's these inappropriate, many time improper, and sometimes wrong.

Remember the double pendulum example of chaos, that actually has a closed from Lagrangian equation that makes the pendulum predictable enough to write a Java App to draw the seemingly chaotic path, but is only seemingly chaotic? This is chaotic only when the starting angle is above a specific value.

That approaches dilute the proper message of agile. The myth continues.

New Android App for Cycling - Sportstracklive

New Droid App that tracks our cycling route, elevation gain and loss, and when I hook up the heart monitor, the stats on "zone training."

This was a training ride yesterday. Leaving from the meighborhood (bottom middle), up 75th the Hwy 66, right on Rabbit Mountain (at the top of the map, with a 12 degree pitch in the last 100 yards), out to Lyons and the Fruit Loops (the two loops on the left), and back down 36 (really annoying hills), and the final sprint back to the neighborhood. 47 miles of hills and road. Next weekend is the Buffalo 100, with nothing but hills.

Capabilties Based Planning, Use Cases, and Agile

The discussion of how do you know what done looks like? in the agile software development world has many answers. Ranging from we'll let the customer tell us, to we have this collection of User Stories and Use Cases that tell use what done looks like.

Jens Coldweys (turn on translation) blog speaks to the use of Use Cases and Scenarios in the development of software. These Use Cases and Scenarios need a Reason for existing. This reason is usually missing or is linked to the wrong source.

• The reason we need this is the customer says we do
• The reason we need this is that any system like this has this requirement

The missing piece is not only why but the connections between the why and the actual mission outcome. By that a business mission, a government mission, a military mission, any mission.

So before the next step, let's put some definition out there:

• Mission - why we exist, why we want this system.
• Values - the guiding principles we'll use in fulfilling the mission
• Vision - the picture of the future
• Strategy - the differentiating activities that will be used to fulfill the mission

So where do these Use Cases and Scenarios come from? Good question. No answer to that question? Then these Use Cases and Scenarios have no real reason for being other than someone or some group says they want it. But that usually leads to trouble when those needs and wants themselves don't have an architecture.

• How do they relate to each other?
• What are the dependencies between them?
• Which are more important than others? This is not a ranking system, but which are more important in terms of fulfilling the mission?

The answers to these questions come from the Capabilities Based Plan for the project. This Plan states what capabilities are needed for the mission to be successful, for the system to provide the needed outcomes for the customer, for any result to fulfill its mission.

Don't know what capabilties are needed, the units of measure for those capabilities? Then any set of Use Cases or Scenarios that the user and developers come will likley be OK. This is the same problem with the requirements elicitation process. Requirements need a reason for being. A Raison d'être. Why do we have this requirement, why do we have the Scenario.

Here's how to develop those capabilities statements. Without answering these questions, those wonderful scenarios, Use Cased, User Stories have no real reason for being in the context of a "system."

Quote of the Day

Of all the causes which conspire to blind Man's erring judgment, and misguide the mind; What the weak head with strongest bias rules, - Is pride, the never-failing vice of fools

Alexander Pope (English Poet, 1688-1744)