Regression to the Strategy

---

Regression -- as a process -- is an analytical look back through past events (that relate to one another) to find or calculate a smooth path or relationship that more or less represents an optimum way through the events (or dots, or data). 

Optimum in this situation means that the "best" regression path is that path for which the distance or divergence from the regression path to any particular event is as minimum as possible. 

Regression as strategy

One interpretation of the regression path that is useful for project managers is that the regression path is the overall strategic path, and the events or dots or points off the path are the tactical outcomes in the moment. 

The tactical outcomes pull on the strategic path to go this way and that way; thus, the overall strategic outcome is dependent on the tactical outcomes .... but we would expect that consequence. 

Other stuff that matters

One more event: Regression analysis can provide valuable insights, such as determining the strength and direction of the direction the strategy might take with one more event pulling this way or that way. 

In the image above, if the big dot in the upper right is the desired strategic outcome, then some adjustments to tactics are going to be required to bend the trend line to the desired target position. 

This situation is the project management challenge: how to use the insight from regression analysis to fashion a path to the target.

A bit about forecasting:  Technically the regression line is not valid outside the observed events. Thus: be wary of any projected outcome based exclusively on historical performance. This is the bane of earned value calculations which project linearly based on historical performance.

That all said, consider these ideas: 

Patterns and Trends: Regression analysis can identify patterns, trends, and relationships in historical data. These patterns can provide insights into future behavior , assuming that the underlying conditions and relationships remain stable. In projects, that assumption is always being tested.

Sensitivity Analysis: Regression analysis allows for sensitivity analysis, which involves examining how changes in the tactics impact the strategy. Sensitivity analysis is also another name for "efficiency" analysis wherein you look for how efficient resources are being used, and what is the marginal value of the next increment of resource.

Some caution, repeated: It's important to note that regression analysis relies on certain assumptions and limitations. Extrapolating relationships beyond the range of observed data or assuming that historical patterns will continue unchanged in the future can introduce uncertainties and errors. Therefore, when using regression analysis for future predictions, it is crucial to consider the limitations and exercise caution while interpreting the results.

Bottom line: Yes, it is possible to conceptualize the optimum path in regression analysis as a strategic outcome and the push-and-pull drivers as tactical inputs. This analogy can be helpful in understanding how regression analysis relates to strategic and tactical decision-making.

---

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

Cost and Schedule, but Cost before Schedule?

---

Cost, schedule, scope, and quality. 

Everyone in this business has a familiarity with those four parameters

Everyone knows that even if they are fixed on paper in the project plan, they are fluid in practice.

How fluid? And who manages the fluidity?

The answer to the second part is easiest to say: You do the managing, meaning you as PM or PEO.

And to the first part, there's always cost and schedule, but in the crunch, if you're a business or a government guy or NGO spending the taxpayer's or donor's money, cost always comes before schedule.

Meaning what?

• Meaning that money is more precious than time; it's a matter of scarcity that determines value.
• Meaning that more forgiveness is granted for lateness than for cost overruns.
• Meaning that the political and business sensitivities to money are always greater than they are for time. This is a form of 'utility' bias. Losing money is agonizing, often out of proportion to the factual loss; not so much with time.

Until it's not

Ooops! There are time-sensitive projects to be sure where you'll peay any price to make the milestone. Sometimes lives depend on timeliness; sometimes, there is a business deadline that simply expires at midnight. In this event, you flip the utility curve around and pay the price 😟

---

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

Shall, will, and may

---

You shall ...

I will ....

You or I may .....

Heard these phrases before?

What to make of them?

Actually, if you're sitting in the PMO reading a contract or other legal document handed to you by your contract's administrator, or you're on the other side helping to write an RFP , then these words are important.

• "Shall" should be understood to be directive without discretion to act otherwise. Take 'shall' to be a synonym of 'must'. Usually, the context is that 'you' tell 'them' that they 'shall' do something.
  
  
• "Will" is the other side of the table. When I impose a 'shall' on you, I often give myself a corresponding task. In that event, "I will" do something in the same context that I impose on you a "shall". "I will" should be taken as a commitment, just as "You shall" should be taken as a directive.
  
  
• And then comes "may". A task constructed with a 'may' is discretionary on you and I. We may do it; we may not

All clear? You may close this posting.

