Directing attention: 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.

Metrics: some rules

---

"Management 3.0" has a blurb they call "12 Rules for Metrics"

There are a few of these I find unique and interesting, repeated here, more or less:

• "Measure for a purpose": Without using those words exactly, I have written on this topic many times. Don't ask for metrics and measurements unless you have a plan for using the data productively to advance the project
  
  
• "Shrink the unknown": This is a play on you 'can't measure everything'. Their advice: find peripheral metrics that add up to a better knowledge of that which is not directly measurable.
  
  
• "Set imprecise targets": A modern version of advice developed in post-World War II quality movements of the day, this idea is that precise targets become the tactical objective to the detriment of progress on the strategic purpose of the project.
  
  Editorial: innovation may be stifled if there is too much focus on the nearby tactical objective, to wit: be agile!
  
  
• "Don't connect metrics to rewards": Another piece of advice from the distant past which opines that rewards should be directed toward strategic outcomes.
  
  Anecdote: when incentives were placed on finding errors in code, then what occasionally happened is that coding was more near-term sloppy, knowing that putting the quality in last would be financially rewarding.

<

---

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

Are we there yet? Agile "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!

Managing idle white space

---

My advice is always to schedule loosely, spreading buffers at strategic points to protect the critical path and even the feeder paths. 

Strategically: sound advice. 

But.... If you do this, your schedule is going to have idle time or 'white space'. 

Some would look at that and see schedule dollars slipping by. 

What's a good tactical thing to do?

Begin with the team

One of the big differences between a team and a group is cohesiveness around the goal:

There's no success individually unless there is success collectively

Don't let idle ruin cohesiveness

Inevitably, keeping the team together to promote cohesiveness raises the question: 

How to keep everyone busy all the time -- other than 'painting rocks' (which is the way the Army used to do it)?

In theory it's simple: keeping everyone productively busy means actively managing their downtime, aka the 'white space', between and amongst their planned activities.

White space and the matrix

In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

Backlog and whitespace

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.

• Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
• Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
• So also bring in mock testing, special event prototyping, and, of course, that bane of all:
• Maintenance of team records.

Running cost of teams

One big advantage of managing by teams: the cost is relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each. 

Of course, many PMs are NOT comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:

The cost of a project is not its value; in a "good project", value as judged by users and customers greatly exceeds cost

Here's the memo: Manage for value! (Oh!, did I say I wrote the book?)

---

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

Asymmetrical Value Proposition

---

I've written a couple of books on project value; you can see the book covers at the end of this blog.

One of my themes in these books is a version of cybernetics:

Projects are transformative of disparate inputs into something of greater value. More than a transfer function, projects fundamentally alter the collective value of resources in a cybernetics way: the value of the output is all but undiscernible from an examination of inputs

But this posting is about asymmetry. Asymmetry is a different idea than cybernetics

"Value" is highly asymmetrical in many instances, without engaging cybernetics. One example cited by Steven Pinker is this:

Your refrigerator needs repair. $500 is the estimate. You groan with despair, but you pay the bill and the refrigerator is restored. But would you take $500 in cash in lieu of refrigeration? I don't know anyone who would value $500 in cash over doing without refrigeration for a $500 repair.

Of course there is the 'availability' bias that is also value asymmetrical:

"One in hand is worth two in the bush"

And there is the time displacement asymmetry:

The time-value of money; present value is often more attractive than a larger future value. The difference between them is the discount for future risk and deferred utility.

Let's not forget there is the "utility" of value:

$5 is worth much less to a person with $100 in their pocket than it is to a person with only $10

How valuable?
So when someone asks you "how valuable is your project", your answer is ...... ?

 

---

---

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

Scheduling: Don't do this

---

'The mistake' to avoid in scheduling is to construct a milestone-success situation that strictly depends upon two or more tasks scheduled (planned) to finish at the same time.

So, what's the big error here?

• First, as regards milestone success, each of the tasks leading into the milestone is a risk to success (success means: it is achieved on time)
• Second, total risk is the product of all the input risks (as seen by the milestone) . 
• So, whereas each task coming into the milestone may not be too risky, say by example 90/10 (*), three tasks of 90/10 each would present a risk to the milestone such that success is reduced to about 73/27 (**)

What are you going to do about this?

Bring on the time buffers! (***)

• You might be able to add a buffer on one or more of the input tasks to raise the success of that task to 99/01, or so
• You might be able to add a buffer following the milestone, such that any late success is absorbed by the buffer (This tactic is called "shift right" by schedule architects)

Reconsider the schedule architecture

• You might be able to reorganize the schedule to eliminate this milestone
• You might be able to shift resources, activities, or other criteria to change the properties of the milestone

What if there are common vulnerabilities among the tasks?

• Common vulnerabilities means the tasks are really not independent; there are couplings between them.
• The "math" of independent events, as given in the footnote below, is less accurate.
• Generally, the 'tail' situations are more prominent, meaning the central tendency around the most probable finish time "smears" out a bit, and thus possibilities further from the central figure are more prominent.

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

(*) 90 successes out of 100, or 90% chance the task will finish on time, or early.

(**) Here's a footnote to those estimates: It's assumed the two tasks are independent, meaning:

• They don't share resources
• They don't have the same vulnerabilities to a common risk
• The progress, or not, in one does not affect progress in the other

(***) A scheduled event of zero scope, but a specific amount of time, aka: a zero-scope time box.

---

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

Is Game Theory the answer?

---

In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing. —Theodore Roosevelt

Actually, that's Teddy's version of cousin FDR's famous "Try something!"

But what if it's all about a threat -- something external -- for which you have no experience?

