Velocity is not what it used to be

---

Velocity?
Yes, velocity is rate that the project can produce "throughput" [the stuff that is valuable to the customer, not the detrius of project paperwork]

Some things are running a bit slower than it used to be:

• Supply systems are more choked because workers and materials are missing and limited along the way
• People on H1B's are MIA
• Relationships are slower to develop virtually, robbed as they are of the bonding experience of informal interaction
• Processes are being redesigned -- and debugged -- on the fly to accommodate virtualness
• Metrics and measurements are not entirely relevant the way they used to be; changes are required to get relevant again
• Lack of office and campus perks are pushing the labor force to less efficient workdays

Ah, but some things may be better -- or run faster -- where there is less:

• Complexity of communications declines exponentially with fewer participants [there are 8 ways to arrange communications between three people, but 15 ways with four people]
• Lean may be in for a new renaissance: we just don't need some stuff, and so pitch it!
• Some costs may be less as physical space is used less

But then there are hazards that could be velocity speed bumps, some new, some more intense:

• Your pay may become "localized" to where you are. If you're in the country, you may not lose any salary, but you may be capped
• Culture changes may go to quick-step. Can you keep up?
• Cyber security is on everybody's list. Working remotely provides entry for all manner of hazards
• Lack of spontaneous interaction, which is the seed corn for innovation, may slow down new ideas, but then: who would know if the idea never pops up?

---

Buy them at any online book retailer!

Don't ask for data if ...

---

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 the PMO there are too many incidents of reports, data accumulation, measurements, etc for which there actually is no plan for what to do with it. Sometimes, it just curiosity; sometimes it's just blind compliance with a data regulation; sometimes it's just to have a justification for an analyst job.

The test:

 If someone says they need data, the first question is how does it add value to what you are doing, and do you have a plan to effectuate that value-add?

Do you have a notion of data limits: enough, but not too much to be statistically significant, and control limits for useful -- or not -- metrics.

And information?

Well, the usual definition is that information is data, perhaps multiple data, integrated with context and perhaps 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 for value-add before spending resources

---

Buy them at any online book retailer!

Looking for the unique

---

"When I plan a project, the first thing I do is make a list of what's unique  .... what will my new and untried experiences be for myself and my team, and what's new for the customer: will they see the value?"

Not actually me, but others whom I respect say this

It strikes me that what is said above is just common sense; profound in its plainspoken words
But, then what?

Having identified the unique, and made the list, one must go on to prioritize the importance of dealing with each. There are matters of risk management, cost-to-benefit, and the simple fact that managing more than a dozen objects in a class is just beyond the pail for most.

Of course, you can distribute the load and delegate to others to take on their dozen objects, and thereby get more breadth and perhaps depth.

Kano Analysis
At this point, there is something to be said for Kano Analysis. The value of unique -- as viewed from the customer side (an Agile principle applicable to all projects) -- has multiple characteristics:

• Some truly unique outcomes will be ignored by customers; they are "indifferent" about them, and perhaps only if missing do they cause a customer to fuss
• Other unique stuff is the real ah-hah! of the project. This the customer reacts to strongly
• And then there that which is somewhere between indifferent and ah-hah!

Allocating scarcity
The first rule of resources is there's never enough. And so, to the unique there must be allocations of scarce resources, and thus the PMO is paid the big bucks to manage who gets what.

At the end of the day, if done "right" as judged by sponsors and customers, the PMO is rewarded with the chance to do it all over in the next project. How swell!

---

Buy them at any online book retailer!

Mapping project value-add

---

To get things in the right sequence, let's define "value-add" before talking about mapping value-add

Simply put, insofar as one-time projects are concerned (setting aside repetitive services, etc):

Value-add is anything you can make out of stuff -- to include intangible stuff -- that is ultimately delivered to the customer, or makes the deliverable a good thing in the customer's eyes.

And so, the mission for the PMO becomes: build and deliver value to the customer. Such implies a process to acquire "stuff". Then to mix, modify, and assemble; test, package, and deliver.

Fair enough
And so, how to lay out this process?
Enter: Value stream mapping

Value stream mapping
Value stream mapping may look like a new label on old wine. But even if that is so, the wine ages well. In the old days, we simply called it process mapping.

• Activities are usually arranged in finish-to-start precedence; 
• Feedback loops are established to promote stability; 
• Points of control, and control limits are established; and
• Value is accumulated, step by step.

Some would call this an earned-value view of value mapping. Fine with me.

Getting lean
Value stream mapping derives from the Lean community, where of course the focus is on leaning out non-value add. So, in value stream mapping, each activity, to include workflow steps, and other governance and ancillary activities, like a trouble report or a status report, are evaluated for value-add. Presumably, such an evaluation leans out the unnecessary detail and complexity of too many rules.

A lot of governance would not fit the value-add definition directly, but most indirect activities don't. Nevertheless, most practical organizations can't live without some non-value overhead that goes along with everything.

The map
One thing I do like about value stream mapping is the clarity of the diagramming. Take a look at this diagram:

If you're interested in more, this diagram came from a nice post at LeadingAnswers

---

Buy them at any online book retailer!

Three C's of PM

---

Usually, I say the 'three C's' of PM are:

• Communicate
• Communicate 
• Communicate

Which, in actionable terms are:

• Tell them what you're going to tell them
• Tell them
• Tell them what you told them

But, as I view the PMO through the lens of a small business, I'm wondering if the daily thought of a PM doesn't go to:

• Capital (meaning project financing)
• Community (largely virtual these days)
• Connections (business, political, and functional)

---

Buy them at any online book retailer!

Trusting vs interests

---

After dinner, [Churchill said] that he had only one single purpose – the destruction of Hitler – and his life was much simplified thereby. If Hitler invaded Hell he would at least make a favourable reference to the Devil!

Suffice to say, a colorful way of saying that there are circumstances in which we agree that we have common interests to cooperate and solve a problem, but don't ask me to trust you, at least not without independent verification

And so one wonders: every PM text on teamwork in a project has a chapter on trust and trust worthiness.
Fair enough
But, is is possible to run a project successfully on the basis of aligned interests where there might not be trust in all its dimensions?

I submit that in the domain I worked most -- building systems for the US military and its agencies -- that often was the time I was aligned with a competitor to do a job jointly, while on the next job competing fiercely with that same competitor.

Did we trust them? Sure, to some extent, but warily. Alignment of interests requires some level of trust, but wariness and demand for verification is allowed, if not demanded.

 

---

Buy them at any online book retailer!

Good process; good outcome

---

Good process improves the chance of good outcomes and reduces unforced errors ....

Robert Gates, former US Defense Secretary

This bit of wisdom seems obviously good on the surface, except that some of our PMO and project leaders are just not process-people.

They don't think in terms of finish-to-start order, merging of parallel paths of investigation or action, or even of allocation of resources in non-conflicting manner.

And some of most esteemed political leaders are famously not process oriented, Franklin Roosevelt perhaps the poster-boy for disorganized governance.

Error containment
And so, what to do if your guy is not a process person, no matter their other talents?
Enter: systems of containment, even if subtle. Example: General George Marshall, who ran the military side of WW II, refused to meet with Roosevelt except officially, and always with an agenda.

Ah, if only the world could fit neatly on a process map!

---

Buy them at any online book retailer!