Wednesday, November 13, 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!

Sunday, November 10, 2019

Thoughts on "change"



I ran into a blog item on change the other day, at a blog site called Rule of Thumb.

The posting entitled "The Change Curve", depicts a project management adaption of the change model proposed by Elisabeth Kubler-Ross in her book "On Death and Dying" when she described the "Five Stages of Grief"

Rule of Thumb proposes this adaptation for project management of the Five Stages into these six ideas:

•Satisfaction: Example – “I'm happy as I am.”
•Denial: Example – “This isn’t relevant to my work.”
•Resistance: Example – “I’m not having this.”
•Exploration: Example – “Could this work for me?”
•Hope: Example – “I can see how I make this work for me.”
•Commitment: Example – “This works for me and my colleagues.”

Of course there are many other models of both change and change resistance. One useful model of change (not change resistance) is by Kurt Lewin; I like it because it's similar to Deming's PDCA (plan, do, check, act). Lewin's model is three steps:
  1. Unfreeze previous ideas, attitudes, or legacy
  2. Act to make the change
  3. Freeze the new way in order to institutionalize the change.
And, A.J. Schuler, a psychologist, has his 10 reasons about why change is resisted in a paper entitled "Overcoming Resistance to Change: Top Ten Reasons for Change Resistance". His lead-off idea is "doing nothing" is often perceived as less risky than "do something"--in other words, Plan A (do nothing) trumps Plan B (do something). 

But the one I like is that people fear the hidden agenda behind the reformers ideas! Amen to that one.




Buy them at any online book retailer!

Friday, November 8, 2019

Backlog management



Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling the culprit

Coupling? Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.
  • Loose coupling: there is some effect transferrence, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
  • Tight coupling: there is almost complete transferrence of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost none is lost flexing the frame.

In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.

The most common remedy is to buffer between effects. The effect has to carry across the buffer. See Goldratt's  Critical Chain method for more about decoupling with buffers

But buffers may not do the trick. We need to think of objects, temporary or permanent, that can loosen the coupling from one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in environment A without strongly influencing environment B; this is sort of a "us vs them" approach, some might say stovepiping.

Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:
  • Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
  • Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.
Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!




Buy them at any online book retailer!

Tuesday, November 5, 2019

Communication, communicating


"They" say that the three most important tasks of project management are:
  1. Communicate
  2. Communicate, and
  3. Communicate
To that end, I recently had an opportunity to try out my skills. My neighbor, a very nice young woman, had to travel on business and asked me to keep watch on her cat.

After a few days she called from the road to check on the cat:
She asked: "How is Millie doing?"
I responded: "Millie is dead"

A pause

She scolded: "You could have let me down more easily; you could've said Millie is on the roof. 
Then later you could tell me she fell off the roof and died"
With contrition, I responded: "Yes, I was insensitive. A lesson learned, to be sure"

A pause

She asked: "And, how is my mother?"
Confidently, I responded: "She's on the roof!"



Buy them at any online book retailer!

Sunday, October 27, 2019

Sometimes, you have to fire your client



Are you an independent practitioner? In the US, 1/3rd of the workforce are independents. An amazing proportion to my way of thinking.

One of the advantages -- and at the same time, one of the hazards -- is that you get to fire your boss; and, you even get to select your boss.

This essay gives a few pointers for the newbie independents -- know when to hold'em; know when to fold'em. You know you've got a bad client when:
  • They try to set up the deal at 10pm at night or a weekend... unless you want to work 24x7
  • They say it's an easy job they can do themselves.. unless you want to be micromanaged
  • They want to talk about themselves instead of the job task... unless you want to be their counselor
  • They say they've tried to get the job done with many others, and they all failed.. so might you!
  • Rude, insensitive behavior.. unless you like the bad-ass type
  • Those that ask for a miracle, or an unlimited commitment.. unless you give up your independence

One suggestion is to beef up the contract; guard your intellectual property rights (something I really pay attention to) and get a non-refundable down-payment. That one has been a sorting parameter for me. Don't forget the non-poaching clause: your client shouldn't have the freedom to hire your staff.

What's the right wording: "We're not a good fit", or "This job is not a good fit for my skills" (I use that one a lot)

And, if they really insist you take the job, add on a premium for your anticipated trouble!



