Kotter on leading change

John P. Kotter is a change guy. I've been going through his 1996 classic "Leading Change"

Here's my take: it's a good book, but a little long on the narrative since the essentials are right up front: 8 leadership steps towards change management.

Now, admittedly, this is more aimed at the business readiness swim lane, and the foreplay necesssary to get the business and the customer ready, than it is aimed at some of the change management tactics for scope control. Nevertheless, here's my paraphrase of Kotter's 8:

---

1. Put a value on short term versus long term
2. Gather a coalition of the willing
3. Develop the vision, goals, and strategy
4. Communicate
5. Push action to the practitioners
6. Be incremental
7. Consolidate gains
8. Leverage culture

---

Now, in Kotter's actual formulation for point #1, he wrote more about creating a sense of urgency than simply putting a value on the short term. But, actually, I'm not a fan of crying wolf on urgency just to get the team moving. Frankly, I'm more about finding a legitimate reason to value a short term goal; with that in hand, you should be able to get some action going.

His point about #5 was the ole "empowerment" thing. It was probably less worn in 1996 that it is 15 years later. The issue is that the empowered may not know how to use their power. That hasn't changed since power and empowerment were invented:

Those with the power have no experience

Those with the experience have no power

General Sir John Dill

Placentia Bay Conference, August 1941

I really like the last one about culture. We've mused on culture a few times here. Just click here to get a sense of where I'm coming from.

Bookmark this on Delicious

Pharma risk management

I don't often address industry-specific risks here at Musings, but an article about risks in the pharmaceutical industry caught my eye. Entitled "Risk Management for the Pharmaceutical Industry", it talks about the usual stuff, couched very nearly in PMBOK Chapter 11 vernacular of plans, identification and assessment, and risk responses. So, no news there.

But, given the life-safety issues of pharmaceutical projects, I thought this was a pretty good list:

A Risk Management Program starts with identifying the possible
risks (and benefits) associated with a product or with the process
used to develop, manufacture, and distribute the product. The following
questions should be asked at each stage of the product’s life cycle:

• What are the safety risks?
• Who is at the highest risk?
• What populations are at risk?
• Are the risks predictable?
• Are the risks preventable?

... an overall approach to RMP evaluation ideally would:

1. Select well-defined, validated metrics.

2. Use at least two different evaluation methods for key RMP goals
or objectives. Preferably, the different evaluation methods would be
both quantitative and representative to offset the biases that are intrinsic
to any single evaluation process.

3. Use qualitative data collected from a large and diverse group of
patients when quantitative data are either not available or not applicable
to the evaluation measurement. Qualitative data such as focus
group testing may be useful in assessing the effectiveness of education
and comprehension about safety and risk information.

4. Consider using evaluation methods to assess if each RMP tool is
performing as intended.

Now, it's point #2 that's worth a pause. There's no end of project management references to cognitive biases, the most compelling work done by Daniel Kahneman and Amos Tversky. And, there's wide acceptance of various estimating methods that use multiple estimators, like the Delphi method and its agile counterpart: planning poker. And, we all know the danger of the single point estimate: any single point is likely to be wrong, so better to estimate with multiple points in a range.

But, there's little literature that I've seen that recommends outright multiple methods to neutralize methodology bias: that's more aggressive than multiple evaluators. Multiple methods means approach the problem differently, and independently, and then see if a consensus can be reached on the risk.

This is sort of the RMP equivalent of having multiple contract designers work on a common requirement, each with their own methodology; no two independent designs will incorporate the same errors. So, when the two designs are applied against a common problem, it's not likely they will both experience an error at the same time. One or the other will always be successful.

It's conservative, it's expensive in the short run, but in the pharmaceutical domain, the long-term consequences of being wrong are too calamitous to put aside a short term expense.

Here's a nice lesson in risk and experiment evaluation using a pharmaceutical example from the Kahnacadey.org

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

A. Hamilton on project management

Alexander Hamilton, one of America's founders, could have been one of the original thought leaders behind the governance of project management if he had been born a century and a half or so later.

Hamilton's main governing philosophy can be summed up in this simple idea:

---

Centralize goal setting and decentralize the means to accomplish them

---

Translated to project governance, Hamilton would have been in favor of a strong program office to set the rules and limitations of behavior, and to set the goals and vision of the larger ideas of the project, but at the same time he would have embraced a vigorous community of "do'ers" competing for the opportunity.

As a governance principle, Hamilton would oppose oversubscribing the powers and limitations of the program office, in the same he objected to the first ten amendments to the US constitution.

Instead of  writing many of the Federalist Papers that interpreted the constitution and gave rationale for many of its provisions, he might have written many of the supporting papers for the PMBOK and other project management standards. Perhaps he would be a modern day blogger.

Philosophically, he would support a professional cadre for project management. He made a distinction between the "consent of the governed" and governed by representatives. He felt that a professional group of governors would be required to master the complexity of a republican government, even as James Madison, another Federalist Papers author was concerned for scale and scalability of such a governance paradigm to a truly geo-distributed team (the States and the federal union)

Indeed, scale was on the mind of many. How do you convey a common culture, a common appreciation for the rule of governance (law), and a coordination of  seemingly independent actions such that there there is synergistic coherence towards the common goals?

In the United States, the importance of scale and integration was first grasped by Lincoln and his treasury secretary Salmon P. Chase as they approached a great war in 1861: the first problem was project funding--there was none. There wasn't even a national currency. So Lincoln and Chase, ever inventive as program managers, invented their own funding: they invented paper money and promised it was backed up by gold (it wasn't by the end of the war).

They invented creditor financing by selling war bonds, and they invented the supply chain on a national scale. They brought in new technologies and applied them to project execution for the first time: railroads for project mobility, and the telegraph for communications, earned value reporting, and marketing.

So, perhaps a rereading of the Federalist Papers as we put the finishing touches on V5 of the PMBOK might do us all a bit of good.

Photo: painting by John Trumbull, 1806

Bookmark this on Delicious

 

EBITDA?

Has everyone got a handle on EBITDA?

If not, in a few words, EBITDA is a measure of cash earnings from the real business, the day to day stuff that creates value for customers, users, and stakeholders: cash, as earnings, before any interest payments, taxes, or deductions for non-cash items like depreciation of tangile assets and amortization of intangibles.

---

Profit is an opinion; cash is a fact

---

Tom Pike

Fair enough. But since this a project management blog, why should we care?

Well, for one we PMs are in the value business; mostly we're in the earned value business. When the project is successful and earns its value, then it's ready for the business. The deliverables can go on to deliver on EBITDA.

What about NPV and EVA you ask? Haven't we PMs been told by CFOs that the way the business goes about measuring financial success in the business domain is with measures of discounted cash flow (DCF), like NPV (net present value) and EVA (economic value add). And, haven't we all seen the IRR (internal rate of return) calculations that demonstrate that this project can't miss (at least in terms of discount)?

I took up this very thing with a CFO in the private equity business with whom I've done business for many years, Steve McBrayer. He writes:

[Private equity] is ..." much more cash flow oriented than [publically traded businesses]. I think it is the nature of the private equity industry in general – Capitalism at its finest in my opinion – very investor focused.

