Monday, September 23, 2019

Value shifting as we speak

I wrote "a" book on project value, "Managing Project Value", though I would like to say I wrote "the" book on project value .... but I won't go there. (See the cover image below)

Now, in that book I assert that "value" is commonly in two flavors:
  • Value as a system of beliefs, " .... are a moral and ethical code of sorts; collectively, they form culture ... "
  • Value as worth, " ...Value is the worth we place upon something for which we are willing to give up something else.  In other words, worth or worthiness has a transactional aspect, and thus we speak of ‘transactional value’ 
Business value begets project value
For decades, business value has been transactional, the ultimate purpose of which is to increase shareholder value in the business.

And so, we get this bit:
We posit that the best way project managers contribute to maximizing value is to deliver a “best value” outcome.

Best value is the most valuable set of outcomes possible for the available investment, risk, and constraints.

Best value is not necessarily best financial benefit; best value can be the best possible outcome of any scorecard metric.

Best value at the project level maximizes value at the business level
But, is all this still true?
Is "maximizing shareholder value" giving way to some other measurement or accountability?
And, can there be accountability without competition, the "Economist" editors ask.
Perhaps not
If not, then away with monopolies!

And to whom should there be accountability and for what?
Is this a new enlightenment?
Maybe the circle is widening; no longer mostly shareholders and shareholder value.
But, as I've written elsewhere, accountability to everyone is tantamount to accountability to no one. So, add carefully to shareholders those to whom you are to be accountable.

Project balance sheet
All then market, cultural, and political dynamics take us back to the project  balance sheet: business value in balance with project outcomes and risk. If one side is to change -- the  value proposition of business -- then so to must the other side.

To wit: stand by for change; stand by for challenges to project culture!

Buy them at any online book retailer!

Friday, September 20, 2019

Culture vs Strategy

Culture vs strategy? Put that way, it sounds like a competition
Hello! It is.
And: "Culture eats strategy for breakfast every day" (Unknown author)
Meaning: Change is hard! People are gounded in culture; it's foundational; it's a matter of security and well-being. Resist!

Bring your A-game
Any strategic idea that has to overcome culture better be a strong one. Come with your A-game! Expect losses (*). The cost will be greater than you estimate; and it will take longer.

Velocity will seem like you are dragging anchors (Actually, you probably are)
Don't expect popularity. In fact, you may not be a survivor ... but it's for a good cause!

Not particulary PC, but the expression used to be: "Shoot the first one; hang the second; the rest will follow"

Buy them at any online book retailer!

Tuesday, September 17, 2019

Crafting a value statement

Value, like quality, is elusive to define "they" say. In the eye of the beholder, etc.

Fair enough

What do we think of this manifesto (*)?
"The purpose of professional management is to serve clients, shareholders, workers and employees, as well as societies, to harmonize the different interests of stakeholders"
Certainly "professional management" includes professional project management. And, by extension the purpose (read: value) of projects is not different from the purpose of those who manage them.

Not so fast!

Some would rebut this thesis this way:
"Accountability to everyone means accountability to no one"
But some many years ago this overall issue was worked pretty hard; the outcome was the "Balanced Scorecard" which recognized that the interests of all parties did indeed need to be harmonized and provided a framework for accomplishing same.

However, lest we forget, the PMO gets measured by some, but not by all. And, say what you will, the measurers will be satisfied by the measurees before anyone else.

And that -- the interests of the measurers -- at the end of the day, is the value statement of the project.


(*) Davos manifesto of 1973 for the World Economic Forum

Buy them at any online book retailer!

Friday, September 13, 2019

microknowledge vs micromanagement

Robert Gates, former U.S. Defense Secretary, wrote in his memoirs that a strong and effective leader in a big and complex organization needs to put the time and energy into acquiring "microknowledge" but refrain from "micromanagement".

An interesting thought, to be sure. Let the emphasis lie on "... put in the time and energy... "
But, this stuff is not free.
Didn't Malcolm Gladwell say: 10,000 hours to be an expert?
Well, microknowledge should not be 10,000 hours worth; indeed: most Defense secretaries don't even serve 10,000 hours.

So: "Microknowledge"? What's that?
  • Think of it as the knowledge you would need if you were to micromanage -- thus, it's the knowledge you use to assert leverage, influence, and legitimacy over those you do lead.

Understanding vs direction
In other words, you need to understand the traffic while you resist the impulse to direct the traffic -- others can do that for you. (*)

  • And, it's the knowledge you use to make decisions about delegation (this individual can likely to "this" but would not be good at "that"...) and assess performance.

But, of course, there's a dark side: microknowledge also what feeds the old saw: "he knows enough to be dangerous, but not enough to be effective" If this said about you, then you've crossed the line from legitimacy and leverage to nuisance and nemesis... Back off!

(*) Think of the scene from the movie "Patton" when the General himself is standing in an intersection of tangled tank traffic directing their movements... you probably don't want to do that, even though with microknowledge you might be successful

Buy them at any online book retailer!

Tuesday, September 10, 2019

The many flavors of scope creep

Can there be scope creep in Agile? 
Doesn't agile define creep away in a stroke: "Scope is whatever is prioritized in the backlog that fits within the budget (OPM, other people's money) and the time.

The backlog changes all the time, but that's not creep, it's just backlog management."

What I just wrote is a "best value" definition of scope. But, sometimes it doesn't sell.

I credit my agile students with these observations about "creep", to wit:

Project scope creep: it may be well and good that a true pure play on agile has no conception of scope creep, because the backlog is simply rebuilt as a zero-base-backlog (ZBB) after every iteration -- if not after each iteration, then certainly after every release.

Consequently, after every release, you should be able to stop and be satisfied you've delivered the best possible stack of high value objects. Amen!

Resource scope creep
On the other hand, if you can't get commitment for dedicated teams because the resources are needed elsewhere, then you are saddled with the overhead and inefficiency of rolling out and rolling in resources. This is resource scope creep -- spending more on resources' training, recruiting, and assimilation than the budget allows.

Clearly, this is a different flavor than project scope creep.

And, it's been around since forever!
Who's not heard of "resource plug-and-play"?
The plug-and-play process: just define a role, line up the role with appropriate resumes, pick one, plug him/her in, and you're off to the races!

  • For more on plug-and-play, see the work of F.W. Taylor and "management science"

Agile to the rescue!
The fix is in: a pure play in agile means having fully dedicated teams that use the inevitable white space in the team schedule to improve the product -- more testing, more refined refactoring, working completely through the technical debt -- but not to get off the team and go elsewhere, only to return later.

The idea of giving up on matrix and other plug-'n-play resource schemes is pretty much opposed by managers not willing to give real agile a try.

