You've been asked to write a strategic plan (ugh!)

---

Who wants to write a strategic plan?

Really, nobody, unless you are a professional planner and that's your livelihood.

But, what if you're asked to write, or help write, a plan?

Of course, you can "google" it; and you'll find no lack of help with templates and outlines and even some process.

But here's a bit from my experience.

Ask for the narrative

Asking for the narrative from whomever has asked for the plan is everybody' s favorite first step.

But it may not be as easy as story-telling:

• Maybe the sponsor knows they are in a bad spot, but doesn't know where the future is. This is a really hard one, since the future could be anywhere
• Maybe the sponsor knows what the future should be, but has no idea of how to get there. This is the easier one, since at least there is a target to aim for
• Maybe the sponsor is in name only; maybe the 'strategic plan' is called for in the standing protocols or bylaws, and the sponsor actually doesn't feel the need for the plan. This is also a hard one because committed resources to get the plan done will be problematic
• Maybe the sponsor thinks a strategic plan is just a 3-year budget plan. This will take some work to get that mindset reset.

Nonetheless, all that said and internalized, you actually do need a narrative in order to provide an organizing framework.

What are some of the questions?

The right questions to ask are situational. That should be intuitively obvious. Private sector, civil government, police-fire-military, non-profit, religious, and on we go. A lot of diversity.

Frame the questions in context with the traditional four sectors (Balanced Scorecard):

1. Financial objectives
2. Products and services, now and 'then'
3. Customers and customer service, now and 'then'
4. Operations and operational effectiveness

Financial is just not accounting. The fundamentals of the business model may be at stake. Maybe your industry is changing so rapidly, you exit for new territory.

Customers support the business model, yes, but ....  The business model exists to serve customer needs. Maybe they just don't need what you have, so something new is needed. What are the characteristics of a new or different customer base?

OE (operational effectiveness) is the tricky one for many:

• Will you need the workforce you have now?
• Should the workforce be younger or older; more or less expensive; more or less diverse; and with new or just improved skills? Can you even ask some of these questions?
• Will you emphasize remote or local, W-2's or contractors?
• Will you need the facilities you have now? Buy or lease new? Here or somewhere else? 
• "Lean" was supposed to be the OE answer, but times have changed. What's the secret sauce for effective operations going to be?

There's a lot of stuff that goes into a strategic plan. Good luck with that!

---

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

Quiet Quitting

---

One of the human resources trends going about is "Quiet Quitting". 

Has this come to a project on your street?

As in all such trends, there are numerous versions which heretofore might have been labeled "work life balance"

So, here is a bit of what to look out for:

• The 'union' version: Work to rules. Nothing above and beyond the call. Put in the required time; do as good a job as possible; then leave it all and go home. No emails and texts off hours
• The 'frustrated' version: Do the absolute minimum to get by; don't volunteer; maintain a low profile. 
• The 'anti-burnout version': Work really hard, but then leave on time; no weekends or late hours; leave it all when you leave.

Remote and virtual work can be problematic

• Some say the 'quiet quitting' is more pronounced with remote workers where job hours are super flexible
• Some companies are pushing back by 'return to the office mandates'

But then there's this:

From time to time, we all need to rebalance, rethink, and recharge. 

Many projects are recognizing the need and providing buffers and recharge time

In other words, many projects are getting ahead of "quiet quitting"

---

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

Don't risk the team (in extremis)!

---

Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

Formula  solution
Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like that lend objectivity to the process (not playing favorites, etc). Note: more on this in the "6x2x1" model discussed last

Productivity drop
Of course, the real issue is one that agile leader Scott Ambler has talked about: the precipitous drop in productivity once you reach about 70% throughput capacity of the team. Up to this point, the pace of output (velocity) is predictably close to team benchmarks; thereafter, it has been observed to fall off a cliff.

Other observers have put it down as a variation on "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . In this case, it's too many people on the team with too many interferences. It's been observed that to raise productivity, reduce staff!

Wave bounces
In the physics of wave theory, we see the same phenomenon: when the "load" can not absorb the energy applied, the excess is reflected back, causing interference and setting up standing waves. This occurs in electronic cables, but it also happens on the beach, and in traffic.

Ever wondered why you are stopped in traffic miles from the interference while others up ahead are moving? Answer: traffic load exceeds the highway's ability to absorb the oncoming cars, thereby launching reflections of standing waves that ebb and crest.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference. Like I said: the way to speed things up is to reduce the number of teams working and the number of staff applied.

WIP Limits
In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity.

Sometimes the problem arises with sponsors: their answer is universally: Throw more resources in, exactly opposite the correct remedy

6x2x1 model
One of my students said this:

"Daniel Pink  has an excellent book called Drive, the surprising truth about what motivates us. In the book, Pink talks about inspiring high productivity and maintaining a sustainable pace.

One of the techniques is the 6x2x1 iteration model. This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

You can also run a 3x4x1 model for four week iterations. Proponents of this approach have observed that the development teams will often tackle tough problems, implement significant improvements and generally advance the project during these free play periods. Without the time crunch to complete the story points the team also refreshes itself."

I don't know, but Pink's thesis may have been the genesis of the Google and Microsoft "time off" plans I've already mentioned, or maybe the experience of those plans found their way into Pink's thesis. Either way, time off matters!

---

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

If there's no Plan B .....

---

If there's no Plan B, then the first rule is "Make Plan A work!"

And it might require that you be aggressive about making Plan A work ... no fooling around.

No Plan B

Wait! Isn't there always a Plan B somewhere?
A general officer once told me: If there's no Plan B, invent it!

