Classified projects --

---

Most of my career has been working in the black and grey world of classified projects. 

If that is your domain, heed these words:

It is the nature of classified projects that "successes are unheralded and .... failures are trumpeted"

JFK

So, if you have an idea of putting your successes on your resume, looking for your next job, gig, or career move, beware!

 

---

Buy them at any online book retailer!

Virtual collaboration: a comment

---

" ....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 ....

---

Buy them at any online book retailer!

Ghost writer and communicator

---

So, you work in project communications, perhaps directly for the PM. 

Great job, and it can be a lot of fun being creative.

In the 'old days', that probably meant long-form press releases and updates to the project web page or communications dashboard.

Today, it's those plus social media; scripts and plans for podcasts and videos; and other duties as assigned (ODAS)

But, if you're a ghost writer for the 'boss', who gets the credit? Do you have a byline as a contributor? And, does the boss get the credit for imaginative and effective writing or production when it's really you?

Welcome to the world of ghost writing. 

The person you're writing for gets the credit, usually, and you're lucky if you're recognized outside your PMO. You probably knew all that coming into the job. Why else is it called 'ghost' writing?

 

But what if you disagree in some fundamental way with the content of the communication you've been asked to write or produce? What then?

Two cases:

1. Opinion: It's not your opinion you're opining. You can write 'B' for the public, but believe 'A' privately.
2. False facts: If not about 'beliefs' but rather about misleading or even factually incorrect material, you have an obligation to push back. 

Life is too short

If you can't live with the material you're writing, then don't. Find new material; and find a way to persuade the boss to let you use it.

And if all that doesn't work, you may have to fire the boss! (Aka: get a new job)

---

Buy them at any online book retailer!

Projects and capitalism

---

'Capitalism' is in the news. And, not for the first time we're hearing about how corporations have an obligation more reaching than just the traditional shareholder value -- meaning profit maximization.

Community impact is now in the mix, more so than in the past, and that may mean capitalism will be paying attention to multiple factors beyond profit maximization:

• Environment -- a steady standby, to be sure
• Diversified workforce -- at least as diversified as the local community
• Job stability -- meaning, careful about robotics displacing workers
• Job location -- meaning, careful about remote working, virtual teams, and the lot
• Educational opportunity -- perhaps a mentorship with the local intern program or university
• Social justice -- meaning a safe workplace, and support for social justice in the community

Regardless of whether you think business should take these on, you probably think that these are 'C-Suite" issues -- isn't that what we pay them the big bucks for?

Not so fast!
There is flow-down to consider. Since at least 1992 -- ancient history for many of you -- the "Balanced Scorecard" has been a feature of business score keeping. And with it, a deconstruction and flow-down of corporate goals throughout the business.

And so, we can anticipate that such will reach to the PMO. 

Cost-Schedule-Scope-Quality
Wait! In the PMO, our thing is cost-schedule-scope-quality. Where do we fit that other stuff in?

• First effect: Scope -- some of these things will inevitably get cranked into our scope statement. Fair enough. But, scope connects to cost and schedule ..... don't forget that!
• Second effect: Cost -- it takes money to do some of these community things.
  
• Third effect: Velocity, meaning rate of throughput, meaning: schedule. No doubt some of these community things are going to slow us down .... but, perhaps a trade worth making.

Measuring the PMO
At the end of the day, project metrics should -- and will -- reflect this larger landscape. 

 

As examples of how such capitalism objectives might flow down to the PMO, maybe we don't remote as much as we could and keep a more robust local presence. Such will increase velocity because bandwidth has been added to team interactions and communications, and cost may be reduced a bit because remoteness is not free

 

Maybe we adjust the supply chain to be locally more than we need to -- in effect: buy local.

 

Maybe we hire less experienced but local people and invest in their development. Such may adversely effect velocity and cost in the short run but pay community benefits in the long run.

Steady on! Maybe we need a business culture from the C-suite that supports all this!

---

Buy them at any online book retailer!

The Incompetence Dodge

---

There are so many 'laws' that govern Project Management one wonders how to keep track of them all.

Now comes "The Incompetence Dodge", originally formulated by Sam Rosenfeld and Matt Yglesias. Their domain was foreign policy, but their idea can be recast to project management.

Simply put: if your idea failed, you need not look to the quality of the idea; you simply blame others for implementing your idea incompetently. 

Simple tactics, and the dodge

With such a simple tactic, any errors of strategy on your part are transferrable to others as errors of tactics!

Thus, you dodge around bad ideas by the ruse of incompetence by others.

How long can this go on?

How long? It depends on whether you are in charge of the time or the clocks.

If you've got time on your side, you can run out the clock, maintaining the dodge forever.

And, here's the really good part: you don't need jump on incompetence right away. You can wait and see which way it goes. 

• If your bad idea is somehow rescued by brilliant execution, you can claim victory. 
• But, if it goes awry, you can jump on incompetence and avoid personal defeat!

Bottom line: you can be blameless!

---

Buy them at any online book retailer!

Negative feedback: good or evil?

---

The question is posed: Is negative feedback good or evil?

Answer: Good!

Really? 

Yes, 'negative' is good.

Ooops: did I mention what feedback is? Generally it is a sample or portion of an outcome, or something quite similar but directly related to an outcome.

Here's the thing: 'Positive' feedback is reinforcing, agreed, but that may not be a good thing. The primary purposes of 'feedback' are to: 

• correct behavior (not always, or even mostly, human behavior), 
• prevent 'runaway' and chaotic responses, 
• confirm outcomes as expected, and 
• enhance the predictability of outcomes. 

