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!

The worst error in scheduling

---

The worst error in scheduling is to have a milestone depend upon two or more tasks scheduled (planned) to finish at the same time.

Here's a footnote to that witticism: It's assumed the two tasks are independent, meaning:

• They don't share resources
• They don't have the same vulnerabilities to a common risk
• The progress, or not, in one does not affect progress in the other

So, what's the big error here?

• First, as regards milestone success , each of the tasks leading into the milestone is a risk to success (success means: it is achieved on time)
• Second, total risk is the product of all the input risks (as seen by the milestone) . 
• So, whereas each task coming into the milestone may not be too risky, say by example 90/10 (*), three tasks of 90/10 each would present a risk to the milestone such that success is reduced to about 73/27

(*) 90 successes out of 100, or 90% chance the task will finish on time, or early.

What are you going to do about this?

Bring on the time buffers! (**)

• You might be able to add a buffer on one or more of the input tasks to raise the success of that task to 99/01, or so
• You might be able to add a buffer following the milestone, such that any late success is absorbed by the buffer (This tactic is called "shift right" by schedule architects)
• You might be able to reorganize the schedule to eliminate this milestone, or one or more of its input tasks.

(**) A scheduled event of zero scope, but a specific amount of time, aka: a zero-scope time box.

---

Buy them at any online book retailer!

Can you spend $1M in a month?

---

Here's the challenge: On your project, can you spend $1M in a month?

Take a minute and think about it.

Consider:

• If you've got 100 people with an annual payroll of $15M, then yes, it's possible, even likely
• If you've got 20 people with an annual payroll of $3M, then maybe, with overtime and some material charges.

Got your answer?

Good!

Then here's another challenge: If you can spend $1M in a month, can you do a $1M project in a month? Are they one and the same thing?

Consider:

• It's hard to get 100 people up and moving coherently to start and finish something in a month (that $1M may disappear into "start-up" inefficiencies)
• It's not too hard to get 20 people moving, but you might have to really work on motivation if you think you're going to spend $1M on people, but there may be tools, training, facilities, etc that will absorb funds.

So, having thought about it, maybe if you really need your 100-person team, 2 months and $2M is a better thing to have;

And, if you only need your 20-person team, even with overtime, you will be hard pressed to spend as much as $1M

What does all this mean?

You've just made some 'estimates' (gasp! that dreaded word)

Perhaps a bit crude and rude, but at least the 'breadbox' is somewhat defined

Never let it be said that nearly every minute of the day we are not making estimates:

• How long to get to the computer (home or office)
• How long for that meeting
• How much time to spend on email
• How much to spend on a car, hotel, or even a cruise
• On, and on, estimating!

---

Buy them at any online book retailer!