• Call in your PMO team and brainstorm? Perhaps
• Ask the question -- what's the other guy -- the guy doing the threatening -- going to do?

And, if the other guy does X, what's your next move? With that question, you've arrived at 'game theory'

Game Theory and Project Management

Here's the set-up for game theory and project management: As project managers, we may find ourselves challenged and entangled with sponsors, stakeholders, and customers, and facing situations like the following which some may find threatening:

• Adversarial (or competing) parties find themselves entangled in a decision-making process that has material impact on project objectives.
• Adversarial parties have parochial interests in decision outcomes that have different payoffs and risks for each party.
• External parties, like legislators, regulators, or financiers, make decisions that are out of our control but nonetheless affect our project.

• The success of one party—success in the sense of payoff—may depend upon the choices of another.
• Neither party has the ability or the license to collaborate with the other about choices.
• Choices are between value-based strategies for payoff

Game theory is a helpful tool for addressing such challenges.

Specifically, game theory is a tool for looking at one payoff (benefit or risk) strategy versus another and then asking what the counter-party (adversarial, competing, or threat party) is likely to do in each case.

In the game metaphor, “choice” is tantamount to a “move” on a game board, and like a game, one move is followed by another; choices are influenced by:

• A strategic conception of how to achieve specific goals
• Beliefs in certain values and commitment to related principles
• Rational evaluation of expected value to maximize a favorable outcome—that is, a risk-weighted outcome

Tricks and traps

If you look into some of the issues raised by game theory, there are two that are important for project managers

1.  Because you don't know for certain what the other guy is going to do, your tendency is to optimize the balance between your risks and benefits. In doing so, assume (or hypothesizing) the other guy has a similar motivation: to optimize risk v. benefit conditioned on what you do.
   In this case, "you update your priors" as new insight into the competition becomes visible.
   
   Actually, this situation is not altogether stable for you, as you've made yourself somewhat hostage to the other guy. And, the other guy likewise. Everything stays in motion.
   
   
2. Or, you may arrive at a spot, called a Nash Equilibrium, where your choices are irrelevant to the other guy's choices. Thus, the other's choices provide no incentive for you to change your mind.

Challenge yourself to a game

To see how this stuff actually works, challenge yourself to a game. Tricks and traps #1 is demonstrated with this video, "The prisoner's dilemma", and then #2 is the next video in the same series that explains the Nash Equilibrium 

Oh, did I mention this is also Chapter 12 of my book, "Managing Project Value"?

---

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

Tactical brilliance; Strategic blindness

---

It happens: a successful project is a business bust. 

Put it down to "tactical brilliance but strategic blindness"

And by "strategic blindness" we mean being oblivious, either deliberately or unwittingly, to the impact to, or needs of strategic success for the enterprise. (meaning: long-term success). 

Built into that statement is this idea:

The tactical--strategic bridging difficulties could be one of mechanics at the bridge or one of attitude about even crossing over the bridge.

Root cause?

Consider this example: One of America's generals of the Gulf Wars was tactically successful but some historians--like Tom Ricks--place him in the 'circle of blame' for the "peace" that followed the major battle plan. 

Why so? Largely for statements (according to Ricks), somewhat paraphrased that addressed the military--diplomatic bridge:

I'll handle everything today, and you handle everything tomorrow

which, on its face, sounds like a clearly delineated division of effort. Everyone in their own sandbox. On the other hand, some call a sandbox a silo, meaning: no visibility.

But here's an example closer to home for PMs: 

A CCTV camera installer chose to install a camera in a large hall in the ceiling (customer requirement) but failed to consider in any way how the camera in his particular choice of installation could be maintained over the operational lifecycle. 

When queried, he said: 'My installation is the quickest and cheapest for you. Cameras last a long time; no maintenance required.' 

In the end, under customer pressure, he devised an installation which is functionally maintainable for the enterprise.

It's the interface! Or is it?

But, delineations are actually interfaces--or should be--and definitely not opaque boundaries (silos). And as project managers we certainly know about interfaces: 

• protocols for information flow (to include requirements) across or through them; 
• timing and timeliness as quality factors for the interfacing information;
• white box--black box understandings; 
• temporary stubs; and so forth.

But is it a matter of interface mechanics? Certainly not so in the examples above.

Today--tomorrow

The today-tomorrow idea is the root cause of strategic blindness: a matter of tactical optimization for tactical metrics, ignoring by mindset the larger and perhaps more valuable optimization for strategic success.

You may have read or acted upon the concept of "The Theory of Constraints". ToC argues a similar idea, to wit: That there are going to be constraints (read: interfaces) in every plan, but tacticians should not be overly incentivized for their part of the plan, lest there be excesses which only have local value and may have detrimental value strategically. 

 

ToC is all about strategic success and all about emphasizing that the mindset of tacticians along the way has to be "how can what I'm doing make the enterprise more successful in the long term?"

Hands across the interface!

There are bookshelves of advice on how to overcome silos, opaque interfaces, etc. All good, no doubt. The main message here is this (and it's a bit of take from Agile methodology):

You are not successful unless the enterprise is successful. Local metrics count little in the face of enterprise failure.

 

---

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

Project patents for AI Inventions

---

Patent an invention of an AI system?

Not so fast!

This we learn from David Miessler:

The UK Supreme Court has ruled that AI systems cannot be recognized as inventors of patents. In other words, only a natural person can be an inventor, which is fine, except it won’t stop inventors from using armies of inventor/documentation agents from not only coming up with ideas but writing and submitting all the paperwork. In the name of the human. (Read the source document here)

Will this be the position of the patent office and courts in the U.S.? Who knows, but then there is the question of enforcement of a U.S. AI patent in Europe.

---

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