These latter advantages come from so-called 'negative' feedback.

NOTE: providing feedback has its own jargon: We say: feedback closes the loop (the loop is from outcome back to the source that drives the outcomes), or the 'loop is closed'

Now the tricky part: Strength and timing are everything. 

To close the loop effectively, the strength (or amplitude) of feedback, and the timing (or phasing) of feedback has to be such that the feedback provides a countermeasure to the potentially errant outcome, the net effect being an outcome just as predicted, void of the bad stuff.

What could possibly go wrong?

Actually, a lot can go wrong.

No feedback at all is the worst of the worst: the 'system' is 'open loop', meaning that there are outcomes that perhaps no one (or no thing) are paying attention to. Stuff happens, or is happening, and who knows (or who knew)?

Timing errors are perhaps the next worst errors: if the timing is off, the feedback could be 'positive' rather than 'negative' such that the 'bad stuff' is reinforced rather than damped down. 

Strength errors are usually less onerous: if the strength is off, but the timing is on, then the damping may be too little, but usually you get some favorable effect

Practical project management

Feedback for correcting human performance is familiar to all. Too late and it's ineffective; too much over the top and it's taken the wrong way. So, timing and strength are key

But, the next thing is communication: both verbal and written (email,etc). Closing the loop provides reassurance of the quality and effectiveness of communication. You're just not talking or writing into the wind!

And, of course, in system or process design, loops should never be open. Who knows what could happen.

 

---

Buy them at any online book retailer!

Sketching out the architecture

---

I was recently directed toward an interesting site (blog, presentations, etc) by Simon Brown, and his download presentation about "sketching the architecture" that more or less reinforces my idea that:

 "If you can't draw it, you can't build it."

Box model

From this idea flows my "box model" approach to setting down high level narrative (business story with context), major functions (boxes) and the interconnecting process (network).

Now, Brown tells a similar story -- with more depth re design -- with an idea he calls C4. C4 is a box model that Brown claims enables agility in architecture:

• Context
• Container
• Components
• Classes

One thing in Brown's version is an assertion that multiple views may be needed to convey the architecture completely. To this end he posits views like:

• logical vs conceptual;
• process vs functional; and others.

In Brown's world, these different views are tools to "... manage complexity and highlight different aspects of the solution."

For instance, logic shows interconnections with conditions (if, then, else, etc) and process shows work flow, as an example.

Profound
These ideas of Mr. Brown are profound:

• We can visualize our process but not our software.
• In [Brown's] experience, software teams are unable to visualize the software architecture of their systems.
• Pictures are the simplest form of documentation.
• Sketches are not complete models.
• Abstraction is about simplifying, not creating a different representation.

---

Buy them at any online book retailer!

The Requisite Law of Variety

---

Now, this could be a bit stuffy, but it's actually quite readable: "The Requisite Law of Variety"

Reduced for a quick understanding, 'the Law' is an interesting concept to consider, to wit:

• Essential Elements (E): these are outcomes, results, or other artifacts that you want to have some control over; or they are controls and mechanisms that you have to influence outcomes and results and disturbances
• Disturbances (D): these are events or actions that impact E .... usually there are a lot of these!
• Regulation (R) or controls: these are the means or actions to limit the impact of D's. Even in the Agile world, there are some controls or protocols to regulate the pace and rhythm
• Passive capacity (K): in effect, buffers and elasticity that limit the fragility of the system and allow for some absorption of D without breaking E 

The Law is a bit mystical when expressed as math, essentially saying:

"the the variety -- or set -- of the E's that you need or value should be greater than

• the variety -- or set -- of disturbances (D) reduced, absorbed or mitigated by regulation (R) and
• other, or further, disturbances reduced by buffers or elasticity (aka: passive capacity, K)."

Practical project management

In other words, the practical advantage to a PM for having a big variety of Es is that Es overwhelm a smaller variety of Ds (or diversifies or dilutes the impact of Ds ) because big E implies a lot of different outcomes that are important, and a big tool set with which to work (*)

Risk management point of view:

So, whereas, some variety of Ds may have impact of some part of the Es, not all Es will be affected. Thus, the larger the variety of Es, the less impactful is a much smaller variety of Ds.

Value proposition point of view

If there is only one thing that is important to you as a project outcome, all your value is in that one thing. Consequently you have set up a vulnerability such that a single disturbance could wipe out your value proposition.  That is way too fragile!

And, 'having only one thing' violates the Law of Variety which intones that the variety of Es should be greater than the Ds that could impact E.

Anthony Hodgson puts it this way:

[The Law of Variety] ... leads to the somewhat counterintuitive observation that the regulator [or PM] must have a sufficiently large variety of actions in order to ensure a sufficiently small variety of outcomes in the essential variables E.

This principle has important implications for practical situations: since the variety of perturbations a system can potentially be confronted with is unlimited, we should always try maximize its internal variety (or diversity), so as to be optimally prepared for any foreseeable or unforeseeable contingency.

If you are familiar with the ideas of "anti-fragile" in system design, this last sentence is a good alternate phrasing for what makes systems anti-fragile, i.e. resilient

---

(*) In effect, the Law of Variety provides opportunity to define project success in several ways. If one of the Es doesn't work out, perhaps another one will. 

Some might say that with such a strategy, every project can be successful, or none a total failure: you just need to find a good E to hang your hat on. 

With such reasoning, it's not hard to conclude that 'project success' or 'failure' metrics are tricky. For more on this debate, look to the endless commentary on the Standish Reports of project success.

---

---

Buy them at any online book retailer!