Setting strategy

---

Consider this military wit, and put it in the context of a PMO.  

"There is an old—and misleading—bit of conventional military wisdom which holds that “amateurs study tactics, while professionals study logistics.”

The truth is that amateurs study only tactics or logistics, while professionals study both simultaneously.

The most brilliant tactics ever devised are pointless when the supplies needed to execute them do not exist, while all the supplies in the world are useless when a commanding officer has no idea how to effectively employ them."

Quote from "Field Marshal: The Life and Death of Erwin Rommel"

by Daniel Allen Butler

Are you the professional or the amateur?

Consider what are "logistics" in the project domain:

• Supplies and materials, of course
• Utilities, communications, and facilities (you gotta sit somewhere)
• Tools and training
• Supporting activity from Finance and Accounting (they have the money!) 
• Supporting activity from purchasing, inventory management, and receiving (they have the goods!)
• Supporting activities from the various "ilities"

If you can get that wagon train all connected and working for you, then of course there is the small matter of strategy:

• How strategic are you? Anything less than a year probably qualifies as tactics. Anything over three years and you should build in some tolerance for some business instability.
• What is the lay-line to your strategic goal, and of course, what is your goal?
• How much deviation from the lay-line can you tolerate for agile tactics (zig and zag along the lay-line)
• Can you be strategic on some elements of the 'balanced scorecard' and simultaneously tactical on others(*)?

Got all of the above together? 

Good. Now(!) you can entertain tactical moves, knowing the support is there.

_________________________

(*) Balanced scorecard: Finance, Customer, Product, and Operating Efficiency

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

AI clip art is coming to a PPT near you

---

"Generative AI" is mainstreaming seemingly everywhere since coming on the scene in 2018 as described by a paper from OpenAI.

Introduced in 2020, we've had GPT-3, a text-to-text auto-generation system, commonly used in natural language translation where context is integrated into the translation; and for text generation from simple prompts. (*)

The next thing up the generative AI ladder is text-to-image. And for that the AI folks have multiple competing systems: DALL-E-2, Midjourney, and Stable Diffusion. And some have started to 'generative AI' video built on top of Stable Diffusion.

Microsoft has had a strong investment position in generative AI for some years with its partnership with OpenAI. Now we see some of this effort mainstreaming for the casual user. Several posts like this one have announced the coming generative AI capability in MS Powerpoint -- built off DALL-E -- for generating clip art from text prompts.

In combination with text-to-text for presentation animation, this could be a biggie for presentations, proposals, marketing material, and really anywhere imagery is used throughout the project. This is especially interesting when you get to architecture and physical design.

 

Of course, for the casual user, this may be a bridge too far, meaning that without some experience the tweaking required to get a clip art that is really illustrative of your point, this may be too much trouble -- at first.

But for the power user, AI may be just the trick for really clever and appealing art to illustrate project materials. 

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

Look here for more on GPT-3

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The first two questions in Risk Management

---

Doing a little risk management?

Here are your first two questions:

1. Can I afford the downside? (Interpret that question with these rewordings: In effect, can I afford to let the risk go unmanaged, or can I afford to take the risk, given I have a choice?)
   
   
2. Can I improve the chances that the risk event won't happen, or can be somewhat mitigated, if I can obtain more knowledge? (This is the classical epistemological question in risk management)

Given all the climate issues of hurricanes, fires, tornadoes, and melting ice sheets, who's not asked those questions, not only for their personal situation, but also for their business and project situations?

In Florida, around the Kennedy NASA spaceflight center and the Canaveral Space Force Base, those questions are always Topic A. For the hurricane Ian in September, 2022, at great expense and loss of schedule, the Artemis I rocket was rolled back several miles from its launch pad to the safety of the Vehicle Assembly Building. 

• Increasing knowledge of the hurricane approach clarified and quantified the risk to the on-pad vehicle
• Loss or damage to the vehicle was perhaps not "unaffordable" but certainly would have been costly not only in absolute value, but enormously costly in utility value (public perception of NASA decision making; cost of investigations; threats to budgets; etc).
  Ergo: NASA mitigated by avoiding the risk of the on-pad of exposure.

Actually, if you follow the pre-launch protocol of any of the NASA, Space Force, or private launches, they are manifestly one of asking those two questions on literally hundreds of risks, threats, and vulnerabilities. 

But of course, it's not only launching space vehicles where these two questions come into play. Almost everything from going to work in the morning to running any kind of project day-to-day is going to engage these two questioins.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

A comment on Architecture

---

"Architecture" has been in the PM-domain commentary more and more as rapid and flexible methodologies compete with more experienced ideas.

• It's been said, correctly, that architecture is where functional utility is addressed first (*)
• And it's been said, again correctly, that architecture generally imposes, usually conforms to, and applies the construction and integration rules for the domain of the project. (**)
• It's been said, repeatedly by me and others, that every project has architecture (and an architect) even if somewhat buried in other tasks and roles, because everything virtual or real has an architecture