---

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

"Command Presence"

---

I once had a colleague, who I admired greatly, be demoted from a vice-president position for lack of "command presence" (his telling of the reason)

And, so what is "command presence" and is it something to strive for? Can it be learned? Can it be taught?

Here's a few ideas on the topic:

It's about personal qualities and behaviors

Command presence refers to a set of qualities and behaviors that encompasses the ability to project confidence, assertiveness, and control over a situation, as well as to inspire respect, trust, and obedience from others.

Perhaps the phrase brings up an image of a military leader. Rightly so. But it's evident wherever leadership and the ability to influence others are important.

Is it "command and control" dressed up to be more palatable? It can be, but it shouldn't be. Command presence can be felt effectively in horizontal organizations as well as more vertical structures.

Judge for yourself as you read on:

You've got it when you've got:

Confidence: In a project situation, individuals with command presence exude a sense of self-assuredness and belief in their abilities, bordering on arrogance. They display confidence in their decision-making, communication, and problem-solving skills, which if directed toward objectives understood by all,  helps to instill trust and reassurance in others.

Calmness under pressure: Command presence involves the ability to remain composed and level-headed in challenging and stressful situations. 

Assertiveness: Command presence requires individuals to assert their authority and communicate their expectations clearly and firmly. 

Saying "no to power" is often part of the job jar. So is picking your moments to say 'yes'.

Individuals make decisions decisively, without hesitation, and are not easily swayed by external pressures. Of course, that can be borderline stubbornness, but one can be assertive and still be convinced by new evidence (Bayesian thinking) 

Physical and vocal presence: This is not about the big-guy small-guy syndrome. And it's not about being the verbal bully in the room. Be aware of your non-verbal cues which play a significant role in command presence. Maintain an upright but casual posture without being rigid, maintain eye contact, and use strong and confident body language. Speak with a clear and authoritative voice, commanding attention and conveying a sense of purpose.

Knowledge and expertise: Leaders with command presence possess a high level of knowledge, skill, and experience in their field. But, at the same time, they are respected for their respect of others who have the expertise in the moment.

Respect and empathy: While command presence requires a certain level of assertiveness, it is important for leaders to also demonstrate respect and empathy towards their subordinates. By showing understanding and consideration for others' perspectives, leaders can foster a positive environment and build stronger relationships.

Can it be learned? Can it be taught?
Yes, and yes

Developing command presence is a lifelong journey.

It's a learning exercise that involves honing one's communication skills, emotional intelligence, self-confidence, and expertise. 

---

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

Building the Appian Way

---

As a project, the Appian Way was monumental for its time: Phase I, built in only one year .... 312 BCE ... the paved road (originally, a military road) cuts through the Alban hills and the coastal Pontine marshes to connect Rome to far southeast Brindisi.

But think about this: the Project Executive Officer, PEO, one Appius Claudius Caecus, did not have a couple of tools at his disposal that we so routinely use that they are not even noticeable:

• There was no "0" in the Roman system of math. "Nothing" was not a number. Roman numerals are/were for counting and positioning (ranking, or ordering), but not for measuring. Today, we say that Roman numerals are "cardinal" numbers, meaning numbers that are for counting.
  
  How did Caecus calculate his project variances? Was zero-variance not a possibility, given no '0" in the system?
  
  However, to build a road, you've got to be able to measure things. So, when it came to measuring and dealing with quantities, the Romans relied on a separate system known as the Roman system of measurement. This system was based on various units and standards, such as the foot (pes), the inch (uncia), the palm (palmus), and the cubit (cubitus), among others. These units were used for measuring length, weight, capacity, and other quantities.  
  
  
• There were no fractions in their system of mathematics, even though a pseudo-system of fractions existed in ancient Egypt. Maybe if Marc Antony has been around three centuries earlier, he could have brought fractions home.
  
  
• And, there were no negative numbers. This concept is almost middle-ages in its origin. Not until the 16th century did negative numbers really come into general mathematics. 
  
  Does this mean that Planned Value - Earned Value (*) was always positive? That if circumstances were such that at some point EV were greater than PV, a negative number to be sure, that Caecus could only describe that he was ahead of plan, but couldn't calculate it?
  
  
