Burn-down chart: an analogy

---

It seems that there is always confusion the first time someone rolls up on an agile methods burn down chart:

• What are we burning?
• How much is there to burn?
• How long does it take?
• What is the starting point?
• When does it end?

An analogy
Think of a burn down chart in the same way you regard the fuel gauge in your car:

• You fill up the tank
• You drive around, consuming fuel
• Eventually, it the fuel runs out, the gauge shows empty, and the car stops

So, to make the analogy:

• The gauge, if it has any metric calibration at all, probably says "full" at the top.
• Let's say that "full" is 20gal (US) or about 75ltr. So, the gauge could read 20gal instead of "full".
• But, if the car gets 30mi/gal, then the gauge could read 600mi (965km) when "full" instead of 20gal. Some driver digital display systems give such measures
• But, if you drive about 10mi (round trip) every time you run an errand, go shopping, go to a restaurant, etc, then the gauge could read 60 trips when "full" instead of miles or gallons. Naturally, when the gauge gets to 1/2, then you've got 30 trips left in the tank.

And so it is with a burn down chart.

• Typically, we're burning some consumable resource, like hours (gallons of fuel), to empty the backlog (tank)
• When the backlog runs out, we stop
• But, we could look at some velocity, a rate of consumption, like stories per hour (miles per gallon)
• Or, we could look at the number of stories (trips to the store) we expect to complete if we burn all the hours (fuel)

---

Buy them at any online book retailer!

Can you beat a checklist?

---

Can anyone image doing serious risk management without a checklist? (The answer, of course, is No ... or, it should be!) Actually, any procedural management can benefit from a checklist.

There's been whole books written about checklists. In fact, one of the more prominent books -- "The Checklist Manefesto" by Dr. A. Gawande -- entitles Chapter 1: "The Problem of Extreme Complexity", recognizing the contributors of breadth and depth and interdependencies (check on this before you do that....) are more than we can reasonably keep in mind.

PM Tool Heresy
Here's some heresy for the PM tool geeks among us: Many PM tools are great for laying out the schedule, the architecture, and for obtaining estimates -- via simulation -- of likely outcomes, but they are really burdensome at day-to-day management.

Why so? In a word, complexity.

You can't -- as a practical matter -- put all the dependencies in the tools or the logic would be byzantine.

No one could understand or follow it if you put it down (why did you do this? why did you do that?..). Some interactions are best left to the team leader.

What's a PM to do?
And, so how to manage those interactions and day-to-day requirements? Checklists! Check off on this and check off on that.... And, it's a great tool at a daily stand-up

Here's some specifics:

• Small lists... No list too large; keep the near-future in sight
• Lots of lists; make a new one every time the situation changes
• Coordinated lists; I have this one.. do you have it's companion?
• Reusable lists; once a list is validated by actual use, archive it for reuse
• Validated lists; get SME input to validate the list... a list can be just as wrong as any other tool
• EV lists; Don't put aside earned value... the sponsor and everyone involved wants output, and they want output commensurate with its value
• Kanban lists; teams push things along through a sequence of steps... did everything get DONE?

Fair enough.

It's all about situational awareness, look-ahead strategies, and understanding the constituents of getting from here to there. There's no new scope; just go to the scope statement for the parts and go to the schedule for the milestones.

Then: checklists!

The end.

---

Buy them at any online book retailer!

Agile for Project Managers: an analogy

---

It's been a few years since I wrote the material for the presentation below, but I find it timeless.

It's all about an analogy

It's all about how a self-directed team working on a mission of top-down importance and specification -- these imperatives coming from executive leaders -- get the job down sufficiently well (in Agile speak: well enough) to succeed

Agile for project managers - a sailing analogy-UPDATE from John Goodpasture

---

Buy them at any online book retailer!

Some stuff you need quickly

---

Robert Gates, the former United States Secretary of Defense, in a September 2008 speech, said: 

“Our conventional modernization programs seek a 99% solution in years. Stability and counterinsurgency missions—the wars we are in—require 75% solutions in months. The challenge is whether in our bureaucracy and in our minds these two different paradigms can be made to coexist”.

Since that speech, the Defense acquisition management system has been revised twice. Now, there is official sanction for faster methodologies with lower overhead.

---

Buy them at any online book retailer!

Against the Gods -- a review

---

"Against the Gods, The remarkable story of Risk" by Peter L. Bernstein is an excellent read and ambitious premise well delivered.

Perhaps the best general history of risk -- and presentation of the major concepts of risk -- that is understandable by all practitioners at any level.