But beyond rules and utility there are myriad components to architecture

• It expresses the art contained within the domain. In software, there is definitely art!
• It expresses the culture of the context in which the product or outcome will live
• It provides coherence and organization to the entity under development

Architecture and system engineering share a lot of the same goals for organization, coherency, and predictable performance. 

• System engineering focuses hard on interoperability of the sundry pieces and parts, making interfaces work smoothly, and being the keeper of the flame of cybernetics, anti-fragile, and anti-chaos. 
• And system engineering often morphs into system test for validation and verification.
• Whereas architecture often morphs into softer elements such as appealing design and fit-to-culture.

All said, as long as what you are building is itself divisible -- and pretty much everything above the atomic level is -- then there are both architectural considerations of integration and system engineering choices at interfaces.

What about rapid and evolving methodologies?

These usually are focused at a level below architecture and system engineering. Usually the focus is on rapid or evolutionary development. In the case of Agile methods, there is a lot of flexibility allowed within the general constraints of interfaces. Architects and SEs work at the black-box level; Agilists work on the internal white-box solution

____________________

(*) "Utility" is the measure of effective value vs actual value. If you don't like it, if you can't live with it, or if it means little to you, it has little utility to you, although others may find its actual value quite satisfactory. The classic explanation is a poor person with $10 in their pocket vs a rich person with $10. The utility of $10 to the poor person is very much more than it is to the rich person.

(**) One only has to look into the architecture issues of the Sydney opera house to appreciate how the architect pushed conformity to construction rules to the limit 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Join the 'practicals' with 'virtuals'

---

Have you noticed this?

Have you noticed that some people seem firmly planted and comfortable with their surroundings, but there are others that can't operate a hammer or a screwdriver?

Have you noticed that on many projects there is a unofficial segregation of the workforce something like this (*):

• The "practicals" who live and work and think in the physical world (whether in the office, or not)
• The "virtuals" who live and work and think in the remote, virtual, and digital space (even if they go into the office)

Join things up: Leverage the differences and make it an "And":

In the best of all cases, the win-win is to leverage the conjunction of 'practicals' and 'virtuals' as a reinforcing join of culture, skills, and interests. 

Architecture is a good place to start. How could you build a new "anything" without both working together: Design, analysis, construction? 

Have you ever looked closely at a sweeping fly-over highway bridge, as a good example? 

• How do they get those massive iron beams to gently curve over hundreds of feet and join seamlessly with the next? 
• How do they get the concrete columns to have just the right arc to give the roadway above the right degree of bank on the curves? 
• How would the CAD ever match up with the 'physicals' who drive the rivets and build the molds if they didn't work together ... rather than apart.

Practicals Versus Virtuals

'Versus' doesn't buy you anything

Instead of the joy of a 'reinforcing join', the opposite may be a dis-attraction, rejection, or tension between strangers from two spaces: physical and virtual.

In systems terms, there may be little or no throughput, poor gain on resources committed, and outright hostility. Obviously, there is nothing to be gained by being at loggerheads about the differences in experience, attitude, and values. Those who can type should also be able to use a screwdriver; but it works the other way around also. 

But, in fact, the cultural divide can be a chasm: pay, promotion, recognition, status, security to name a few of the HR issues, but also respect, arrogance, and elitism that unwittingly divide rather than unite, to say nothing about herd loyalty and commitment to win-loss.

If there were an answer ...

If there were an answer for this, other than self-awareness and walk-in-their-shoes exercises, I would put it down in the next paragraph

But, there is no next paragraph .....

++++++++++++++

(*) Credit to Ross Douthat for the idea of 'practicals' and 'virtuals'

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

About data; here's the first rule

---

The first rule of data:

• Don't ask for data if you don't know what you are going to do with it

Or, said another way (same rule)

• Don't ask for data which you can not use or act upon

 And, your reaction might be: Of course!

But, alas, in too many PMOs there are too many incidents of reports, data accumulation, measurements, etc which are the progeny of PMO doctrine. But the reality is: There actually is no plan for what to do with all this stuff that comes in. 

Sometimes, a data collection is just curiosity; sometimes it's just blind compliance with a data regulation; sometimes it's just to have a justification for an analyst job. 

But sometimes, there is a "feeling" that if such data is not coming in and available that somehow you're failing as a manager. Afterall, one view of management is to measure, evaluate, and act. If you're not doing the first step, how can you be managing effectively? Ergo: measure everything! Somehow, the good 'stuff' will then rise to the top. (I submit "hope" and "somehow" are not actually good planning tools)

The test:

 If someone says they need data, the first questions are: 

• What are you going to do with the data?
• How does the data add value to what is to be done
• Is the data quality consistent with the intended use or application, and 
• Is there a plan to effectuate that value-add (in other words, can you put the data into action)?

And how much data?

Does the data inquisitor have a notion of data limits: What is enough, but not too much, to be statistically significant (*), informative for management decision making, and sufficient to establish control limits?

