Beware the people model!

Models! No one would deny they aren't an important tool in project management. They are the backbone of what we call 'parametric estimating'. That is, models establish a functional relationship between activity and outcome, given the value of one or more parameters.

Y = A * X + B is the simplest linear model. Outcome Y is a function of independent variable X, but the outcome of Y depends on some parameters, specifically A and B. Given values for A and B, usually determined by observation and experimentation, sometimes observed over many projects and circumstances, Y is determined when X is determined.

Of course, it gets more complicated quickly, especially if there is a X-squared in the mix.

But here's the question: are parametric models suitable to predict behavior by team members in various situations? For years, the answer was more or less yes, and the state of the art was advanced by economists seeking predictions of behavior under various economic situations. The general idea was the individuals could always be counted upon to maximize the expected utility of a situation.

Expected Utility? Utility is the assignment of value--numeric value--to ordinal values, like high, medium, and low, and other events or qualities. Typically, project managers would use either a 1-2-4 binary scale or a 1-2-3-5 Fibonnaci scale.  Expected utility is just the risk-adjusted average of the utility assignments. Most people would rationally seek to maximize the utility--the value--of any situation.

Now, along comes the economic crises and so also comes a lot of sole searching about parametric models of human behavior. Naturally, project managers see some of their own experiences and problems here.

In an essay he wrote, David Brooks recently reviewed the bidding on all of this. He has noticed the cyclic nature of faith in models, wherein a short time ago the autonomous and rational decider was the model figure. Then practical results set in: some realization that the irrational impluses of all human behavior needed to be factored in, to the point we are now: back to John Maynard Keyes, a man of the early last century.

In a particularly fitting quote to which every project manager will find affinity, Brooks writes:

"....John Maynard Keynes “was not prepared to sacrifice realism to mathematics,” as the biographer Robert Skidelsky put it. Economics [and, read: also, project management] is [among other things]a “moral science,” Keynes wrote. It deals with “motives, expectations, psychological uncertainties. One has to be constantly on guard against treating the material as constant and homogenous.”"

Enough said!

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

Puzzles and Mysteries

Maybe you haven't thought about it a lot, but there are interesting ideas that surround the differences between the idea of a puzzle and its solution, and a mystery and how to unravel it. As one interested in risk management, the puzzle vs the mystery is part and parcel to the spectrum of variation that stretches to recognizable risks and then beyond to unknowable uncertainty.

Of course, a puzzle follows rules that are not be violated. Because there are rules, there can be strategy for the solution and these strategies can all but be templated. And, there is a complete solution. First viewed as a bunch of dots, a puzzle really is a narrative, and once the narrative is discovered, many of the dots fall rapidly into place. Making a narrative out of dots is a key skill in the risk management business. The full effect of the dots is not knowable until the narrative is evident.

Mysteries, on the other hand, have a deeply obscure narrative. Usually many of the dots are missing and may never be recovered. In fact, from a few dots, the mystery detective [read: risk manager looking way forward] synthesizes a narrative, poses a hypothesis or theory of the event, and even so, a decision is likely to be made with only partial information, conflicting information [or seemingly so] ignorance of the true narrative, and therefore ignorance of the likely outcomes.

Those accustomed to puzzles may not fair well in the ambiguity and unresolved confusion of mysteries. Not everyone can be Holmes!

For more on mysteries and puzzles, check out Malcom Gladwell's 2009 book: "What the dog saw: and other adventures"

Try something!

Quote from the noteworthy:

"It is common sense to take a method and try it. If it fails, admit frankly and try another. But above all, try something." FDR

Franklin Roosevelt was famous for his tolerance for ambiguity. In the scope of leadership styles, on many difficult and uncertain occasions, he was the supreme delegator.

Among those that practice this style with aplomb, and Roosevelt was certainly one, a good deal of trust flows down, ceremony is minimum, and for the one who is the "paper at the bottom of the birdcage", there is no help coming from above!

And, expect not only ambiguity, but also competition. It's common for delegating leaders to empower more than one and let the best rise to the top!

Start on the critical path?

In project management school, the lesson on Critical Path includes Rule #2: "Apply resources first to the critical path and subordinate demands of other paths to ensure the critical path is never starved."

Most of the time, Rule #2 is good advice. [Rule #1, if you haven't guessed is: create a schedule network so that the critical path is revealed; Rule #1 is ignored by those that work only with milestones]

Some of the time, Rule #2 has unintended consequences, like making the critical path longer! How does this happen?

The problem arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. Now, the parts are not interchangeable. Now we must consider not the generic staffing profile for a task but actual capabilities of real people.

Now we must consider the intersection of the staffing plan with the schedule plan. When two plans intersect, the results are not always as we want them. Intersection means overlap, and overlap means that the planning elements must be moved about so that each overlap is harmonious.

Take a look at the following figure for Rule #2:

You can probably see that if not for the specific assignments of Mary and John, the critical path could be as short as 50days, not 65 as shown.

Let's violate Rule #2 and invent Rule #3: Reorganize the network logic

Staffing does not actually start on what was the critical path, but the overall schedule is shorter nonetheless. A new critical path is born which incorporates the sequencing constraints of the original path and the staffing constraints brought about by Mary and John.

Obviously, on any network of non-trivial scale you can not really do this by hand; it requires a schedule optimizer and the optimizer has to be configured to try, at least, violating Rule #2.

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

Project CEO's of something

Ever thought about being a CEO of something on your project?  That's the question and the theme of an interesting interview with entrepreneur Mark Pincus  in the "Corner Office" [The New York Times, Sunday January 31, 2010]

Actually, Pincus is describing how he solved another problem: scaling personnel management beyond what he considers practical for the personal touch: about 50 people.

His solution is low tech, but it's easy to see how it could work: Give everybody a sticky note and a white board and ask them to write down what they want to be CEO of--something for which they will take personal responsibility, for which they will be the playmaker and make it happen!

Everyone that has managed more than a small team can remember the first time their management role took them out of close physical proximity to the team--a move into an office, a move to another building or floor, or venue. Good grief! How do I manage if I can't observe what's going on?

Making a team of little CEO's may be the answer!

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

Culture, projects, and politics

Here's a quote worth considering the next time politics interrupts your project:

"...the central conservative truth is that it is culture, not politics, that determines the success of a society [read: project]. The central liberal truth is that politics can change a culture and save it from itself [read: avoid dissing a project that might be worthy but not culturally compatible].”

Who said these words of wisdom? None other than Daniel Patrick Moynihan, former White House advisor and U.S. Senator.

So, what to make of this idea?

Point 1: Culture dominates! If your project methodology is counter-cultural, then be advised: "some work required here"

Point 2: Culture is changeable, but politics is untidy tool!. Politics, sometimes at variance with long-held beliefs [organizational, not necessarily personal], and sometimes at variance with principles [actionable guidance around beliefs] is often the tactial plan of the moment.

Point 3: Culture adapts to the new reality over time, if actions are repeated consistently.

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