Command vs Comment

---

Now, the word 'command' is probably a no-no among many. It's all about synergy and shared commitment, etc.

 

Maybe

On projects of any scale, and businesses of scale, there are people 'on the commanding heights', in a command situation, and with command responsibility. Don't believe it? Check in with the C-suite and see what they say.

 

So, that said, we arrive at today's topic: Commands and-or comments. Which is which is sometimes vexing, but does it matter?

 

Actually, Yes, it can matter a lot. Consider some of these situations and outcomes:

• A PM is not promoted for lack of 'command presence'. What is that? See below.
  
• 'Commands' are given (in the civilian world) but for lack of follow-though  the permanent bureaucracy all but ignores them
• A casual comment is understood -- in context -- to mean "get it done"
• A casual comment is misunderstood to be a command, when it reality it was just a casual comment

So what's going on here?

Command presence: You know it when you see it. A confident aura that invites -- rather than demands -- followership. Obviously, no empty suit!

Sloppy communication. The "one in command" is careless about a comment, not understanding or observing the reaction that surrounds it

Underlings too eager to please. These guys make the most of reflected and proximate power -- power and authority absorbed simply because they are in close proximity to the throne.

Bureaucrats understand the impracticality or incompleteness of the command.  And so it is ignored or modified on the spot. Actually, this is a very common consequence of "flow down of goals and objectives" and also of assuming operating detail will be filled in below by the people who actually have to do the work.
So, don't be surprised to see how a command actually materializes!

---

Buy them at any online book retailer!

Throughput accounting: pushback

---

 

Whenever I write about or talk about 'throughput accounting' I get pushback.

Fair enough.

You won't find such accounting in your Accounting 101 textbook, except perhaps in a chapter dedicated to cost accounting wherein the concept of 'variable cost' is discussed.

But 'variable cost' doesn't quite capture the concept:

'Throughput' is the stuff that gets through to end-users, beneficiaries, or customers that they can apply to whatever it is they do. 

Accounting for what it takes to produce 'throughput' is the essence of 'throughput accounting'

• First, of course, is 'variable cost': If you have to buy a gallon of paint to put the finishing touch on 'throughput', then the cost of the paint is 'variable' to your day-to-day expenses, and the cost of the paint is directly part of the cost of 'throughput'.
• But second, you might reallocate resources from day-to-day 'running the business' to specifically and directly produce the throughput. If such is reallocated, then add that to the cost of throughput.

What about the day-to-day?

But, many ask, what about all the day-to-day stuff to make possible the environment and capabilities and capacity to affect throughput. Shouldn't there be some "ABC" of those costs? (*)

• My answer is: no. But ....
  
• Yes, you can try that. But, be prepared for endless arguments about allocations which in-and-of-themselves add no value. 
• And be prepared to 'de-conflict' allocation overlaps such that the sum of the ABC costs does not exceed the sum of the actual business expenses, to wit, by example: a manager's cost is allocated to several projects in an ABC sense. Then it's discovered that the sum of all the manager's allocation exceed the actual cost of the manager. Back to the allocation drawing board!
  

What about revenue?

Does 'throughput' have to generate new revenue in order to be 'throughput'?

No.

Back to the definition: the users or beneficiaries may not be revenue customers. So, there's no direct tie of throughput to revenue.

 

What about 'value'?

Does throughput have to make the business more valuable ... in effect, increase the size of the balance sheet? 

No.

Value is consequence of throughput, but in many instances the value which is consequential to throughput can not be directly monetized. Such is the case for many non-profits and government agencies. Yes, they have balance sheets; but no, those balance sheets don't accumulate the consequences of their activities like a for-profit business' balance sheet does.

It's complicated

Yes, but ....

Throughput' is the stuff that gets through to end-users, beneficiaries, or customers that they can apply to whatever it is they do.

 

----------------------

(*) Activity-based costing (ABC) is a method of assigning overhead and indirect costs—such as salaries and utilities—to products and services. The ABC system of cost accounting is based on activities, which are considered any event, unit of work, or task with a specific goal.

---

Buy them at any online book retailer!

Institutional stability

---

Certainly since the dawn of the internet in the mid-90's, and gaining momentum since the millennium, disruptive change has been a fact of business life, to say nothing of the impacts on culture and behavior in the general population.

But, there's a case for institutional stability among all the disruption and debris of change.

And that case is built on the value proposition of strategic outlook:

That is to say: individuals come and go; incumbent leadership teams come and go, but the general framework for business activity changes at a much slower pace, in effect providing strategic stability and security even if there is great tactical maneuvering.

It's not too much to say that this institutional framework, consisting not only of process and procedure, but also cultural norms, actually facilitates effective change in product substance. 

 

How so? Consider this: The new team doesn't need to invent the framework -- at some cost -- while they are inventing the new "thing"; they may only need to bend the framework a bit. 

 

PMO Stability

The thing about strategic stability is that people don't have to keep looking over their shoulder to see if they've been left behind or left out on a limb. 

What does this mean to the PMO? 

• Less overhead, for one thing; and greater throughput for another. 
• Stability means less rework, and 
• It means that remote teams can get the job done with a much less onerous overlay of constant communication with the mother ship.

Command vs cooperation

Admiral "Bull" Halsey, a disrupter in his day (WW II in the Pacific), has been quoted as saying "cooperation is no substitute for command". "Command"was the culture of his day. 

 

We've moved along. Today, we might say: "Cooperation is an essential replacement for command"

If that is so, and few would argue otherwise in the mosaic we call the modern economy, then strategic stability is all the more important.

How can you reasonably cooperate if the basis for cooperation is in constant flux? To cooperate is to assume and accept that certain behaviors and commitments of the counter-party will sustain over time while you do your thing. 

Thus, the inherent value in institutional and strategic stability.

---

Buy them at any online book retailer!

Let's communicate!

---

Sometimes, our language idioms get in the way of the top three project management tasks:

1. Communicate
2. Communicate, and 
3. Communicate!

A few examples to illustrate.

First, about schedule:
"Slow down" and "Slow up" mean the same thing: make the schedule slower. 'Up' or 'down' is irrelevant; you can choose to go in either direction!

The third hand of the clock is called the 'second hand'. Oh well; I'm not sure if this is a confusion of ordinality or cardinality, or something else.

"After dark" actually means 'after light'; that is, after the sun goes down if you are scheduling a night action.

About risk:
"Fat chance" and "slim chance" mean the same thing: there's not much of a chance that things will go as desired. So, when it comes to weighting a chance, choosing slim or fat is unimportant They may play the same way.

About management:
"Overlook" and "oversee" are quite different management activities. The former means to ignore, while the latter means to observe. 

About job satisfaction:
"Work is terrific", but you won't do it unless you are paid. 

About experience:
"Wise man" and "wise guy" are really not the same thing at all. The former is about wisdom borne of experience, and latter is about ignorance, regardless of experience

About environment:
"If all the world is a stage" where are your customers going to be? Understanding the customer's environment is one key to quality (in the large sense).

I could go on, but I won't!

 

---

Buy them at any online book retailer!

Interdependence stretches the critical path

---

In project management school, the lesson on Critical Path includes Rule #2:  

"Apply resources first to the critical path and subordinate demands of other paths to ensure the critical path is never starved.

Most of the time, Rule #2 is good advice.(See Rule #1 below) 