Buy them at any online book retailer!

Wednesday, October 23, 2019

Agile down the ages



In the beginning, there was pre-history Agile, almost prehistoric era:
  • Before 2000 and the meeting in Utah that birthed modern Agile
  • Rogue developers trying various "light weight" and "rapid" prototyping and coding practises. In the SEI world, a ghastly level 1 operation of different strokes for different folks
  • Everyone else slaving to command and control -- SEI maturity model uber alles!
And then came the 'our way or the highway' era
  • Passionate, almost hysterical, disciples of the paradigm handed down from the Utah mountain
  • There is no God but the one Agile God
  • "You just don't get it" if you question us
  • Push back from the money crowd: "I'm not going to put money into something that has no plan"
And now, the common sense era
  • Distinguished Agilists are writing and coaching for the real world where every sprint does not put code into production (shocking!)
  • Every deliverable with value is not necessarily code (imagine! other stuff has value-add)
  • You're actually allowed to not have a retro session after every sprint; some stuff does not need to be completed after every sprint
  • The product owner and customer/user can be surrogates for large organizations
  • Plans can be drawn, and a business case for the money guys!
  • Stories can be detailed out as requirements
What will they think of next?


What more on agile? Available now! The second edition .........



Buy them at any online book retailer!

Sunday, October 20, 2019

Need help with Monte Carlo analysis?



For many years, I've preached the benefits of the Monte Carlo simulation (MCS). For many reasons, it's superior to other analysis paradigms. In network analysis, for instance, it handles the parallel join or 'gate' as no other method will.

In fact, it's this very capability that renders the Monte Carlo superior to other risk adjusted ideas, like the PERT method in scheduling. PERT suffers from an inability to handle the 'merge bias' at gates because PERT does not handle the mathematics of multiplying distributions (required at gates); PERT only provides a means to calculate a statistic for each task.

Architecturally, gates are the weakest construct in schedules, so any failure to handle them is a show stopper in my mind



I get questions
But, my students ask me invariably: how can the MCS be any better than the 3-point estimates that go into it; if the 3-pointers are guesses, isnt' the whole MCS thing just a crap shoot?

And, the second thing they ask is: who's got the time to triple the estimating problem (from the most likely single point estimate to the trio of optimistic, pessimistic, and most likely) especially in a network of many hundreds, if not thousands, of tasks?

My answer is this: it depends; it depends on whether or not your are the work package leader concerned for a handful of tasks, or the project manager concerned for a network of hundreds (thousands in some cases) of tasks.

If the former, then you should not guess; you should take the time to consider each estimate, based on benchmarks, so that each estimate is has some auditable calibration to the benchmark.

But if the latter, then let the Central Limit Theorem do the work. A few bad estimates, indeed a lot more than a few in most cases, have negligible impact on the MCS results. In other words, the good, the bad, and the ugly tend to cluster around a central value--a phenomenon called central tendency. Thus, at the PM level, you can live without completely solid calibration. Only a few estimates need to be pretty well thought out vis a vis the O,P,ML triplet.

Calibration?
This may sound like heresy to the calibration crowd, but as a politician recently said: arithmetic! Actually, calculus is the better word, since we have to deal with functions. And it's calculus that gives us the tools to understand that a few bad estimates, even really bad estimates, are largely discounted for effect by the integrated effects of all the other estimates. So, let's not get uptight about a few bad eggs!

Nevertheless, to do a MCS, you do need estimates of O, P, and ML. Where do they come from?  All the tools allow for defaulting in a trio to every task. Is that a good idea?

Here's my counsel:
  • Take the time to estimate the most likely critical path. The MCS tool will identify other near-critical paths, and may even find an alternate path that is critical (not the one you thought)
  • Establish, in the risk management plan, a policy about the defaults values (for % of ML)
    The policy may have several elements: hardware, software, administration, and process tasks. Each of these will have hard, medium, and easy tasks.
    The policy can be a matrix of O, ML, and P defaults for each (Example: for hard software, the policy is to estimate O = 80% ML and P = 200% ML).
    These generally come from experience, and that means from actual results elsewhere, so the defaults are not just picking values out of thin air....there's usually back-up




Buy them at any online book retailer!