The content is presented in a general historical order in major sections by epoch. The first being from the ancients to 1200, then the middle ages and Renaissance. Finally, then into the industrial revolution, and modern era.

Along the way, Bernstein recounts not only the emerging understanding of risk per se, but also the allied concepts of counting, numbers, chance, and of course, business management.

No math! (Almost no math)
There is not much math or statistics to trip up the qualitative mind! (Yea for that) But, the presentation of the evolution of our understanding of chance introduces many of the main characters and demonstrates their contributions with just enough math/quantitative examples to make it interesting.

Mystical and Divine... pressing on!
Much of this material describes the period 1700 - 1900 when much of the modern underpinnings of chance, probability, and statistics were developed and made understandable to the general business population. We learn, for instance, that it was in this period that the notion of risk in the modern sense emerged from the mystical and divine to the cause-effect concept.

While the parallel developments of mathematics, business practises--like insurance--and a math/cause-effect foundation for risk are presented with a storyteller's gift, I found Bernstein's recounting of the ideas that developed after 1900 to be the most interesting and insightful.

Along comes the psychologists
Of course, the story in this book ends just about the time that the ideas of Amos Trversky and Daniel Kahneman, first developed in the 1970's, are gaining popular acclaim in the 90's. Thus, in this part of the book we get a great explanation of the expansion of utility theory first developed in the 1700's but advanced into Prospect Theory by Tversky and Kahneman.

There is also excellent explanations of various biases and other cognitive maladies that intrude on the rational and objective. We learn a good deal about the failure of invariance--the idea that same manager can be risk averse and risk seeking depending on not only the point of view presented (glass half full/half empty) but also whether there is a sure loss or a sure win at stake.

Someone else likes it
Bernstein's expertise is in the financial world. John Kenneth Galbraith wrote of "Against the Gods": "Nothing like it will come out of the financial world this year or ever. I speak carefully; no one should miss it".

---

Buy them at any online book retailer!

Just changed, or transformative?

---

Change: things are different, or will be. Often a matter of process and function
Transformation: Change + values or philosophy that are changed as well


Some say that we still don't get it, some 12 years after notable John Kotter wrote his seminal article "Leading Change: Why Transformation Efforts Fail." Some say 30% or more fail. Of course, this begs the question: what is failure, or perhaps harder: what is success?

A piece I read by Ron Ashkenas says:

"Unlike change management, it [transformation] doesn’t focus on a few discrete, well-defined shifts, but rather on a portfolio of initiatives, which are interdependent or intersecting.

More importantly, the overall goal of transformation is not just to execute a defined change — but to reinvent the organization and discover a new or revised business model based on a vision for the future.

It’s much more unpredictable, iterative, and experimental. It entails much higher risk. And even if successful change management leads to the execution of certain initiatives within the transformation portfolio, the overall transformation could still fail."

Of course transformation is unpredictable! Who can say where a change in beliefs and values is going to lead? Who can say if such is really a good thing?

We can put parameters around objective change management stuff, but it's hard to measure, much less predict, non-objective phenomenon. About the best you can do is look at the A/B situation: A: the way it was; B: the way it is now.

A/B testing is a big thing in many projects these days.
How else to actually evaluate things?
So, is it change or is it transformation? Usually the former shows itself right away; the latter may be generational (See: transformative politics)...
You'll just have to wait and see; or better yet, get promoted and have someone else wait and see.
 

---

Buy them at any online book retailer!

So, who's responsible for Customer?

---

One of my students offered this strategy for establishing, maintaining, and leveraging relationships with the customer. I thought it was pretty good, so here's the idea:

1. Customer Account Responsible (ACR) -- who ... is the Account Manager
for the domain, market or dedicated to the customer (big accounts) responsible for:

• Account relationships,
• Opportunity identification,
• Commercial management,
• Communication management.

2. Customer Solution Responsible (CSR) – This role is held by various people
depending on the company type – Solution Architects, Solution Consultants,
Solution Managers etc – and they have the responsibility of:

a. End-to end solution integrity
b. Collection of and documentation of requirements from the customer – Executive, Business, Technical and Users requirements.
Securing the sign off on the requirements scope with the ACR and CFR to the customer.
c. Prioritization of the requirements with the respective customer responsibilities, in order of increasing importance, and determining the “fit to need” alignment of the requirements
d. Map solution requirements to the vendor solution/product portfolio, and determine the Delta, and how to fill those Delta.
e. Hand off complete solution design documentation to the project execution team, and provide input to the executing team (CFR) for project execution planning.
f. Including and manages SME’s , Product Owners etc and their deliverables as needed in various verticals that are needed to address the solution design and product lifecycle

