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!