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!

Public access to Government research

---

Since at least 2013, there's been a push from the President's Office of Science and Technology Policy to make as much as possible of government sponsored research available to the public for free.

On August 25th, 2022, this policy initiative of access to government research got another push when OSTP published more detailed and aggressive guidance to the executive departments.

What was behind pay walls and other barriers may now be in the free public domain. 

Your project might benefit.

Check it out.

---

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

Working for an enterprise with Agile

---

Applying agile methodology in your software project? Good!

Working for an organization large enough to be called an 'enterprise'? Probably that's good.

Why so?

• Access to resources is the main reason. You may have heard that agile is all about small self-directing teams -- yes, that's part of the doctrine.
   
• But how many teams are needed for your project? Dozens? Hundreds even? Where do those people, tools, training, facilities, communications, etc. come from? And who pays for all that?
  
  
• Answer: the Enterprise.
  

Ah, yes, the enterprise has money!

And where does that money come from? Not you, most likely. Other people! So Other People's Money (OPM) is what is funding you.

Who are these people? If an enterprise, then there are going to be a wide variety: Customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners (if privately held), or investors (if you're a publicly traded company)

Enterprise imposes expectations

So, here's the thing: even if you're doing Agile methods in an enterprise setting, the enterprise will impose expectations up front .... starting with: expected value return on resources invested.

It's natural that Agile people resist too much "up front" definition; we're about evolution and iteration. But there has to be a compromise.

It's the ageless problem: Other people's money! OPM comes with strings, to wit: a value return is more than expected; it's required.

Enterprise expects estimates (gasp!)

And here's another thing: the enterprise expects that you can estimate/forecast/predict what the resource requirements are that will get to something valuable (to the enterprise). In other words, it's rare indeed that there's a pot of gold you can dip into at your leisure and convenience, unless you're just a researcher working on your own small project.

Enterprise brings scale

What makes an enterprise an enterprise is size and scale. 

And what makes a project "enterprise" in it's scope is size and scale.

And there is the rub: Size and scale is always more than what a handful of people can carry around in their head. So, many others have to lend a hand and participate in making and supporting both size and scale. 

Scale is not just a lot of one thing, like a large code base. Scale brings breadth, meaning a lot of different things involved and integrated, and scale brings then brings rules, procedures, accountability, etc. into the frame because a lot of people have to work somewhat anonymously ... according to rules and procedures ... to bring it together, repeatedly, within predictable limits.

The question: "Can it be done what your doing 'at scale'?" Hand-crafted, job shop, one-off are not descriptions of scale.  

Enterprise brings rules

There will be a lot of rules. 

There will be a lot of rules because there will be a lot of people involved, many you will never meet, doing jobs for the enterprise you may not even be aware of, but these jobs will nevertheless touch your project or product.

Enterprise requires a narrative

Invariably, one of the rules is going to be you have to have a viable narrative to get resources committed to your project. The standard elements of the narrative you've heard before:

1. Vision: What is envisioned as the benefit to the enterprise? Who are envisioned as the beneficiaries?
2. Scope: What is it you're going to do (and what are the ancillary or consequential impacts elsewhere in the enterprise that you don't consider part of your scope?)
3. Schedule: when can you likely produce results (no single point estimates, of course. It takes a range!)
4. Resources: how much, and when (cash flow, and resource allocations)

I can't do this!

Narrative, estimates, rules, value commitments?

You're not enterprise-ready!

I almost forgot:

I wrote the book: "Project Management the Agile Way: Making it work in the Enterprise" 2nd Edition

---

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