And information?

Well, the usual definition is that information is data, perhaps multiple data, integrated with context, and interpreted for the current situation.

So, the rule can be extended: If there are not means to process data into information, is the data necessary to be collected?

Bottom line: To state the obvious: always test a request for data collection for value-add before spending resources!

______________

(*) Statistical significance: The observed behavior in the data is unlikely to be just a random outcome; the data is predictability attributed to something specific which can be described statistically.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

A word about threats and risks

---

Daniel Miessler has an interesting essay about threats, vulnerabilities, and risks that is worth a quick read.

He summarizes this way:

•  A Threat is a negative scenario you want to avoid
• A Threat Actor is the agent that makes a Threat happen
• A Vulnerability is a weakness that can be exploited in order to attack you
• A Risk is a negative scenario you want to avoid, combined with its probability and its impact
• The difference between a Threat and a Risk is that a Threat is a negative event by itself, where a Risk is the negative event combined with its probability and its impact

All good, but then what do you do about any one of these?

Begin with knowledge acquisition.

Any threat, risk, or vulnerability that is susceptible to reduction by knowing more about it is probably worth the investment to gather the available information, or conduct experiments, models, or simulations to put data into an analysis process 

Such activity is applying the skills and processes of epistemology which is the theory of knowledge, especially with regard to its methods, validity, and scope. 

Most important for project management, "epistemology is the investigation of what distinguishes justified belief from opinion." (Oxford online dictionary)

And, to carry it a bit further, such risks, threats, and vulnerabilities are often called epistemic risks, etc.

Truly random effects

If your knowledge study convinces you that more knowledge won't improve the mitigation, then you are in the realm of random effects which are largely unpredictable -- that is, random -- within certain boundaries. 

There are two major categories of such randomness that project managers deal with:

1. The central tendency type of randomness wherein random effects tend to cluster around a central figure, and outliers fall off and away from the central figure. This leads to the so-called "bell curve" which is usually not a perfect bell, but nonetheless the centrality is evident in the data
   
   
2. The "power law" type of randomness wherein random effects are "one-sided" and fall off roughly as the square of the distance from the main lobe. The Pareto histogram is a familiar example, as is the "80-20" histogram.

The best way to identify which of these two phenomenon is your situation is by experimentation, observation, simulation, and modelling to develop data and thereby determine the "fit".

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Stabilize your project

---

Stability!

It counts for a lot.

It implies -- for behaviors and management decisions -- predictability, reliability, under-control (but not risk-free, of course), coherent narrative, steady-state goals, and a strategy that is understandable to those who have the job of implementing it.

Perhaps you are aware, as many are, that stability requires feedback to effect error correction and trap excesses and blind alleys. 

Ah yes!

We know about feedback.

Open loop systems -- those with outcome but no feedback -- are prone to many uncontrolled and unexpected responses. Who can predict what a stimulus will do to a system that has no feedback? Actually, that's a really tricky task.

So, what about feedback? 

What's to know?

• Timing is everything! Getting the feedback "phased" in time such that it has a correcting effect rather than a destructive effect is vital. The former is generally called "negative feedback" for its corrective nature; the latter is generally called "positive feedback" for its reinforcing rather than corrective nature. And, when its too late, it's generally called ineffective.
  
  
• Amplitude, or strength, or quantity is next: It has to be enough, but not too much. Tricky that! Experimentation and experience are about the only way to handle this one.

What could possibly go wrong?

Actually, a lot can go wrong.

No feedback at all is the worst of the worst: the 'system' is 'open loop', meaning that there are outcomes that perhaps no one (or no thing) are paying attention to. Stuff happens, or is happening, and who knows (or who knew)?

Timing errors are perhaps the next worst errors: if the timing is off, the feedback could be 'positive' rather than 'negative' such that the 'bad stuff' is reinforced rather than damped down. 

Strength errors are usually less onerous: if the strength is off, but the timing is on, then the damping may be too little, but usually you get some favorable effect

Practical project management

Feedback for correcting human performance is familiar to all. Too late and it's ineffective; too much over the top and it's taken the wrong way. So, timing and strength are key

But, the next thing is communication: both verbal and written (email,etc). Closing the loop provides reassurance of the quality and effectiveness of communication. You're just not talking or writing into the wind!

And, of course, in system or process design, loops should never be open. Who knows what could happen.

I should mention:

The study of feedback systems generally falls within what is called 'cybernetics'. As described by sciencedirect.com, MIT mathematician Norbert Wiener defined cybernetics as “the study of control and communication in the animal and the machine." 

From Wikipedia, we learn: The core concept of cybernetics is circular causality or feedback—where the observed outcomes of actions are taken as inputs [ie, feedback] for further action in ways that support the pursuit and maintenance of particular conditions [ie, 'ways that support' requires the correct timing and strength]

---

 
Like this blog? You'll like my books also! Buy them at any online book retailer!