Rule #1, if you haven't guessed is:
Create a schedule network so that the critical path is revealed.

If you're only working with major milestones, there is no Rule #1.
It follows that there can be no Rule #2, and so no insight to schedule starvation. Pity.

 
A longer path?

Some of the time, Rule #2 has unintended consequences, like making the critical path longer! How does this happen?

The problem arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. Alas! The "parts" are not interchangeable. Mary and John are unique. Consideration must be given not only to the generic staffing profile for a task but also to the actual capabilities of real people.

Staffing and Schedule intersection

The intersection of the staffing plan with the schedule plan sometime brings up results that are not always as we want them. Intersection means overlap, and overlap means that the planning elements must be moved about so that each overlap is harmonious.

Take a look at the following figure for Rule #2: There are two tasks that are planned in parallel. If not for the resource requirements, these tasks would be independent, and if independent the critical path would be 50 days -- the length of task 1. Task 2, as you can see, is only 20 days duration.

You can probably see that if not for the specific assignments of Mary and John, the critical path could be as short as 50 days, not 65 as shown.

Let's violate Rule #2 and invent Rule #3: Reorganize the network logic to take into account unique staffing applied to schedule tasks.

 

Using Rule #3, staffing does not actually start on what was the critical path, a violation of Rule #2. 

 

But the advantage of Rule #3 is that the overall schedule is shorter nonetheless. In this case, the critical path is only 55 days.

 

There is still inter-dependence among tasks. But a new critical path using Rule #3 more optimally incorporates the sequencing constraints of the original path and the staffing constraints brought about by Mary and John.

Here's the main idea to take away: 

Any lack of independence among tasks will stretch the path upon which those tasks are scheduled

---

Buy them at any online book retailer!

The V&V thing ....

---

Have you thought much about this? Two of the conceptual conundrums of the hybrid agile-conventional methodology are:

1. How do you verify that which is incomplete and
2. How do you validate the efficacy of that which is yet to be conceived?

Verification and validation (V-and-V) are traditionally held to be very important project practices that to some may be difficult to map directly into the Agile domain, to wit:

• Validation: Each requirement is validated for it’s business usefulness, in effect its efficacy toward project objectives.
  Validation is usually not later than the last step in gathering and organizing requirements.
  (Of course, in Agile methods, it's allowed to change the requirements book on the fly according to customer feedback about interim results, so there may not be a well defined "last step".)
  
  
• Verification: When development (construction) is complete, and when integration of all constructed requirements is complete, the roll is called to ensure that every validated requirement is present and accounted for. (See above re the changing book on requirements)
  

Validation
Placed into an Agile context, validation is applied both to the project backlog and to the iteration backlog, since changes are anticipated to occur.

Validation is typically first applied at the story or use case level, validating with conversation among the interested and sponsoring parties that the functionality proposed is valid for the purpose.

 

One can imagine validating against external rules and regulations, perhaps internal standards, and of course validating against the business case.

Verification
Verification is generally a practice at any level of construction and itegration, verifying that which was approved and prioritized in the backlog(s) is, in fact, found in outcomes. And, if not, any differences are logged as technical or functional debt.

Depending on the project paradigm, V-and-V can be carried into integration tests and customer acceptance tests, again testing against various benchmarks and standards for validity, and verifying that everything delivered at the iteration level got integrated at the deliverable product level.

Is this an issue?

Is importing a really old idea of V&V into the Agile domain an issue? It could be. 

V&V is systematic accountability, and many resist being held accountable to a planned narrative. 

 

Accountability requires estimating as a prerequisite, and we know where that debate is going (Disclosure: I'm an estimator!)

The remedy: change the name; press on. Agilists have any number of alternate names for V&V, but at the end of the day, being accountable for efficacy and completeness is part and parcel to competent participation in the project domain.

---

Buy them at any online book retailer!

Coffee shop innovation

---

Mr. Andrews and Chelsea Lensing at Coe College are working on another study, about the importance of coffee shops to innovation.

Looking at the expansion of Starbucks from its base in Seattle starting in the 1980s, their preliminary results suggest that patenting activity increased when Starbucks came to town. The same happened when Dunkin’ Donuts, Peet’s Coffee and other chains arrived (*)

Yes, of course, there is the counterpoint: There are many cases of the lonely genius. Although, you might ask, how many of them are quietly doing their thing at a coffee shop?

But more often than not, the informal mixing of disparate ideas, a propensity for a bit of risk taking, and a forgiving professional environment are the ingredients for innovative ideas that take off.

If you don't have it, build it

Don't have a coffee shop nearby? Maybe that's step one: build a coffee shop. And, then build in the relevant policies that allow for "flexible time" at the shop. You might even build it on your premises ... many do.

------------------

(*) From the New York Times, November 3, 2020

---

Buy them at any online book retailer!

Velocity!!

---

"At every turn, leaders chose velocity and production over efficiency, thrift, safety, and even prudence"

Ian Toll, Historian

Well, of course, Toll is describing the build-up in the western Pacific in the closing year of WW II. Most, but not all of us, will not have projects in which velocity is prioritized over safety.

Most of us, but not all: In the last 20 years, such has been the case in not a few project instances, in support of wartime emergencies.

Velocity is just a rate

For the math inclined among us, velocity is a rate: something per something else. 

For those with a little calculus training, it's the first derivative of the steady state, expressed as: dx/dt, a small change in the steady state during a small change in time

Velocity is throughput

But for the PMO, velocity is about throughput: Project input -- not especially valuable to the end user -- integrated and transformed into something that is especially valuable.

How fast can you do that? Whatever the answer is, that's "velocity". The rate at which value is produced for the end user. 

Velocity at what cost?

Now, back to Mr. Toll's observation: Apart from safety, it may be that the project office is willing to suffer lots of rework, blind alleys, cost incentives, inefficient process, and inefficient redundancies in order to get some throughput at an high pace.

So be it. But when it comes to safety, we enter a new realm of risk in which the penalties can reach all the way to the criminal. 

But if not criminal, there still can be unimaginable costs: One can only wonder if the Challenger and Columbia would be in a comfortable retirement if only safety were not subordinate to some element of velocity.

---

Buy them at any online book retailer!

Sequential vs Cumulative

---

I'm a sequentialist.

When planning a project, I think first about how to sequence the scope: do this first, then that. Or, do these things in parallel, followed by this or that.

MS Project, and similar tools, are the sequentialists go-to tool for planning sequences and establishing the sequential order of the project.

Not so fast!

What about cumulative, non-sequential, scope and effects?

For these, we need a cumulalist to help with the plan.

Accumulations of the cumulative

The obvious non-sequential scope is all the sundry overhead that descends on the project: HR stuff, regulatory requirements, environment maintenance, training, re-provisioning and refit, and on it goes.

 

But, that is all foreseeable, and to an extent, such overt actions can be accounted for in the plan.

 

Other things accumulate, leading to a cumulative effect on through-put, and thus cost and schedule, and perhaps even quality:

• General fatigue from the stress of solving problems and meeting deadlines
• Frustrations that mount up from dealing with the bureaucracy, other teams, outside consultants and contractors
• The weather (unless you live in paradise, like I do, in Florida)
  
• The pandemic 
• Network issues and connectivity constraints
• Security constraints and threats

There are many sequentialists on every project, and in every sponsor organization, keeping watch on the march toward the final milestone. 

Fewer may be cumulalists keeping watch on the build-up of factors and effects that may have impacts on the progress of the sequence.

Beware the accumulation of cumulative effects!

 

 

---

Buy them at any online book retailer!

Dodging the pandemic

---

If you're a PM running a project during the pandemic, you probably have one or more of these problems:

• Supply chain issues: stuff is out of stock; stuff is not available on time; stuff costs more
• Velocity and throughput issues: Throughput is slower to achieve; there's more overhead and NVA (non-value added)
• Communication errors: Remote work is really work with restricted bandwidth; nothing really replaces the high-bandwidth of in-person person-to-person communications, formal and informal. Restrictions introduce timing errors; misunderstandings; information gaps
• Matrix assignments: to keep people off overhead, they are assigned piecemeal to multiple projects. But this introduces commitment conflicts and start-stop inefficiencies
• Innovation MIA(*): Most innovation is a beneficiary of a lot of informal collaboration that somehow surfaces a neat thing to do. Such may go MIA with remote working

So, what is to be done in such an environment as described above?

• First, bring on the slack! You need to buffer every budget ... cost or schedule ... with slack (white space) that allows for the project to absorb small shocks in supply chain, velocity blips, resource conflicts, etc. Such a strategy is the essence of being "anti-fragile"
• Second, be aware of -- and react to -- constraints (bottlenecks) that may move about ... here and then there ... as external circumstances change. You may need to be at the top of  your game applying the "theory of constraints" (**). 
• Bring in redundancy and work-arounds to keep things moving. You may need back-up supply chain options, prototypes, and ability to work with reduced scope by applying redundant capabilities (instead of 10 blades in the rack, maybe you can work with just 6 that are essential)
• Add excess bandwidth to facilitate increased informality and opportunity for interaction.

Bottom line: Make everyone in your chain aware of the lean-in you are doing so that there is confidence and support for your PMO.

-----------------

(*) MIA: missing in action
(**) Read about Elihu Goldratt's "Theory of Constraints" on Wikipedia or elsewhere

---

Buy them at any online book retailer!

Critical path: who's in charge?

You've got a job to do; you've sequenced and scheduled it

But, in the middle of your critical path there is another independent project (or task) over which you have no control. In effect, your schedule has a break in its sequence over which you have no influence.

Yikes! 

This is all too common in construction projects where independent "trades" (meaning contractors with different skills, like electrical vs plumbing) are somehow sequenced by some "higher" authority.

So, what do you do?

If you have advance notice of this critical path situation, you should put both cost slack and schedule slack in your project plan, but there may be other things you can do.

 

Cost slack is largely a consequence of your choices of schedule risk management. 

Schedule risk management may have these possibilities:

• Establish a coordination scheme with the interfering project .... nothing like some actual communication to arrive at a solution
• Schedule slack in your schedule that can absorb schedule maladies from the interfering project
• Design a work-around that you can inexpensively implement to bridge over the break in your schedule 
• Actually break up your one project into two projects: one before and one after the interposing project. That way, you've got two independent critical paths: one for the 'before' project and one for the 'after' project

 At the end of the day: communicate; communicate; communicate!

---

Buy them at any online book retailer!

A bit of Kano Analysis

---

"Customer value", aka "the value proposition", is complicated. 

Books fill the shelves on those topics. 

• What do 'early adopters' value?
• How does age come into play?
• Is economic willingness different from economic capability in the value equation?
• How do culture and relationships figure in the proposition?

One might ask: is there a way to map all this stuff so that a picture emerges? If there is, I've not seen it. But, taking those questions one at a time, Kano Analysis may help see the bigger picture.

What is Kano analysis?

Kano analysis is a product feature/function evaluation tool that gives visualization to relative merit over time as trends change. The usual presentation is a four-sector grid with trend lines that connect the sectors. 

The grids are defined by the horizontal and vertical scales. Don't take the word 'scale' too seriously; for the most part the scales are non-calibrated, but informed, opinion:

• Vertical: customer attitude, feeling of satisfaction, or other elements of value appeal.'
• Horizontal: some quality (or metric) of the feature/function that's important to the customer.

 

The trends need not be linear, and need not be monotonic, changing direction as customer/user attitudes change.

 

Developers use the Kano board with sticky notes to show how feature/function in the form of stories or narratives might play out over time.

 And, we take the trouble to do this because:

• There's only so much investment dollars available; the dollars need to be applied to the best value of the project.
  Presumably that's the "ah-hah!" feature, but the "more is better" is there to keep up with competition; and, some stuff just has to be there because it's commonly expected or need by regulation.
  
• Trends may influence sequencing of iterations and deliveries. Too late, and decay has set in and the market's been missed.
• The horizontal axis may be transparent to the customer/user, but may not be transparent to regulators, support systems, and others concerned with the "ilities". Thus, not only don't forget about it, but actually set aside resources for these 'indifferent' features and functions.
  

How far ahead of the trend can you be and not be too far ahead? Just a rhetorical question to close this out.

---

Buy them at any online book retailer!

The Economics of Strategy

---

A good blog read on this topic -- the Economics of Strategy -- is found at herdingcats
written by Glen Alleman.

 

In his posting, Alleman makes a couple of important points:

• There are many tactical actions that can be taken within a project -- like attention to risk management -- that ultimately have strategic outcomes for the business: enhanced profit on the income statement, sustainable free cash flow, and a stronger balance sheet
  
• Likewise, there are many tactical decisions about product features and functions that will enhance customer value but have only marginal impact on business outcomes, and yet have strategic consequences for the business. See: customer loyalty

Four elements of strategy

Of course, attention to strategic finance and customer satisfaction are two of four components of a good business strategy. 

A third is development of the business capability and capacity to innovate and produce. Typically, there is a cost-benefit and cost-outcome analysis that is required to figure out how much to invest in training and development of people, and how many robots to purchase.

A fourth is just do what you do all the better. That is, invest in operational effectiveness -- lower overhead, fewer reworks, more throughput for the dollar.

All four contribute

So, when you are considering all economics contributions to or effects on strategy, the balanced scorecard of finance, customer satisfaction with the value delivered, investments in organizational development, and improvement in the economics of throughput

---

Buy them at any online book retailer!

Tradeoff vs corruption

---

How do you know when you've crossed the line from making trade-offs to fomenting corruption?

That's not a question asked very often in the is space, and not usually asked in polite company.

Nonetheless, it happens.

And, what is "it"?

"It" is making decisions about doing 'this' or 'that' that are a violation of accepted norms wherein the outcomes have an inappropriate personal benefit, rather than a decision among legitimate alternatives where the personal benefit is non-existent or indifferent to the outcome. 

 

Corrupting decisions take many forms: There may be a financial benefit, like a stock option that gets out of negative territory; there may be a job benefit insofar as the decision comports with the business narrative; or there could be a 'traitor in our midst' problem.

Sovereignty

They say that in a republican democracy (small 'r', small 'd') that the people are sovereign and that political power is simply a delegation from the sovereign -- such a delegation intended to benefit the sovereign (the people at large). Political corruption is then using that gifted and delegated power to work against the interests of the sovereign to one's own benefit. 

How does that work in a project? Who is the sovereign? What is corruption in the project sense?

You could say the owners and shareholders are sovereign. You could say that customers are sovereign and that all business value is a delegation from customers. 

• To work against the customer's interest (or owners and share holders) with false claims and hidden quality shortcomings is committing corruption. 
• To work for a compromise that is beneficial to customers and business alike is making trade-offs.

 

Enough!

---

Buy them at any online book retailer!

Feeling the pressure

---

" [The concern my some is] that with all good intentions, some project managers might start cutting corners. It's easily done. Don't be fooled by the trappings. ....

This sort of success comes with a lot of pressure. There are deadlines, penalties, [finances], and [executive changes]. [PMs] are stuck in the middle. Priorities can become murky.

It would be natural for some to feel the pressure and choose speed over quality" 

Louise Penny, novelist

I'm sure you can tell from the brackets that I took the excerpt from one of Ms Penny's crime novels, but nonetheless her character's words probably ring all too true to many readers. One wonders if she is writing about the false engineering found in the diesel car industry or the calamitous decision-making in the aviation industry of late.

Risk assessment and confirmation bias

I put it down to executive-level risk assessments. Looking the other way or deliberately hiding is always the path to trouble. There is a political adage that might apply: the coverup is always worse than the underlying transgression.

Even if that is understood, the pressure of the moment is often telling. One sign: the stressed PM is looking everywhere for confirmation .... and making themselves susceptible to confirmation bias. It is likely they will hear what they want to hear.

It's like a bad email

Most people handle email (and social media) poorly, sending email (or media) when they are mad or when they think no one else will find out. Never make an important decision when mad, and always assume what you write will appear on the front page.

The same is for the high-risk assessments. Unless life itself hangs in the balance, there is time to consider the consequences more thoughtfully. Take that time.

---

Buy them at any online book retailer!

Ghost writer

---

So, you work in project communications, perhaps directly for the PM. In the 'old days', say 15 years ago, that probably meant long-form press releases and updates to the project web page or communications dashboard.

Today, it's those plus social media.

But, if you're a ghost writer for the 'boss', who gets the credit? And, does the boss get the credit for imaginative and effective writing when it's really you?

Welcome to the world of ghost writing. 

The person you're writing for gets the credit, usually, and you're lucky if you're recognized outside your PMO. You probably knew all that coming into the job. Why else is it called 'ghost' writing?

 

But what if you disagree in some fundamental way with the content of the communication you've been asked to write? What then?

Two cases:

1. Opinion: It's not your opinion you're opining. You can write 'B' for the public, but believe 'A' privately.
2. False facts: If not about 'beliefs' but rather about misleading or even factually incorrect material, you have an obligation to push back. 

Life is too short

If you can't live with the material you're writing, then don't. Find new material; it probably means a new job. If you're a gig person, fire the boss!

---

Buy them at any online book retailer!

Value flow

---

About value (*)

In many posts in this blog, I have established these propositions:

• That there is a distinction between project value and business value, and 
• That the interests of the customer/user, sponsor/stakeholder, and project manager are to be balanced among these parties, even as they all compete for attention as value is developed. 
  

We recognize that:

• Each has their own needs and wants, 
• Each has their own sense of urgency and importance, and 
• Each has an idea of the investment they want to make and the risk they are willing to accept.

Value planning challenge

The planning challenge for project sponsors is to fashion a practical and rewarding opportunity from the myriad of permutations and combinations of needs and wants, colored by urgency and importance, affordability, and risk. 

 

To make the best of opportunities requires goal setting and strategic development in the context of mission and vision. 

• Mission provides the compelling call for action. 
• Vision provides the epic narrative and points the way ahead. 
• Goals set the stage; goals motivate business strategy and, in turn, motivate project strategy

OE and project objectives:
Business goals, extended through business strategy, drive project objectives. But of course business strategy also drives operational effectiveness (OE) ....

OE being the quality of the operations and operating programs that amounts to doing things better with predictable repetition (see: Michael Porter for more ideas like these). But even predictable repetition, if done better over time, like projects, add value to the business.  

OE and projects, working together, are two instruments of strategy. They are interdependent. The outcomes of projects may well affect operations—add, change, or delete them—thereby closing the loop on goals and strategy, as captured on the business scorecard 

Strategic Plan

Here, at the bottom of this post, is the bottom line:

Strategy is a plan that integrates continuous improvement of operational effectiveness with a vision and narrative for differentiated innovation attained with projects

 

-----------------------

(*) Some of the material in this post come from Chapter 2 of my book, cover illustration below, "Managing Project Value"

---

Buy them at any online book retailer!

Running a business

---

On the one hand:
Follow the science; follow the engineering; follow the facts; adhere to policy and precedent

On the other hand:

Listen to the customer; stay ahead of the competition; keep an eye on shareholder value; don't be late!

As one prominent CEO opined, business decision-making is all about a talent for making trade-offs. In effect, "situational decision-making" somewhat akin to "situational leadership". Different and multiple styles to be fitted to the situation:

• Nothing is so simple as "follow the facts" and adhere to precedent. 
• Nothing is so "lacking sense" as just "listen to the customer"

Here's another idea: seek stability and predictability. The fact is that without either, your only recourse is to apply a heavy discount to future value. 

Not so fast! 

Maybe your business model thrives on instability, in effect working off the 'rate of change' rather than the steady-state. 

Many 'transactionalists' work this way, making large bets on even small changes (very large times a very small number may still be a quite large number, aka: the "one-percent doctrine").

But if you are the business leader that heads toward the unpredictable, then you should be thinking of how to make your business "anti-fragile", to wit: to be able to absorb great shock without collapse.

• By having interior firewalls to stop risks from propagating
  
• By having redundancy to fill in for failed capability and capacity
  
• By having reserves to cover losses
  
• By not being totally "just in time" because there may not be time
  

No matter the model for decision-making, an internalized methodology that you can apply with confidence is your best tool, to be practiced and made like "muscle memory"

 

---

Buy them at any online book retailer!

Influence at a distance

---

The energy from a transmitting antenna decreases as the square of the distance from the transmitter to the receiver -- if the distance increases by a factor of 2, the energy decreases by a factor of 4. Light obeys the same rule. 

 

And all of the above only applies if the bandwidth is infinite and the transmission is in a vacuum. If the bandwidth is high restricted, as in a filter, or the media of transmission is not clear, then there are more losses of energy and there is a time-delay as well. 

 

The fact is, even an enormous energy source may have little effect at long distance, and increasingly less as the distance lengthens.

 

So that's the physics for the day.

How do these physics apply to the PMO? 

Influence at a distance

The plain fact is: if you want to maximize your influence, you have to be close to the flag pole -- be at the center of decision making and in the room, at the table.

Now you say, remote video conferences are all the rage, and so how does distance make a difference?

And I say:

• No virtual conference setting is as clear as being there; there are losses
  
• A good deal of communication is lost in the restricted bandwidth, particularly the informal communications during breaks and the body language exchanged off camera
• If you're really far away, everyone knows you can't get to the flag pole in a hurry, so your influence is discounted
• All the power of the "casual" encounter at just the right moment is lost

So, how to have influence at a distance

• Create intimacy and familiarity by being a frequent communicator
• Be up front and noisy about your points of view
• Give feedback on everything so they know you are listening and thinking
• Be a contributor; be consequential -- get things done. Avoid the empty suit "all talk"
• Innovate where possible. Be the source, rather than the sink for energy
  

 

---

Buy them at any online book retailer!

CPP and Technical debt -- history

---

debt (n): that which is owed

technical debt (n): unmet scope items owed for project completion

The term "debt" as applied to projects has been promoted as part of Agile methods since at least the late 1990s, certainly more than a generation ago. As a matter of process, debt is added to backlog, and scheduled, according to priority, in sprints or iterations like all other scope is processed.

But, guess what!

Debt has been around longer than 25 years. Who knew?!

Well, of course, there have been "punch lists" and "check lists" and "parking lots" and the infamous version 2.0, but really: how old is this debt concept?

 

Circa 18th century

In the late 18th century, a small group of American politicians, the elite of their day, met to frame a new constitution for the United States.  Heretofore the country had been operating under Articles of Confederation which were judged to be too weak to hold the union together.

Crafting a new constitution for a republican form of government, to operate at continental scale! Never been attempted. A rather massive project when you get right down to it.

 

One of the first orders of business in the Constitutional Convention was to form the "Committee on Postponed Parts"

 

Committee on Postponed Parts

Brilliant! There you have it, perhaps one of the first technical debt vehicles applied to a large scale project -- the CPP!.

 

Different, but also similar, to the priority ranking and scheduling of technical debt we see today, the Committee was an active body. Its members, like PMs today, set priorities, scheduled when to birth it's ideas on the main body, and debated alternatives for "customer satisfaction". 

So, curiously, what were some of the "postponed parts" from the Constitutional Convention?

• The first 10 amendments, known as the Bill of Rights, was deferred to the first Congress seated under the new constitution (*)
  
• The location of the permanent capital city
• The assumption of war debt by the "general" (aka federal) government
• A central bank
  

Actually, there were a lot of "parts" postponed. By design, the Constitution had to be skinny in its enumerated powers to gain state ratification, but robust in other ways to form a strong union. No small matter, architecturally.

And so, many thorny issues were labeled "postponed parts" and were not closed for many years after the ratification. Nonetheless, the American constitution today is testimony to the workability of the debt concept embodied in the Committee on Postponed Parts.

_____________________

(*) Actually, the first Bill of Rights was a set of 12 amendments. But two were not approved and left with the CPP. Thus, what we popularly know as the "First Amendment" was actually numbered "3rd". Ah, but ordinal numbers, like first, second, third, do not convey importance or priority -- just order.

 

 

---

Buy them at any online book retailer!

Who comes back first?!

---

Ah ha! You are going to reopen the in-person office for the PMO.

Good show!

Ooops! 

Who comes back first? Is there a pecking order? Will there be hurt feelings if you're not picked first? What does that mean, to not be picked first?

And, the other side of that coin: You're picked, but you don't want to go back! Now what? Can you opt-out? What if you do opt-out .... is there a career impact? After all, the big action is often closest to the flag pole.

 

Now you're back and you don't like it! It's just not the same atmosphere; some of the people are missing; relationships are screwed up. Now what? Ask to go back to remote? Can you do that?

Here are the answers:

I don't have any answers. It's all situational, but you shouldn't shoulder all the angst yourself. Find someone to talk with. There many be many fewer demons than first appear.

---

Buy them at any online book retailer!

It's about the sequencing!

---

Sequencing is getting things in a time-order. What comes first; what comes next?

Sequencing is the first task in forming a schedule, but only after you figure out the scope.

 

A before B

If you understand the nature of A and that of B, then if there is a dependency between them vis a vis time order, then getting A done before B sounds easy, but sometimes it makes you wonder!

• Is there a preamble to B that should be done before A is completed?
• Are the resources for A and B in conflict or not available; such could affect the "preamble" activity.
  
• Can B really start after A, or are there other dependencies on the start of B?
  
• Do I really want B to start, or do I want to pause and start C somewhere else? 
• If I start B, immediately after A, have I introduced unnecessary risk or other impacts?
  

Schedule depends on sequence

So, if you're thinking about sequencing, you're probably also thinking about schedule: how long it's going to take?

Or, the other way around: if you are working on a schedule, you have to get the sequence down first. 

 

From time to time, arguments boil up about scheduling tools, like MSProject and others. The usual thinking is that these tools are "so last century" and haven't kept up with more agile planning techniques. 

 

And, worst of all, these older tools promote waterfall (gasp!) scheduling, which is demagoguery for finish-to-start precedence. 

 

Finish-to-start precedence is a sequencing concept. If you pooh-pooh such precedence, I challenge you to put up the roof before the walls are in place.

It's all about the sequencing

First, you have to know what you are going to do. To wit: you can't sequence that which you don't know about, and furthermore, even then there may be sequencing errors you discover once you understand the full extent of the scope.

 

For any project, step 1 is to assemble (or define) the elements of scope by some affinity criteria. (Using the roof-after-walls example, get all the roof stuff in one grouping, and all the wall stuff in another grouping. That way, you can sequence the roof group after the wall group.)

Back to MSProject

MSProject is a good planning tool for sequencing. You can work in the gantt-chart mode and sketch out the big picture pretty rapidly, setting up key milestones as schedule goals. You need not use the precedence mode at all.

However, there is a bridge too far: 

If  you plan in too much detail, MSProject and other such tools are way too tedious to use for maintenance of the schedule once the project is under way. 

 

As a practical matter there will be "mico-dependencies" that crop up, which are worked in real time; micro-loops for feedback and checking results against the evolving construction baseline, etc. that are way too expensive to schedule, status, and maintain as they change.

My advice: at the PMO level focus on the major sequences that drive toward value-add milestones.

---

Buy them at any online book retailer!

The skills stack

---

The skills stack. Heard of it? Somewhat like other stacks of stuff, except the focus is on skills needed in the PMO ... and elsewhere. 

Actually, to me, the description of the stack as provided by strategic thought leader Greg Githens, is less a stack -- which implies an ordering from top to bottom -- and more a flat mesh of interrelated skills. 

 

As used by Githens, one might argue with the term "skill", given that we usually think of skill as some ability specifically learned, practiced, and applied. But, if you expand "ability" into practiced and applied behavior, and also into directed energy and attention, then "skill" in this broader sense is what Githens is getting at. 

 

So, here are three "skills" ... broadly speaking ... I particularly like, as authored by Githens:

... AMBITION, [which] captures an individual’s desire to... achieve their goals.

... ANTICIPATION, [which] is ... looking into the future, knowing that your decisions today will bear their consequences in the future. ...

... REFRAMING, [which] is .... intentionally adopting new points of view and explanations. ...

To this I might add:

• Ambition is typically personal, and often self-centered, but in a larger calling, one could be ambitious to be consequential, to wit: to make a difference that affects others as well as yourself. To be consequential, to have made a difference by your efforts, could be your goal. Why not?
  
  
• Anticipation is certainly looking ahead into the future. A skillful anticipator can assemble a narrative, with its attendant consequences, benefits, costs, and risks, and sequence the tactics necessary to achieve the objective.
  
  
• Reframing is a quite useful skill, often stated as "walk in the other guy's shoes". In effect, step out of your frame of reference and see it from your nemesis', customer's, sponsor's, or partner's perspective, experience, and sense of risk.
  Often, you have to set aside many biases, and reorder priorities in order to skillfully reframe a situation.
  Set aside biases? Really? That's not an easy thing to do. The science of game theory, however, provides some of the tooling that useful for seeing things from another point of view.

---

Buy them at any online book retailer!

Counter-party risk

---

Define counter-party: 

In a transactional relationship, the other party to -- or participating in -- the transaction is your counter-party.

 

In project situations, there are usually many counter-party transactional arrangements, such as contractors and suppliers with transactional relationships. And within the business there may be transactional relationships among business units and the PMO. 

 

Oh! And don't forget the money: there may be financiers of the business or project which have a counter-party relationship to the project.

Fair enough. But now comes counter-party risk: the risk that the other party to the transaction, or perhaps you yourself, will not be able to hold up their side of the transaction.

 

About counter-party risk

So, you are about to enter into a transaction with another party. What might be the risks?

• Trust: you may not know the other party well enough to convey trust, a willingness to believe what they say without the protections of a written agreement.
• Ability to perform their side of the transaction may be in question. Do they have all the requisite tools, resources, and experience? Is something required of you in order for the other side of the transaction to be completed?
  
• Willingness to perform their side of the transaction when the whole deal comes under stress may require backup

What is your strategy; what are your tactics?

• Your strategy should be to keep the counter-party fully engaged with intent to fulfill their side of the bargain.
• Your tactics should be to put in place standard risk management tools: Written agreements with incentives and penalties; sober assessments of their track record on similar activities; and perhaps insurance for consequential damages if the counter-party fails.
  

---

Buy them at any online book retailer!

Complicated and complex

---

"They" say it's complicated

"They" say it's complex

Are they saying the same thing?

No, actually, there are differences:

• It's complicated if "it" has a lot of parts and pieces
• It's complex if the parts and pieces have a lot of interactions among them, and many of the interactions are not readily apparent, hard to model or predict, and may even lead to chaotic responses 

Good or bad; fix or ignore?

So is complicated or complex a good thing or bad? How would you know? And, what's to be done about them? 

Short answer: Chaos is almost always bad in a system, product, or process -- whatever is the project's outcome. Thus, for that reason alone, complexity may not be your friend.  

But, even without chaotic propensity, complexity is usually not a good thing: complex systems are hard to service; hard to modify; difficult to integrate with an established environment; on and on. If such are present, then complexity is present -- that's how you know.

Complicated is usually a matter of cost: lots of parts begets lots of cost, even if there is minimal complexity. Simple is usually less costly and may not necessarily sacrifice other attributes.

So, what do you do? 

You've read the theory; now, to action:

• Chaos is bad; let's start there. The fix is to reduce complexity. To reduce complexity, a generous number of interfaces are required.
  The purpose of the interface is to block propagation of chaotic responses and contain risk to smaller elements of the system.
  Proof is in the testing. All manner of stimuli is applied to try to induce chaotic responses, and address those that occur. 
  
  
• Complexity is first addressed by interface design; then by service design. To wit: if you have to fix something, how would you separate it from the system for diagnosis, and then how would you repair or replace? Addressing these functional problems will in turn address many of the issues of complexity
  
  
• Complicated means a lot of parts. If that's more expensive than you want to afford, then integrated assemblies will reduce the part count and perhaps address some of the issues of complexity.
  If you've ever looked inside an old piece of electronics circa 1960 or older, you can appreciate the integrated modular design of today's electronics. Hundreds of piece parts have been integrated into a dozen or fewer assemblies.
  

---

Buy them at any online book retailer!

Delusions of vision

---

In this blog and elsewhere, the visionary leader is extolled, aspirational in every respect.

But, what if their strategic vision is delusional?

• From predicates A and B, the leader envisions C
• But, inferring C from A and B is a delusion, unsupported and unsupportable

Perhaps such a delusion is revealed in hindsight, but in the moment who can say C is a delusional inference to be drawn from A and B? How can anyone know that a person is deluding themselves?

There are some signs:

• C is a possibility, yes, but a really long shot by probability
• C is a black swan; there is nothing from history to support C as a consequence of A and B
• C requires new physics, unlikely to ever be realizable
• C requires unusual political support, unlikely to be anyone's political investment
• C is just "confirmation bias" for an outcome wished for but otherwise unlikely

What to do?

So, if your PMO is being led by a leader you think is deluding themselves, what should you do?

 

First, look for your own confirmation bias. Indeed, are you the one that is deluded into thinking the bold and brave is not possible and you look for the supporting evidence to confirm your point of view, discounting ideas to the contrary?

Second, are there others that have the bona fides to not only agree with you but to also speak truth to power about the likely outcomes?

And third, if not C, then what is the inference to be drawn from A and B? Which is the greater error: the cost of accepting C as the objective, or the cost of discarding C and going for C-alternative?

Obviously, all situational. There's no fixed process or recipe.

Did I mention: Good Luck!

 

---

Buy them at any online book retailer!

Coupling, coherence, and other stuff

---

Has someone in your PMO suggested applying a dose of system engineering to portfolio management? If they have, I wonder if they think of it as "three C's and D"?

A bit cryptic? Well, not so much when you spell it out:
Coupling, coherence, cohesion, and diversification

The short form explanation of  three C's and D looks like this:

Here's a little explanation:

Coherence

Coherence is what gives rise to reinforcement and to synergies. Coherence gets its power from phasing and sequencing....in other words, timing. Take 20 people and let them chat at a party and you have--to the macro listener--noise; but phase things correctly and you could have a choir. In other words, from noise a song!

Cohesion

Cohesion is what makes things stick together and perform under stress; to accept tension among parts and keep on going. In a portfolio, it's a matter of making good on the overall business value proposition, and doing so under stress.

The qualitative idea is weak or strong cohesion; ordinarily the metric is strength under stress, which for projects is tolerance for failure.

Strong cohesion means that if one project, or some aspect of a project, fails in some sense, the tensions created among projects because of failed dependencies are not crippling to the business outcomes. Cohesion requires redundant or alternate paths to customer satisfaction through the network of portfolio projects.

Coupling

Coupling is well understood notionally: it's the idea that one effect or outcome directly influences another. Generally, we think of coupling as being loose or tight, referring to how well one effect is transferred onward. Insulation loosens the coupling between outside and inside, etc. 

 

In projects, loose coupling is usually the desired quality. A failure in one project is not coupled into the next is the idea. In portfolios, the same is true. We want high coherence and strong cohesion but loose coupling. And, all three together is sometimes a challenge.

Diversification

Most of us understand diversification from the financial portfolio experience: when one investment is down, another is up, and the overall result is within a range of acceptability. If all investments are really independent of each other, the range of results is compressed by approximately the square root of the number of investments in the portfolio--the square root of N rule.

The same is true of project portfolios. The secret sauce is independence. If coupling is not loose, independence is forfeited, and so also is the power of diversification forfeited.

How to sum up?

Perhaps I'll just say there's a place for system engineering in project management. 

---

Buy them at any online book retailer!

Be Bold; be brave; be calculating

---

I would hardly think today of making my first flight on a strange machine in a 27-mile wind . . .

I look with amazement upon our audacity in attempting flights with a new and untried machine under such circumstances.

Yet faith in our calculations and the design of the first machine, based upon our tables of air pressures, secured by months of careful laboratory work, and confidence in our system of control … had convinced us that the machine was capable of lifting and maintaining itself in the air

— Orville Wright, from “How We Made the First Flight” (*)

I hope you were able to read the last sentence, as long as it is -- my editor would have been apocalyptic!

So, what have we got here with O.Wright's statement that can inform project management?

He begins with audacity! Audacity: "a willingness to take bold risks"
To be audacious! Audacity is a risk attitude that is at first personal, but then infects the whole project culture.

But not recklessly bold risks. Audacious is one thing; willful recklessness is entirely different.

Then comes the skill and science

So then comes the science, the engineering, and the risk management to leaven the audacity. Afterall, as we learn from author Jo Nesbo, "Someone will no doubt come up with an opinion with the benefit of hindsight, but we prefer to be wise in foresight".

In this case, wisdom in foresight requires:

• Calculations and tables of metrics
• Careful laboratory work
• Confidence in the system engineering
• Measurable goal: capable of lifting maintaining itself in air
  

And what does the world get with this elixir of bold thinking, careful consideration of risk, and skill-and-science?

• Heavy machines that fly
• Semiconductors of near atomic size
  
• Electric, hydrogen, and possibly others that upend the transportation industry
• Social media
• Private space travel
• And all the other stuff yet to be envisioned!

----------
(*) Quotation courtesy of Herding Cats

 

---

Buy them at any online book retailer!

Smart and Not-so-Smart

---

Harry’s poker-playing friend claimed that probability theory, and how to play your cards according to the rule book, was the easiest thing in the world.

But what separated smart players from the not-so-smart was the ability to understand how their opponent was thinking ...

Harry Hole, Detective,
according to author Jo Nesbo

Now, in project terms, we would like to think we don't have to worry about opponents. But, of course, that's not the case. Most practical projects at scale have a nemesis, either technical, managerial, or political.

Also, it would be great if we could all grasp "Game Theory" which lays out methodologies for assessing what your opponent is likely to do in the context of what you might be likely to do. [You can read some about this in Chapter 12 of my book, cover illustration below, "Maximizing Project Value"]

In effect "Game Theory" combines probabilities, rules for applying game rules, and methodologies for  making an 'informed estimate' of what others might do.

Stability and equilibrium
If you are working with probability theory in your project, then you are thinking and acting with some uncertainty in mind. As our detective friend says in the opening quote, just understanding some of the 'rules' around uncertainty estimates is not enough.

Coming to some sort of stable (and predictable) position in the project environment is perhaps the most advantageous outcome one could expect in an environment of uncertainty. 

 Perhaps the most practical utility of Game Theory, as applied to projects, is developing equilibrium as a stable and desirable outcome. Odd as it sounds, equilibrium is often achieved by accepting a sub-optimum outcome as a compromise outcome between 'adversaries'. 

And why would you settle for sub-optimum? You settle because the alternative is more costly without compensating benefit.

The "Nash Equilibrium" 

The Nash Equilibrium is an example of such an outcome, and it is explained in Chapter 12. In essence, you and your opponent agree to a compromise plan for which their is no net upside for either of you to divert from the plan. In other words, at the Nash Equilibrium, things are worse for you (and your adversary) if either of you make a change.

The counterpoint is obvious: as long as there are incentives for a more advantageous deal, stability will always be on the knife's edge. Recognizing whether or not you've achieved a Nash Equilibrium may be the smartest thing you can do.

---

Buy them at any online book retailer!

About compartments

---

It's how we all get along, especially in the close quarters of a project team -- even if virtual:

"A well-ordered life has compartments. People that have secrets know that other people have secrets. That's how we all get along

Dialogue from "The Paladin" by David Ignatius

 

Of course, in the pristine description of project methodologies in the PMBOK® and elsewhere, projects are an open book. The project pyramid is transparent from top to bottom; information is readily available.

Real projects are compartmented
I should say that a well-ordered project is strategically transparent but tactically compartmented. Everyone should know and internalize the major mission elements, but tactically, there is value in limitations. 

Effective communication emulates life in a lot of ways, and one of those ways is to compartment information. Immediately, the N-squared number of communication channels between N sources is reduced exponentially.  From that one action, communication quality goes up:

• Fewer rumors, more authoritative information
  
• Less noise, greater signal
  

And, compartmentation is helpful when you need to put space between big egos; separate clashing personalities, and limit people interactions. It's how we all get along.

But also, compartmentation is a tool for limiting information according to sensitivity, proprietary protections, and utility according to function. Sometimes, it's just better to know less, at least with respect to tactical detail.

And, compartments reduce risk.
How so?
In the sailboat business, we speak of "rip stops" in sails. Sails are never one large sheet; they are always compartmented by seams. If a problem arises in one part of the sail, the "rip stop" seam contains the problem, prevents its spread, and usually leaves a lot of the sail useful for powering the boat.

The same goes for a project: compartments are "rip stops". A problem in one aspect of the project is contained, but the rest of the project goes forward.

And, I might add: In system engineering, we build with subsystems linked by carefully constructed interfaces. The interface provides "loose coupling" that helps contain and compartmentalize any issue in one subsystem.

The architecture of project methods
When developing the architecture of your project methodologies, think of what it takes to have a well-ordered project

---

Buy them at any online book retailer!

All is not a Bell Curve

---

It's a bell, unless it's not
For nearly all of us when approaching something statistical, we imagine the bell-shape distribution right away. And, we know the average outcome is the value at the peak of the curve.

Why is it so useful that it's the default go-to?  Because many, if not most, natural phenomenon with a bit of randomness tend to have a "central tendency" or preferred state of value. In the absence of influence, there is a tendency for random outcomes to cluster around the center, giving rise to the symmetry about the central value and the idea of "central tendency". To default to the bell-shape really isn't lazy thinking; in fact, it's a useful default when there is a paucity of data. 

Some caution required: Some useful stuff in projects is not bell shaped.  Yes, the bell shape does serve as a most useful surrogate for the probable patterns of complex systems, but no: the bell-shape distribution is not the end-all and be-all.

But if no central tendency?
Lots of important stuff that projects use every day have no central tendency and no bell curve distribution. Perhaps the most common and useful is the Pareto distribution. Point of fact: the Pareto concept is just too important to be ignored, even by the "bell-thinkers".

The Pareto distribution, which gives rise to the 80/20 rule, and its close cousin, the Exponential distribution, is the mathematical underpinning for understanding many project events for which there's no average with symmetrical boundaries--in other words, no central tendency.

Jurgen Appelo, an agile business consultant, cites as example of the "not-a-bell-phenomenon" the nature of a customer requirement. His assertion: 

The assumption people make is that, when considering change requests or feature requests from customers, they can identify the “average” size of such requests, and calculate “standard” deviations to either side. It is an assumption (and mistake)...  Customer demand is, by nature, an non-linear thing. If you assume that customer demand has an average, based on a limited sample of earlier events, you will inevitably be surprised that some future requests are outside of your expected range.

Average is often not really an average
In an earlier posting, I went at this a different way, linking to a paper on the seven dangers in averages. Perhaps that's worth a re-read.

So far, so good.  BUT.....

What's next to happen?
A lot of stuff that is important to the project manager are not repetitive events that cluster around an average. The question becomes: what's the most likely "next event"? Three distributions that address the "what's next" question are these:

• The Pareto histogram [commonly used for evaluating low frequency-high impact events in the context of many other small impact events], 
• The Exponential Distribution [commonly used for evaluating system device failure probabilities], and 
• The Poisson Distribution, commonly used for evaluating arrival rates, like arrival rate of new requirements

Even so, many "next events" do cluster
But project managers are concerned with the collective effects of dozens, or hundreds of dozens of work packages, and a longer time frame, even if practicing in an Agile environment.  Regardless of the single event distribution of the next thing down the road, the collective performance will tend towards a symmetrically distributed central value. 

For example, I've copied a picture from a statistics text I have to show how fast the central tendency begins.  Here is just the sum of two events with Exponential distributions [see bottom left above for the single event]:

Good enough
For project managers, central tendency is a 'good enough' working model  that simplifies a visualization of the project context.

The Normal curve is common surrogate for the collective performance.  Though a statistician will tell you it's rare that any practical project will have the conditions present for truly a Normal distribution, again: It's good enough to assume a bell shaped symmetric curve and press on.

---

Buy them at any online book retailer!

Strategic leadership

---

Are you willing to follow -- or be led by -- a  leader who can't do the job you're doing?

What I'm speaking of is the distinction between the strategic leader and the operational leader

• The strategic leader is the visionary -- usually -- but most importantly is the leader that connects all the dots in the long game; allocates resources strategically; causes integration to occur for the benefit of the far future. 
• The operational leader leads by example -- can step in and do your job if necessary; more tactical and willing to make course corrections in the short term. Definitely in touch with the details

A bit tricky, this leadership thing: if you don't think your leader can do your job, do you think they are an "empty suit"? Many pin that label on the strategic leader.

It's not always clear cut:

The strategic person often has to make the tactical call at the cross roads to go this way or that way; or relieve and replace subordinates that are not performing. And, the operational person is going to engage strategic planning and engage with their Board, regardless of their main focus and agenda.

Optimistic v pessimistic

 From the concepts embedded in the "cone of uncertainty", we generally think of strategic people as optimistic in their outlook for the simple reason that the long reach gives time to make things right.

The flip side: the press of immediate actions -- and problems -- makes the operational leader more pessimistic

Situational leadership style

From the concepts of "situational leadership", we generally think of the strategic leader as the delegation person: give the tacticians all the rope they need and stand back. If they fail, replace and repeat.

Planning as a methodology

And, the strategic leader is going to put more stock in long range planning. In fact, to the strategist, the planning itself is more important than the plan. As soon as you've got a plan, you're in tactical mode. Let others do the execution.

---

Buy them at any online book retailer!

Guessing and Bayes

---

In my posting prior to this one, I gave an example of two probabilities influencing yet a third. To do that, I assumed a probability for "A" and I assumed a probability for "B", both of which jointly influence "C". But, I gave no evidence that either of these assumptions was "calibrated" by prior experience.

I just guessed

What if I just guessed about "A" and "B" without any calibrated evidence to back up my guess? What if my guess was off the mark? What if I was wrong about each of the two probabilities? 

Answer: Being wrong about my guess would throw off all the subsequent analysis for "C".

Guessing is what drives a lot of analysts to apoplexy -- "statisticians don't guess! Statistics are data, not guesses."

Actually, guessing -- wrong or otherwise -- sets up the opportunity to guess again, and be less wrong, or closer to correct.  With the evidence from initial trials that I guessed incorrectly, I can go back and rerun the trials with "A" and "B" using "adjusted" assumptions or better guesses.

Oh, that's Bayes!

Guessing to get started, and then adjusting the "guess" based on evidence so that the analysis or forecast can be run again with better insight is the essence of Bayesian methodology for handling probabilities.

 

And, what should that first guess be?

• If it's a green field -- no experience, no history -- then guess 50/50, 1 chance in 2, a flip of the coin
• Else: use your experience and history to guess other than 1 chance in 2
  

According to conditions

Of course, there's a bit more to Bayes' methodology: the good Dr Bayes -- in the 18th century -- was actually interested in probabilities conditioned on other probable circumstances, context, or events. His insight was: 

• There is "X" and there is "Y", but "X" in the presence of "Y" may influence outcomes differently. 
• In order to get started, one has to make an initial guesses in the form of a hypothesis about not only the probabilistic performance of "X" and "Y", but also about the the influence of "Y" on "X"
  
• Then the hypothesis is tested by observing outcomes, all according to the parameters one guessed, and 
• Finally, follow-up with adjustments until the probabilities better fit the observed variations. 

Always think Bayesian!

• To get off the dime, make an assumption, and test it against observations
• Adjust, correct, and move on!

---

Buy them at any online book retailer!

Schedule merge: the biggest hazard of all

---

Do you understand the risk you are running when two events come to a merging point in your schedule?

Here's the situation:

• There's a series of tasks running along on one path, call it "A"
• There's another series of tasks, not dependent on "A", running along on path "B"
• But, all the events set to begin on path "C" can't begin until everything on paths "A" and "B" finish.

In effect, the completion of everything along "A" and "B" gates, or controls, the beginning of "C".

So, where is the hazard? 

The hazard is that "C" will be late starting if either "A" or "B" are late. Actually, that doesn't sound like such a big deal, so what's the problem here? 

It's all in the probabilities. Consider this example:

• "A" probably late 1 chance in 4 [written as: 1/4], and
• "B" probably late 3 chances in 10 [written as : 3/10].

Not great, but not too bad for either one of them. But what can we say about the chances for "C"?

 

We'll show in the discussion that follows that "C" will be late approximately 1 chance in 2. That's a good deal worse than 1/4 or even 3/10. It's a biggie if you are trying to figure out when "C" is going to kick-off.

 

Reasoning with probabilities

To deal with probabilities, we have to deal with a number of chances of "A" and "B" because probabilities are determined by observing variations in the same thing over and over.

 

So, for this example, let's use the common denominator of 4 x 10 for the number of chances (*).

• In 40 chances, we expect "A" to to be late 10 times (1 chance in 4, 10 chances in 40), but on-time 30 times. Of course, "C" will be late those 10 times that "A" is late.
  
• But when "A" is on-time, 30 chances (out of 40), the performance of "B" determines the performance of "C" ("B" late makes "C" late).
  
  
• In 30 chances we expect "B" to be late 9 times (3 chances in 10, 9 chances in 30).
  But if late 9 times, then "B" is on-time 21 times
  
  
• Consequently: "C" is expected to start on-time 21 of 40 trials, or just over 50% (about 1/2)
  
  
• But, that means "C" is expected to be late almost half the time -- 10 late starts from the effects of Path A and 9 more from Path B. Altogether, that's 19 late starts out of 40  -- a serious performance degradation from either that of "A" [25% late, 10 out of 40] or "B" [30% late, 12 out of 40]
  

(*) the common denominator of 1/4 and 3/10 is 40

We can show all this with this mapping chart:

	Path A	Path B	Path C
Probably late	1/4	3/10	1 – 21/40
Probably on-time	3/4	7/10	21/40

Independence simplifies:
Notice that along the bottom row, Path C is just the multiplication of Path A and Path B probabilities
Along the top row, the probabilities in all cases are just 1- bottom row, cell by cell. [the number 1 represents all possibilities]

These calculations are only valid if Path A is in every way independent of Path B. If not, then there is cross-talk between paths that will degrade the calculations. 

But in a project, what does independence mean?

• No shared resources that could cause conflicts
• No shared lessons-learned after the tasks on Path A or B begin
• No changes in "A" because of what is happening in "B"

Now, in a in-person project, maintaining independence may be difficult, perhaps not even desired -- to wit: why not share?  But in a remote/virtual project, independence may be the order of the day, even if it is not desired. Another effect of the virtual thing, to be sure!

 

 

---

Buy them at any online book retailer!