Do the math!

A funny thing happened on the way to advanced project management. Too many want the mantle but too few want to do the math. In fact, the PMBOK 4th edition has less math in it than the 3rd edition.

Project managers are most often judged on their metric performance--cost and schedule, etc--but few want to invest in the math skills to drive the metrics better.

For those wanting to catch up a bit, I strongly recommend the 15 minute videos at the online Khan Academy. You can start back in the 5th grade and work yourself through a graduate education in math and statistics. And, it's free. And, it's in bite size chucks. Here's a sample:

Bookmark this on Delicious

It takes a Theme

Definition: A theme is the central idea or ideas explored .....

While you might start with an issue or theme in mind, themes will also develop or emerge as you write. It may not be until the editing stage that you even begin to recognize your themes. Having recognized them, your themes will help you determine what to cut .... and what to highlight.

Quoted from About.com

So, as between message, messenger, and presentation--the three pillars of communication--themes are the message. And, they show up everywhere:

• Portfolios: Ask this: what's the message of the portfolio that binds the constituent programs, projects, and initiatives together?

In my PMO days, I had one portfolio that was exclusively CRM (customer relationship management); the message we wrote conveyed our idea of customer intimacy. (Remember Michael Treacy's and Fred Wiersema's 1993 paper in the Harvard Business Review: "Customer Intimacy and other Value Disciplines"? Intimacy, operational excellence, or product excellence are the big three)

• Programs: like a portfolio, the "big idea".

• Projects: the theme should come right out of the charter, the raison d'être as it were: why are we doing this project, or what's it to accomplish.

The agile guys have picked up the "theme" thing. In fact, agilists say that portfolios have "investment themes", the driving message for why invest in this or that portfolio.  I like that one. And, then themes tie to epics--the top level narrative that explains what's going on. Leffingwell writes:

Epics are development initiatives that are intended to deliver the value of an investment theme and are identified, prioritized, estimated, and maintained in the portfolio backlog.

Agile Software Requirements

And, let's not forget marketing and sales; they've been around for centuries. In modern days for project managers it's proposals, the response to an RFP. Right up there in the executive summary ought to be the win theme--why me (or us)? If you've not tried to write such a message, give it a try sometime. You might find the message harder than it looks to get succint, effective, and memorable!

    Bookmark this on Delicious

Experience from synergy

Mike Cohn has a nice posting on something he calls "communities of practice" but which I think of as experience from the synergy of multiple players. Regardless of how you label it, I think his diagram says a lot:

Looking carefully at the diagram, notice both cross team and intra-team (vertical) participation in the "communities" (horizontal). Mike is Scrum-centric, so his diagram has a Scum master community. If I'd done the drawing, I would've been less prochial since there are many competing methodologies, other than Scrum, that provide quite good agile experiences.

And, by the way, this is not an agile idea per se. I've been doing things like this in the defense and aerospace business for years (old wine, new bottle?). However, Mike's presentation is very effective. (Remember: communications = message + messenger + presentation)

And, of course, the diagram is only a hint at what you can do. It's probably best to extend this to a program or portfolio. The PMO often instigates and sponsors such collaboration.

Many groups call such a matrix "birds of a feather". I have attended many "birds of a feather" collaborations at conferences and such. But Mike is saying: make it a regular and sustained practice, not just an occasional get together.

Good advice!

Bookmark this on Delicious

Tell me again, what's risk management?

When I teach risk management, I always get these three issues:

The risk register, if it's done at all, is a dead end. You do it, probably up front, and rarely revisit it. And, you don't budget (or, are not allowed to budget) for the response plans, and like a dangling participle, the RR never connects to the real project (aka, baseline).

But, hey check a square: the RR is done! (And, so is risk management. Whew! that was hard stuff)

Second issue: Evaluating the quality of an estimate, or evaluating the quality of incomplete information--as from a sample--is said to be "not risk management". It's estimating or it's decision-making or it's sampling or it's quality management, but it's not risk management.

And third: without a formal process--like the six steps in the risk management knowledge area of the PMBOK as an example--there's no risk management going on, or there's no risk management that can go on.

Well, the first issue is troublesome, but not fatal. As many have said: "It's not the plan, it's the planning that has value". If''ve you got no funding, and an insensitive sponsor, then your risk response plan is "accept the risk". But, having done the planning, you'll be that far ahead if the risk event actually occurs. Not great, but usually not fatal.

