Wednesday, November 14, 2012
Democracy, government, and GitHub
Clay Shirky is a frequent speaker on TED. The other day I ran into his recent talk on how democracy, government, and GitHub are related. That's not self-evident to be so I looked in.
GitHub, for the unaware, is an open source source-control system (aka configuration management, or source repository) from the genius' at LINUX. The big claim to fame with GitHub is that is completely distributed, no central control, but has a shared protocol for managing updates and relations about and between objects.
Shirky comes into when he discovers that even government agencies are using it to manage the relationships, something like mind maps, among constituents, regulations, statutes, and documents.
Very interesting idea when you think about it. And lots of project management applications at the PMO level, as well as at the cost account or work package or iteration level.
Here below is the TED presentation, but equally interesting is this explanation of how GitHub works using a project document as the object:
Monday, November 12, 2012
5 ways to work conflict
I'm always on the the alert for the five best ways to do this or that, or somebody's top ten ideas about something. Usually, there is a gem hidden in there somewhere.
Here from "A Girl's Guide to PM" comes five ideas on conflict management (although they were written by a guy, Daniel Raymond, doing a guest posting). Nonetheless, with a little (actually, a lot of) paraphrasing on my part, here they are:
1. Be an alpha
The authoritarian approach is particularly effective if the project is nearing completion.
2. Avoid or ignore
Do good; avoid evil. Stay calm, and press on. Ignore team conflicts as if they don’t exist.
3. Sacrifice self-concerns
See the other guy's point of view, and go with it. You may have to view the underside of the bus to do this, however, so be prepared for the sacrifice. Re my introduction: this is the gem for me; I've not really seen self-sacrifice on the list before.
4. Collaborate
Sit down with the people who are in conflict and talk it through. They may have a good idea, and they may see that you have a good idea, and perhaps something will emerge not evident from either idea standing alone.
5. Exchanging concessions
Show me yours, and I'll show you mine. Something of value exchanged for something of value, with resolution of the conflict as part of the transaction.
Saturday, November 10, 2012
Knowledge and uncertainty--a quotation
“Knowledge is an unending adventure at the edge of uncertainty”
British mathematician, biologist, historian of science, theatre author, poet and inventor
Thursday, November 8, 2012
Conversation through contracts
In the agile business, we've pretty much done away with the 'shalls' and 'wills' of traditional structured requirements, replaced by the conversational story. Even the use case, certainly structured by the UML paradigm, is not so much a 'shall and will' device.
My recommendation over the past several years that I've been talking about this is that the right contract is a fixed price framework with either fixed or cost reimbursable work orders, each work order corresponding to a iteration. Obviously, to keep the overhead down, a really lean process for writing work orders is Job 1.
First conversation
The time to have the first conversation is before the framework is put in place. This is when you explain the vision and discuss the top level narrative and the overall value proposition. Subsequently, the framework captures the contractual elements of the overall project...if you're building a bridge, that's one thing; if you're building an ERP, that's another.
Retrospective conversation
Then, as part of the retrospective review of the backlog, iteration by iteration, there are more conversations, each one then put more or less into the job order. The JO should still have some flexibility to handle unforeseen backorder problems. However, the foresight of the JO need not be but a few weeks, so it's risk of the truly unknown is foreshortened.
For more, give this a read:
Bookmark this on Delicious
Tuesday, November 6, 2012
Risk attitudes aren't stationary
It's a simple idea, somewhat obvious when you stop to think about it, but risk attitudes aren't stationary. I'm using the term 'stationary' in the statistical sense: if stationary, it doesn't matter when you make an observation; the observed phenomenom is time invariant.
So, if not stationary, then attitudes must change with time; and indeed, they do. This is one interpretation of the cone of uncertainty:
- In the far future, when there's plenty of time to make an adjustment, and all options are on the table, we're more optimistic about a risk (it might be a big deal if it happens, but we'll probably be able to fix things before it does)
- In the near future, when most of the options are off the table, we're more pessimistic that we'll be able to fix whatever goes wrong.
- In between these two, we're more or less centered: might happen, might not; either way, we can deal with it.
You can see that it's the usual triangle model for risk, skewed towards pessimism, so that the expected value is a bit more pessimistic than the single trial most likely outcome. Of course, the real world is not a world of triangles; but the triangle is a good model nonetheless because it's mathematically simple and the central limit theorem tells us that the distribution model is irrelevant to Monte Carlo results. So, we might as well use something simple!
Now, put on the temporal dimension and you get something like this:
1. Estimates about the far future are usually overly optimistic, leading to underestimates and then overruns. The sales staff on the project are notorious for this practice; who's not heard: Win it first, then fix it!
2. Keep an eye on those expressing a risk attitude: sponsors, stakeholders, even cost account leaders. Their notions, and thus the risk register itself, are not stationary. Everyone says risk management is constantly iterative, and so it is, and this is one of the reasons why so.
Sunday, November 4, 2012
We spent all the money; used all the schedule...
On first inspection it seems like common sense: Measure the stuff that will make a difference to your success. There's a corollary of course: Why would you measure stuff that is indifferent to your success?
I guess this is sufficiently mysterious that it warranted a recent article in the Harvard Business Review, the theme of which is: measure stuff that really counts!
When we port this idea to the project domain, it's amazing what you find. Most project managers focus on measuring the consumption of input (the stuff that feeds the beast), and resist, even disdain, measuring production of output: that which the beast begets--project value.
Of the former (input), I am speaking of money, schedule, resources. Of the latter (output), I am speaking of throughput, value earned, and metrics about "done". To its credit, the Agile movement has given a real lift to the output metrics. In fact, I call agile an output-centric methodology. There's less worship of the cost and schedule, and almost total focus on throughput (velocity x units/time) and "done" (no credit on the burn-down if it can't be delivered)
But, returning to for a moment to the Harvard Business Review, the point made in the article is that cause-and-effect are not all that straightforward. The article is repleat with regression plots showing the weak relationships between outcomes and what was thought to be the input drivers. Here at Musings, we've made the point about the difference between correlation (things moving together) and cause-effect (things moving because other things move).
So, even when you turn your focus to output, more so than input, you still may miss the cause for the effect of a better and more valuable project outcome.
To go there, you need metrics about integration of the parts (something often missed by the earned value crowd), and the emergent effects of all the parts working together (not entirely predictable). (Parts are parts, but it's the system!)In other words, to really shift from input to output, you need metrics about how the system of deliverable parts is going to make good on your project objectives.
Not altogether up on systems? See: Donella Meadows: Thinking in Systems.
Friday, November 2, 2012
A quote from Nassim Taleb
Statistical and applied probabilistic knowledge is the core of knowledge; statistics is what tells you if something is true, false, or merely anecdotal; it is the "logic of science"; it is the instrument of risk-taking
Nassim Taleb
You got to hand to the guy: he is passionate about his subject. Of course, he's also the first person to tell you that his most infamous invention, the "Black Swan", is black--that is, extraordinarily rare--because there are no statistics to predict it.
Two of the more useful properties of statistics are these:
- They are predictive because they are surrogates of a past track record
- They are persistent in the sense that they are survivors: wait weeks or months and if the circumstances haven't changed, neither have the statistics.
- There's merge bias at milestones; they are inherently weak objects in the schedule
- Diversification follows the sqrt(N) rule: diversify into 4 independent events, and get a 2:1 improvement in risk
- Expected value is usually more pessimistic, and therefore more conservative, than most likely
- Expected utility value is not objective, and subject to many biases
- Independent events tend to centrally cluster--the theory of central tendency
- A sample of a large population can be an economic approach that saves time and money
Subscribe to:
Posts (Atom)