Insure for failure?

Maybe you can insure against the failure of Plan A. Perhaps that's your Plan B -- just get your money back, even if you forego the functional outcomes of a successful Plan A. 

But you can't go through life buying insurance for every risk. At some point, you need to ask the 'affordability' question. If affordable, don't insure it; otherwise, look at mitigations.

Losing function

But functional or relationship loss is altogether different. You can't buy insurance for that one. There really may be no Plan B.
What then?

When there's no Plan B, then you change behaviors

It's all well and good to follow the first rule: Make Plan A successful.

But mitigating a functional or relationship loss is often and largely about personal interactions, behaviors, personal risk taking, and pushing limits.
And only you can sort this; only you can assess the cost to yourself -- not necessarily dollars.

Think about the cost if there's no Plan B!

Supremely unfortunate!

---

"The supreme misfortune is when theory outstrips performance"

Leonardo da Vinci

And then there's this: 

During the technical and political debates in the mid-1930's by the FCC with various engineers, consultants, and business leaders regarding the effect, or not, of sunspots on various frequency bands being considered for the fledgling FM broadcast industry, the FCC's 'sunspot' expert theorized all manner of problems.

But Edwin Armstrong, largely credited with the invention of FM as we know it today, disagreed strongly, citing all manner of empirical and practical experimentation and test operations, to say nothing of calculation errors and erroneous assumptions shown to be in the 'theory' of the FCC's expert.

But, to no avail; the FCC backed its expert.

Ten years later, after myriad sunspot eruptions, there was this exchange: 

Armstrong: "You were wrong?!"

FCC Expert: "Oh certainly. I think that can happen frequently to people who make predictions on the basis of partial information. It happens every day"

++++++++++

Quotations are from the book "The Network"
  Like this blog? You'll like my books also! Buy them at any online book retailer!

Being anti-fearful

---

Is this the worst news possible in project management?

All the money has been spent, and nothing has been delivered ... nothing has been earned!

Yikes! What happened to get the project to this point?

Did you fear the data?

• Were you fearful of the data, unwilling to measure or unwilling to believe the measurements of value attainment?
• Or worse yet, you actually don't know how to measure value attainment.
• Or even more worse, you kill the messenger who has the data!

What value is to be attained?

And by the way, it's damn hard to measure increment value attainment if, at the outset, you have no idea of the value to be attained. (the so-called emergent project .... feed in money and hope! something useful comes out)

And here is another fear: Fearful of making and estimate because, actually, you have no idea of what its going to take to do the project. And fearful that as resource expenditures pile up that there is nothing to show for it.

Most often, that occurs when you've made no estimate of the value requirement ... project outputs ... and the corresponding inputs required for such outputs.

So, how to be anti-fearful?

• A priori estimates are a must
• Metrics that represent attainment are a must
• Data transparency is a must (don't kill the messenger or hide the message under a project rock)
• Aggressive reaction to metric data is a must
• Pro-active look-ahead where possible. 

---

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

Virtual is not face-face! Who knew?

---

" ....virtual collaboration is like evaporated milk with 60% of the water removed; safer; mostly up to the job, but a sterile version of face-to-face that leaves an unsatisfying aftertaste"

"Bartelby" columnist in the "Economist"

Our columnist goes on:

"There are downsides to being a clinically efficient worker. They include relinquishing the daily banter and complicity among colleagues..... Hyper efficiency and distance mean less opportunity for interpersonal tension but also less gratuitous job, which is hard to replicate on Zoom."

But then, on a business channel, I hear a start-up guy talking about developing a software application (alternative to Zoom, or Skype, or Webex) that has 'humanity built-in' 

"Humanity built in"! Perhaps, but let's wait and see ....

---

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

All that time! Who manages it?

---

You've no doubt read here and elsewhere that the critical path and the most important path are sometimes different, sometimes). 

How so?

The 'critical path' is a technical term arising from precedence scheduling techniques wherein a path is 'critical' if any stretch of that path stretches the very last milestone of the project.

The 'most important path' is a matter of business priorities. It's the path that gets you to the most important operational milestone for the business.(*)

For success on either path, resources are needed; schedule reserve (slack and elasticity) arising from  buffers are needed; and myriad constraints need to be overcome (see: Theory of Constraints). 

Thus the question is begged: 

Who makes all these decisions about resources assigned to the schedule, and who manages the buffers, and who manages the constraints (roadblocks)?

The buck stops with the PM, of course. 

Well, not exactly! Not all the time.
 

There's this problem: 

You've got a job to do; you've sequenced and scheduled it

But, in the middle of your critical path there is another independent project (or task) over which you have no control. In effect, your schedule has a break in its sequence over which you have no influence.

Yikes! 

This is all too common in construction projects where independent "trades" (meaning contractors with different skills, like electrical vs plumbing) are somehow sequenced by some "higher" authority.

So, what do you do?

If you have advance notice of this critical path situation, you should put both cost slack and schedule slack in your project plan, but there may be other things you can do.

 

Cost slack is largely a consequence of your choices of schedule risk management. 

Schedule risk management may have these possibilities:

• Establish a coordination scheme with the interfering project .... nothing like some actual communication to arrive at a solution
• Schedule slack in your schedule that can absorb schedule maladies from the interfering project
• Design a work-around that you can inexpensively implement to bridge over the break in your schedule 
• Actually break up your one project into two projects: one before and one after the interposing project. That way, you've got two independent critical paths: one for the 'before' project and one for the 'after' project

 At the end of the day: communicate; communicate; communicate!

---

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