Thursday, October 17, 2019

Fidelity



Fidelity, faithfulness, and commitment often seem to be the tension between:
  • What the customer/sponsor/user want, and
  • What the project charter/scope calls for.

Why so? Why isn't it straightforward? The business case begets the project charter; the charter begets the project plan; and then the project team is off to do the deliverables. Simple, right?

Wrong!

It's never that simple -- though on paper that's the way it should be.

What is reality is a challenge between "fidelity to user expectation" and "fidelity to user specification".

Expectation v specification. How to manage this? First, it's should always be a decision and not just a consequence of wandering off track; and second:
  • If you have the latitude to shift "loyalty" from specification to expectation, you are in what the community generally calls an "agile" environment.
  • If the decision process takes into account expectation as well as specification, then both of these should be on the list of "inputs" to the decision. And,
  • Indeed, there may be two decisions, one for each criteria, with the customer as the referee: does the customer want to honor the spec, or shift to expectation? (Does the customer have the latitude to make this decision?)
Keep this thought close by: what is really at stake is a "best value" outcome: "the most useful and important scope that's affordable."



Buy them at any online book retailer!

Monday, October 14, 2019

Kill the messenger?



The messenger: “Unfortunately, my King … here I am, unwilling and unwanted … because I know that no one ever welcomes a bearer of bad news.” —Antigone by Sophocles, circa 442 BC
 
The surprise: “It is pardonable to be defeated, but never to be surprised.” —Frederick, the Great
Who's listening?
Pedro C. Ribeiro, writing in NASA's ASK magazine, has a nice posting on risk perception. He reports on a study that tells us that nearly 3/4ths of all those that report a risk condition to the PMO feel as they are not heard or listened to.

The messenger of bad tidings is not welcome! Hello! No news there, to be sure!

Failure of leadership:
Postmortem analyses, inquiries, and audits of failed projects often uncover streams of unheeded warnings in the form of letters, memos, e-mails, and even complete reports about risks that were ignored, past lessons not learned, and actions not taken—a failure of leadership that creates the conditions for a “perfect storm” of problems that could and should have been prevented, but nevertheless catch leaders by surprise.
Who's to see?
Remember: even Nassim Taleb defines a black swan from the eye of the beholder. What's a calamitous surprise to some may be foreseeable to others. 

So, even though the PMO may not be able to see around the next corner, they may be some with extraordinary powers of sight that need to be listened to. Ignore them at your peril!


Buy them at any online book retailer!

Tuesday, October 8, 2019

Beware common sense!


This bit comes to us from Neil deGrasse Tyson from his book "Accessory to War"
"What separate great scientists from ordinary scientists ... is the capacity to .... not let common sense dictate or constrain their thinking.

The formidable English physicist Issac Newton, for instance, questioned the the fundamentals of light and color. Who in their right mind would have thought that ordinary light -- white light -- was composed of colors at all?"
In contemporary parlance, this is "thinking outside the box", a meme of behavior and mindset which Tyson might have us believe separates the really good from the only adequate.

Of course, there is a case for "only adequate" which probably describes the bulk of practitioners since the truly gifted and great are out on the tails, as it were. "Only adequate" gets us safe and sturdy, risk averse, tried and true, and free of controversy. The ball does not advance very far, but then it's not supposed to.

On the other hand, "only adequate" isn't going to get you "E = mC2" and all the rest. If you are going to try to convince the world of space-time warp, best to avoid common sense!



Buy them at any online book retailer!

Saturday, October 5, 2019

Percent complete -- Boo!



Perhaps I've said this before. I certainly intended to. But, percent complete is a worthless metric

Not a value measurement:
Percent complete is a ratio. The ratio is dimensionless, whereas value has a dimension; it can be measured.
Percent complete is not only not a measure of value completed; it’s really not even a measure of completeness, even if some things are "completed" at less than 100%.

I say this because, as a ratio, both the denominator and numerator are in play. Thus, “percent complete” is a moving baseline.

What about Agile?
In the Agile space, percent complete is replaced entirely with “remaining effort”. In other words, the Agile management focus is on three questions:

  1. How much do I have to do—to wit: backlog for the iteration, release, or project
  2. How much have I done already—backlog burned and done, and
  3. How much do I have left to do? Note: how much left includes the WIP.

