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.

  • 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?

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?
  • 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.

    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!

    Monday, May 9, 2022

    There is a case for bureaucracy ... sometimes

    If you can't trust your people
    Or, you don't know your people well enough to trust them
    And, you can't replace the former
    Nor do you have time to get to know the latter .....

    Then the management solution is simplicity itself:
    Invent a bureaucracy and assign them to it!

    Bureaucracy is the management alternative to trust. 
    • Rules, regulations, and punishment do all the work. No fuss, no muss!
    • Sometimes, incentives are useful, so don't leave them out.

    Now admittedly, bureaucracy cuts against the flat, agile grain which is "the way to do it" for modern managers. 

    But, beyond a point, flat is too flat, and agile is too agile.
    Let's be realistic:
    • Many can not handle complete freedom, 
    • Have questionable judgement, 
    • Are misaligned to strategic goals and imperatives, and 
    • Generally spend time and money without regard to the fact that neither the time nor the money is theirs.
    Bring on the bureaucrats!

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

    Thursday, May 5, 2022

    About communication

    Sometimes, our language idioms get in the way of the top three project management tasks:
    1. Communicate
    2. Communicate, and 
    3. Communicate!

    A few examples to illustrate.

    First, about schedule:
    "Slow down" and "Slow up" mean the same thing: make the schedule slower. 'Up' or 'down' is irrelevant; you can choose to go in either direction!

    The third hand of the clock is called the 'second hand'. Oh well; I'm not sure if this is a confusion of ordinality or cardinality, or something else.

    "After dark" actually means 'after light'; that is, after the sun goes down if you are scheduling a night action.

    About risk:
    "Fat chance" and "slim chance" mean the same thing: there's not much of a chance that things will go as desired. So, when it comes to weighting a chance, choosing slim or fat is unimportant They may play the same way.

    About management:
    "Overlook" and "oversee" are quite different management activities. The former means to ignore, while the latter means to observe. 

    About job satisfaction:
    "Work is terrific", but you won't do it unless you are paid. 

    About experience:
    "Wise man" and "wise guy" are really not the same thing at all. The former is about wisdom borne of experience, and latter is about ignorance, regardless of experience

    About environment:
    "If all the world is a stage" where are your customers going to be? Understanding the customer's environment is one key to quality (in the large sense).

    I could go on, but I won't!


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

    Monday, May 2, 2022

    From strategy to plan to approval

    To state a strategic principle is one thing; to reduce principle to a practical plan is another; but then to get stakeholders to approve and invest in both the principle and the plan is yet another.

    General Eisenhower had something to say about this, and one should be fully aware that not only did his strategic principles have to satisfy those with a focus on Europe, but also in the larger context of  two simultaneous wars whose connectivity was largely their overlap of a common source of supplies and resources.

    "However -- and here is the rub -- it was easy enough to state [a strategic purpose] as a principle but it was to prove difficult indeed to develop a feasible plan to implement the idea and to secure it's approval by the [controlling investors]
    General Eisenhower in "Crusade in Europe"

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

    Wednesday, April 27, 2022

    To command, or is it just a comment?

    Now, the word 'command' is probably a no-no among many. For those who dissent from 'command', it's more likely all about synergy and shared commitment, etc. 

    Can PM work without a culture of 'command'?
    But on projects of any scale, and businesses of scale, there will always be people 'on the commanding heights', in a command situation, and with command responsibility. 

    Don't believe it? Check in with the C-suite and see what they say.
    So, that said, we arrive at today's topic: If on the 'commanding heights', is a word spoken always a command, or can it be merely a comment? Indeed, are 'commanders' allowed the freedom and informality to just make a comment? 

    Which is which is sometimes vexing, but does it matter?
    Actually, Yes, it can matter a lot. Consider some of these situations and outcomes:
    • A PM is not promoted for lack of 'command presence' in their communications. What is that? See below.
    • 'Commands' are given (in the civilian world) but for lack of follow-though the permanent bureaucracy all but ignores them
    • A casual comment is understood -- in context -- to mean "get it done"
    • A casual comment is misunderstood to be a command, when it reality it was just a casual comment

    So what's going on here?

    Command presence: You know it when you see it. A confident aura that invites -- rather than demands -- followership. Obviously, no empty suit!

    Sloppy communication. The "one in command" is careless about a comment, not understanding or observing the reaction that surrounds it

    Underlings too eager to please. These guys make the most of reflected and proximate power -- power and authority absorbed simply because they are in close proximity to the throne.

    Bureaucrats understand the impracticality or incompleteness of the command.  And so it is ignored or modified on the spot. Actually, this is a very common consequence of "flow down of goals and objectives" and also of assuming operating detail will be filled in below by the people who actually have to do the work.
    So, don't be surprised to see how a command actually materializes!

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

    Friday, April 22, 2022

    Zooming at the office

    Wow! I read a piece by Daniel Miessler wherein he opined that people are going to the office, only then to sit on Zoom calls! 
    • Actually, if you're doing that, you can do it from home. 
    • But, if you're doing that ... if you have to do that ... hopefully the community advantage of going to the office to have face-to-face with colleagues, influencers, bosses, and others is also part of your day.
    In fact, there are a lot of reasons to go to office, but to sit on a Zoom call should be low on the list, even if unavoidable. Probably on everybody's list are these:
    • You have got to get out of the house or the coffee shop!
    • You need, or want, the community of real people that you can't get even at the coffee shop
    • There are tools and capabilities that are only accessible at the office
    • The company culture may be shifting; you need to catch up on that
    • There may be a science experiment in your old coffee cup if you didn't clean it really well
    • Zoom works better from the office than from the home
    And then there's office politics:
    It helps to get close the flag pole if you want an opportunity for a seat at the table and a chance to be an influencer yourself. And by close, I mean: in the room, not on the screen, whenever possible.

    But, if it's about a need for 'talking truth to power', person-person is the most influential way to do it. In the old days you might write a supporting memo; now: a supporting email. But never social media!

    Influencer: Someone who is a respected expert; someone who is just a bit crazy and attracts attention with provocative speech or behavior; someone who can persuade others to a course of action

    Of course, vacation requests and appeals for a better job or compensation all work better in person. On the other hand, we hear about people getting fired by email. Yuk! (If you are going to fire someone, go the office to do it!)

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

    Monday, April 18, 2022

    "T" people vs "I" people

    "T" people: lots of breadth; collaborative across disciplines; depth in one or two 

    "I" people: deep and narrow; the experts

    Bastien Rieck explains all of this in a posting about recruiting. He says this about software people specifically:
    Given the state of the art in the software industry, T-shaped people are a sought-for commodity: the current ‘framework du jour’ might be obsolete in a few years, but the horizontal bar of a T-shaped person ensures that they can also contribute to other aspects of a project, and quite likely will develop new vertical bars, i.e. new expertise over time

    He goes on to talk about Ts as multipliers

    Throughout my career, the most impactful projects always had a T-shaped person onboard. This person would usually not be an expert in the subject matter, but would be able to provide the direly-needed scaffolding and foundation of a project that is all too often ignored in the initial phase, until it comes back later on with full swing to wreak havoc. This includes, for instance: 
    • Setting up a suitable build system. 
    • Writing some unit tests for the code. 
    • Creating a skeleton of the models that are to be developed. 
    • Designing nice mock-ups or logos. 
    • Creating animations or graphics for presentations.

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

    Thursday, April 14, 2022

    Threats, vulnerabilities, and risks

    Daniel Messiler has an interesting essay about threats, vulnerabilities, and risks that is worth a quick read.

    He summarizes this way:
    •  A Threat is a negative scenario you want to avoid
    • A Threat Actor is the agent that makes a Threat happen
    • A Vulnerability is a weakness that can be exploited in order to attack you
    • A Risk is a negative scenario you want to avoid, combined with its probability and its impact
    • The difference between a Threat and a Risk is that a Threat is a negative event by itself, where a Risk is the negative event combined with its probability and its impact

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

    Sunday, April 10, 2022

    From the desk of Nasim Taleb

    “The three most harmful addictions are heroin, carbohydrates, and a monthly salary.” Nasim Taleb

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

    Thursday, April 7, 2022

    Useful history, or not?

    Is keeping project history valuable? Doesn't every project office have at least cost history? Isn't all parametric pricing based on history?

    • Yes, Maybe, Yes .... respectively, to the above! 
    • And, could there be parametric estimating without history (*)? No, definitely not.
    • Or, could there be project, event, or risk statistics without history? (**) No!

    Ooops, perhaps everyone does not agree:
    "History can not be explained deterministically and it can not be predicted because it is chaotic.

    So many forces are at work and their interactions are so complex that extremely small variations in the strength of forces and the way they interact predict huge differences in outcomes....

    Not only that, but history is what is called a level two chaotic system (***). ...  Level two chaos is chaos that reacts to predictions about it, and therefore can never be predicted accurately"
    Yuval Harari

    And, so the take away on this is what? 
    That history is useless for predicting an outcome? Or, that one historical outcome could easily have been another, quite different, except for some favorable interactions -- thus, who knows what might happen the next time around?

    Or, even more intriguing is the last point: a prediction actually changes the predicted outcome. Somewhat like the oft encountered conundrum that a measurement or observation may change that which is measured or observed. (****)

    And, of course, there is the timeless nemesis: causation vs correlation vs coincidence.
    • Causation: A causes C
    • Correlation: A causes some reaction in B which causes some reaction in C (correlation has a third party in most cases, though B may be hidden and hard to discern)
    • Coincidence: Stuff happens
    Ultimate take away: history is problematic, even if it is very instructive. Predictor be aware!

    (*) Parametric estimating: $X per page; $X per line of code; $X per linear foot, etc 
    (**) A statistic is a calculation made from observed or measured values, like the average of all the salaries on a team. Statistics are 'backward' looking in the sense that all the data in the calculation comes from history.
    (***) There are two main classifications of chaos, explains Daniel Miessler:
    First Order Chaos doesn’t respond to prediction. The example [ ] is the weather. If you predict the weather to some level of accuracy that prediction will hold because the weather doesn’t adjust based on the prediction itself.

    Second Order Chaos is infinitely less predictable because it does respond to prediction. Examples include things like stocks and politics.
    (****) As an example, when probing sensitive electronic circuits, the probe itself can change the performance of the circuit.

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

    Sunday, April 3, 2022

    The influencer thing

    Energy dissipates as the square of the distance from the emitter to the receiver -- if the distance increases by a factor of 2, the energy decreases by a factor of 4. (*)
    The fact is, even an enormous energy source may have little effect at long distance, and increasingly less as the distance lengthens.
    So that's the physics for the day.
    How do these physics apply to the PMO? 

    Influence at a distance
    The plain fact is: if you want to maximize your influence, you have to be close to the flag pole -- be at the center of decision making and in the room, at the table, where your energy is maximum.

    And, of course, you have to have something of substance to say. But, I'll leave the content effect on influence to another posting.

    Now you say, remote video conferences are all the rage, and so how does distance make a difference?
    And I say:
    • No virtual conference setting is as clear as being there; there are losses
    • A good deal of communication is lost in the restricted bandwidth, particularly the informal communications during breaks and the body language exchanged off camera
    • If you're really far away, everyone knows you can't get to the flag pole in a hurry, so your influence is discounted
    • All the power of the "casual" encounter at just the right moment is lost
    So, how to have influence at a distance
    • Create intimacy and familiarity by being a frequent communicator
    • Be up front and noisy about your points of view
    • Give feedback on everything so they know you are listening and thinking
    • Be a contributor; be consequential -- get things done. Avoid the empty suit "all talk"
    • Innovate where possible. Be the source, rather than the sink for energy


    (*) The dissipation can be disturbed by many environmental factors, so the square-effect assumes ideal conditions for the energy to travel outward.

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

    Thursday, March 31, 2022

    Be a sequentialist first; beware the accumulations!

    I'm a sequentialist.
    When planning a project, I think first about how to sequence the scope: do this first, then that. Or, do these things in parallel, followed by this or that.

    MS Project, and similar tools, are the sequentialists go-to tool for planning sequences and establishing the sequential order of the project.

    Not so fast!

    What about cumulative, non-sequential, scope and effects?
    For these, we need a cumulalist to help with the plan.

    Accumulations of the cumulative
    The obvious non-sequential scope is all the sundry overhead that descends on the project: HR stuff, regulatory requirements, environment maintenance, training, re-provisioning and refit, and on it goes.
    But, stuff like that is all foreseeable, and to an extent, such requirements can be accounted for in the project plan.
    Beware! Other things accumulate. Insidious accumulations aggregate to a cumulative effect on through-put, and thus cost and schedule, and perhaps even quality:
    • General fatigue from the stress of solving problems and meeting deadlines
    • Frustrations that mount up from dealing with the bureaucracy, other teams, outside consultants and contractors
    • The weather (unless you live in paradise, like I do, in Florida)
    • The pandemic 
    • Network issues and connectivity constraints
    • Security constraints and threats

    Who's watching?

    There are many sequentialists on every project, and in every sponsor organization, keeping watch on the march toward the final milestone. 

    Fewer may be cumulalists keeping watch on the build-up of factors and effects that may have impacts on the progress of the sequence.

    Beware the accumulation of cumulative effects!


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

    Sunday, March 27, 2022

    Starving or stretching the Critical Path?

    In project management school, the lesson on Critical Path includes Rule #2:
    Apply resources first to the critical path, and subordinate demands of other paths to ensure the critical path is never starved.
    But, of course, Rule #2 follows from Rule #1

    Rule #1, if you haven't guessed is:
    Create a schedule network so that the critical path is revealed.

    But here's an issue: If you're only working with major milestones, then there are no network of dependencies, so there is no opportunity to apply something like Rule #1. It follows that there can be no Rule #2, and so no insight to schedule starvation. Yikes! 

    No starvation, but a longer path?
    Some of the time, Rule #2 has unintended consequences, like making the critical path longer! How does this happen?

    The problem arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. Alas! The "parts" are not interchangeable. Mary and John are unique. Consideration must be given not only to the generic staffing profile for a task but also to the actual capabilities of real people.

    Staffing and Schedule intersection
    The intersection of the staffing plan with the schedule plan sometime brings up results that are not always as we want them. Intersection means overlap, and overlap means that the planning elements must be moved about so that each overlap is harmonious.

    Take a look at the following figure for Rule #2: There are two tasks that are planned in parallel. If not for the resource requirements, these tasks would be independent, and if independent the critical path would be 50 days -- the length of Task 1. Task 2, as you can see, is only 20 days duration.

    You can probably see that if not for the specific assignments of Mary and John, the critical path could be as short as 50 days, not 65 as shown.

    Let's violate Rule #2 and invent Rule #3: Reorganize the network logic to take into account unique staffing applied to schedule tasks.

    Using Rule #3, staffing does not actually start on what was the critical path, a violation of Rule #2. 
    But the advantage of Rule #3 is that the overall schedule is shorter nonetheless. In this case, the critical path is only 55 days.
    There is still inter-dependence among tasks. But a new critical path using Rule #3 more optimally incorporates the sequencing constraints of the original path and the staffing constraints brought about by Mary and John.

    Here's the main idea to take away: 
    Any lack of independence among tasks will stretch the path upon which those tasks are scheduled

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

    Saturday, March 19, 2022

    Visionary's approach to Risk Management

    And expect a parachute to follow

    From the Netflix series "Inventing Anna"

    Actually, in the book "The Network" by Scott Wooley -- which is a pseudo-biography of Edwin Armstrong (vacuum tube amplifier inventor, among many electronics inventions ... 42 patents and IEEE Medal of Honor) and David Sarnoff (founder of RCA and NBC) ---  there are many "Leap!" projects described, to include but not limited to:

    • AM and FM modulation, commercial radios and radio networks (NBC)
    • Transoceanic radio telegraphy
    • Television, color television, and television networks
    • Communication satellites (RCA)
    These guys were amazing!

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

    Monday, March 14, 2022

    The THREE things to know about statistics

    Number One: It's a bell, unless it's not
    For nearly all of us when approaching something statistical, we imagine the bell-shape distribution right away. And, we know the average outcome is the value at the peak of the curve.

    Why is it so useful that it's the default go-to?  

    Because many, if not most, natural phenomenon with a bit of randomness tend to have a "central tendency" or preferred state of value. In the absence of influence, there is a tendency for random outcomes to cluster around the center, giving rise to the symmetry about the central value and the idea of "central tendency". 

    To default to the bell-shape really isn't lazy thinking; in fact, it's a useful default when there is a paucity of data. 

    In an earlier posting, I went at this a different way, linking to a paper on the seven dangers in averages. Perhaps that's worth a re-read.

    Number Two: the 80/20 rule, etc.

    When there's no average with symmetrical boundaries--in other words, no central tendency, we generally fall back to the 80/20 rule, to wit: 80% of the outcomes are a consequence of 20% of the driving events. 

    The Pareto distribution, which gives rise to the 80/20 rule, and its close cousin, the Exponential distribution, are the mathematical underpinnings for understanding many project events for which there is no central tendency. (see photo display below) 

    Jurgen Appelo, an agile business consultant, cites as example of the "not-a-bell-phenomenon" the nature of a customer requirement. His assertion: 
    The assumption people make is that, when considering change requests or feature requests from customers, they can identify the “average” size of such requests, and calculate “standard” deviations to either side. It is an assumption (and mistake)...  Customer demand is, by nature, an non-linear thing. If you assume that customer demand has an average, based on a limited sample of earlier events, you will inevitably be surprised that some future requests are outside of your expected range

    What's next to happen?
    A lot of stuff that is important to the project manager are not repetitive events that cluster around an average. The question becomes: what's the most likely "next event"? Three distributions that address the "what's next" question are these:

    • The Pareto histogram [commonly used for evaluating low frequency-high impact events in the context of many other small impact events], 
    • The Exponential Distribution [commonly used for evaluating system device failure probabilities], and 
    • The Poisson Distribution, commonly used for evaluating arrival rates, like arrival rate of new requirements

    Number three: In the absence of data, guess!
    Good grief! Guess?! Yes. But follow a methodology (*):
    • Hypothesize a risk event or risky outcome (this is one part of the guess, aka: the probability of a correct hypothesis)
    • Seek real data or evidence that validates the hypothesis (**)
    • Whatever you find as evidence, or lack thereof, modify or correct the hypothesis to come closer to the available evidence.
    • Repeat as necessary
    (*) This methodology is, in effect, a form of Bayes' reasoning, which is useful for risk analysis of single events about which there is little, if any, history to support a Bell curve or Pareto analysis. Bayes is about uncertain events which are conditioned by the probability of influencing circumstances, environment, experience, etc. (Your project: Find the Titanic. So, what's the probability that you can find the Titanic at point X, your first guess?)

    (**) You can guess at first about what the data should be, but in the absence of any real knowledge, it's 50/50 that you're guessing right. Afterall, the probability of evidence is conditioned on a correct hypothesis. Indeed, such is commonly called the Bayes likelihood: the probability of evidence given a specific hypothesis.

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

    Tuesday, March 8, 2022

    Supreme misfortune

    "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, February 28, 2022

    So, you have to write an RFP!

    Spoiler alert! This posting may be dry to the taste...

    Ever been asked to write an RFP (request for proposal)?
    It may not be as easy as you think.

    Top-down metric
    My metric is about 2-3 hours per finished page, exclusive of specifications. Specs are normally just imported from an engineering, marketing, or product team. So, it could take you the best part of a week to put an RFP in place.

    Check this out
    My outline is given in the Slideshare presentation below

    Beyond the outline, here's a few things to think about.

    Source identification: 
    Sources are those that are going to respond to the RFP and do the work if selected
    Sources, per se, are not part of the RFP, but sources are its audience. And because the RFP is written for a specific audience, so sources certainly influence the RFP.

    Source identification, or better yet: source identification and validation (vetting), is both a science and an art. The science part is an objective list of source attributes; the art part is judgment, admittedly not objective.

    Among sources, there's sole source (the only one in the world who can do it) or selected source (the only one in the world you want to do it), but more often an RFP is a tool to regulate competition among multiple sources.

    Award criteria: How are you going to decide who wins?
    • Lowest cost, technically acceptable (pass/fail) is the easiest and most objective.  Just open the envelop of all those with passing technical grades and take the lowest cost -- no questions, no fuss
    • Best value is not easiest and not entirely objective, but it might get you the most optimum solution. Rather than pass/fail, you get to consider various innovations and quality factors, various management possibilities, what the risk is to you, schedule, and, of course, cost.

      Best value may not be lowest cost. That's always controversial, since cost is the one value proposition everyone understands. No one wants to spend more than the value is worth.

      The flexibility of best value (or, glass half empty: lack of objectivity) comes with its own risk: the award, if in the public sector, is subject to protest about how the best value was determined.
    Risk transfer: what technical, functional, and business risks are you going transfer to the contractor, and are you prepared to pay for that transfer? In effect, you're buying insurance from the contractor.

    All other risks are your to keep; you can be self-insured, or pass them off to an insurance party.

    Risk methods: Here are some risk methods you can put in the RFP:
    • Contract incentives, penalties, cost sharing, and other contract cost-schedule-scope controls: all are forms of risk management practises.
    • Liquidated damages: you get paid for your business losses if the contractor screws up
    • Indemnity: your contractor isolates you from liabilities if something goes wrong
    • Arbitration: you agree to forgo some of your legal rights for a simpler resolution of disputes
    Statement of work (SoW): This is the part most PMs know something about, so a lot of words aren't needed. It may be the first thing an interested contractor reads.
    The SoW answers this question: what is it you want the contractor to do? A top-level narrative, story, WBS, or vision is usually included.

    The SoW is where you can say how agile can the contractor can be interpreting the vision. Think about how anchored to your story you are.

    Typically, unless you are pretty confident you are right, you don't tell the contractor how to do the job, but only what job needs to be done.

    Specifications: How's and what's for compliance: It is certainly necessary to speak about how something is to be measured to prove compliance; or you can speak to what is to be measured to verify compliance to the specification.

    Requirements: And last but not least, the book of requirements is tantamount to the infamous Requirements backlog.

    Give these ideas about requirements some thought
    • Are they objective, that is: having a metric for DONE
    • Are they unambiguous? ... almost never is the answer here. Some interpretation required. 
    • Are they complete? ... almost certainly never is the answer here. But, can you admit the requirements are incomplete? In some culture and context, there can be no such admission. Or, you may be arrogant about your ability to obtain completeness. My take: arrogant people take risks and make mistakes...the more arrogance, the larger the risks... etc

      But, where you can say: Not complete, then presumably the contractor can fill out the backlog with new or modified requirements as information is developed?
    • Are they valid? Can you accept that some requirements will be abandoned before the project ends because they've been shown to be invalid, inappropriate, or OBE (overtaken by events)?
    • Are they timely? Can you buy into the idea that some requirements are best left to later? ... you really don't have enough information at the beginning. There will be decision junctions, with probabilistic branching, the control of which you simply can't

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

    Thursday, February 24, 2022

    Practicals and Virtuals

    Have you noticed this?
    Have you noticed that on many projects there is a bifurcation of the workforce that is by job class, by cultural affinity, by natural skills and interests, and by work-site and location? (*):
    • The "practicals" who live and work and think in the physical world (whether in the office, or not)
    • The "virtuals" who live and work and think in the remote and digital space (even if they go into the office)
    Practicals And Virtuals
    Leverage the differences and make it an "And":
    In the best of all cases, the win-win is to leverage the conjunction of 'practicals' and 'virtuals' as a reinforcing join of culture, skills, and interests. 

    How could you build a new bridge without both working together: Design, analysis, construction? 

    Have you ever looked closely at a sweeping fly-over bridge? 
    • How do they get those massive iron beams to gently curve over hundreds of feet and join seamlessly with the next? 
    • How do they get the concrete columns to have just the right arc to give the roadway above the right degree of bank on the curves? 
    • How would the CAD ever match up with the 'physicals' who drive the rivets and build the molds if they didn't work together ... rather than apart.

    Practicals Versus Virtuals
    'Versus' doesn't buy you anything
    Instead of the joy of a 'reinforcing join', the opposite may be a dis-attraction, rejection, or tension between strangers from two spaces: physical and virtual.

    In systems terms, there may be little or no throughput, poor gain on resources committed, and outright hostility. Obviously, there is nothing to be gained by being at loggerheads about the differences in experience, attitude, and values. Those who can type should also be able to use a screwdriver; but it works the other way around also. 

    But, in fact, the cultural divide can be a chasm: pay, promotion, recognition, status, security to name a few of the HR issues, but also respect, arrogance, and elitism that unwittingly divide rather than unite, to say nothing about herd loyalty and commitment to win-loss.

    If there were an answer ...
    If there were an answer for this, other than self-awareness and walk-in-their-shoes exercises, I would put it down in the next paragraph

    But, there is no next paragraph .....

    (*) Credit to Ross Douthat for the idea of 'practicals' and 'virtuals'

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

    Monday, February 21, 2022

    Bad news?

    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, February 17, 2022

    The first rule of 'data'

    The first rule of data:
    • Don't ask for data if you don't know what you are going to do with it
    Or, said another way (same rule)
    • Don't ask for data which you can not use or act upon
     And, your reaction might be: Of course!

    But, alas, in the PMO there are too many incidents of reports, data accumulation, measurements, etc which are PMO doctrine, but in reality, there actually is no plan for what to do with it. Sometimes, it's just curiosity; sometimes it's just blind compliance with a data regulation; sometimes it's just to have a justification for an analyst job.

    The test:
     If someone says they need data, the first questions are: 
    • What are you going to do with the data?
    • How does the data add value to what is to be done
    • Is the data quality consistent with the intended use or application (**), and 
    • Is there a plan to effectuate that value-add (in other words, can you put the data into action)?
    And how much data?
    Does the data inquisitor have a notion of data limits: What is enough, but not too much, to be statistically significant (*), informative for management decision making, and sufficient to establish control limits?

    And information?
    Well, the usual definition is that information is data, perhaps multiple data, integrated with context, and interpreted for the current situation.

    So, the rule can be extended: If there are not means to process data into information, is the data necessary to be collected?

    Bottom line: To state the obvious: always test a request for data collection for value-add before spending resources!

    (*) Statistically significant: Enough data to distinguish between a 'random or chance outcome', and an outcome that is really from an event, factor, or stimulus of interest. As a practical matter for the uses of PM, ten independent data points is usually enough to establish statistical significance. Other disciplines may require more.

    (**) Data quality: To add value, the data must be timely vis a vis the context, as complete as practical (nothing left out), consistent over time and space, more unique than redundant, sufficiently accurate in a metric sense, and void -- to the extent possible -- of qualitative biases. The latter is a tall order since all human reasoning is biased in some way or another.

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

    Monday, February 14, 2022

    The software is never done (!)

    The software is never done!

    Certainly not news; and certainly not profound to any engineer, coder, or PM working in the software industry, writing apps, or supporting software enabled devices.

    Users have come to expect routine and regular updates to all things software.

    Ooops, not so fast!
    What about the automobile industry?
    Traditionally: the car is done! 
    • Buy it; keep it; sell it, eventually. Never needs an upgrade!
    But that tradition may be short-lived: Cars will need upgrades over the life-cycle

    What now?
    A few months after I bought a new car I got a recall notice to take it in for an upgrade to the transmission control software. That recall system is probably the way to keep software up to date for many of the in-vehicle software programs. 
    • But, is this only a warranty service? 
    • How long would manufactures support software upgrades for 2nd or 3rd party apps?
    • The life of car is 12 years+ for new vehicles. That's 'forever and forever' in the software industry, comparable to still supporting the iPhone 4! 
    Big Tech
    So-called big tech is taking over much of the user interface and user apps in new vehicles (except Tesla which does all its own in-house design and does not support Android and Apple apps on its user panels)

    Long term support
    As a project manager, what can you look forward to as regards long-term supportability of apps?
    And, as a app developer, you may be one layer removed from knowing that it will find its way into the automobile industry. 
    And as a business manager or customer support liaison, which customer are you supporting most?
    • The one that pays the bills (automobile manufacturer) or 
    • The customer that buys the car?
    In the Agile sense of value-as defined-by-the customer, who is most influential?
    Long term, these are my wonderments. I wonder how they would be written into project requirements?
    • I wonder if you'll be able to go to your local auto parts retailer and buy an upgrade-on-a-stick for legacy vehicles? 
    • I wonder if there is not a whole industry to be invented supporting older cars with updated interfaces?  
    • I wonder if its practical to expect the after-market developer to maintain currency for 'a long time'. 
    • I wonder if personal security, data security (nav data, for instance, but also other data about downloads to the car like music stations and podcasts, etc), and all the rest will not spawn a whole set of requirements, support issues, and a supporting industry?

    Perhaps in the future, the mantra will have to be something like this:

    The software is never done!
    And, neither is the car!

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

    Friday, February 11, 2022

    The principle of 'calculated risk' (updated)

    "In carrying out the task assigned .... you will be governed by the principle of calculated risk ... which you shall interpret as avoidance of [risk] exposure ... without good prospect ... as a result of such exposure ...  of greater [benefit]" (*)

    Admiral Chester Nimitz
    to his subordinate admirals,
    Battle of Midway, June, 1942

    "You will be governed by the principle of calculated risk"
    What does that really mean?

    "You will be governed ..." means you've been handed the governance task; there has been a passing of (command) authority and decision-making. Whatever the strategic and most far reaching business and project considerations there are, and whomever has the responsibility for articulating the strategic vision, all that has been compressed into an instruction to "you". "You" have the authority to assess cost and benefit in the moment, and pull the trigger ... so to speak ... to take a risk or not.

    "Calculated risk" is intended to convey a defensive tactic to protect a scarce or endangered asset or outcome; unless the loss of that asset begets a larger offsetting advantage. To that end, there are these constituents:

    • First, a risk assessment based upon what it means for the loss of a scarce asset or a debilitating outcome vs the benefit or advantage of a favorable outcome. Call this a cost-benefit analysis and calculation
    • Second, the quality of your knowledge base, assumptions of knowledge accuracy and timeliness, and a heads-up that there may be knowledge gaps. This is really the epistemic component of the risk: how much can the risk be mitigated by better knowledge?
    • Next, doctrine, ideology, or rules-of-thumb are made subordinate to the calculation. Now to walk away from doctrine for a calculated risk takes some intellectual flexibility and maturity, to say nothing of walking out on the limb.
    • If there is an adversary or nemesis, game-theory may be useful to estimate reactions (walk a mile in their shoes, etc .... )
    • And last, if there is no scarcity which requires the protection of a risk calculation, then the principle is unnecessary.

    Fair enough

    What happens when it comes to actually facing the risk in a real project situation?

    • Intellectual flexibility may be required. 
    • Cool heads will be needed; emotion will be left at the door, hopefully
    • Random effects will almost certainly intervene and perturb the knowledge-base calculations. You probably can't do much about the randomness; that's the nature of the it ... more knowledge doesn't help.
    • Updates to game theory assumptions we be needed along the way.
    • And, revisits to the knowledge base to update the risk calculation (the calculation may be rather dynamic in the doing ...) will be needed. (**) 

    Plan B:

    In spite of cool calculations, in the heat of the moment managers may blunder through the guardrails. Then what?

    There should be a framework for Plan B on the shelf. Facts at the time will fill in the framework.

    Ah, but who's in charge of Plan B? 

    Someone should always be hanging back to grasp the strategic picture while tacticians deal with the here-and-now. And, that someone should have supreme executive authority to step in and make corrections.


    (*) A Naval War College essay dissecting the Nimitz principle of calculated risk is found here.

    (**) This idea of revision in the face of new information is the Bayesian approach risk calculations. That is: you have a hypothesis, "A", based on your going-in knowledge; then there's a change or there is observed evidence "B". Now you know more, and so the likelihood changes ("likelihood" being the probability that the observed evidence will support the original hypothesis, P(B/A)


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

      Tuesday, February 8, 2022

      Roll back the black box

      It's a system engineering idea:
      • Encapsulate a function, 
      • Make it opaque to outsiders, and 
      • Feed it inputs and external controls, biases, and offsets
      • Look for and utilize the prescribed outcomes
      • Voila! You've got a black box!
      What if ...
      What if there are chaotic responses, unforeseen resonances, inexplicable outcomes and distortions, and even destructive behavior?

      The question is begged: Do you understand how your black box works? Very likely if you don't know, the larger system doesn't either because, hey!, you designed the larger system!

      If your answer is No to the above, then here's some advice: roll back the black box and expose the functionality to the point you can understand it; you can defend it; you can reliably forecast it's role in your system

      Working on AI?
      The modern idea of AI with multiple layered meshes of data processors may be the ultimate black box.   If this is your domain, read a bit of this Wired article to get onto my point of view.

      Buy them at any online book retailer!

      Friday, February 4, 2022

      Remoting the physical job

      Old news: Remote work on software and administrative tasks is routinely applied in projects.
      New news: Remote work on physical jobs is, or will be, moving to projects from operations and production
      Other news: Is this outsourcing by another name?

      Assisted robotics
      So, what we're talking about here is assisted robotics.
      • In production, we've been flying airplanes, taking pictures, sniffing bombs, and assisting robotic fulfillment in warehouses for years ... very successfully (measured in human jobs displaced and quality of outcomes)
      • Robotic-assisted medical procedures are more common place than they were
      But in one-off projects, assisted robotics has been a costly thing
      But, it's coming!
      • Designing building a new antenna for spacecraft? Need to work in a 'clean room'? I can operate a lot of the machine tools and assembly tools from home, or least from a remote project office, and I don't have to put on a 'clean suit' to work on the antenna!
      • Building cable bundles and other physical assemblies: do it with human-assisted robotics. Did I mention: no errors, ever! And perfect solder joints.
      • Working on bio-tech, or chem-tech? Hazardous? Bring on the assisted robotics!
      There's a pattern here:
      • Multiple robots do most of the work
      • Humans intervene to stop and start the work, and to trouble-shoot when the robot gets stuck
      Computing the RoI
      • There's capital investment (CapEx) in the robotic machinery (Hopefully, you can make business of designing and building one-off space craft antennas)
      • There's overhead expense to train the workforce to be a robot's assistant
      • And there's project direct expense to add project-specific instructions to the robot's operating system
      • And don't forget that although robots can work 24/7, without fatigue and frustration, the human handlers do need time off or shift rotation
      • But overall there's less labor input and higher quality output (less rework, etc) that drive the 'return'
      Outsourcing by different means
      Did I just say that humans are to train robots to take their jobs away?
      Ooops! That may not be the right message
      Is this just a different outsourcing problem?

      Buy them at any online book retailer!

      Tuesday, February 1, 2022

      When A comes before B

      When A comes before B
      If you understand the nature of A and that of B, and if starting B depends on A, then getting A done before B sounds easy, but sometimes it makes you wonder!
      • Is there a preamble to B that should be done before A is completed?
      • Are the resources for A and B in conflict or not available; such could affect the "preamble" activity.
      • Can B really start after A, or are there other dependencies on the start of B?
      • Do I really want B to start, or do I want to pause and start C somewhere else? 
      • If I start B, immediately after A, have I introduced unnecessary risk or other impacts?

      And, there's this:

      Schedule depends on sequence
      So, if you're thinking about sequencing, you're probably also thinking about schedule: if I plan for "this sequence", how long is it going to take?

      Or, the other way around: if you are working on a schedule, you have to get the sequence down first.

      Scope is what you sequence, but ...
      It seems obvious, but it's worth saying: you have to know what you are going to do. To wit: you can't sequence that which you don't know about. 

      And furthermore, even then there may be sequencing errors that you discover once you understand the full extent of the scope. Leave some slack for the unknown!

      BUT ... Sequencing value-add to the business may be the ultimate sequence determination. Taking care of the business may be your job-one. If you can, choose sequence in favor of the business!

      Scheduling tools
      Scheduling tools, like the ubiquitous MSProject, are a good planning tools for sequencing. You can work in the Gantt-chart mode and sketch out the big picture pretty rapidly, setting up key milestones as schedule goals. You need not use the precedence mode at all.

      However, there is a bridge too far: 
      If  you plan in too much detail, many of these tools are way too tedious to use for maintenance of the schedule once the project is under way. 
      As a practical matter there will be "micro-dependencies" that crop up, which are worked in real time; micro-loops for feedback and checking results against the evolving construction baseline, etc. that are way too expensive to schedule, status, and maintain as they change.

      Milestone focus
      My advice: at the PMO level focus on the major sequences that drive toward value-add milestones.

      Buy them at any online book retailer!

      Sunday, January 30, 2022

      Balancing project sponsor and project manager conflicts

      If you follow this blog you've read several references to the project balance sheet. So, is this about accounting? Yes, and no: Yes, it's about a double entry tool to keep track of "mine" and "yours", but no, it's not the accountant's tool used in your father's accounting office.

      Take a look at this figure:

      What have we got here?

      First, the business and the project; but also what's mine -- the project stuff -- and what's yours -- the business stuff. Mine and yours!

      First, the left side
      On the left side of the balance sheet is the sponsor's investment in the project. Investment need not be all monetized, and it need not be all tangible. Sometimes 'good will' -- the accountant's name for the intangible gut feeling that this thing is worth more than book value (market-valued assets) -- counts for a lot. (Think: sponsor commitment, even when the going gets tough)
      'Yours' simply means it's resources and commitments owned and given by others to the project. It's the 'your's side of the balance sheet that's somewhat akin to the right side of the financial balance sheet (money owed to creditors and money invested by owners).

      Then, the right side
      On the right side is the 'mine' side of the project balance sheet, akin to the left side of the financial accounting sheet (assets of the enterprise). The right side is the project side:
      • Estimates and evaluations of the project manager
      • Uses for the investment and resources to be entrusted to the project manage -- in effect deliverables and other artifacts, and perhaps some intangibles as well*
      All about facts
       And, take note: the left side, the sponsor's side, is the fact-free zone: it's a top down allocation of resources to the vision. It is the ultimate utility expression of the sponsors: what's valuable, and how valuable, even if not entirely objective.

      And on the right side, it's all about facts (benchmarks) and estimates (benchmarks applied to project circumstances). It's bottom up.

      The gap
      Of course, there's the inevitable gap where utility collides with facts and fact-based estimates. The gap is the risk between expectations and capacity-capability. And how large is the gap (risk): only as large as needed to create a balance--that is, a deal with the devil--so that the project can go forward.

       In other words, the gap (risk), shown on the project side, is only as large as it needs to be to close the gap. Usually, it's a matter of negotiation, but once the PMB is set, the risk is the PM's responsibility to manage.

      Oops! the PM is the ultimate risk manager.

      In a real world example, I had this situation:
      • We bid a job competitively in a firm fixed price environment. 
      • We offered a price that was equal to our cost; in other words, no fee (profit).  We just wanted to keep the lights on and keep barriers to competition with our customer as high as possible. 
      • We won! 
      • And, in  the next moment, my general manager said: "Your bonus depends on making 4% net margin".  I had my gap!  (oh yes, I made the margin and the customer was satisfied)

      * Yes, indeed! Projects produce intangibles, even good will, but it makes for an accounting of project value all the less objective.

      Buy them at any online book retailer!