Shifting from input to output
Again, it's an input/output focus tension... managing the white space by moving resources around is an input focus; leaving resources in place to use the white space for quality is an output focus.

Traditional schemes often put resource managers in charge of finding resources for the project manager. Obviously, those resource guys are going to focus on getting their job done according to their metrics.

Agile schemes are a bit different: once the resource manager has given up the resource to an agile team, it's the team leader who's responsible for getting good productivity and managing the white space on behalf of a best-value product

Buy them at any online book retailer!

Saturday, September 7, 2019

Let them figure it out

"Let them figure it out" is the mantra for small team management at its best.
I'm constantly amazed at how fast and successfully small teams converge to a local optimization, finding a methodology for doing whatever they are doing that maximizes their interests.

Local optimization
In several recent situations I was an observer and a participant as 20 or teams of anywhere from 2 to 6 people were given the same task, given the same instructions, given the same resources, and had the same strategic goal.

What happened?

There were about a half dozen unique methods that were synthesized in real time, tested, and the most advantageous selected. What I noticed were several dynamics working nearly simultaneously:
  • Self organization: who is going to do what -- mostly, a volunteer thing as to who does what, though informed by task, skill, and capability of the team members
  • Convergence: fail quick, fix, and retry til it's working well. You can feel it when the non-value add stuff dissipates and it's all about value-add
  • Local interests: Local interests are both personal and team oriented. Each person tends to maximize their own interests to the extent that they fit in the overall team envelop; and the team optimizes to max out their contribution to the strategic goal
And the PMO?
The PMO was there to set the strategic goal; put the resources in place, having recruited the teams; and knock down the issues that were not foreseen. And, lest it not be forgotten: to provide feedback during and after -- both a real-time incentive, and a after-action atta-boy

This stuff actually works!

Not so fast! Is virtual local?
But, did I mention virtual teams?
Virtual teams have less bandwidth and so their velocity is correspondingly less.
Convergence times are greater, etc. But, the principles apply

Buy them at any online book retailer!

Wednesday, September 4, 2019

Business literacy

In a recent essay, we learn that law students are now beginning to get courses and intern experience about running a real business. How novel! People who work for money acquiring an understanding of how money is made in a business.

Business and the PMBOK?
Now, looking through the PMBOK and similar guides and manuals, you'd be hard pressed to find much from a MBA agenda or even basic accounting for non-financial project managers. I'm constantly amazed at the blank stares I get when I talk about the general ledger and the chart of accounts for the project, or the balance sheet, or the cash flow analysis. Hello! Is there anyone home?

Usually there is some sign of life when you bring up NPV -- they say: "isn't that the effect of time on money?" (Actually, not exactly. It's the effect of risk experienced over time, but let's not quibble if life is stirring)

And, education is free!
And, there's actually no excuse anymore. You can find free downloads of ebooks of the dummies' guide to an MBA.

Or, gasp!.. go to a library.

Actually, in the downtown City of New York public library I recently observed that the reading rooms were full of young people staring at Mac's. (Off axis question: why are there no PCs in the reading rooms?). In fact, the NYC main library was about full... just sayin': people use libraries.

And, of course, talk to your finance-and-accounting person... I'll bet they'll explain the Chart of Accounts for your project quite readily

Let's banish business illiteracy!

Buy them at any online book retailer!

Sunday, September 1, 2019

About choice

I've been working on a couple of projects with my wife.
From her I get this little item in a text:

I wasn't laughing... honestly!

Buy them at any online book retailer!

Thursday, August 29, 2019

Approaching team burnout

Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

Formula  solution
Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like that lend objectivity to the process (not playing favorites, etc). Note: more on this in the "6x2x1" model discussed last

Productivity drop
Of course, the real issue is one that agile leader Scott Ambler has talked about: the precipitous drop in productivity once you reach about 70% throughput capacity of the team. Up to this point, the pace of output (velocity) is predictably close to team benchmarks; thereafter, it has been observed to fall off a cliff.

Other observers have put it down as a variation on "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . In this case, it's too many people on the team with too many interferences. It's been observed that to raise productivity, reduce staff!

Wave bounces
In the physics of wave theory, we see the same phenomenon: when the "load" can not absorb the energy applied, the excess is reflected back, causing interference and setting up standing waves. This occurs in electronic cables, but it also happens on the beach, and in traffic.

Ever wondered why you are stopped in traffic miles from the interference while others up ahead are moving? Answer: traffic load exceeds the highway's ability to absorb the oncoming cars, thereby launching reflections of standing waves that ebb and crest.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference. Like I said: the way to speed things up is to reduce the number of teams working and the number of staff applied.

WIP Limits
In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity.

Sometimes the problem arises with sponsors: their answer is universally: Throw more resources in, exactly opposite the correct remedy

6x2x1 model
One of my students said this:
"Daniel Pink  has an excellent book called Drive, the surprising truth about what motivates us. In the book, Pink talks about inspiring high productivity and maintaining a sustainable pace.

One of the techniques is the 6x2x1 iteration model. This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

You can also run a 3x4x1 model for four week iterations. Proponents of this approach have observed that the development teams will often tackle tough problems, implement significant improvements and generally advance the project during these free play periods. Without the time crunch to complete the story points the team also refreshes itself."

I don't know, but Pink's thesis may have been the genesis of the Google and Microsoft "time off" plans I've already mentioned, or maybe the experience of those plans found their way into Pink's thesis. Either way, time off matters!

Buy them at any online book retailer!

Monday, August 26, 2019

Mistakes? What, me?

Some say that an enlightened business/agency/enterprise is one that provides the freedom to make mistakes. Quantmleap had a posting on this very topic.

Perhaps... But, I don't agree with the broad idea that we need to allow for and accept mistakes. Mistakes are only tolerated up to some point, then ....

If you're working your own money, then you're free to make mistakes. But, if you're working with other people's money (OPM) it's all together a different situation.

Take a risk
This idea about mistakes should be more narrowly drawn, to wit: we need the latitude to take risks --some of which may not work out -- that are within the risk tolerance of the enterprise. How do we know what the tolerance limits are? We can ask, or by experience and intuition we learn/know the boundaries.

Risk evolves
Here's the tricky part: risk attitude is not stationary: it matters when you look at it. Over time, optimism abates; pessimism rises. And, prospect theory tells us that risk attitude is different if you are facing a choice between bad or worse or between good or better.

So, it matters when the mistake is made (temporal dependency) and matters whether or not a mistake was made trying to avoid a really bad outcome (utility dependency)