3. Customer Fulfillment Responsible (CFR) – this is normally the PMO organization that turn the solution into reality inside the customer organization/premises/site:

• Project management team,
• Service Delivery team,
• System Integration team,
• Field Engineers,
• Technical Architects etc

PMO is are responsible for:

• System Integration and Final Acceptance testing
• Validation with the customer, and
• Finished Product Handover to the customer Project/Service Operations team.

At this stage the solution ceases to be a project, and is included into the Customer Operational and Support Lifecycle Management.

---

Buy them at any online book retailer!

The project balance sheet -- not for accountants!

---

If you follow this blog you've read several references to the project balance sheet. So, is this about accounting? Yes, and no: Yes, it's about a double entry tool to keep track of "mine" and "yours", but no, it's not the accountant's tool used in your father's accounting office.

Take a look at this figure:

What have we got here?

First, the business and the project; but also what's mine -- the project stuff -- and what's yours -- the business stuff. Mine and yours!

First, the left side
On the left side of the balance sheet is the sponsor's investment in the project. Investment need not be all monetized, and it need not be all tangible. Sometimes 'good will' -- the accountant's name for the intangible gut feeling that this thing is worth more than book value (market-valued assets) -- counts for a lot. (Think: sponsor commitment, even when the going gets tough)
'Yours' simply means it's resources and commitments owned and given by others to the project. It's the 'your's side of the balance sheet that's somewhat akin to the right side of the financial balance sheet (money owed to creditors and money invested by owners).

Then, the right side
On the right side is the 'mine' side of the project balance sheet, akin to the left side of the financial accounting sheet (assets of the enterprise). The right side is the project side:

• Estimates and evaluations of the project manager
• Uses for the investment and resources to be entrusted to the project manage -- in effect deliverables and other artifacts, and perhaps some intangibles as well*

All about facts
 And, take note: the left side, the sponsor's side, is the fact-free zone: it's a top down allocation of resources to the vision. It is the ultimate utility expression of the sponsors: what's valuable, and how valuable, even if not entirely objective.

And on the right side, it's all about facts (benchmarks) and estimates (benchmarks applied to project circumstances). It's bottom up.

The gap
Of course, there's the inevitable gap where utility collides with facts and fact-based estimates. The gap is the risk between expectations and capacity-capability. And how large is the gap (risk): only as large as needed to create a balance--that is, a deal with the devil--so that the project can go forward.

 In other words, the gap (risk), shown on the project side, is only as large as it needs to be to close the gap. Usually, it's a matter of negotiation, but once the PMB is set, the risk is the PM's responsibility to manage.

Oops! the PM is the ultimate risk manager.

In a real world example, I had this situation:

• We bid a job competitively in a firm fixed price environment. 
• We offered a price that was equal to our cost; in other words, no fee (profit).  We just wanted to keep the lights on and keep barriers to competition with our customer as high as possible. 
• We won! 
• And, in  the next moment, my general manager said: "Your bonus depends on making 4% net margin".  I had my gap!  (oh yes, I made the margin and the customer was satisfied)

---

* Yes, indeed! Projects produce intangibles, even good will, but it makes for an accounting of project value all the less objective.

---

Buy them at any online book retailer!

Speak softly; big stick leadership formula

---

• Hit the ground running
• Consolidate control
• Ask questions of everyone wherever you go
• Manage by wandering around
• Determine the basic problems of each organization and hit them head-on
• When attacked, counterattack
• Stick to your guns
• Spend your political capital to to reach your goals
• When your work is stymied or done, find a way out

As quoted by Doris Kearns Goodwin in "Leadership in turbulent times"

 

---

Buy them at any online book retailer!

Loosen the coupling

---

Looking for schedule success?
Easy! Loosen the coupling!

Remember the "shift right" phenomenom in scheduling?

If two or more events are tightly coupled to a milestone -- meaning no slack -- then a slip of any event pushes the milestone, to wit: shift to the right

 And, the risk is exponential with the number of events:

The risk of two events is the risk-squared (where risk is probability of success)
Two risks of 80% success each are about 64% likely as a simultaneous pair

What's a project manager to do?
Answer: schedule loosely (add buffers to one or more events). This is the main take away in the "Critical Chain" concept, but it's also a fundamental principle in system engineering

• Shock absorbers are needed between critical parts that require some independence of action

Subcontractors
No better example of this is in the management of subcontractors that are not captive to your project. They often march to their own drum, putting their interests first. And, why not?

For project success (scheduling being an important success parameter), when dealing with subcontractors, loosen the coupling! Buffer everything they are supposed to do -- if you can. You'll be less disappointed.

---

Buy them at any online book retailer!