Pages

▼

Friday, November 30, 2012

Authority and power

Authority and power: often misunderstood; often abused; sometimes used effectively

I suggest the following about authority and power  :
  • Managers have authority by virtue of institutional/constitutional position, and power by virtue of their exercise of authority
  • Authority is the ability and the institutional right to authorize (to say YES)
  • With or without authority, you can always say NO (and gum it up; staffers do this all the time)
  • Power comes from the fear/threat/utility of the application of (authorized) resources
  • Really effective power comes from the ability to communicate, where communication means to be able to instruct/educate/persuade/motivate.
  • However, it's also true that a leader (less so a manager) without authority can still have power -- perhaps very effective power -- by virtue of their communication skill.   
Someone with authority but no real power can say "do this" but it won't get done or it won't stick. Stickiness is the real mark of power... say "do this" and it gets done, and it sticks! (No back channel work arounds, no problems of subordination; it just sticks!)

Of course, authority can segue into authoritarian.
We've posted on that before:

at

Wednesday, November 28, 2012

Permission to fail

We often hear that managers want "permission to fail"; or that more progressive organizations convey "permission to fail"

Really?

I suggest some caution: "permission to fail" in most instances means "permission to take a risk" that might have good payoff, but which also might not work out. If it doesn't, there may be harm, but at least no foul.

It never means "permission to be incompetent", or not to be up to the job.

at

Monday, November 26, 2012

Thinking -- a quotation

Thinking is hard work. That's why so few engage in it
Henry Ford

Although project management is a thinking person's profession, you wonder sometimes what's going on when silly things happen. But, of course, that's why we blog: to raise issues for thinking people
Delicious Bookmark this on Delicious
at

Saturday, November 24, 2012

Inside the PMI ACP Exam

Mike Griffiths writes the "Leading Answers" blog and contributes considerably to the efforts of PMI to support agile. On his blog site you'll find things like mapping the PMBOK to agile process steps using an interactive matrix that you can use to click about and find interesting agile tips for working with the PMBOK.

Now, in a recent posting, he provides (in a downloadable pdf of a ppt presentation) an explanation of the ACP exam, entitled "Inside the PMI-ACP Exam." We learn this bit of news: the PMI-ACP certification population has now passed the risk management certification population to become the most popular certification after the PMP and CAPM.

For practitioners looking not only for sample questions but also for the structure and organization of the exam, Mike's presentation is a really nice reference to have.


Delicious Bookmark this on Delicious
at

Thursday, November 22, 2012

Stage Gates and Agile

One of my Agile Project Management students asked me about stage gates and agile. My first response was this:
  • Agile is not a gated methodology, primarily because scope is viewed as emergent, and thus the idea of pre-determined gate criteria is inconsistent with progressive elaboration and emergence.
  • Agile does embrace structured releases; you could put a criteria around a release and use it as a gate for scope to be delivered
  • Re budget: agile is effectively 'zero base' at every release, if not at every iteration. You can call the question at these points of demarcation.
  • Agile is a "best value" methodology, meaning: deliver the 'most' and 'best' that the budget will allow, wherein 'most' and 'best' is a value judgement of the customer/user.
  • Of course, every agile project should begin with a business case which morphs into a project charter. Thus, the epic narrative (the vision narrative) is told first in the business case, and retold in more project jargon in the charter. Thence, there are planning sessions to get the general scope and subordinate narratives so that an idea of best value can be formed.
But, DSDM is one agile method, among others, that is more oriented to a gated process than say, SCRUM. To see how this could work, take a look at this presentation:

And, you can follow-up with this:




 

at

Tuesday, November 20, 2012

Lies, damn lies, and ....

I am reading (on a free Kindle reader app) a great book on the power (and frustration) of Bayes Theorem. The book is: "The Theory that would not die" by Sharon Bertsch Mcgrayne

Bayes is the guy--from the 18th century--who told us that given some data (actual observations) we can reverse engineer the underlying probabilities, or at least the parameters like mean and deviation. One catch is that we are required to guess a starting point. Oops! Guessing is not what we do in project management, or mathematics for that matter.

This idea (guessing to start, and then improving the guess with real data) is an anathema to the 'frequentists' who go at it the other way 'round: given parameters, we can predict data.  Oops! if the event has never happened, or happens infrequently, or has never been observed, where do the parameters come from? How can we use situations like these to drive decision making? If we can't make a decision with it, then does anybody care? Spending time observing such stuff is not what we get paid to do in project management.

I was searching for some point-counter point stuff to go along with the book. I came upon this presentation from a guy (Louis Lyons) at Oxford. You gotta love the last page! (as below)



at

Sunday, November 18, 2012

21st century talent

The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, relearn, and unlearn
Alvin Toffler
 
In an interesting paper on scribd.com about talent demands in the 21st century entitled "Brawn from brains: Talent, policy, and the future of American competitiveness" we find this illustration:


One only needs to look at how the table of contents is presented as the top level ideas to get the gist of this very readable essay:

 
Delicious Bookmark this on Delicious
at

Friday, November 16, 2012

Risk management?

This is risk management:
 
Risk
 

Sometimes, it just doesn't work like it's supposed to:
 
 
 
 
at

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:




at

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.
at

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
 
 
 
at

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.


That said, how do you convey a conversation through the vehicle of a contract? Off hand, it sounds like an oxymoron to be sure. There's certainly no more structured device in the project business than a contract. Is it the right framework to converse with?

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:

Delicious Bookmark this on Delicious
at

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.
We see risk attitude portrayed in this model:


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:


So, what are the rules of thumb here? They are:

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.


at

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.

at

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.
For project purposes, statistics may be the most useful for the rules of thumb they support, rather than the statistical analysis that the project analyst provides:
at