We also need the latitude to make tactical errors (mistakes in some cases or calculated risks in others) so long as we don't make a strategic error. That is, we can be wrong tactically so long as we can recover and get back on a track toward the strategic objective. But to make a mistake on the strategic objective is almost always fatal.

We should also be mindful that -- even with the latitude allowed for these classes of mistakes or errors in assessment or even judgment or risks gone bad -- the cause or causality of the mistake is material. Negligence will never be tolerated; so also duplicity, though innocent ignorance may be ok.  Thus, the same mistake (effect) with different cause may be tolerable, or even thought to be a good bet that didn't work out.

Consequently, as in all 'rights', the right to make a mistake is not absolute;  as a practical matter there are often many constraints to even a liberal degree of latitude.

Buy them at any online book retailer!

Friday, August 23, 2019

Getting it done

"Others may have plans; I have deadlines"
Amy Klobuchar
This sentiment has been expressed in other forms, most famously by many:
  • Plans don't survive first touch with reality
  • Plans are nothing; planning is everything
The big idea:
Plans are the process; outcomes are the value.

Manage with milestones
Detail planning is good -- it brings out the interdependencies and sequencing demands. But such attention to detail is inefficient, even counter-productive during execution. Much more better in my experience to manage to milestones, which is, in effect, "managing to deadlines".
The point of projects is to create value. 
Ultimately, the plan is project detritus; the outcome is the only lasting memorial to success

Buy them at any online book retailer!

Tuesday, August 20, 2019

Think for yourself?

"Don't take a [drink of] the Kool-Aid when you don't know the flavor"
Cory Booker

In other words:
You may like what you hear; just be sure you understand what it is you like

Buy them at any online book retailer!

Saturday, August 17, 2019

Project narrative

Agile leans heavily on the idea of "the narrative" or "epoch"; other methodologies speak of strategic outcomes and value statements. In any form there is the inference of "the" narrative, as though there is only one arching aiming point for the project.

Not so fast!
Not all might agree; alas, there might be (are you ready for this?) disagreements regarding the value statement, narrative, or needed outcomes

"But seeing our disagreements through the lens of narrative might get us closer to a crucial insight -- which is that in a big, diverse, and complicated [project], multiple narratives can be true all at once"
Ross Douthat
Political observer
Likely true, but what do we do with it? 
For one thing, if the word "narrative" is understood to be "agenda" in some circumstances, then the first thing to do is to separate the "agenda narratives" which are largely political from the "functional narratives" which are more traditionally aligned with the scope-resource-schedule-quality drivers.

Each narrative class has its own (balanced) scorecard and project balance sheet: outcomes balanced by resource and risk