The second is just misunderstandings. There're no facts about the future; only estimates in the present of what the future could be. There's uncertainty in every estimate, and thus by definition, there's risk. Risk management ideas apply, even if you don't do a risk register for every estimate. And, by the way, nobody does except for those estimates that have material strategic impact to the project. Otherwise, you fall back to reasonably accepted practices, like 3 point estimates and Monte Carlo simulations. That's risk management, even if it's estimating also.

The third is another form of misunderstanding. Everyone thinks about and manages risk every day, from driving to work to putting hot coffee in your lap. It doesn't take a formal process, but the mind, either working in System 1 or System 2, rapidly steps through identification, prioritization, evaluation, and response. You may not be conscious of the systematic way you process risks.

Of course, what about safety engineering and design? Doesn't that incorporate risk management in projects? And, don't leave out the "ilities". Mean time between failures (MTBF), mean time to repair (MTTR), and other "ilities" are all based on statistical uncertainty and statistical models. Where would projects be without the Poisson or Exponential distributions?

And, what about post-project business risks? These reflect back into the project as effects on performance, functionality, feature, and aesthetic appeal. Shouldn't these risks be "risk management" to the project manager?

And, on an even larger scale, every alert project decider considers the consequences, to include the affordability (or not) of consequences, in everything decided. That's risk management also. It's just not written down.

So, everyone's a risk manager, all day, every day!

Bookmark this on Delicious

Agile oscillators

When I first got out of engineering school, one of my first projects was to build an oscillator. An oscillator is a device--should I call it an object?--with "just enough" reinforcing feedback of output back to input, with the feedback arrival timed just so, such that there is a constantly varying cyclic output, swinging first one way and then the other.

The nature of the varying cyclic output can be quite jarring, or it can be nuanced and smoothed out:

Now, along comes Agile, and my thoughts go back to the oscillator. And, I'm not the only one. Jim Highsmith has been thinking about the same thing. The architecture (stucture and behaviors) of all agile methods includes feedback, mostly from customers/users, but also from sponsors/stakeholders. The mandate for agile teams is to respond, and be responsive, to feedback. That is, a sample of output--in the form of user experience--becomes a part of the input to the deliberations of the agile team.

Now, if the feedback is phased (timed) one way, it will stablize the iteration. Change the timing a bit and it will destablize the iteration and cause oscillations. In effect, the team builds one thing, only to find out--in the wrong timing--that the customer has changed their mind; the team responds to the change. But, meanwhile, the customer is experiencing the wrong (earlier) thing and seeks correction. Ooops! the team is driven back, or a different way.

If the timing is never corrected, the iteration becomes oscillatory and really nothing gets done.

Time for the project manager to step in and call a halt and dampen the oscillations. Everyone needs to take an Iteration 0 break to do a little reflection and get the timing reset. Maybe a spike needs to be inserted to allow for some non-deliverable prototyping or modeling.

In any event, oscillations can not be allowed for more than a cycle, perhaps two. If not naturally damped out, the PM must take action!

Bookmark this on Delicious

Square root of 2, and more!

I started to tag this posting "trivia" but thought better of it. But I was interested to learn from John Baez, a mathematician of some renown, that the Babylonians had pretty much worked out the square root of 2, an irrational number not the ratio of anything, and they did it using a number system with base 60.

Here's the proof, according to mathematician Baez. A tablet, written by a beginner because of the large lettering, has sides of length 1/2 (30 in base 60) and writing that shows the calculation of the diagonal to an excellent approximation of Sqrt(2)*1/2, or 1/Sqrt(2).

Baez explains:

Well, actually, there's no evidence that the Babylonians (now, Iraqis) ever knew about irrational numbers. They expressed everything in fractions and used approximations.

And that by the way is the lesson for project managers: we live in the one-sigma world where a decent approximation is "good enough". A lot of really good project management gets along fine on approximations. We can leave to Dr Baez to give us the theoretical underpinnings!

Bookmark this on Delicious

What are you doing?

If you can’t describe what you are doing as a process, you don’t know what you’re doing.

W. Edwards Deming

Bookmark this on Delicious