Since the backlog is dynamic—some new things added, some things abandoned, some things left over as debt from prior iterations—you can see that percent complete is meaningless.

The backlog at any given moment is the denominator (burned, WIP, and not started); the numerator is the backlog burned. Both numerator and denominator change from moment to moment, rendering the metric useless for management purposes.



Buy them at any online book retailer!

Wednesday, October 2, 2019

Excel is watching you!



If you've ever managed a project with a really large data set, say the payroll for a bunch of 1099 developers, or the sales records that you're trying to translate and import to a spreadsheet, you may need to watch a couple of important cells to let you know what's really going on:
  • Summary totals; 
  • error codes; 
  • record totals, etc. 
Excel gives the PMO a convenient tool in the Watch Window, found on the tool ribbon with Formulas/Formula Auditing

To use it, just open the watch window by clicking the icon, then click on Add Watch in the Watch Window, and then select some cells.

Thereafter, every time you click on Watch Window in the Formula ribbon, it brings up your list with the latest values. My only irritation with the functionality is that the change is not time tagged. Nonetheless, pretty convenient to use.



Buy them at any online book retailer!

Sunday, September 29, 2019

Your first project as PM


You've done a lot of projects as member of the project team, but you've never been the PM
Now you are one
And your first thought may be: "What do I need to know, and why do I need to know it?"
  • If I gather a bunch of data about what is going on, what do I do with it?
  • Didn't someone say: Don't measure what you are not going to manage?
  • And, very likely, someone said: Don't manage what's not important (or, meant to say: let the self-managing stuff manage itself)
How's it going?
I remember being asked early on: "How's it going?"
And my first thought was: what do you mean?
And, my second thought was: shouldn't I know what is meant by "how's it going"? And, gasp! how do I measure it? (Assuming I knew what "it" is)

Milestones are everything
If it's a big project, you may have an administrator or a team of administrators working schedules.
Yea for them!
Your job is to work value-milestones
  • What are the big chunks of value that need to be ready when
  • No one will long remember the details; but they will remember if you hit the big milestones, rollouts, and put value on the line as promised.
  • Even cost will be forgiven as a tactical necessity if you get the value-milestones right
What to measure and manage
And so, it comes down to barriers, inhibitors, risks, resources etc that will make or break a milestone.
That's the answer you should give to "how's it going" which is really "how's it going to the next milestone?"

Milestones are not self-managing; that's where you job comes in. Figure out what you need to measure to determine if you're going to make it, and then go measure it! From the data, determine a course of action to correct -- or maintain -- the path to success.

 


Buy them at any online book retailer!

Thursday, September 26, 2019

Talking to not strangers


Here we go again; another of those bits about how to talk and listen. To wit: a conversation!
This one's on TED Talks: "How to have a better conversation".

Naturally, to have a conversation you have to be in the conversation. But with everyone staring at screens all day, and text more popular than talk, it's no small matter to actually have a conversation the old fashioned way: actually paying attention to another person, responding in a two-way conversation.

I heard the TED person say this, which somehow captures the idea:
"You don't need to learn how to pay attention if, in fact, you're paying attention"
Meaning, of course, that paying attention comes naturally if you're actually doing it; and if you're not, it's quite evident to the other person in the conversation.

And, here's another thing: it takes two to converse, but sometimes the least said the better.
Calvin Cooledge (former US President if you're not sure who that is) is quoted:
No man listened himself out of a job
 Meaning, of course, that a conversation where you are saying stupid stuff is probably not the conversation to have, even in text form

And, for the metrics among us, we are told:
The average speaker speaks 250 words per minute, but we are capable of understanding at twice that rate
Question: what are you doing with the whitespace? Mulitasking? Or, as Covey would have us do: listen with the intent of understanding

A good conversationalist is always prepared to be amazed! 







Buy them at any online book retailer!

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?
Perhaps
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"
Perhaps.
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" wikipedia.org/wiki/F._W._Taylor

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.

Ooops!
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 ....

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

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

Absolute?
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
 Senator
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
Senator

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.

De-clutter!
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!

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 slideshare.net presentation (*):



_______________

(*) See: slideshare.net/jgoodpas 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
Anonymous
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!