Who's in charge?
In the beginning ....
In the beginning, the agenda (read: political) narratives may be supreme:
  • Buy America first
  • Buy best value, or buy best price?
  • Be first!
  • Be dominant
 But then there are the project practicalities that push against the political agenda:
  • Buy America? You can't get them here: Most essential rare-earth minerals come from abroad, and most from China
  • Price? "My only concern is that this system was built by the lowest bidder" Astronaut
  • First is best? See: Netscape (the business model didn't work in the long term)
  • Dominance, but not at the expense of nimble (Netflix vs Blockbuster, both originally in the CD business)
Your role?
All of the above: politician (to get things rolling), and project manager (to make sure the roll is successful).
And "you" may be a small team; it's rare to get a supremely good politician and manager in the same package (See  "Ike" Eisenhower and George Marshall two of the best politician-managers)

Buy them at any online book retailer!

Tuesday, August 13, 2019

Against the Gods .... (no luck required)

If you are in the project management (read: risk management) business, one of the best books that describes the philosophy and foundation for modern risk management is Bernstein's "Against the Gods: the remarkable story of risk".

Between the covers of this "must read" we learn this bit:
The essence of risk management lies in maximizing the areas where we have some control over the outcome while minimizing the areas where we have absolutely no control over the outcome and the linkage between effect and cause is hidden from us.

Peter Bernstein
"Against the Gods: The Remarkable Story of Risk"

Knowledge and control
Picking apart Bernstein's "essence" separates matters into control and knowledge:
  • We know about it, and can fashion controls for it
  • We know about it, and we can't do much about it, even if we understand cause and effect
  • We know about it, but we don't understand the elements of cause and effect, and so we're pretty much at a loss.
Of course, Donald Rumsfeld, in 2002, may have put it more famously:
" ....... because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know."
No luck
So there is an ah-hah moment here: if all things have a cause and effect, even if they are hidden, there is no such thing as luck. (Newtonian physics to the rescue once again)

Thus, as a risk management regimen, we don't have to be concerned with managing luck! That's probably a good thing (Ooops, as luck may have it, if our project is about the subatomic level, then the randomness of quantum physics is in charge. Thus: luck?)

Indeed, our good friend Laplace, a French mathematician of some renown, said this:
Present events are connected with preceding ones by a tie based upon the evident principle that a thing cannot occur without a cause that produces it. . . .
All events, even those which on account of their insignificance do not seem to follow the great laws of nature, are a result of it just as necessarily as the revolutions of the sun.

Buy them at any online book retailer!

Saturday, August 10, 2019

After that, we had systems!

I was reading Matthew Squair's course materials on System Safety Fundamentals when I came across this slide:
"Life was simple before World War II. After that, we had systems."
Rear Admiral Grace Hopper (USN)

You've got to smile at that witticism!

The Admiral Dr (*), of course, is credited with leading the team that developed the first linking complier that led directly to COBOL.

But she had a fierce wit
Perhaps she is best known for inventing the system "bug" when she literally found a dead bug in in an inoperative computer system.(**) She retired from the Navy at age 79 in 1986 after serving about 50 years.

About risk, she is quoted "Ships are safest in port, but that is not what ships are built for"

And, of course, she is famous for demonstrasting that a nanosecond is the time taken for electrical signals to travel about a foot. She was known to carry a bundle of 'foot-long' "nanoseconds" to her classes in computer science. Watch here for her demo.

(*) PhD, Yale, '34 Mathematics
(**) a mix of lore and truth

Buy them at any online book retailer!

Wednesday, August 7, 2019

Value stream mapping -- new or old?

Value stream mapping seems to be a new label on old wine. But nevertheless, the wine ages well. In the "old days", we simply called it process mapping.

Value stream mapping derives from the Lean community, where of course the focus is on leaning out non-value add. So, in value stream mapping, each activity, to include the workflow of authorization and other governance, and ancillary activities, like a trouble report or a status report, is evaluated for value-add.

Some call it "de-cluttering". Don't hang onto the stuff you really aren't going to use.

And, of course de-cluttering the non-value add begs the question: what is value-add?

There is an answer, of course, but it may take a bit of customization to make it work everywhere. Simply put:  
Anything that is ultimately delivered to the customer, or contributes to making the customer deliverable a good thing in the customer's eyes; anything that makes the customer more successful; and anything that gives the customer the willingness and capacity to pay.

A lot of project and business stuff would not fit this definition directly. Nevertheless, most practical organizations can't live without them, so there's a certain non-value overhead that goes along with everything.

Clarity of diagramming
One thing I do like about value stream mapping is the clarity of the diagramming. Take a look at this diagram:

If you're interested in more, this diagram came from a nice post at LeadingAnswers

Buy them at any online book retailer!

Sunday, August 4, 2019

Who said 'hybrid Agile'?

What's the hybrid thing?
It's agile coexisting in the same project with a traditional methodology, presumably for the swim lanes that are not software.
Some call hybrid agile as: agile in the waterfall

Are hybrids practical? After all, the traditional is top down planned, most requirements up front, much system testing at the end, etc. Agile is the not-traditional. Can you fashion a hybrid out of these two?

Actually, hybrids are very practical, if one internalizes the "hybrid operating principle"

Hybrid Operating principle
Agile projects are simultaneously strategically stationary and tactically iterative and emergent

I mean by “strategically stationary” that:
  • Whenever and wherever you look, the project has the same strategic intent and predictable business outlook.
  • Strategically stationary is not unique to agile, of course -- traditional methods actually impose stationariness, and business planners do also.  
Strategic intent is what is expressed by the business for the opportunity and vision of the project.
Strategically predictable business outlook
is the outcome that is expected of the project, typically expressed as the mission, but also found on the business scorecard.

I mean by tactically iterative and emergent that:
  • Flexibility is delegated to development teams to solve issues locally;
  • Teams are empowered to respond to the fine details of customer demand while respecting strategic intent in all respects; and
  • Teams are expected to evolve processes in order to be lean, efficient, and frictionless in development.
And this all leads where?
The overlay of strategy with tactics

The upshot of a tactically emergent and iterative risk response is that we may find that actions in the moment are a seeming variance to the strategy—that is, the project plan. But, over time, we may take other actions that converge on the strategy. In effect, we overlay the strategy with tactical expediency at the moment.

What are these actions?

For the Agile work stream, the most common tactical move is adjustment of the iteration backlog, the repository of “stories” or use cases that are the gist of requirements in the Agile methodology. 

Another form of tactical maneuvering is the result of technical or functional debt: those small items which have been left behind on a “punch list” to be completed before the project ends.

And why are these actions taken?

Most commonly, because the customer/user sees a better way to achieve a functionality; sees an unnecessary story that can be dropped; or has been given information about a requirement, heretofore unidentified, that should be added to the backlog.

These debt may cause small changes which may seem to lead off the strategy, but more often they help to converge to the strategic intent.

Buy them at any online book retailer!

Thursday, August 1, 2019

Unintended consequences of metrics

In the online "Cross Talk -- Journal of Defense Software Engineering" for Sept Oct 2016 there is a an article entitled "Positive Influences and Unintended Consequences" by Rob Ashmore and Mike Standish of the U.K. Defence Science and Technology Laboratory

On the general topic of metrics, they make the point that generally all metrics have unintended consequences. (No news there; I think we can all agree with that. In my parlance: For every measure, there is a counter-measure. To which there is a counter-counter measure .... ) And to make their case, they cite observations by other researchers of U.K. public sector organizations that the consequences can be grouped into eight distinct types:

Tunnel vision, when management focuses on quantified aspects of performance rather than overall quality.
Sub-optimization, where narrow, local objectives are prioritized over the wider objectives of the organization as a whole.
Myopia, which involves the pursuit of short-term targets at the expense of legitimate long-term objectives or outcomes.
Measure fixation, where managers focus on the metric, rather than the objective for which the metric was developed.
Misrepresentation, where the reported metrics do not match the behavior on the ground.
Misinterpretation, where those to whom the metrics are reported make incorrect or inappropriate decisions.
Gaming, where behavior is deliberately altered so as to exploit loopholes in the measurement system.
Ossification, where an overly rigid measurement system prevents innovation.

To combat these phenomenon they introduce and explain a tool which is really just a cause-effect diagram that closes on itself -- closed loop. A "causal circle" of sorts. Read the article for more detail.

 I can't fault them on that idea. I've been preaching for years that closed loop systems are the only stable systems, and that goes for communications generally, measurements specifically.

Buy them at any online book retailer!

Monday, July 29, 2019

Critiquing behaviors

It was famously said, in a paraphrase: lead people, manage things. I buy into this advice, so I'm always on the alert for something that plays into it.

So here's a distillation of best practice for delivering criticism. And, full disclosure: the first time I really had to do this, I really screwed it up!

So, the main points are:
  • Deliver the news in person, not on the phone, Facebook, or by tweet or email!. I once had a boss (vice president) who was fired by email... so chicken-crap by the guy who sent the email.
  • Focus on actionable things to do. Seems eminently sensible to be concrete, but often you get this: A friend was told he did not have the "leadership presence" for executive office. What do you do with that?
  • Bring praise. I always try to start with praise. In fact, my advice is never come without praise. No one is a complete dolt. Seems kind of backwards to me to start negative and then wind saying: "but you do a lot of stuff well".
  • Encourage problem solving, since folks who can see a problem and get it solved always have a job; and those that can't are 'takers' for the most part and always at risk for their job.
  • Provide a model. If you're asking for change, there should be a model for guidance. Afterall, if there's no direction to change to, how is one to know where the utility lies?

Buy them at any online book retailer!

Friday, July 26, 2019

Grand strategy -- an illusion?

Every enterprise engages in strategy.
  • It's a matter of routine to some: Driven by the calendar, it's now time to do the "strategic plan".
  • To others, it's another name for how to engage with risk -- a risk might be a tactical failure, but at the same time, it could be a strategic success: The other guy won today, but he killed himself doing it.
And, of course, there is always self-interest: To be accused of not thinking strategically is a definite career limiter.

An illusion?
But, is grand strategy an illusion? I think not! But, consider these pro-illusion ideas from a recent essay on just that point:*
"It makes sense to put stock in strategy if:
  • The [enterprise] has consistent preferences, if 
  • It can assess the costs and benefits of alternative courses of action (and make decisions more or less rationally), and if 
  • It has the capacity to follow through on its strategic choices.
But [perhaps] none of this is possible, and thus strategy is an illusion .....

In the complex and highly uncertain world of [big project and big enterprise] politics, it is all but impossible to identify the ideal strategy ahead of time. The [enterprise or project] lacks full knowledge about the threats it confronts, in part because [other businesses and markets] act [in private] and in part because their interests change over time. As a result, the consequences of [strategic] policy are consistently unpredictable.

The strategizing ritual contributes to a .... sense of insecurity. Psychological blinders, moreover, make strategizing still more difficult.
  • People suffer from all sorts of cognitive limitations that hinder decision-making—in particular, a tendency to rationalize. 
  • Instead of acting on the basis of ... beliefs, we revise our beliefs to make sense of our improvisations. 
  • We avoid identifying priorities and the tradeoffs among them.
  • Moreover, businesses are not unitary actors, and bureaucratic battles impede strategic planning and consistency.
This sounds like the "noestimates" version of "nostrategy": As a result, the consequences of [strategic] policy are consistently unpredictable.

I'm not buying the thesis that not thinking about a future that has a discriminating difference with the present is somehow a good thing. Just because -- the future is unpredictable with precision and there are unknowns and unknowables that will drive us off course -- is no reason not to tackle the hard stuff

*David M. Edelstein and Ronald R. Krebsein, writing in the Nov-Dec 2015 issue of Foreign Affairs

Buy them at any online book retailer!

Tuesday, July 23, 2019

"Little Data"

"Big Data" is the meme du jour, but most projects run on "little data", the sort of data that fits into the constraints of spreadsheets like Excel. It's everyday stuff that drives estimates, scorecards, dashboards, task assignments, and all manner of project analytics.

Let's Excel
So, assuming you using Excel as a spreadsheet for doing actual calculations and data entry, you will find that you need to do some analytics and data analysis from time to time.

"Little Data" spreadsheet tools
Filters are one of the most useful "little data" tools in spreadsheets. Filter is the Excel name for the process and tool, but which the database people -- familiar with SQL for row by column -- would call a query. 

Pivot tables are another spreadsheet data query tool, but they are not the discussion today.

"Comments" -- those text annotations to a cell -- are not analysis tools, but they can be very useful regarding the context of the data. It's amazing how many people ignore adding comments to a spreadsheet.

How to filter
And so, how to do a filter in Excel, something practical for the project manager? There are YouTube clips galore on the subject, but here's a neat, step by step, illustrated process that goes from the simple to the advanced.

Just what the PMO need to get into the data business

Some other rules
Beyond what you will read in the linked article, there are a few data rules that will make life simpler
  • Every column should have a header or title that is unique, even if just column1, column2, etc
  • Only one data value in a cell. Thus, first and last names should be in separate columns; so also city and state. But maybe also captain and ship's names. This is called "normalizing" the data
  • Keep the static data in separate row/column areas from the data that changes. So, if a ship sails to San Francisco on a certain date, the ship's description goes in one area; the city description in another; but the city/date/ship is dynamic and belongs in a third area.
  • Don't put 'word processing' paragraphs or labels in the middle of the data. In other words, maintain the integrity of row by column
  • It's good to have at least one column that is guaranteed to be uniquely valued in each cell, like a row ID
  • If you can avoid using "spaces" in the data, that's good. It makes the query more sure. So, "column1" instead of "column 1"

Buy them at any online book retailer!

Saturday, July 20, 2019

Micrometers, chalk, and axes

On a recent aircraft restoration project I learned this 3-step process of mechanics (who knew? You can't make this stuff up!), which in three short statements illustrates the axiom that a process, viewed end-to-end, is not better than it's worst component, and also ...

Precision and accuracy, no matter how diligent, are wasted on the poorest resolution of the process
  1. Measure with a micrometer
  2. Mark it with chalk (in our case, Sharpie marking pens), and
  3. Cut it with an axe! (in our case, shears of one kind or another, or (gasp!) the band saw)
The high precision guess
Ooops! This very process shows up in project management. See: accuracy vs resolution and the spreadsheet -- estimates that are just a bit better than a guess (the axe) are entered into cells with zillions of digits of resolution (the micrometer). Nonsense.

Domain distortion
And, we see it as domain distortion when the defined process crowd with six sigma control limits wants to port their ideas into the domain of the one sigma program office. Again, nonsense (except for the problems defining process in six sigma that is quite portable and worthy)

Small stuff gets washed out in the big picture
It seems I'm constantly explaining why/how the precision of a estimate in a work package more or less washes out at the PMO level in a Monte Carlo simulation of all the work package effects.

Monte Carlo is the 3-step process micrometer-chalk-axe writ large:
  1. Agonize over every work package estimate (micrometer, but the WP manager does this step)
  2. Enter all the WP data into a simulation package using 3-point estimates and benchmarks (chalk, likely applied by the project analyst)
  3. Run the simulation to get the "big picture" (axe)
What I find is those in the PMO wielding the axe seem to get inordinately excited about an outlier estimate here or there. If you're the axe-person, don't sweat the micrometers!

Buy them at any online book retailer!

Wednesday, July 17, 2019

Kanban, WIP, etc

Kanban, WIP, and three others are what I frame as "five tools for managing"

I've put it together in this presentation (*):


(*) See: for all of my online stuff .... free for download, but an attribution would be appreciated

Buy them at any online book retailer!

Sunday, July 14, 2019

Soccer for 3 year-olds

Ever been to a soccer match with 3 year-olds on the field?

All go for the ball all the time; it's just a herd moving around the field (*), more or less with ball the center of attention. But, little is done except to kick at the ball. And certainly no one is ready for the breakout.

And this applies to project management how?

The best example is email with the dozen addressees. Everyone gets the "ball" but actually no one gets the ball. "Hey, everyone was supposed to do something!" But actually, no one did anything but kick it around.

It's like 3 year-olds playing soccer!

(*) field = pitch to some

Buy them at any online book retailer!

Thursday, July 11, 2019

Oceans to fly

Everyone has oceans to fly, if they have the heart to do it. Is it reckless? Maybe. But what do dreams know boundaries?
Amelia Earhart

This month we celebrate the Apollo program and the flight of Apollo 11 specifically, the first man-to-land-on-moon mission completed 50 years ago this month. (*)

Surely Apollo was our ocean of the times, 50 years ago.

And, coming only 11 years after the U.S. launch its first satellite in January, 1958 -- the so called "grapefruit" -- Apollo was certainly reckless in a certain kind of way, myriad risks taken in order to meet the timeline set by President Kennedy to get to the moon by the end of the 1960's.

(*) Launched July 11, 1969; moon landing July 20, 1969

Buy them at any online book retailer!

Monday, July 8, 2019

A historical perspective

The future may not repeat history, but it rhymes
No linearity
Another way to understand the opening witticism is that activities guided by people aren't amenable to linear -- that is, straight line -- projections and forecasts. But they are often close

Fair enough ... most would agree. Experience keeps us between the lines, as it were.

The upshot is that using the facts of history to forecast the randomness of the future requires the forecast to be probabilistic -- that is: needs to allow for a range of outcomes, subject to the biases, experience, pressures, and circumstances that inform human activity -- in the moment.

Repeat vs Rhyme
Linear projections of the past history or performance into the future usually are wide of the mark. Why? Because the very projection itself stimulates a counter-strategy. Thus no repeat!

But, projects are rarely a green field, so there are historically defined limits -- process, culture, experience. Thus, the future rhymes with the past, even if not repeated.

Project manager's mission:
Among several possible mission statements is this one (*):

The mission of the project manager is to defeat forecasts that imperil delivering expected value within the bounds of reasonable risk 
Perhaps you can see the rhyming effect of that statement .....

(*) See page 2 of this blog for a more complete explanation of the project manager's mission

Buy them at any online book retailer!

Thursday, July 4, 2019

4th of July

This office is closed on 4 July due to circumstances beyond our control
Sign on British Consulate in the USA

Buy them at any online book retailer!

Monday, July 1, 2019

Sacred but not immutable

There are a lot of project principles, and processes built on those principles, we think of as immutable: stationary--and proven--with time, experience, context.

Somewhat like the speed of light: Every observer or practitioner in any frame would see them the same way

Not so fast!

Sacred indeed! To be respected? Yes! Defaults that are best practice? Absolutely
But immutable? No.

Unlike the speed of light, Planck's constant, the G-gravitational constant, and a few others, everything else is subject to interpretation, framing, circumstances and context, and the advance of process improvement.

To be immutable in the project context is to be on the edge of denying "new physics" that might move the PMO to a more effective plane

New under the Sun
Just during my professional PM time, I've witnessed:
  • Theory of Constraints
  • TQM in multiple forms, largely abandoned
  • Critical chains
  • Agile methods
  • Monte Carlo simulations into the main stream
  • PERT dismissed
  • Iron triangles, parallelograms, and other interdependencies
  • Black Swans and other physics of the unknown (chaos, fragile systems etc)
  • Risk matrix
  • Etc

Buy them at any online book retailer!

Sunday, June 30, 2019

Agile -- what it means

Dilbert: We need 3 more programmers.
Boss: Use agile programming methods.
Dilbert: Agile programming does not mean doing more work with less people. 

Boss: Find me some words that do mean that and ask again

Dilbert is a creation of Scott Adams
And so, you might ask: what does agile mean?

How about this?

Agile means getting effective project results even in the swirl of complex and uncertain project requirements, primarily by applying small teams, working collaboratively, to deliver increments of business value, with priority according to business effectiveness, importance, and urgency
Ooops! I seem to have left out anything about process. Is agile a process-free zone? Of course not! No one does anything functionally without applying a bit of process, even if it's only two steps.

My observation -- and personal experience -- with myriad small teams is that they self organize to optimize their self interests amazingly fast, first trying one process -- perhaps a baseline process -- and then quickly shifting to another to find a "local" optimization. Sometimes there's an obvious leader; sometimes it's all for one; one for all.

When/where collaboration improves their lot, they'll readily collaborate. Where it's problematic is when collaboration demands are laid on top-down with no obvious improvement in the local process and no apparent connection to goals or objectives. If the top-down thing is legitimate, then the project leadership needs to get in the communications mode to show how all the dots connect! 

Buy them at any online book retailer!

Friday, June 28, 2019

Decisions on auto-pilot

[Some decision analysis'] have been going on for long enough that they've built up their own speed and force. ... We call them decisions, but they really aren't. [They are] the sum of so many previous events and determinations that they have a weight that feels like a layer of time
David Ignatius
"We call them decisions but they really aren't".
The worst variety of such auto-pilot decisions is trying to rescue or justify "sunk cost", to wit: we've invested so much that we can't afford to decide anything else but to keep going 

Invested in vain
"Sunk Cost" is the cost already expended for which you can't recover. It's no basis for a decision. Decisions should be made on the outcomes to be had by further investment: the ROI on the future.

Of course, easy to write this; harder to execute. No one wants to be embarrassed or fired over wasted or abandoned effort and cost. No one wants to explain a sacrifice or supreme effort made in vain

Advance in a different direction
But a Marine general in Korea, circa 1950, was heard to say (or so he was alleged to have said): "Retreat, hell! We've advancing in a different direction"

Sometimes that's the decision to be made in spite of "...  a weight that feels like a layer of time"

Buy them at any online book retailer!

Tuesday, June 25, 2019

"Open" risk management

To be open
Every text and paper I've read describes risk management like many other project processes: open, transparent, available to any on the project team. Risks are identified, evaluated, ranked, made subject to some form of risk reduction paradigm; and everyone is made aware.

Oh, but if it only were!
Most of us can handle the text book process. It's more will than capability

But, on projects of material consequence, the "real" risk management is not open
The "real" stuff begins when the text book processes have run their course

Or, not to be open
Too often than not, risks are compartmented. Sometimes "innocently" because the related work and scope are compartmented by project circumstances: security; systems partitioning; backlog partitioning; teams and teamwork; virtual teams

Judgments scorned as guesses
Only bring facts! Ooops, there are no facts about the future; only assessments of events, impact, and probability. All the facts are in the history.

No facts? Then you're just guessing, "they" say. So, "they" say: take you guesses elsewhere.

Inconvenient assessments
But, then, of course, there's the inconvenient assessments that need to be "buried". These assessments come to the wrong conclusion or forecast; they are not in accord with company or agency politics. Sometimes it just petty professional competitions

Whatever: of these we can say that risk management is "closed", not open; not transparent; and not available to all who need to know

Bummer !

Buy them at any online book retailer!

Saturday, June 22, 2019

Who calls anymore?

Who calls anymore? Some, but many fewer than before .... unless it's a robo call

It's surely not news that a lot of business communication has moved to the text and email.
Fair enough

But, that leaves much more communication open loop and unacknowledged than is/was the case with the telephone call.
That may not end well. Such open loop communications violates basic control-loop theory. To wit,
to have predictable outcomes, the loop should close on the sender as a means of confirmation of message received.

So now, as non-verbal correspondents, we have the responsibility of upping our game.
Some help is found in the essay "How to get every email returned"

From that essay and my own experience, my advice is this:
  • Keep it short!
  • Write in bullets where ever possible.
  • Don't exaggerate ... when discovered this kills your credibility
  • Don't guess; meaning: say only what you know
One troubling assertion in the essay: Emotion is more persuasive than facts.
Perhaps; it depends

I worked for a few years for a Asian company with Asian managers. Culturally, those managers put more emphasis on facts than comparable American managers. In my experience, Americans were/are more tolerant of ambiguity, uncertainty, hunches, instincts. Often, these are wrapped in emotion

One last point, circling back to closing the loop:
  • Ask for acknowledgement. Often, the "open-loopers" are unaware of the poor practice of not closing with their correspondent

Buy them at any online book retailer!

Wednesday, June 19, 2019

Understood ... misunderstood

The blog at herdingcats provided this little bit of wit:
Don't write so that you can be understood, write so that you can't be misunderstood. — William Howard Taft
Taft has a good point there:
  • Not only to be understood (meaning + context) 
  • But to not be misunderstood (meaning + context + motivations or expectations)
Not so fast!
It's often not that simple

You want not to be misunderstood:
First, for understanding, start with the three step process for communications

To be understood, steps 1 and 2:
1. Tell 'em what you're going to tell them
2. Tell them

To not be misunderstood, step 3:
3. Tell them what you told them

Second, to avoid misunderstanding, deal with these hazards:
  • Missing or ambiguous antecedents (Pronouns should be banned! Be specific with names, as example: Tom and Jerry wrote the report. But there were complaints about the analysis that was done; he should have done it more carefully)
  • Big words not commonly understood (intellectual arrogance) 
  • You've got in your head, but you don't get it down on paper (and you don't know you didn't get it down on paper)
    Typically the context or connections with prior thoughts are missing on paper.
    The best way to address this missing material: compose the words now and read them a day later .... does the wording still make sense?
You want, or can tolerate, misunderstanding by some, but not all
You don't want your intended correspondent to misunderstand, but it's ok if everybody else misunderstands, even as they seemingly understand.
  • In politics: plausible denial (everyone's favorite go-to). The words are understood, even as the intended understanding -- deliberately open to misunderstanding -- is obscure. (Make them an offer they can't refuse)
  • In security: You and I have the code for the plain text, but others see and understand the coded text differently.
    As example: Coded text, i.e. what the world understands: "Play the piano"; Plain text (what you and I really understand): "Start the process"
  • In command and control: interpretable instructions or vision. To wit: strategic wording written down, but implementing details and interpretations left to others
    (In effect, delegation to the tactician or field commander. But sometimes you let interpretation "live" with the times and circumstances [so-called "living documents"])

Buy them at any online book retailer!

Sunday, June 16, 2019

Manage the white space

You've got a team to manage; until you don't
Keeping the team together promotes cohesiveness, intra-team loyalties, and productivity (no investment required to introduce new players and relationships). But, if there's too much slack -- i.e. downtime or "whitespace" --  you might lose your team.

But, keeping you team begs the question: How to keep everyone busy all the time so as to fend off raiders looking for resources?  In the popular vernacular of project management, keeping everyone productively busy means actively managing their downtime, aka 'white space', between and amongst their planned activities.

Whitespace methodologies
In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.
  • Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
  • Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
  • So also bring in mock testing, special event prototyping, and, of course, that bane of all:
  • Maintenance of team records.
What does it cost?
One consequence of managing by teams: the cost is known, predictable, and relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each.

Affordable value
Of course, is the team affordable? Many PMs are not comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:
The cost of a project is not its value; in a "good project", value greatly exceeds cost

Buy them at any online book retailer!

Thursday, June 13, 2019

Risk: the second thing you do

Managing risk?
Can you imagine there's risk to manage?

Here's the second thing you do:
  • Evaluate the slack ... 
What's to evaluate?
  • You might think the most important thing about slack is how much is there; what do I have to work with? Nope
  • Whatever you've got, the most important thing is sequence and position. Where in the course of events are you going to position slack so that it works to your greatest advantage?
Slack makes the first thing possible
  • We all know that the first thing in risk management is loosen the coupling.
  • Slack is the mechanism for such loosening
Where to position slack?
  • At the end (of a schedule or task)
  • Between joins of physical units (if expansion allowance is necessary)
  • Wherever timing is critical
It's not to wasted
Apart from overly tight coupling, poor positioning or sequencing of slack is a resource wasted. And, it will cost you otherwise to substitute an alternate resource!

Buy them at any online book retailer!

Monday, June 10, 2019

Performance; experience; wisdom; track record

 “You do not write your life with words...You write it with actions. What you think is not important. It is only important what you do.” (*)
Patrick Ness 
What you do adds up
Getting promoted? Hopefully not to your level of incompetence!
Want to get promoted? Most do.

What's needed: a personal track record; as Ness would say: a record of what you do.
  • Personal performance over time
  • An accumulation of experience
  • Demonstration of wisdom
About wisdom and experience
Hopefully, you recognize the linkage of the last two: wisdom derives from experience, but wisdom only derives from the experiences of both success and failure
“By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest.”
About performance  
Laurie Harvey has an idea on this: KPIs for success , meaning KPIs for personal success as a project manager. In her essay, Harvey makes one big point up front:
When performance is lacking, everyone knows it; when performance is on par, it may not be noticed .... until it is.

KPIs for success
So, what's par for the PM? What goes into the personal track record?
Harvey looks at these as instrumental to a winning track record, stuff that will get noticed over time
  • Delivery according to expectations
  • Budget acumen
  • Process improvements
  • Relationships and communication
  • Risk management
  • Customer orientation
And for the MBAs among us
Harvey's list is all good stuff; all project oriented. If you're going for a big promotion, my advice: Add to Harvey's list your competence with the business side. A good place to start is the Balanced Scorecard -- Measures that Drive Performance. But that's another story.

(*)  Another way to express Ness' idea: Be consequential!
But consequential actions could be writing (consequential writing is an action, in spite of Ness').

Buy them at any online book retailer!

Friday, June 7, 2019

The core of knowledge

... statistics is what tells you if something is true, false, or merely anecdotal; ... it is the instrument of risk-taking
Statistical and applied probabilistic knowledge is the core of knowledge;
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.

Statistics in the PMO
Two of the more useful properties of statistics are these:
  • They are are surrogates of a past track record; thus, handy for estimating
  • 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. Thus, your story doesn't change with time, an idea called "stationary".
Rules of thumb
For project purposes, rules of thumb may be as useful as actual statistical analysis:
  • There's shift-right bias at milestones; milestones are inherently weak objects in the schedule
  • Diversification follows the "square-root-of-N" rule: diversify into 4 independent events, and get a 2:1 improvement in risk (square root of 4 is 2)
  • "Expected value" -- which is a risk weighted average -- is usually more pessimistic, and therefore more conservative, than "most likely" value" (the single value with highest individual probability)
  • "Expected utility value" is not objective, and subject to many biases (utility is a weighting according to usefulness)
  • 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

Buy them at any online book retailer!

Monday, June 3, 2019

Showing confidence

Making a presentation?
Speaking to a large group?

Are you confident?
Yes? Good show! Hopefully, your audience will think so also.

Mike Clayton has a helpful posting about behaviors during your presentation that will go along with projecting confidence to your audience. Helpfully, Clayton says it takes less than 2 minutes to read it.

Here are two ideas I like, especially the first on about hands. I've personally made that a "must do" and its proven very helpful

Keep them still. Fight the fidget. Take everything out of your pockets (if you have them) to avoid the temptation to play with them. And if there's nothing in your pocket - don't play with it.

Slow down. Nervous people hurry. With speakers I also talk about the power pause, to get and hold attention.
TED-talks: See this stuff in action. View some TED-talks and watch for the confidence projection techniques. You'll find Clayton's advice is universally practiced.

Buy them at any online book retailer!

Friday, May 31, 2019

Project Bulls**t

Many fine books have been written about 'bull' and its excrement, 'bulls**t' (*). Indeed, such may go back to at least the 17th century, if not before, as written into plays and documents of the era.

And so, is it any surprise that, four centuries on, many in the PM profession pride themselves as good bulls**t detectors, having the cultural training to recognize such that comes from a lifetime of exposure and experience?

Indeed, no less an eminence than Harry Frankfurt, a distinguished moral philosopher and professor emeritus at Princeton has been quoted (**):
"One of the most salient features of our culture is that there is so much bullshit"

Lies vs bulls**t
But here's the important matter: project success depends on trustful and trusting relationships -- no news there -- and trust, in turn, depends on a track record of truthfulness. Amen to that, to be sure.

Can the bulls**ters be trusted? Are they truthful?
And, in the same vein, what of the liar?
Distinctions without a difference?

Not the same! Not so fast!
If we can pretty well detect bulls**t, and see through to the truth, is there any real harm done?
What about lies?

Frankfurt goes on (paraphrasing):
The essence of bulls**t is that it is produced without concern for the truth. Indeed, it need not be false, even though the perpetrator is faking knowledge (a stopped clock is right at least twice a day). That is, the bulls**ter is indifferent to the truth .... could be right; could be wrong; doesn't care.

The liar, on the other hand, has a very good handle on the truth which he/she purposely tries to hide or obfuscate. Indeed, the liar is quite sensitive to the truth, not indifferent, and wants to lead us away from it.

Caring or not caring
The liar cares deeply about the truth; the bulls**ter doesn't. At the end of the day, who is the greater threat? Frankfurt would have you believe it's the bulls**ter; I'm not so sure.

The bulls**ter, once identified, can be written off to exaggeration, but not willful deceit.
The liar is willfully deceitful.

In my PMO, if I have the insight to choose, I'm going to take the bulls**ter. My idea is that perhaps there is useful person to be rescued, untainted by a willful disregard for truth.
(*) "On bullshit" by Frankfurt (2005); "On Lying" by St Augustine;  "Your call is important to us; The truth about bullshit" by Penny
(**) Essay: "Say Anything" in the book "When Einstein walked with Goedel" by Holt

Buy them at any online book retailer!

Tuesday, May 28, 2019

Mystery, secrecy, and privacy

This blog is not about politics, so we'll keep to the knitting and wax on about mystery, secrecy, and privacy in the project management domain.

For today's screed, I took a few thoughts from an unlikely source of PM advice I found in an 2013 article by Jill LePore entitled "The Prism" (a term in the news of that time)

I, for one, had not thought a lot about the subtle but substantive differences of our three title terms insofar as they have their individual effects on governance, understanding, communications, and perhaps even innovation.

By Ms LePore's reckoning, we can divine the following:

  • Mystery is knowledge held by a very few, perhaps only one -- the project's "Almighty" -- with the intent of creating a mystique around the idea or the individual. In other words, the mystical knowledge has no overt operational purpose since it is never to be revealed on acted upon. It's all about aura and mystification.

    Politicians love mystery and mystique, isolating them a bit from challenges. Autocrats love mystery too: mystique amplifies power. And, believe or not, the marketing department loves mystique -- mystique sells!
  • Secrecy is the way we compartmentalize knowledge intended to be acted upon and drive operational outcomes -- but only by a selected few actors.

    For whatever reason, secrecy can move the project forward when otherwise acting in a fishbowl with this knowledge is judged to be ineffective... some will be inhibited from full discourse; others embarrassed to show weakness or ignorance; and some will use the information against us.

    In business, secrecy often goes by the name "proprietary". In projects, to take one example -- but there are many legitimate examples -- competitive proposals are always held secretly from the competition.

    And, the flip side is that if your project is in receipt of proposals from vendors vying for your business, then you need project protocols to protect their competitive secrets.
  • Privacy is about our own stuff, our own thoughts, and our own biases that we can live with but choose not to share. Although we are social in our relationships, everyone needs their moment and place of privacy.
    (See: issues with open space project space)

    Of course, sometimes privacy crosses over into a personal secrecy to compartment things you are doing. That's where the trouble begins because governance, understanding, communications, and perhaps even innovation are surely threatened by personal secrecy just as official secrecy can have debilitating effects.
Bureaucracy begets mystery
Mystery accumulates around bureaucracy, whether intended or not. The larger the structure the more mysterious are those in the head office -- including, by the way, the PMO. Open door policies and other communications are partial anecdotes, but the real anecdote is a flat organization.

Mystery can be a tool
On the other hand, companies exploit mystery to create an aura in the marketplace and enhance their competitive posture, especially on competitive project proposals. Every proposal I ever led had a marketing guy attached whose job was not only to develop information on the competition but also to create mystery in the marketplace -- scaring the competition and attracting the prospective customer.

Secrecy requires definition
Secrecy is about deliberate compartmentalization. And "deliberate" is the operative term. To be deliberate requires definition in advance of the criteria to invoke compartmentalization. In some domains, the requirements and definition come by contract and are imposed on the project. But there's also a lot of proprietary activity -- see pharma R&D for instance -- where corporate secrecy abounds.

Privacy is a late comer
In the genealogy of these things, privacy is a late comer. As mystery became less religious and more secular as Europe exited the Dark Ages, privacy in personal affairs became more of a main stream idea. But in the United States, it did not acquire a legal definition until late in the 19th century. Now, projects have to address privacy issues left and right, and with all manner of cultural and geo considerations. And, the culture of privacy is a shifting ground, so projects are always in a demand-driven mode vis privacy requirements.

In some respects privacy is a wicked requirement: circular, no apparent point of entry, and self conflicting in many respects. No small matter as you try to contain scope, cost, and meet milestones!

Buy them at any online book retailer!