• And, of course, there was no concept of random effects and probability.
  Those effects were left to the Gods. (See my review of the book on risk management entitled "Against the Gods")

They did it

So, somehow, the Romans built a magnificent road, parts of which survive today, without a "0", without fractions (formally at least. One can imagine half a cubit, even if they can't formally express the idea), and without negative numbers. 

I wonder if I could run a PMO without these tools? Doubtful! And, my PMO would also have random numbers and systems of probability which also did not come along until about the 18th century.

_____________

(*) PV - EV is a variance, calculated at a specific point in time, that indicates positive or negative schedule variance. You've either earned what you've planned at the right time, or you've not. Some caution, however: this formula is only valid for only the duration of the baseline timeline of the project; it's not valid thereafter. Example: It's invalid to be a year late beyond the baseline delivering all the EV, and then declare that PV - EV is 0, thus no schedule variance!

---

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

Working on a proposal? Some ideas ....

---

Do you read Mike Clayton? You probably should.

Here is his idea of the 12 points of a perfect proposal, augmented and paraphrased with my spin on it.

 

You (better: your value-add)

If you've been solicited by "them" to present a proposal, then "they" already know a good deal about "you". Your (very short summary) narrative should reinforce what they already know about your value-add to their need.

But for an unsolicited proposal, "you" need an opening narrative to introduce and present your value as though you were addressing a stranger. In other words: "Why me?"

Think of this opening narrative as your "elevator speech" ... 30 seconds to set an "anchor" and make yourself "available". Typically, a headline to grab attention and then cover letter or some other means to establish your credibility - in effect, your bona fides.

You're working two biases: "Availability bias" There's value in the fact that you're here and now, so no need to look further. And "anchor bias", your "ah hah!" value hooks them on your offer.

And, in many instances, "you" may be a partnership of literally "you" and others that make up your "team" or partnership. Such makes the introduction and "why me" statement all the more complex, but perhaps all the more compelling.

Them

"Them" are your customer. What they want to know is ... What's in it for them? It's your value-add from their point of view. Show how you have their best interests in mind with this proposal. You understand their needs and desires and know how to satisfy them better than any alternative solution can.

Focus (sans boilerplate)

Any sign of standard 'boilerplate' descriptions, arguments, or evidence will make it look less about 'Them' and more about 'anyone'. 

But focus may be a tricky thing: "They" may want a product, or a service, or product + services. They may want the product, a data package about the product for support purposes, training on operations and maintenance, a warranty, or service-after-sale. 

How does their sense value apportion among all these needs? In a competitive situation, "they" will usually signal their priorities through a list of evaluation criteria for selecting the winner. These criteria should give you guidance about where does the main focus needs to be. 

Value and Benefits

How will your proposal deliver and maximize value to them? The vast majority of business decisions revolve around the capacity to either make money or save money. 

Can you answer this question? Do they go for "best value" or "lowest cost"? If you're not the low-cost provider, then your job is to convince them that your price premium brings unpriced value.

But, if you are addressing government offices, non-profit NGOs, self-help and self-improvement, and other opportunities not oriented to financial gain, then look to the other elements of the "balanced scorecard"(*), the customer's mission and strategic objectives, and of course the evaluation criteria for where you can add value.

Emotions

All that hard evidence gives them a reason to make the decision to accept your proposal. But it may not motivate them to do so. For that, you need to tap into their emotions and biases.

Find emotional hooks into pride, fear, duty, desire, ambition, loyalty, passion... 

Exploit the biases of "availability" and "anchoring" to your idea.

Clayton's opinion: Emotions drive decisions: reasons justify them.

How

So, you also need to show how your proposal will solve their problem, deliver their joy, or enhance their reputation. Make the link between what they want and what you are proposing as clear, simple, and short as you can. .

Process

Next they need to know what will happen if (when) they say yes. What will you do, what will they do, and how long would it all take? For confidence that your is the right choice, they need to see a plan that clearly works.

Context

This section lets them understand how your proposal fits into your life and theirs - your business and their own. This shows that you and they are compatible and is the equivalent of the more traditional (cheesy) 'how we are different to the competition'. Of course this differentiates you. It shows how this proposal is right for them and for you.

Business

Don't go all techy unless they've asked for a technical proposal. Remember who you are speaking to. If your audience is a business person or a group of businesspeople, focus on the business. If your audience is software engineers, focus on the business of software engineering: not the hardware. What is their business? That's how to frame your proposal.

Structure

I get it. You have a lot of ideas to get down. But, before you start, develop a structure that makes it compelling for them to follow. If they asked six questions in a sequence, then a great structure is to answer those six questions... in the same sequence. Make it easy for them to say 'yes'.

One thing: If they have provided a proposal outline to follow, page limits, drawing or illustration or image specifications, and overall format, then don't experiment. Make it easy for them to think highly of you for making it easy for them because they can directly use your proposal materials. There is almost nothing worse than making them reformat or search for content when they told you explicitly what to do

Quality

Finally remember Mark Anthony's advice: 'The evil that men do lives on. The good is oft' interred with their bones'. People remember your mistakes and easily forget all the good stuff. Make sure you check the quality of your proposal, not once, not twice... Better still, get the pickiest, most pedantic person(s) you know to be your "Red Team". You invested all that time. Now add a little more investment, to avoid throwing it all away!

What does a "Red Team" do?

• Working from your perspective, they are editors, fact checkers, and readers for both content and flow
• Working from your customer's perspective, they are challengers to your solution, and they are challengers to whether you've checked all the boxes and met all the requirements of a specified format.

_______________

(*) Balanced Scorecard for a business: Financial, Customer Needs, Operations and Operations Efficiency, and Organizational learning and development

---

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

Agile "Definition of Done"

---

Now we're getting somewhere! No less an Agile/Scrum eminence than Mike Cohn -- author of some really good books and articles -- has come out with a newsletter on -- are you ready for this? -- what's the meaning of DONE in Agile.

His acronym, a bit a poor choice to my mind, is "DoD"... Definition of Done. But, there you have it... perhaps a new GAAP "generally accepted agile practice" for agile-done

In the past, my definition of "Done" has been framed by the answers to these three questions:

1. Is it done when the money or schedule runs out?
2. Is it done when the sponsor or product manager says it's done?
3. Is it done when Best Value* has been delivered?
   * The most ,and the most affordable, scope within the constraints of time and money

If you can't read my bias into these questions, I line up firmly on #3.

Cohn instructs us differently:
A typical definition of done would be something similar to:

• The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
• The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
• The code was either pair programmed or peer reviewed.
• The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
• The feature the code implements has been documented in any end-user documentation such as manuals or help systems. 

Cohn hastens to add:
I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels.

Now, I find this quite practical.. Indeed, most of Cohn's stuff is very practical and reflects the way projects really work. But it's very tactical. There's more to a product than just the code. In other words his theory is proven when, in the crucible of a trying to make money or fulfill a mission by writing software, you are strategically successful (deployable, saleable, supportable product) while being simultaneously tactically successful. How swell for us who read Cohn!

---

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

Think often, think critically

---

Boom! Sometimes we react without conscious thinking. That's survival impulses kicking in.

But there are not a lot of "booms!" in the PMO.

Thus, there's time to think.

And thinking is what occupies most of the time in the PMO domain.

So, if thinking is what we do, then we should be thinking of the quality of our thoughts.

And for quality in the large sense, we should "Think critically"

Critical thinking can be about a lot of things, together, independently, holistically with the environment. Common components are these:

Analysis: Breaking down complex ideas or information into smaller parts to understand their components and relationships. This is process-thinking to reduce or deconstruct complexity.

Evaluation: Assessing the credibility and quality of information, arguments, and sources by examining their strengths, weaknesses, and biases. Especially the biases, of which there seem to be an almost endless list.

Inference: Drawing logical conclusions based on available evidence, reasoning, and patterns. But don't stop with the first inference you make: Bayesian reasoning comes in here: test the hypothesis; gather more evidence; modify the hypothesis, and test again. Repeat.

Interpretation: Making sense of information and identifying underlying meanings or implications within the context of the project, the business, or the environment. Interpretations are always situationally sensitive.

Problem-solving: Identifying and defining problems, generating and evaluating potential solutions, and selecting the most effective course of action .... which may be prototyping and experimentation to ascertain risks and practicalities of the chosen course.

Reflection: Examining one's own thought processes, assumptions, and biases to enhance self-awareness and improve future decision-making. This, you might say, is another Bayesian process.

---

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