• Our primary measure is EBITDA (basically a proxy for cash flow). Our focus is converting EBITDA into operating cash flow as efficiently as possible, while balancing the business needs (investments) against these demands.
• I like to see the business unit bonus program limited to about 5% of EBITDA (I don’t always get there, but that is a reference point)
• I use 10 % of EBITDA as my reference point for Cap-Ex (some business units get more if they have high growth potential and are more “value added” and some get less (for example a pure distribution business with little value add and lower growth prospects)
• At the end of the day, the primary responsibility of the CFO is to prioritize the various projects competing for the limited capital budget.  The valuation tools [EVA and NPV] ... are useful, but not the primary tool that I use...[which] is business judgment: does it make sense; who is responsible for the project; do I have confidence in them; is it critcal?

OMG! Business judgment: what will they think of next?

Bookmark this on Delicious

Teams (a mistake about a mistake)

Jurgen Appelo sometimes gets it wrong. In a recent blog post about teams, he asserts we're "making the same mistake all over" about teams and teamwork.

He writes this nonsense:

Teams are goal-oriented social units (Esther Derby’s definition). Their goal is not just to deliver a project.

• In an environment with continuous delivery and continuous improvement, it is very unclear what a “project” is! The concept of a “project” seems to me a convenient fiction that enables managers to spend budgets. That’s all.

I don’t know what the real goal of a team is. It depends on the team. But I do know that 3 people working together for only 2 months are probably not a team. They are just 3 people working together.

To that, I replied on his blog:

... you are wrong on all points: Esther's definition is wrong: that's the definition of a group, not a team A team is a higher order than a group, elevated by the collective and individual commitment to the goal. There is no personal success unless there is a collective success.

Yes, three months is quite enough time for a group to form into a team; what is required is intra-group trust to form, and for all three to be all in...one for all; all for one

Yes, a simple project is a project. What's a project? something with a specific start and end that delivers something of value to the customer. Yes, in the IT space, the transition to go-live and operations with follow-on bug fixes sometimes makes the "end" look a little murky, but that's management, not project definition.

For more on teams, read my book that you rated highly on your list of top 100: "Project Management the Agile Way,making it work in the enterprise."

Or, if you don't believe me, check out Glen Alleman's thinking on teams

Bookmark this on Delicious

Agile sailors

I recently gave a presentation to a PMI chapter on Agile project management using a sailing race analogy. I've used this analogy before, but this time there was some Q&A that was worth passing along.

 

The first thing is that audience was shocked (shocked!) to learn that agile projects have plans, and even more shocking that earned value concepts (that is: earning some value for the investment made) is also alive and well.

 

The second thing is that those from large companies lamented (I won't say complained because they didn't) that executive managers had little idea about the change in management paradigm that is the most pervasive aspect of agile. It's not the technical practices: those are largely like those in other software methodologies. But it's the change in management practices and thought that is different.

 

What's different?

• What's different is that best value is preferred over a fixed scope specification;
• what's different is that matrix management at the team level, sprint to sprint, must be put aside;
• what's different is that the team, in collaboration with someone holding the customer/users proxy has to be trusted to apply the available investment is the best possible way; and
• what's different is that the project manager manages to milestones that have user/customer/stakeholder value and not to the details of a networked CPM schedule.

 

Take a look and see if you don't agree

 

Agile for project managers - A presentation for PMI

View more presentations from John Goodpasture

Bookmark this on Delicious

Strategic planning v The Strategic Plan

Eisenhower once said: planning is everything; plans are nothing. He had in mind Von Moltke's famous statement: plans never survive first contact with the enemy.

And, although projects are not war, plans seem to suffer the same fate. Plans don't seem to survive the first touch with project reality, though perhaps project plans are a little more surviving than war plans.

In a recent post, "why small business should scrap strategic planning" we learn that small businesses can successfully do away with strategic plans altogether. They're too expensive, time consuming, and irrelevant to write and maintain.

Author Kaihan Krippendorff  says: "What fast-growing companies need is strategic thinking--not strategic planning". He offers three ideas for thinking:

1. Think in the hallway (casual conversations are sometimes very stimulating of new ideas; See A. Cockburn's osmotic communication)
2. Ask "why not" (this is probably the strategic adaption of the 'ask why 5 times' paradigm)
3. Try (something) and adjust (this is Franklin Roosevelt's "try something and if it doesn't work try something else, but don't just sit there" paradigm)

So, not exactly a paragon of original thinking, but perhaps there's something to Krippendorff's thesis, to wit:

• Too many strategic plans are just a three-year display of sales and market share... mostly a money plan and not a strategy per se, necessary but not sufficient
• Product road maps are closer to strategy if there's plan attached
• Three years may be too long for a small business; their horizon may be 6 months to some positive cash flow, or else
• And, if the product flops, do the Roosevelt thing. A lot of start-ups, like Group-on, start on Plan A but quickly shift to Plan B. The planning element "1" from the list above may be the best thing you've got. (Solyndra, anyone?)

But, in the end, Greg Githens told me: Where it’s weak: regardless of size, companies need a coherent strategy.  The article skips by that point.  Hustle and opportunism does not qualify as a competitive strategy.

Hmm...

Bookmark this on Delicious