About knowledge

---

The other day I was asked to comment on "knowledge" as a competency. My immediate reaction: No, without parameters it's not a competency. In other words: knowledge of what? And, to what degree (depth, breadth, etc)?

My reaction was somewhat vindicated by this posting from Laurence Prusak who writes the Knowledge Notebook column for NASA's ASK online magazine. In a column entitled "The Greeks had many words for it", we learn that the Greeks did indeed have seven words for knowledge, whereas in English we have only one.

Ergo, Prusak tells us:

Unlike our shared understanding of almost any other term used in organizations—technology, systems, information, data, markets, processes—we seem to lack a common idea of what knowledge is. This makes working with knowledge quite problematic
Thus the idea of knowledge competency -- which implies an ability to manage knowledge (knowledge management being somehow an organizational competency ... another thing I don't buy without parameters) -- just doesn't compute! Of course, wikipedia begs to differ, having as they do an article on just about everything (click here to save everything?) and thus on knowledge management.

Now, I'm all for being knowledgeable... who wouldn't be? But, some parameters required!

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

On the laws of chance

---

Glen Alleman had a recent posting on sundry quotations about chance and uncertainty -- something we PMs deal with every day (no exceptions!). Here's the one I like -- and it justifies taking a course in statistics (See Khanacademy.org)

• If chance is the antithesis of law, then we need to discover the laws of change - C. R. Rao (mentor to Ramanujan)

Glen's editorial on this: "all variables in project work are random numbers. Without knowing the underlying statistical process and the probabilistic outcomes, no credible forecast for future performance is possible. Deciding anything in the absence of probabilistic confidence is simple not possible"

Not so fast!

Of course, here's the issue: we can't know the things Glen wants us to know... we rarely -- if ever -- have the history or observations depth to develop the 'statistical process' or 'probabilistic outcomes' in the 'frequency' sense of probability (to wit: how often does it occur?)

And, the 'laws of chance' are immutable, not subject to management. To wit: you  can't manage the probabilistic outcomes of fair die tossed repeatedly. Thus, we PMs don't deal with the laws of chance very often -- they are more like laws of physics insofar as our ability to influence them.

But, Glen's last point -- estimating without regard to uncertainty -- is valid: Not possible.

So, what's plan B? Enter Bayes Theorem, which broadly stated says we can:

1. Start the estimate with really no knowledge (if we don't have any), then
2. Systematically improve the estimate with even limited observations (too limited to be of use in a frequency definition of probability, but 'good enough' to improve an outright guess)

Consequently, as Bayesians, we arrive comfortably in Glen's camp: Estimates are a necessary element of PM; estimates are not facts -- hello, they are estimates; and useful -- that is usable -- as estimates if uncertainty is a factor.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

What project management means to me

---

This posting is my contribution to today's "flashblog" organized by Shim Marom who hangs his hat at Quatmleap  (actually, his hat hangs upside down since he is in Australia). The common theme: "What project management means to me"

Well, hopefully it means to mean what it means to the business:

A leadership and management wrapping around project activity that adds value (to the business) by delivering predictable results for the business.   

If PMs can't deliver results to the business -- pretty much the way the business expects them -- what purpose do we serve -- really?

I always think first in terms of mission -- and so, the PM mission is simply this:

The project manager’s mission is to manage assigned resources to deliver the value expected, taking measured risks to do so

And, I think second about why we do projects at all:

We do projects because they are an important means to extract value from opportunity ... by managed application of resources,taking measured risks to do so.

And so what is value?

Project value is equal to, or greater than resources committed to the defined scope and risks taken to achieve favorable accomplishments. The cost of the project is not it's value; it's value is what difference it makes to the enterprise, either on the balance sheet or the mission scorecard.

And so this is it for me... there's another 40 to read on this same subject today!

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Reinventing the PMO (to be agile and other)

---

Rules and tools, and perhaps schools... that was your father's PMO.

But, that's not a great recipe these days. A better idea is given by Jack Duggal who wrote a piece for PMI recently about Reinventing the PMO

I don't think he started out to be an agilist in this article, and I'm not sure he read my most recent book on "Maximizing Project Value" (you can buy it here), but he and I are certainly of a common mind on this.

Some of the highlights are given in a post at leadinganswers on how Jack's idea apply to a PMO in an agile setting. From there, we learn these tidy bits about 'from-the-old' 'to-the-new' ideas in PMO-land:

1. From Delivery of Projects to Benefits Realization and Business Value
No longer is delivery of on-time, on-budget projects considered successful. It is necessary but not enough.

2. From Delivery to Adoption and Usability 
Typically, PMOs are focused on improving execution capabilities. Projects are implemented well, but often the outputs and deliverables are not used or adopted.

3. From Diffused and Disjointed Focus to Holistic and Balanced Adaptive Approach
Often PMOs are pulled to address the current pain or fix the problem of the day. This results in a diffused and disjointed PMO focus and limits the ability of the PMO to provide a balanced approach.

4. From Change Management to Change Leadership
Evolving PMOs understand the need for organizational and behavioural change and get involved in change-readiness assessments and preparation.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Document maintenance

---

Everyone I know is frustrated by the chore -- many times thankless -- of maintaining project documentation. It seems that as fast as it is produced, it is obsolete and requires expensive maintenance. This issue inspired the agilists to write their agile manifesto this way:

"We have come to value .... Working [product]over comprehensive documentation"

Now comes evidence of the problem, as seen by Matthew Squair on a ferry in Sydney:
 

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Plan A

---

You here a lot of talk in project-land about "Plan B": What's Plan B? they say.

But, I've always been a proponent of Plan A: to wit: Do no harm; in many cases, Do Nothing.
Now comes a book that somewhat validates Plan A:

I learned about this handy guide from author Keith Murningham from a book review. There, we learn about the "leadership law" (who knew there even was a leadership law?)

“Think of the reaction that you want first, then determine the actions you can take to maximise the chances that those reactions will actually happen.”

Now, the corollary is that if you don't follow the law, you may not get the results you want.
Fair enough; that happens a lot.

But, among the sins of leaders that lead to poor results, two stood out for me:

1. A focus on their own actions
2. The belief that others understand them completely.

The idea behind '1' is that although 'actions speak louder than words', sometimes the situation is best handled without words or actions. Perhaps others can get you the reaction you want... thus, we come to "Do Nothing".

The idea behind '2' is a failure to exercise the "law of communication". (Full disclosure: this is my own law, but I learned it from others)

1. Tell them what you're going to the tell them
2. Tell them
3. Tell them what you told them

In one step or the other, they are likely to 'get it'. However, Plan A -- Do Nothing -- may still be operative, since communicating may be the only action needed, and all else will flow nicely without harm

One could only hope so....

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Strategic project leadership

---

"The project perspective, position, and guidelines on what to do and how to do it, to achieve the highest competitive advantage and the best value from the project outcome "

Aaron Shenhar and Peerasit Patanakul (2012)

This quote is actually taken from another of Shenhar's numerous papers, though he gives credit to his co-author for the overall definition.

I like it because it brings in the idea of "Best Value" which is more or less my guidepost:

Best Value is the most of the most important and most effective scope for the available investment of resources

Some call this the "most of the most" doctrine. Ok by me!

Of course, if you are going for "highest competitive advantage" and "best value" the immediate question is begged: "In whose opinion?"

Agilists say: "the customer"; traditionalists say: "the guy paying the bills". If it's a commercial business, then by the OPM principle, the customer is the only one paying the bills, so the traditional and agile ideas merge. 

On the other hand, in the public sector, the merge may not be so obvious, and may not occur at all since the guy paying the bills may be a philanthropists or taxpayer with only a very indirect connection to the project. In that case, the question of opinion is more problematic, even Wicked!

From here, I shall leave it to the reader to.....

---

Peerasit Patanakul, P, and Shenhar, Aaron. (2012, February) "What Project Strategy Really Is: The Fundamental Building Block in Strategic Project Management.” Project Management Journal.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

A bit more on change management

---

There are endless tips on change management. It seems like everything is at an inflection or tipping point, and just a bit of management will move it along nicely.

So, among others, John Butman has weighed in on this topic with some useful stuff. He says:

• Accumulate evidence to gain influence... fair enough in this era of "Big Data" and meta-everything
• Align with a metric... a close relative to the first bullet, especially one that's on the business scorecard and affects pay -- those are the best!
• Reduce abstract ideas to real practices... something that's actionable is always influential driving change
• Create a meme! ... in effect, a logo or surrogate for your change idea (See: mobile!)
• Show up in person to push your idea ... this is somewhat related to not being abstract, and include your personal narrative
• Expect backlash -- practice both defense and offense

  ---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Six tips for how to fail at data-driven decisions

---

Sometimes, various blogs on how to fail are not all bad -- not exactly optimism, to be sure -- but valuable nonetheless for the glass-half-empty crowd as well as we glass-half-fullers.

So, in working through my feedly.com mobile reader, I came across six tips for how to fail at being data-driven in your decision making. Of course, in this day of the meme of "Big Data", not being data-driven is almost like being the anti-Christ. If one is not data-driven, one almost has to hide in the closet.

Nonetheless, it's possible to fail quite easily, as we learn from Thomas Redman with this posting: "Become More Data-Driven by Breaking These Bad Habits"

• Go with your intuition -- data not necessary
• Rig the system to hide the inconvenient
• Second guess others to put them on the defensive
• Allow paralysis of analysis ... just one more data item and I'll decide ....
• Allow group think -- in effect, no real critical thinking
• Be arrogant! You have all the answers

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Moving ahead by leaving behind

---

Nick Tasler has a posting on the HBR Blog Network with an intriguing title: "To Move Ahead You Have to Know What to Leave Behind" 

His theme is summed up this way in an early paragraph:

The Latin root of the word "decide" is caidere which means "to kill or to cut." (Think homicide, suicide, genocide.) Technically, deciding to do something new without killing something old is not a decision at all. It is merely an addition.

So, what do the hoarders among us do? We save everything; kill -- or throw away -- nothing! Actually, we find deliberately making these trade-offs -- keep this; discard that -- so energy absorbing (Tasler says: exhausting) that we just layer on new change.

This behavior leads to what Tasler calls "trickle down trade-offs" in which there is sort of a push-down stack with the most current issue on top and the not-dealt-with issues more or less far down the stack.

Many of have seen this in action -- and we joke about planning an exit strategy before the stuff at the bottom finds its way back to the top!

Nooooo.. that's not management -- that's escape. To be effective, we must all acquire the killer instinct and be thought of as 'trained killers' of excess (think: Lean!)

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Think! ... Then, believe

---

Our quotation today comes to us from Larry Ellison

"Think! .. Then, believe"

And, so what's that about?  In a few words: don't believe what you read on a blog, and don't take as gospel the "accepted truth" without validating for yourself. The validating thing requires thinking. Once validated, then you can run it around as a belief, confident that the belief is actionable.

Ellison's poster child for this philosophy: the common "wisdom" -- circa early 1970s -- that relational databases are slow, and their architecture makes them slow. Throwing "big iron" at a relational database might help a bit, but in the end, they are not business worthy.

Ellison chose to think about this, rather than believe the common wisdom; now he is billionaire with a big company behind him, and the database SMEs of the day are mostly middle class retirees!

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Efficiency and agile

---

One thing my agile students frequently ask about is: "How agile can help my projects and organizations be more efficient?"

I usually respond this way:

One way agile gains efficiency is through promotion of and exploitation of trust.

Bureaucracy is generally a management tool to combat low trust. By counter point: in a high trust environment, little bureaucracy is needed and thus energy and resources are redirected at the project value-add.

Fair enough.

But what is it about agile that brings trust where trust is less apparent among the same practitioners immersed in a different methodology? In other words, what is the root cause that leads to the desired effect? We should be wary of simple correlation -- things moving together. We want causality -- this cause begets this effect.

It comes back to three ideas, which in the domain of public service are:

Duty, honor, country

But in the domain of business projects are:

 Duty, honor, commitment and accountability

In the former, if I sense your internalization of "duty, honor, country" I will trust you almost unconditionally. And, a trust broken under these conditions is almost never forgiven or forgotten.

The same goes for the business domain. And, here is where Agile comes in: it embraces and depends on personal commitment and accountability more so than other methodologies that are centered on command and control (see: bureaucracy). This embrace is the root of trust in the agile domain. Those who break this trust are invited out, and not invited back in.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Those pesky 3-point estimates

---

Here's my three point estimate paradox:

We all know we must estimate with three points (numbers)... so we do it, reluctantly
None of us actually want to work with (do arithmetic with) the three points we estimate

In a word, three point estimates suck -- not convenient, thus often put aside even if estimated -- and most of all: who among us can do arithmetic with three point estimates?

First question: where does this really matter in the domain of project management?

• When adding up a budget or calculating the duration of a schedule
• When doing a risk register and someone says to multiply impact x probability

Second question: how do you go about it? Actually, you can build a couple of simple templates in a spreadsheet to do the arithmetic. Then fill in the 3 points, and presto! -- a summation or product (add or multiply) pops out.

The budget
To understand this, start with the basics:

• Suppose I have two work package budgets, one is fixed and one is uncertain. I use a 3-point estimate for the latter. I need the total budget
• As an example, with numbers:
• Fixed budget = 10
• Uncertain budget 3-pts: 5, 8, 12
• Possible totals: 10+5; 10+8; 10+12
• With no other information, pretend you are a Bayesian. You would say your "a priori" is that all 3 totals are equally possible. Thus: 1/3 * (15+18+22) = 18.3

Now, you can see it's easy to extend this to both numbers being uncertain: in that case, you would then do 9 possible totals and divide by 9.

The risk register
Multiplication is the issue with the risk register, typically I x P. Say what you will, but both I and P are uncertain, and usually P is the most uncertain. We usually have no real basis for assuming a probability since we usually have insufficient history to establish a reasonable frequency (1/P)

As an example with numbers, suppose I've been told that with some risk my budget is going to be cut by $50. For our purposes, we can take this impact as a single point "certainty". What's uncertain is whether or not there's much chance it will happen.

• Fixed impact = 50
• Uncertain probability (better thought of as a confidence of a some % or less): 10%, 30%, 50%
• Possible IxP products (this figure, or less): $5, 15, 25 (P is dimensionless, so IxP has the dimensions of I)
• Again we can do our Bayes thing (no information for the 'a priori') and come with the average IxP: 1/3 (45) = $15
• This extensible to uncertainty of both numbers wherein there will be 9 products

Monte Carlo
Is anybody going to do this on a real project with a spreadsheet? Likely not. But, this is the way a Monte Carlo simulation works and the MC Sim is common among projects run quantitatively.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

An agilist on estimating

---

Mike Cohn, who wrote a really good book -- perhaps the Bible -- on estimating agile projects, has a recent email "info item" about estimating. Most of it is good til he gets to the last paragraph.

And, then: OMG! Cohn says: you don't have to do estimating if you don't need to prioritize or if no one is asking for predictions.

My comment to this advice: NO! (Strong message follows). A project without estimates is totally blind to the future possibilities and probable outcomes.

Frankly, it shouldn't matter to you who wants (or doesn't want) to prioritize -- everything that is otherwise not governed by the physics of sequencing requires some prioritization -- and every consumption of resource should be considered in the context of scarcity: all things man made are constrained!

There's a price for using (and consuming).. this is inescapable for project managers.

For more on this general topic -- if you're really a non-believer in estimates -- I refer you to the numerous blogs and twitters on #NoEstimates! A good place to start is here.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Dr. Will on earned value

Dr. (George F.) Will mostly writes about politics and baseball -- and mostly about unwarranted constraints on freedom.  He never writes about earned value.

So, I was struck by this passage which made me think immediately of the earned value examiners that used to descend from Washington onto my projects, foretelling gloom and doom

"Studying history serves [governance] by highlighting contingencies: Things [do not] need to turn out the way they did; choices matter. Since Hegel, Marx and other 19th-century philosophers decided that history is History — a proper noun, an autonomous force unfolding an inner logic — humanity has been told that vast, impersonal forces dictate events, nullifying human agency. But they don’t. Choices matter."

Dr. George F. Will

OMG, choices matter! Said another way: History does not dictate the future when human agency (thoughtful action) is applied.

And that brings us to earned value (I'm a supporter, but only to a point), the value of which is a forecast -- which, by the way, is not a certain outcome -- of where we may go based on where we've recently been. For purposes of the forecast, efficiencies, are presumed constant (over the near-term future) and presumed to be the coefficients of the future.

Of course, efficiencies are not constant -- we just want them to be. That's the paradox of earned value. Efficiencies are influenced by the quality of requirements, the effectiveness of environment, and the competence and willingness and commitment of staff,

Consequently, the outside analysts come with their forecasts of a project in trouble (which may be true) but no solutions (except change the efficiencies). And, of course, that is exactly where human agency comes in: DO SOMETHING (FDR's words) to affect a change.

In other words, an earned value moment of analysis becomes an inflection point. The efficiencies going into the analysis are not the efficiencies coming out-- by choice and by action.

But, earned value has served its purpose: to warn of a need for change, not to forecast the eventual outcome.

---

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting