Monday, September 26, 2022

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!

Friday, September 23, 2022

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!

Monday, September 19, 2022

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!




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

Friday, September 16, 2022

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!

Monday, September 12, 2022

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!

Thursday, September 8, 2022

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!

Monday, September 5, 2022

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!

Wednesday, August 31, 2022

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!

Saturday, August 27, 2022

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!

Wednesday, August 24, 2022

Methodologies: more than one way to do it



Did everyone catch Glen Alleman's posting on LinkedIn about the 'Waterfall Myth'? If not, here are a few value-adds from that posting. 

First up: Glen's definition of sundry methodologies for developing software systems, whether stand-alone, as it were, or embedded with hardware development:

  • Waterfall Approach: Development activities are performed in order, with possibly minor overlap, but with little or no iteration between activities. User needs are determined, requirements are defined, and the full system is designed, built, and tested for ultimate delivery at one point in time. A document-driven approach is best suited for highly unprecedented systems with stable requirements.

  • Incremental Approach: Determines user needs and defines the overall architecture, but then delivers the system in a series of increments (“software builds”). The first build incorporates a part of the total planned capabilities; the next build adds more capabilities, and so on until the entire system is complete.
  •  
  • Spiral Approach: A risk-driven controlled prototyping approach that develops prototypes early in the development process to specifically address risk areas, followed by assessment of prototyping results and further determination of risk areas to prototype. Areas that are prototyped frequently include user requirements and algorithm performance. Prototyping continues until high-risk areas are resolved and mitigated to an acceptable level.

  • Evolutionary Approach: An approach that delivers capability in increments, recognizing upfront the need for future capability improvements. The objective is to balance needs and available capability with resources, and to put capability into the hands of the user quickly.
A long legacy
Now Glen goes on to let us know that some of these ideas go back almost 50 years, if not or more. So if you recognize some Agile concepts in the words above, you would be right. And, their provenance is a trail much longer than the infamous Agile conference --  at the turn of the millennia -- that more or less launched Scrum and XP and others into the public domain. 

What's to like?
Looking at all of these methods conceptually, it's hard not to like a combo of Spiral -- which has a strong focus on risk management of testy requirements that may be impractical at first blush, but might yield to some clever prototyping and evaluation -- and Evolutionary which has an up-front bias toward early value-add for users, but with recognition that these same users are going to provide insight to future capabilities and needs.

The hard part
If you go with some version of the incremental or evolutionary method, or some version of classical Agile, like Scrum or XP, they all presume flexibility on the PM's part to approach and engage the customer or user in product evaluation and value development. 

That's easier said than done in many situations:
  • In the public sector, cost often is first priority, and users have to make do.
  • In the contracting domain, the engagement with the user if often proscribed, limited, and arm's reach remote
  • In the commercial sector, "first" often wins, but what's to come "first" is often a big corporate secret not to be shown to anyone outside the 'green room'. 
And, don't forget: I wrote the book ... see the cover below. You'll find it wherever you buy your books with e-commerce.



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

Saturday, August 20, 2022

Is your PMO worried about 'quantum supremacy'?


What kind of a question is this? 
Is your PMO worried about 'quantum supremacy'?
Actually, some are.

Some of the world's largest banks' IT PMOs are staffing to get answers about how the coming .... but not here yet .... supremacy of quantum computing may affect their projects. And that's to say nothing about comparable PMOs in the law enforcement and intelligence communities, pharmaceuticals, weather, and others.

And before 'supremacy' there comes 'quantum advantage' according to Marco Pistoia, who runs JPMorgan's global technology applied research group. 
  • Quantum advantage means competitive but not overwhelming benefits from quantum computing (Some of this is happening now at Oak Ridge National Laboratory, for instance)
  • Quantum supremacy means overwhelming capability that brings into the frame computing tasks that would never have even been attempted.
What are the issues for PMOs?
For purposes of discussion, they break down into three broad areas:
  1. Threats
  2. Benefits
  3. Operations
Threats
The threat comes from bad actors who acquire quantum capabilities and seek to break into (by solving the decryption, etc.) secure project or business communications, or to break into secure project databases that might have valuable intellectual property or privacy information, to name just a couple of computing-intensive tasks.

So security, heretofore provided by the awesomeness of the computing task to overcome encryption and other security barriers, won't be enough. Many PMOs have to communicate over broad areas, so physical exposure of sensitive communications and data is inevitable.

Of course, quantum encryption by the bad guys of their own stuff may also threaten conventional means to decrypt their nefarious communications.

Benefits
The benefits are almost self-evident: projects that were stymied or impractical by conventional computing capabilities may come into the frame. There may be new science, perhaps even new physics (gasp!)
And certainly a new level of risk management may become available for the truly hard-to-model and understand risk events.
Security techniques that might have been uneconomical may become attractive. 
Data warehouses may provide some residual or latent value that was hidden behind the lack of capacity and capability of conventional computing. 

Operations
Operations break into three categories:
  1. "Keeping up with the neighbors". If you're a big bank, big pharma, big weather, or big anything you have to keep up with your competitors, if not beat them. So your project office, as a component of your enterprise, needs to keep up as well

  2. "Move to the cloud". It's more likely than not that your quantum computing experience is going to be cloud based. Such is already in place for some government and educational projects at Oak Ridge in the "quantum computing hub".
    If now you don't understand the cloud as an enterprise computing platform useful in the PMO and the projects generally, now is not too early to get yourself a project based in the cloud and acquire some experience. 

  3. "Staff for expertise". First, you'll need advisors that can keep track of the technology and explain the utility in terms understandable in the PMO. That's where the banks are starting. Then, you're going to need software people who can architect tasks to fit quantum computers, and other software people to write the code and spin the wheels. 
    And, consider strategic partnerships, especially with the early adopters which tend to be in the research universities, national laboratories, and certain other research centers.
And then there's "entanglement"
Entanglement, somewhat pooh poohed by Einstein, is no-lag-time communication between quantum units without wire and wireless. Literally instantaneous, as it were.
And, such was recently demonstrated over a distance of 20 miles! 
Entanglement brings a new dimension to quantum computing, which may be even beyond "supremacy".



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

Tuesday, August 16, 2022

You pay for others to watch you work


There are a lot of collateral and unforeseen outcomes to the pandemic-driven remote workplace. 

One that I certainly did not foresee is the phenomenon, now a for-profit business, of you yourself paying a fee so that others ... strangers for the most part ... can watch you work.

Or perhaps it should be said the other way around: Some people need a social environment in order to work effectively; they need to know that they are being observed, watched, or evaluated. Without such, virtual loneliness sets in; spirit and productivity plunge. 

Our need to be a part of a professional social environment is important. It's tough to be a loner. So, now you can pay to have a crowd around you. And to be effective, it seems these environments need not be teams, not even groups. Minimally, they are just random collections.
And so now it is possible to join --- for a fee --- Zoom groups of strangers who can  observe you as you also observe them, all working asynchronously and independently on various somethings in their professional lives.
And if it pays off, literally, with improved outcomes that are monetized, who can fuss with the ROI, or the process?




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

Friday, August 12, 2022

Is trust essential? Is the answer obvious?



"They say" that trust is essential to any project team working effectively. To not trust is to layer on ineffective and non-value add efforts at surveillance, double checking, micro-management, etc and so on.

Yet, if there was universally trust everywhere you do business, you would not need nearly all the structure that goes along with people working in groups. But the fact is that projects of any significant scope are organized with hierarchical structure (minimum trust required):
  • Some one is in charge
  • Others "report to ..."
  • Rules are a tool; they can substitute for face-to-face encounters
  • Trust is not really required because 'rules' enforce acceptable behaviors
  • Break the rules, and there are consequences. But, the consequences are usually time-limited. You get out of the dog house after you've served your time

Not so fast!

Hierarchies may be the on-paper way of organizing, but 'getting things done' requires networks; and networks are definitely not hierarchical. 

But networks run on trust, not rules. No trust ... no network, or least no network membership.

  • Oh, yes, there are consequences, but, no, there are no time limits. 
  • You may be in the dog house a very long time.

 And so here we are:

  • On paper: hierarchies and no trust required. Rules are all that is needed; and consequences if the rules are broken
  • In fact: networks are how people work; rules aren't need. But, if trust is broken, there are consequences. And those consequences are very long term.  



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

Density of value


Density, if you're wondering, is always a ratio of "something" per unit of "something else". 
You probably recognize such a construction as a ratio. 

Value is a more complicated idea:
  • It's in the eye of the beholder (I value it, even if you don't)
  • It's subject to bias (one in hand vs two in the bush)
  • It's susceptible to the effects of utility compression (more is better, until it's not)
  • It's what you're willing to pay for (willingness and capacity and capability are different ideas)
  • It advantages cybernetics (the outcome is more valuable than the collection of inputs)
  • It's usually 'most bang for the dollar', not necessarily lowest price. To wit: "best value"
  • It may have a wholly social dimension, as value in the public sector, which may be completely subjective
  • It may combine, or entangle, with the closely related concepts of "quality"   
  • It's a lot of different stuff, all at once
Connect the dots: if density is a ratio (it is) and value is a lot of different stuff, what then is the combo: "the density of value"?

Like value itself, there's more than one idea:
  • Pack it all in: How many different things, each separately valuable, can be packed into one container, device, or app, to wit: valuable 'items' per 'container' 

    The smart phone is the poster child for this one: phone, camera, scanner, database, browser, network connector, mobile operating system, myriad apps, compass, geolocator, clock, timer, and endlessly more it seems

  • Compress it by transforming it
    Though vinyl is coming back a bit, cubic mountains of vinyl are obsolete, but the music plays on digitally, but in a lot less real estate

    I still buy printer paper, but a lot less! I 'print' to pdf and electronically store it (and retrieve  it) more efficiently and more densely (hundreds of searchable pdf's on my smart phone rather than file cabinets full)

    My smart phone is no longer a 5-pound brick
    From vacuum tubes, to transistors, to dual-inline, to integrated circuits, I can build an amplifier on the head of a pin; everything needed is just denser!

    From millions of miles of telephone cable, to microwave telephone relays, to microwave cellular, the density of calls per unit of bandwidth is dramatically more.

    And the information density in a communication channel is approaching the Shannon limit of irreducible entropy. To wit: Transfer the entropy elsewhere! Claude Shannon would be pleased no doubt that so many are working on that very idea.
The question
As you create value, are you creating world class value density?!
Because 'value density' itself is valued!



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

Monday, August 8, 2022

The asymmetry of value


I've written a couple of books on project value; you can see the book covers at the end of this blog.
One of my themes in these books is a version of cybernetics:
Projects are transformative of disparate inputs into something of greater value. More than a transfer function, projects fundamentally alter the collective value of resources in a cybernetics way: the value of the output is all but undiscernible from an examination of inputs

But this posting is about asymmetry. Asymmetry is a different idea than cybernetics

"Value" is highly asymmetrical in many instances, without engaging cybernetics. One example cited by Steven Pinker is this:

Your refrigerator needs repair. $500 is the estimate. You groan with despair, but you pay the bill and the refrigerator is restored. But would you take $500 in cash in lieu of refrigeration? I don't know anyone who would value $500 in cash over doing without refrigeration for a $500 repair.

Of course there is the 'availability' bias that is also value asymmetrical:

"One in hand is worth two in the bush"

And there is the time displacement asymmetry:

The time-value of money; present value is often more attractive than a larger future value. The difference between them is the discount for future risk and deferred utility.
Let's not forget there is the "utility" of value:
$5 is worth much less to a person with $100 in their pocket than it is to a person with only $10

How valuable?
So when someone asks you "how valuable is your project", your answer is ...... ?

 



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

Thursday, August 4, 2022

Detecting deep-fake video calls


As I previously posted, there is a growing threat that the person to whom you are video conferencing is really a deep fake. For projects, this threat arises in recruiting strangers remotely by video call, but also in other situations when the 'familiar face' is really fake. (But I know that person! How could the image I'm seeing be fake?)

Here is a report of new research by NSA and UC Berkley about a new tool -- 'monitor illumination' -- that can 'fake the fakes' in a way that gives better assurance that the fake is detected.

Of course, now that this has been widely published, the counter-counter-measures are probably already on the drawing board, so to speak.



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

Saturday, July 30, 2022

The 2nd Law ....


Did you heat a cup of coffee in the office microwave, and then walk away and leave it there?
Sometimes you just forget.
And when you returned to get the cup, what did you find?
Crap! The coffee is cool again. In fact, the average temperature of all the elements in the microwave are about the same: the coffee, cup, and surrounding air. Whereas after first heating, the averages were quite distinctively different; the coffee was hot; the air was not so much. But after a bit, all discriminating differences are lost. 

Said another way: Over time, and in isolation, "waste" increased, where, in this case, "waste" is the heat (energy) that was usefully in the coffee, but is now wastefully distributed throughout the microwave. The former distinctly organized sources of energy have become homogenous, bland, without contrast and shades of complexion. In effect: disorganized and wasteful; almost without value.

What's happened?
Physics took over.
Yes but ..... Actually statistics is the underlying explanation for the increase in waste, and that idea will take us to project management (which constantly opposes waste)

So read on; I'll get to project management shortly. 

So, what do we make of this?
At the outset, there was order, structure, and organization to the energy in the container. 
But over time, this orderly organization disappeared.

Inexorably, over time, and in isolation (that is: no outside influences or help), "disorder" (as opposite of "order") always increases until some equilibrium is reached. Distinctive differences degrade, becoming homogeneous.

And, by the way, value is lost .... The utility of the disordered is usually less than the ordered. Keep that in mind, project people!

Don't forget the living:
And this phenomenon applies to biological sources also: Without some stimulus from time to time, when in isolation, biological systems all tend toward a low-energy minimum maintenance state.

Statistical formulation
I mentioned statistics.
Hardly was the ink dry on the thermodynamics explanation of the cooling coffee than others grasped the idea that there's a statistical explanation as well: 
The probability of a well ordered configuration is hugely less than a disordered one. Even for the coffee cup situation, there are very few ordered configurations; there are effectively infinite disordered configurations for the distribution of energy. 
Disorder is the more likely end-state.
Generally speaking, given isolation, the probability that disorder increases and order decreases is very high. 
And never the other way around!

The 2nd Law:
All of the above is a layman's explanation of the 2nd Law of Thermodynamics (*), originally conceived as a law of physics to explain the distribution (and redistribution) of energetic molecules in a container. 

But given that there are many more useful concepts that arise from the statistics of disorder, perhaps the 2nd Law should be the Disorder Law.(**)
 
Maximize throughput ... project objective 
Another interesting tidbit, arising from the statistical interpretation, is that it is improbable for a system to be completely disordered or completely ordered. 
The 2nd Law predicts that statistically -- as things are approached asymptotically -- there will always be something missing; something lost; something wasted. 

Minimizing waste and lost value, and maximizing throughput thus becomes an exercise in working with the 2nd Law.


Isolated projects
You probably saw this bit coming: 
Projects that are highly isolated by security protocols, or physical remoteness, or by uninterest and lack of attention are vulnerable to the inevitability of  the 2nd Law. 

If external stimulus, energy, and interest are cut off, then the 2nd Law predicts blandness; lack of innovation, productivity, and morale; an increase of waste; and a general race to the bottom where a minimum effort is maintained. 
And, by the way, who among us have not seen such in the corners of large bureaucracies, oversized project offices, and similar locations? We're likely to say: Does anyone care?
.
Counter measures:
The only avoidance tactic for this decay into mediocrity and blandness is to selectively apply new energy from the outside. 
  • In project terms, this means re-energizing individuals, individually. (Giving everybody a new T-shirt or coffee cup won't restore individual leadership, energy, and innovativeness). 
  • This means aggressively combating wastefulness, non-value add activity, and a general acceptance of 'shit happens'
  • This means allocating time and space, away from the project, for recharging.
  • This means that selective (and genuine) attention to the project by outsiders is mandatory.
  • And, this may require rotation to an outside activity to spark new behaviors.
  • Not least: mitigating some physical remoteness and isolation.


(*) There is a First Law: Energy is never destroyed; it may change form, but in total it is conserved. This is a handy bit of information, but for PM purposes the way in which energy distributes itself is where the action is; and that is the domain of the 2nd Law.

"Entropy" is the word physicists use for "disorder"
 
And, there is a Third Law: The 3rd Law says that there is actually a limit to how disorderly things can become. That's actually good news for PM! But this limit is so remote that it's of no practical consequence in projects, unless you are trying to squeeze the last bit from an information channel. 

(**) There is more about this topic as it affects human situations in Steve Pinker's book, "Enlightenment Now". Pinker uses the term "Law of Entropy" instead of 2nd Law
 

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

Wednesday, July 27, 2022

Mobile internet for platforms in motion



Have you ever had a project where a test unit, pre-production unit, or training exercise involved a mobile platform?
I have.
And, there have got to be many more out there.

Now this is not an endorsement or a commercial, but the recent news is that as of mid-2022, satellite-based internet is available at modest cost for mobile platforms. This after Space X's Starlink service for mobile platforms was approved by the FCC of users in the United States, although international air and sea connections are included.

If you intend to baseline this internet service for your project, be aware that it's not altogether risk free. As CNBC reports, "The FCC imposed conditions on in-motion Starlink service. SpaceX is required to “accept any interference received from both current and future services authorized ....”



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

Sunday, July 24, 2022

Remote interview ... or is it an avatar?



Doing a bit of project hiring by remote interview?
Some caution advised!
You may be talking with an avatar ....

Kyle Barr has a report on gismodo.com with this headline:
FBI Says People Are Using Deepfakes to Apply to Remote Jobs

So, what is Barr reporting that the FBI is saying?

According to the FBI’s announcement, more companies have been reporting people applying to jobs using video, images, or recordings that are manipulated to look and sound like somebody else.

These fakers are also using personal identifiable information from other people—stolen identities—to apply to jobs at IT, programming, database, and software firms.

The report noted that many of these open positions had access to sensitive customer or employee data, as well as financial and proprietary company info, implying the imposters could have a desire to steal sensitive information as well as a bent to cash a fraudulent paycheck.

These applicants were apparently using voice spoofing techniques during online interviews where lip movement did not match what’s being said during video calls, according to the announcement. Apparently, the jig was up in some of these cases when the interviewee coughed or sneezed, which wasn’t picked up by the video spoofing software.

And, somewhat related insofar as fake references and supporting documention, the report includes this timely warning: "The FBI was among several federal agencies to recently warn companies of individuals working for the North Korean government applying to remote positions in IT or other tech jobs"

Bottom line: with remote interviews, some caution advised!


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

Wednesday, July 20, 2022

Submarines in the Idaho desert


Submarines in Idaho?
In the desert?

Actually, a hull, a reactor, and a steam turbine.
All part of the 1953 simulation of the first ever naval submarine nuclear propulsion reactor to run in an actual ship configuration all the way to turning a propeller shaft.

That is what we PMs call a full-scale model and simulation test.
And not only was this first-ever in a ship's configuration, but the reactor-steam turbine combo ran for 96 continuous hours, a near-miracle for the technology of the day. 
"Radical technologies require conservative engineering"
Admiral Rickover, the father of naval nuclear power 

And what significance was 96 hours?
That was the time needed -- according to estimates -- for the soon-to-be Nautilus to transit continuously submerged from North America to Europe.(*)

We know the rest of the story: this "submarine in Idaho" project simulation and testing led to a successful Nautilus, followed by widespread nuclear naval power within a few decades.




.(*) Did you know: in World War II, only 20 miles was the extended range for continuously submerged?



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

Saturday, July 16, 2022

Cloud Security Architecture in the U.S. Government


Have you got a project providing software services to the civil agencies of the U.S. Government? 

If so, you should be aware of a new 'technical reference architecture' authored jointly by CISA, USDS, and the Federal Risk and Authorization Management Program.(*) 

Some of its provisions are likely going to find their way into RFPs and RFIs from the civil agencies.

From the document, we get this insight from the introduction:
This technical reference architecture is intended to provide guidance to agencies adopting cloud services in the following ways:

Cloud Deployment: provides guidance for agencies to securely transition to, deploy, integrate, maintain, and operate cloud services.
Adaptable Solutions: provides a flexible and broadly applicable architecture that identifies cloud capabilities and vendor agnostic solutions.
Secure Architectures: supports the establishment of cloud environments and secure infrastructures, platforms, and services for agency operations.
Development, Security, and Operations (DevSecOps): supports a secure and dynamic development and engineering cycle that prioritizes the design, development, and delivery of capabilities by building, learning, and iterating solutions as agencies transition and evolve.
Zero Trust: supports agencies as they plan to adopt zero trust architectures.

This technical reference architecture is divided into three major sections:

Shared Services: This section covers standardized baselines to evaluate the security of cloud services.
Cloud Migration: This section outlines the strategies and considerations of cloud migration, including explanations of common migration scenarios.
Cloud Security Posture Management: This section defines Cloud Security Posture Management (CSPM) and enumerates related security tools for monitoring, development, integration, risk assessment, and incident response in cloud environments.

 


CISA is the operational lead for federal civilian cybersecurity and executes the broader mission to understand and reduce cybersecurity risk of the nation
The United States Digital Service (USDS) is a senior team of technologists and engineers that support the mission of departments and agencies through technology and design.
Federal Risk and Authorization Management Program provides a cost-effective, risk-based approach for the adoption and use of cloud services by the Federal Government.



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

Tuesday, July 12, 2022

Hire the 'rules people'


A lot of great outcomes are directly from emergent innovation
  • Emergent meaning the properties were not predictable from analyzing the constituents; they surprise us all when the integrated constituents all came together and something new appears!
  • Innovation meaning that risks to norms were deliberately taken; a form of destruction-construction
But not everybody is comfortable for destruction-construction; and indeed, there are many industries where the rules and regulations prohibit departure from the norms.

And so if you are managing a rules-based rules-driven project, what's the profile of the staff you need?
The question begs the answer: people who have been successful obtaining quality outcomes while still following the rules ... staying between the hedges, as it were.

So, who are 'they' that can get it done within the rules?
Look here first for the "rules" people:
  • Former military and police
  • Former government agencies staff
  • Former very large corporate leaders
  • Former staff from major 'safety' projects (where the stakes were life-threatening)
  • People who value discipline, even if not one of the 'formers'
  • Athletes from team sports, particularly if not the star of the team
  • Socially moderate, and so likely to fit well into a heterogeneous team
Now, of course, there are a lot of 'formers' from rules-based organizations that are 'former' because they can't follow the rules. It's likely they have been invited to leave and apply their spirits elsewhere. Your job is to filter these rules-misfits out of your hiring plan.

Rules don't necessarily quash innovation
Rules generally go to methods and limits. Rarely do you find a rule about an outcome.
So, within the allowable methods, and within the allowable limits of disturbance, sustainability, availability, and quality in the large sense, any innovative outcome is possible.

You just need to hire the 'rules people' to get there!




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

Friday, July 8, 2022

Social Media vs Project culture .... same?


The questions have been raised in various forums (and not only in the PM industry):
How much should the project culture be a influencing factor on the social media culture of project participants?

Can they be in opposition successfully?

Is it ok for PMO policy to insist that the project not be compromised on social media?

Before the pandemic, the same might have been said of dress codes (and hair cuts and body decoration, etc) in the office: don't embarrass the project, because influential sponsors, users, investors, et al might drop in. 

Tricky stuff
But we all know freedom of expression is more tricky, more sensitive, more litigious, more everything than something like a dress code. And, when you extend the project workforce internationally, all the more so. Not only are there different interpretations of the same expression(s), there are different norms and expectations. All this gets broadcast without borders.

Strangers in our midst
Then comes the virtual thing: it may well be that much of the workforce has never actually been in the office; may not have actually met policy makers (and enforcers); may not have actually had any professional colleague pay any attention to their social media presence heretofore. 

How do you form effective relationships in such situations?

The cheap answer: Return to the office!
The other answer: Say what you will, but if what you say is aimed directly at the project, then by your own actions you've deliberately engaged with project policy. If you can't abide the policy, then work on your resume ..... if there is no avenue to appeal the policy.



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

Tuesday, July 5, 2022

AGILE: how to get there from left to right


If you are new to Agile (thus, perhaps, a late adopter .... or a newbie to the software industry) read through this posting at LeadingAnswers. 

The big message is: 
Internalize the founding concepts and guiding principles before jumping into sundry Agile practices. 

Start left; move right
In particular, understand this lecture: Absorb the idea of moving 'left to right' from the founding ideas to the many implementing practices. Avoid the shortcut to cut to the chase and start pick among the practices. 

If your mindset is "I'm not keen on the founding stuff; I'm a 'doer'", then LeadingAnswer's post is really designed for you! 

Read it through; take time to grasp the message in the graphics, and then summarize to yourself what you just learned. You and your project will be more successful than you might have been.




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

Thursday, June 30, 2022

Mixed methodologies: Agile and ....



There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty.

This quote comes from a nicely argued case -- from the agile blog 'leading answers' -- for mixing agile methods in rather traditional businesses, like the oil and gas exploration/production business

If ever there was a business that benefits from Boehm's Spiral Model, OGM (oil, gas, minerals) is certainly one. (Disclosure: I hold some OGM leases in Texas, so I've a bit of personal experience with this)

So, what have you got here?
  • A lot of risk acknowledged up front (can't know everything -- thus the opening quote)
  • A need to run with pilot projects before committing to production
  • A need to tie into legacy systems (in the OGM case, distribution systems)
  • A lot of deliverables that can be done incrementally and then integrated
  • Small (it's all relative re small) teams, co-located (or the virtual version thereof), personally committed, with risk hanging on every move.
  • A degree of local autonomy -- even if virtual -- required to meet the challenges of the moment
Sounds like an environment that needs agility, if not agile methods, on a lot of the stuff.

Of course, there's "one big thing":

You can't go around self-organizing (agile speak) willy-nilly! There are regulatory constraints everywhere and safety-first doctrine hanging on every move.

So, yes, there is a big bureaucracy that watches over... it's certainly more intrusive than a coach or a servant-leader (more agile speak)  (I'm sure they never heard this stuff in an oil field or an offshore rig!). In fact, I'll bet the rig boss is a force to be reckoned with!



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

Monday, June 27, 2022

It's all about negative feedback



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 directly related to an outcome.

Here's the thing: 'Positive' feedback is reinforcing, agreed, but that may not be a good thing. 
Really? Why not?
Because positive feedback encourages or promotes outcomes to ever increase, following the rule: 'more is better'. But such may become unstable, erratic, even chaotic. And, if the outcome has elements of distortion, disturbance, or some other impurity, then rather than 'more' you want 'less'.   

Negative feedback -- which is to be understood as feedback phased or timed to be not reinforcing -- helps with stability, predictability, and puts a damper on chaotic impulses. Done right, properly phased feedback can reduce distortion and help cancel-out disturbances. (*)

We can summarize this way: 
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.

I should mention:
The study of feedback systems generally falls within what is called 'cybernetics'. As described by sciencedirect.com, MIT mathematician Norbert Wiener defined cybernetics as “the study of control and communication in the animal and the machine." 

From Wikipedia, we learn: The core concept of cybernetics is circular causality or feedback—where the observed outcomes of actions are taken as inputs [ie, feedback] for further action in ways that support the pursuit and maintenance of particular conditions [ie, 'ways that support' requires the correct timing and strength]



(*) The difference between noise and song among many voices is timing or phasing. The members of a really good choir or ensemble sense the others and with that feedback each member adjusts to the pace of the others. But, get the timing wrong, and it's all just noise. 
 


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

Thursday, June 23, 2022

Measuring time



Daniel Miessler posted this bit of schedule data in a recent blog:
The difference between a million and a billion is counter-intuitively large.

As an example, a million seconds is 12 days, and a billion seconds is 32 years.

I had to look it up to confirm. That's bonkers.


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

Monday, June 20, 2022

China Cyber report from NSA et al


NSA, FBI, and CISA have jointly issued a significant report on China's cyber activity.

A summary quotation is given below:
This joint Cybersecurity Advisory describes the ways in which People’s Republic of China (PRC) state-sponsored cyber actors continue to exploit publicly known vulnerabilities in order to establish a broad network of compromised infrastructure. These actors use the network to exploit a wide variety of targets worldwide, including public and private sector organizations. The advisory details the targeting and compromise of major telecommunications companies and network service providers and the top vulnerabilities—primarily Common Vulnerabilities and Exposures (CVEs)—associated with network devices routinely exploited by the cyber actors since 2020.



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

Thursday, June 16, 2022

Cost management, and force majeure


Are you doing a project under a contract from a sponsor?
When did you do the cost estimating for the price you signed up for?
Is there a clause for "force majeure" (Look in the fine print in the contract's boilerplate)

A lot of contractors (and their lawyers) are spending time on "force majeure"

Three elements required:
(1) unforeseeable event, 
(2) outside of the parties' control, that 
(3) renders performance impossible or impractical.

Did someone say "black swan"? They might have.
So, among the favorites these days are:
  • Supply disruptions affecting schedule and price on account of the pandemic
  • The war in Ukraine (although there is a war somewhere almost all the time)
  • Historically high inflation wrought by the factors above
It's argued -- in the case of contracts that have been ongoing since before mid-2020 -- that these are all 'black swan' events or outcomes not reasonably predicted and their effects not reasonably understandable in foresight. So their impact could not have been accounted for in the original contract price. Ergo: invoke 'force majeure'

A case to be made
  • COVID brought, or is bringing, travel restrictions and quarantines. So that's a pretty solid case for some labor related costs. But, that's getting to be old hat. It's been around since early 2020. In 2022, it's perfectly foreseeable; but if you bid your contract in 2019, or even 2020, then you've probably got a case. 
  • So also has COVID impacted supply all around the world. Another arrow in the quiver, as it were. But again, supply problems have been around since the pandemic.
  • And COVID is behind  massive government stimulus which some believe is the root cause for inflation. Economists are a bit divided on this as the root cause because also there is somewhat independent monetary policy to consider (cost of money), but certainly 2022 is at significant variance with the prior 20 years.
Pricing leverage
So, it comes down to this: do you have pricing leverage with your sponsor? FM clauses may help, but a contract cancellation in the event of a sponsor push-back may not serve your interests either.

Tricky business, this!




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

Monday, June 13, 2022

Risk, but no plan


In my experience, a lot of projects operate more or less on the edge of risk, with no real plan beyond common sense and a bit of past experience to muddle through if things go wrong.

Problematic, as a process, but to paraphrase the late Donald Rumsfeld: 
You do the project with the resources and plan you have, not the resources or plan you want
You may want a robust risk plan, but you may not have the resources to research it and put it together.
You may not have the resources for a second opinion
You may not have the resources to maintain the plan. 
And, you may not have the resources to act upon the mitigation tactics that might be in the plan.

Oh, woe is me!

Well, you probably do what almost every other PM has done since we moved past cottage industries: You live with it and work consequences when they happen. Obviously, this approach is not in any RM textbook, briefing, or consulting pitch. But it's reality for a lot of PMs.

Too much at stake
Of course, if there is safety at stake for users and developers, as there is in many construction projects; and if there is really significant OPM invested that is 'bet the business' in scope; and if there are consequences so significant for an error moved into production that lives and livelihoods are at stake, then the RM plan has to move to the 'must have'.  

A plan with no action
And then we have this phenomenon: You actually do invest in a RM plan; you actually do train for risk avoidance; and then you actually do nothing during the project. I see this all the time in construction projects where risk avoidance is clearly known; the tools are present; and the whole thing is ignored.

Show me the math
But then of course because risk is an uncertainty, subject to the vagaries of Random Numbers and with their attendant distributions and statistics, there are these problems:
  • It's easy to lie, or mislead, with 'averages' and more broadly with a raft of other statistics. See: How to Lie with Statistics (many authors) 
  • Bayes is a more practical way for one-off projects to approach uncertainty than frequency-of-occurrence methods that require big data sets for valid statistics, but few PM really understand the power of Bayes. 
  • Coincidence, correlation, and causation: Few understand one from the other; and for that very reason, many can be led by the few to the wrong fork in the road. Don't believe in coincidence? Then, of course, there must be a correlation or causation!
The upshot?
Risk, but no plan.
Or plan, and no action



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

Thursday, June 9, 2022

How fast can you spend the money?



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!



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

Sunday, June 5, 2022

Expectations from Activity, Methods, Outcomes



Back in yesteryear, I recall the first time I had a management job big enough that my team was too large for line-of-sight from my desk and location.

Momentary panic: "What are they doing? How will I know if they are doing anything? What if I get asked what are they doing? How will I answer any of these questions?"

Epiphany: What I thought were important metrics then I realized now become less important; outcomes rise to the top
  • Activity becomes not too important. Where and when they worked could be delegated locally
  • Methods are still important because Quality (in the large sense) is buried in Methods. So, I decided that I can't let methods be delegated willy nilly
  • Outcomes now become the biggie: are we getting results according to expectations?
There's that word: "Expectations"
In any enterprise large enough to not have line-of-sight to everyone, there are going to be lots of 'distant' managers, executives, investors, and customers who have 'expectations'. And, they have the money! 

But not only do they have the money, they have a big say about how the money is going to be allocated and spent. So, you don't get a free ride on making up your own expectations (if you ever did)

At the End of the Day
  • I had 800 on my team
  • 400 of them were in overseas locations
  • 400 of them were in multiple US locations
  • I had multiple offices
  • It all worked out: we made money!




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

Thursday, May 26, 2022

Systems thinking



"Life was simple before World War II. After that, we had systems"
Rear Admiral Grace Hopper, USN
Matthew Squair, a systems safety expert, has this to say about that (*):
  • From the Gesalt (**) school comes the [systems] view that the whole is often greater than the sum of the parts, i.e. there exists properties that emerge from parts aggregated together .... [which is a telltale sign of a 'system of parts']

  • From the cybernetic (**) school comes the view that systems can be understood by studying, in the abstract, control and communication between the parts that effects causal feedback loops and interactions with the environment [The 'blackbox' view of systems is a cybernetic concept]

In other words, there is more than one way to look at or perceive a system. For those that have given this some thought in the past, or have worked with or in system engineering, that there is more than one point of view of what we would call a system is not new news, but multiple views is a key concept when thinking about systems. 

But nonetheless, the I've found these ideas seem to be most common:
  • There is the hierarchical view of a system as a collection of subsystems that all combine in some way to make a system. In the hierarchical view, the system is parsed into major subsystems according to their similar position in a hierarchy, which, in turn, these subsystems are further reduced to lesser subsystems until there is no meaningful reduction to be made.

  • The proposition for breaking apart a system in order to understand it, to scope and specify it, and to be able to actually construct it is generally called reducing the system to its constituent parts, summarized as reductionism.

    And, the 'science' or 'art' of reductionism is no small matter. Some truly awful reductions have been made in my experience that harmfully impact the understanding and the means to implement the system successfully.

    The risk inherent in reductionism is that the focus is continuously narrowed until the 'big picture' fades way into the background; all sense of synergy and emergent properties that give rise to the 'sum is greater than the parts' is lost. 

  • There is the black box view of a system which is about boundaries, boundary conditions, and means to interface with the system for providing input, obtaining output, effecting control, and processing telemetry or feedback to establish stability and predictability of performance.

    The question is begged: is there a 'white box' view? Yes, such is the internal detail known to 'insiders', but not necessary to those system 'users' and controllers that stand outside the black box.

    Reductionism plays a lesser role; the main utility of reductionism is to decide or allocate functions and performance requirements to the black box, thereby setting boundaries for what is in the box and what is not.

    The great advantage of the black box view, apart from a clear understanding for boundaries, is that interfaces become the focus: how to stimulate the system; how to control it; how to measure it; how to use it's outcomes; and how to repair-by-replacement. In turn, these give rise to widely recognized standards for size, weight, connectors, and other physical attributes, as well as standards for intangibles like software objects and APIs.


    (*) "Critical Uncertainties; the theory and practice of system safety" Matthew Squair, Review Copy, April 2022

    (**) Gesalt is a term of art taken from German meaning that the attributes of the whole are not deducible from analysis of the parts in isolation. First used in psychology to understand behaviors.

    Cybernetics is “the science of control and communications in the animal and machine.” The core concept of cybernetics is circular causality or feedback—where the observed outcomes of actions are taken as inputs for further action in ways that support the pursuit and maintenance of particular conditions, or their disruption.

    Norbert Weiner, American mathematician, is credited with defining cybernetics in systems terms.

     


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

    Monday, May 23, 2022

    It's your critical path ... do you own it?



    You've got a job to do; you've sequenced and scheduled it.
    You've go the critical path in sight. Do you own it? Maybe not!

    What if, 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!

    Thursday, May 19, 2022

    The problem with strategy ....



    Ideas matter, but they do not matter as much as intellectuals and [market strategists] think they do. What matters far more is [project craft], which is about sensing, adjusting, exploiting, and doing rather than planning and theorizing.

    It is the skill of judo player who may have plans but who important characteristic is agility.

    It is what philosopher Isaiah Berlin called "understanding rather than knowledge", the ability to "tell what fits with what: what can be done given the circumstances and what cannot, what means will work in what situation and how far"

    From an essay by Eliot A. Cohen

    Cohen's idea more or less aligns with the oft quoted concept that the first casuality of real work or activity is plans. Which is not to say plans are without value, it's just that their value has a limit, and thereafter comes "sensing, adjusting, exploiting, and doing".



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

    Sunday, May 15, 2022

    Leading a team of rivals



    Bidding on large contracts often requires teaming with a rival(s) to fill gaps in skills and capabilities. One day you're trying to beat them in a competition as your rival, and the next day you're teamed with them, now trying to beat yet another guy, with your 'rival' now your BFF.

    And, what if you're the prime contractor PMO in this arrangement required to manage such a team of rivals with all the parochial tensions, biases, mistrusts, and suspicions that go along with such temporary truces between otherwise competitors?

    From experience: leading coalitions is not easy! 
    • It take the patience of Job, and the resolve to direct traffic -- sometimes saying Yes! and sometimes saying No! 
    • It can't be a matter of permission and consensus when the chips are down: you are the team lead, and lead you must.

    General Eisenhower had the mother of all coalition leadership jobs. Here's what he says:

    "Success in such organizations rests ultimately upon personalities: [executives, managers, technicians] --- and even populations(*) -- must develop confidence in the concept of single command and the leader by which the single command is exercised. 
    No binding regulation, [teaming agreement], or custom can apply to all its parts--only a highly developed sense of mutual confidence can solve the problem" ;

    And, the 'problem' Eisenhower is referring to how to get disparate personalities -- some prickly, some quiescent, and some rude -- to [temporarily at least] cooperate for the greater good, and put aside parochial tensions, biases, mistrusts, and suspicions that go along with such temporary truces.

    His remedy, not explicit above, is to attain confidence from performance. And that requires promoting the achievers and relieving the non-achievers -- with dispatch!



    (*) In the PMO context, 'populations' is akin to all the sundry stakeholders from project investors to product users and maintainers



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

    Thursday, May 12, 2022

    Leadership by 'link and buffer'



    "Link and Buffer" is a leadership concept for a leader positioned between a governing board, to whom they must link the project, and a project team which must be buffered from the whims and biases of the board.

    Fair enough
    But it's not that easy.
    In the "link and buffer" space live various skills:
    • Vision and practicality: to the board, the project leader talks strategically about outcomes and risks; and about the strategic direction of the project. But, to the team, the leader talks practically about getting on with business. All the tactical moves are effectively smoothed and buffered into a strategic concept which the board can grasp

    • Tempers and angst: When there's trouble, tempers fly. Buffering is a way to decouple. The board's angst does not directly impinge on the project if properly decoupled by the project leader.

    • Personality translation: Few on the project team will know or understand intimately the personalities on the board. Taking the personality out of the direction and recasting instructions into a formula and format familiar to the project team is part and parcel of the buffering.

    • Culture translation: In a global setting, the board may be culturally removed or distant from the project team. Who can work in both cultures? That of the board, and that of the project team? This is not only a linkage task but a translation task to ensure sensitivities are not trampled.

    Examples of "link and buffer" abound in military history. Perhaps the relationship between Admiral Ernest King and Admiral Chester Nimitz is most telling. King was in Washington during WW II and was Nimitz superior in the Navy chain of command. Nimitz was in command of the Pacific Ocean Area from his HQ in Hawaii.  
     
    King was responsible for a two ocean Navy in a world war; Nimitz more limited. Nimitz was the link and buffer from the tactical fighting admirals at sea, and the strategic war leaders in Washington.  No small matter!




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