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!