Pages

▼

Friday, December 29, 2023

To lead and to follow


A mark of effective leadership is recognizing that following advice, sometimes tactically off the main beam of your strategy, is not a weakness of leadership but rather an indicator of personal security and  strong character. 

About a leader somewhat infamous for stubbornness it was said:

Once again [our leader] had demonstrated his uncommon ability both to lead and to follow, to stand firm and to give way. This was the hallmark of his early years [of professional development] in the teeth of expectations that he would be professorially rigid and dogmatic. He made a point of treating [sponsors] with respect, as partners in a common cause

James MacGregor Burns

Over managing; under leading:

Sometimes confusion arises when leaders take the advice of managers -- the people who know how to get things done. Has leadership been submerged and management become dominate? Needless to say -- but I'll say it anyway -- management is focused on measurable results, metrics of performance, and predictability-reliability. 

We don't usually put a lot of measurable metrics around leadership. We know it when we see it: vision, inspiration, motivation, innovation. When present, these attributes drive business and organization success, and that is measurable. 

But when a leader loses their way, or has a mind-blank of vision, regression to management is often where they go. And you'll know it when you see it: an unusual, or even inappropriate, focus on management metrics.  In such situations your project is "management rich" and "leadership poor". 

What to do about it?

Task 1: Speak truth to power. Point out the slip, perhaps inadvertent, from leadership to management.
Task 2: Make leadership demands that will push your inadvertent manager back into the right sandbox.



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

Tuesday, December 26, 2023

How much knowledge?

Got knowledge?
"If a little knowledge is dangerous, where is the man who has so much as to be out of danger?"

Thomas Huxley,
"On Elementary Instruction in Physiology", 1877

 


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

Friday, December 22, 2023

Gambling for resurrection

Your project is in trouble.
You've spent all the money and have little to show for it.
There's a decision to be made: Shut it down, or take a gamble on resurrection?

A gamble on resurrection is a financial theory about risk taking that posits taking on more risk or leverage in a hope that circumstances -- mostly beyond your control -- will turn favorably and bail you out. (When visiting casinos, I remind myself that the glitz and glamour was all paid for by losers; so there must be a lot of them, and they must lose a lot of money). 

A gamble on resurrection is also a management theory that posits inventing or prioritizing an unrelated event in order to divert attention from the problem at hand. (so called "wag the dog" tactic)
Leaving aside any management diversions -- which risk reputation and integrity-- the economic practices at a decision point about shutting down, or not, modify the gamble in these ways:

Sunk cost rule:
The usual PM rule invoked at this decision point is to ignore sunk cost because you can't do anything about it. Focus only on the future. Is there a viable plan or not? If not, shut it down. 

Moral hazard rule:
If the decision is to shut down, that can't be made without consequences of accountability, else there is a moral hazard created that failure has no cost. 

Of course, the degree of moral hazard is a function of whether or not the project was planned as a high-risk adventure with an anticipated high rate of failure. Such is the essence of the "fail fast; fail often" theory that drives extreme risk takers.

Deleverage rule:
When developing a go-forward resurrection plan, rather shutting it down, the usual planning doctrine is to actually take less risk than the risk that got you here. In other words, you "deleverage" the risk-to-reward ratio and plan more conservatively.


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

Tuesday, December 19, 2023

Threats and Risk: an introduction


Daniel Miessler 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
All good, but then what do you do about any one of them?
Begin with knowledge acquisition.
Any threat, risk, or vulnerability that is susceptible to reduction by knowing more about it is probably worth the investment to gather the available information, or conduct experiments, models, or simulations to put data into an analysis process 
Such activity is applying the skills and processes of epistemology which is the theory of knowledge, especially with regard to its methods, validity, and scope. 
Most important for project management, "epistemology is the investigation of what distinguishes justified belief from opinion." (Oxford online dictionary)

And, to carry it a bit further, such risks, threats, and vulnerabilities are often called epistemic risks, etc.

Truly random effects
If your knowledge study convinces you that more knowledge won't improve the mitigation, then you are in the realm of random effects which are largely unpredictable -- that is, random -- within certain boundaries. 

There are two major categories of such randomness that project managers deal with:
  1. The central tendency type of randomness wherein random effects tend to cluster around a central figure, and outliers fall off and away from the central figure. This leads to the so-called "bell curve" which is usually not a perfect bell, but nonetheless the centrality is evident in the data

  2. The "power law" type of randomness wherein random effects are "one-sided" and fall off roughly as the square of the distance from the main lobe. The Pareto histogram is a familiar example, as is the "80-20" histogram.
The best way to identify which of these two phenomenon -- central clustering or power law -- is your situation is by experimentation, observation, simulation, and modelling to develop data and thereby determine the "fit".



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

Saturday, December 16, 2023

U.S. Gov Research in the public domain


You hear a lot about theft of intellectual property, aka IP. Well, a lot of IP in the U.S. government domain is freely available:

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!
at

Tuesday, December 12, 2023

Are you in the groove, or a rut?


Are you "in the groove", making good time and product, or are you in a rut?
How to tell?
  • A rut is about 6" deeper than a groove
  • It's easy to see over to the next groove -- it may be better -- and you can change grooves if you need to
  • In a rut, you often can't see out for other opportunities
  • A rut sometimes just gets deeper the more you're doing
Alex Walton, 3PM
In a rut, the first rule of holes often applies: just stop digging!

Beyond platitudes:
Most people would prefer not to be in a rut; it's not stimulating and rewarding
  • Like never before, self-help is the first step out. And the internet is the primo source of self-help.
  • Summoning the courage to take a risk is probably step two. Even if you're just moving into a groove in familiar space, that sometimes requires some risk-taking
  • Asking others for an evaluation of your profile is an important risk step. Park your ego and your pride long enough to take in the data and process it.
  • You may have to outright quit and start over, maybe even entry level. Or, if you're entrepreneurial (and everyone isn't), you can start your own 
But the most important thing is to overcome inertia and "do something". If it doesn't work, try again. Ruts are not permanent.


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

Friday, December 8, 2023

Layoffs? I've got a project to run


Well, talk about cratering a schedule and resource plan!
Layoffs in the middle of a project will do it for you.

But wait!
There may be a silver lining here:
  • Communication complexity in and among project participants decreases as the square of participants. That could be a winner

  • You may be able to select the departees. That's tough in any circumstance, but it's also an opportunity to prune the lesser performers.

  • Some say that if you want to speed up a project, especially software, reduce the number of people involved (the corollary is more often cited: adding people to a team may actually slow it down)

  • There's an opportunity to rebaseline: All the variances-to-date are collected and stored with the expiring baseline. A new plan according to the new resource availability becomes a new baseline. Unfavorable circumstances can perhaps be sidestepped.
Of course, there are downsides:
  • If your customer is external, they may not relent on any requirements. You're stuck trying to make five pounds fit in a three pound bag.

  • There may be penalties written in your project contract if you miss a milestone, or overrun a budget. That just adds to the fiscal pain that probably was the triggering factor for layoffs.
Did you see this layoff thing coming?
  • On the project balance sheet, you are the risk manager at the end of the day. So, suck it up!

  • And there's the anti-fragile thing: build in redundancy, schedule and budget buffers, and outright alternatives from the git-go. And, if you didn't do those things in the first baseline, you've got a second bite at the apple with the recovery baseline.
<

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

Tuesday, December 5, 2023

On being accountable


Are you accountable?
Most of us want to answer 'yes, of course!'; how could it be otherwise? 
Most of us would endorse these ideas:
I'm always accountable for what I do. 
I'm accountable for that which I am responsible.
(Subtext: this can only be true if my personal integrity does not allow me to push blame on to others for failures and missteps, or claim false credit for what others actually did)
Accountability attaches credit and blame.
In popular culture, it seems to be more about attaching blame: A common refrain: "Who's to be held accountable for this!?"

Actually, being accountable means accepting blame or consequences when valid, but also stepping up and accepting accolades when earned.

I like this from Henry Evans, the author of Winning with Accountability, who says accountability is “clear commitments that in the eyes of others have been kept.”

Evans has set the frame: the final judgment about accountability is with others. 
In this sense, the concept of personal accountability is somewhat of an "earned value" idea: 
  • You have a 'planned' set of responsibilities to get things done.
  • You 'earn' accolades or consequences as you account for your actions
  • Others judge the earnings and apply the credit or debit
Thus, in all schemes of accountability, you have a part to play: It's on you to commit to your responsibilities. So, even though Evans' statement is not explicit about being responsible, the holistic idea of accountability stemming from commitment embraces responsibility.

But what I don't like about Evans' statement is that it could be interpreted as requiring 'achievement' (in the sense of a commitment kept) when, of course successful achievement is not a requirement for accountability. Only a commitment to execute responsibly is.

And so in the context I've laid out it's common to encounter these questions:
  • What is accountability, or what is it to be accountable?
  • Can there be accountability without responsibility?
  • Can there be responsibility without accountability?
  • Are you given accountability, or do you grab it and take it on?
  • Is the apex of the pyramid always accountable for anything down in the pyramid? (See: Captain of the ship is accountable ..... )
I don't want to dig too much more deeply into the psychology of 'accountability', and realistically that would be a fools' errand because project and business culture drive a lot of the answers to the questions above.

So, without making a big thing out of the answers, I'll offer my thinking here:
  • As Evans puts it, accountability is about taking personal responsibility for outcomes: "I got this!" "I'm the one you can count on to get it done" "I will be there to see it through". All statements of commitment.
    And with Tom Petty in mind: "I won't back down!".

  • The accountability/responsibility questions are ageless; they've been around since forever! The usual answer is: 'If you want me to be accountable for outcomes, then give me the responsibility for plans and resources. If you crater my plan and matrix out my resources, then you're accountable and not me!

  • If you're not the apex (most senior executive) of the pyramid, you might be 'assigned' accountability: 'This is your mission and no one else's;  go get it done, and tell me when you're finished'.

    Actually, if you're low to mid in the pyramid, there's probably a backup to you. If it's a big pyramid, you may be an interchangeable cog in the mechanism. Nonetheless, grab it and go!

  • Most of time, 'seniors' are always happy to have accountability 'grabbers' in the mix. It makes it easier to allocate the mission requirements. And, you may quickly earn and retain the leadership label.

    But the 'grabbers' are sometimes seen as more interested in climbing the ladder than actually advancing the mission. So, some balance of eagerness and opportunity is required.

  • Traditionally, the 'apex' is accountable for the performance of everything done in the name of the pyramid. This is accountability without personal responsibility for outcomes. The "commitment" embedded in the concept of accountability is interpreted as 'committed to ensuring a responsible person is found, assigned, and expectations for outcomes established".

    In the military particularly, and certainly on ships at sea, this idea is deep culture.

    But, that idea often gets lost. One chief executive famously said that success has many fathers, but a failure is an orphan.

    Worse is the chief executive who denies accountability for all but successes. That is morally corrupt and a morale killer.


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

Friday, December 1, 2023

About thinking


The real problem is not whether machines think but whether men do.

B.F. Skinner


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

Wednesday, November 29, 2023

Scale makes it different

Scale is its own thing.
Bigger is not always better, but it's always different.
For that matter, so is smaller.
Look no farther than physics: 
  • Smaller: Sub-atomic quantum physics features particles with properties that are statistically uncertain, but those same properties would be deterministic but for the small (!) size.

  • Bigger (or greater): For objects moving at near the speed of light the laws of physics don't change, but the math does (Einstein's theories). For example, you can’t just add velocities together the way Galileo or Newton did; you have to add them relativistically. You can’t just treat distances as fixed and absolute; you have to understand that they contract along the direction of motion(*).
What about projects at scale?
At large scale, one observer (*) has said: "The quantitative becomes qualitative" meaning: when it gets big, the whole thing takes on a different character, apart from the numbers. Example: soloist vs a choir; a few people vs a crowd; the Grand Canyon vs a gorge, and so forth. 

There's a lot going on in big projects; some stuff we all know about and have experience with:
  • Communications degrade qualitatively and exponentially with the number of communicators. If two people are talking to each other, it's merely bi-lateral. But if 5 people talk among themselves, there's 5*4 ways that communications can flow: N*(N-1)

  • Bureaucracy inevitably replaces personal trust and one-one relationships. You can't know and trust everyone is a large project with myriad subcontractors (1099s or entire companies), remote team locations, etc. So bureaucracy has rules, workflows, organization structure, and other institutional relationships to replace and substitute for personal relationships.

  • Interfaces, whether institutional in the PMO or as part of systems of deliverables, become all so important. You may not have any visibility or understanding beyond the interface specification you must meet. (See: Systems, below)
 But there are other influences that are prominent at scale:(***)
  • Systems is the way you think about things. Anything really large has properties of systems, and so you have to think like a systems-savvy person: interactivity; interconnections; dependencies; sequencing; process and constraints; chaotic and impulsive behavior. If you don't know much about systems, start here.

  • Phase or state changes: Increasing complexity arising from increasing parts is usually not linear; there may be abrupt changes of state or performance. Suddenly there are walls you can't get through; people you can't reach. Or, machines reach their absolute limit, beyond which their performance is unpredictable or unreliable

  • Reduction vs construction: What you can disassemble you may not be able to reassemble or construct from the pieces. An unintended explosion may be an "unmanaged disassembly" in systems' speak. You can't put Humpty Dumpty back together.

  • Symmetry, or not: If it's symmetrical, then it looks the same from all points of view. As things scale up, symmetry is often, if not usually, lost. There are just too many different points of view.
Scale effects on cost and schedule
Scale has two effects on cost:
  1. Scale increases friction with so many moving parts to the project. That is a cost increase, albeit with the benefit of having access to myriad capabilities and functionalities
  2. Scale is improves efficiency, making cottage industry efforts into industrial strength workflows, thereby reducing cost.
Scale requires "loose coupling" in schedules. 
That is, white space or buffers are needed to accommodate a dizzying number of dependencies and interactions. And loose coupling protects the critical path, as we know from Critical Chain scheduling. All of this has a combined effect of stretching the schedule. But that's the "cost of doing business" at large scale.
 
-------------------
(*) Karl Marx
(**) Attribution: Ethen Siegel
(***) If you are into science, read this oft-cited paper: "More is different"


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

Saturday, November 25, 2023

Shifting baseline syndrome

It's a rare project of any significant scale that does not rebaseline sometime in the life of the project.
Why rebaseline?

The PM rebaselines when the "old" baseline is no longer relevant as a guide to management. Either cost, schedule, or scope have gotten so far off the original baseline that the baseline is no longer valid for future management decisions. Thus: rebaseline.

How do you go about rebaselining?
  • Gather all the actuals and variances in the current plan. Archive that data.
  • Replan the future from the present. That is the new baseline
  • At the end of the project, add the archive to the new baseline performance for the overall project performance.
Shifting Baseline Syndrome
Shifting baseline syndrome is the phenomenon whereby, over time, the "old" baseline drifts out of memory, or perhaps new staff never experienced the "old" baseline. We acquire the mantel of the new baseline, and all seems fine in this "new normal" which morphs to just "normal".

Measurements are taken against the new baseline; in effect, the goal posts have been moved. We become insensitive to the position where the goal posts used to be. The new position is accepted as normal, and we move on from there.

Countering the syndrome
Actually, it's not really necessary to counter the syndrome day-to-day and you wouldn't want to if you could. The new baseline is your management plan going forward.

It is only necessary to keep in mind at the PMO level that there is an archive of actuals and variances to be accounted for at the end of the project. 

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

Tuesday, November 21, 2023

Are you sinking? Or sunk?

Let's keep the basics in front of us:
  • Projects are transformative processes packaged together
  • Inputs (cash, people, buildings and tools, overhead like training) are transformed into deliverables that don't remotely look and feel like the inputs
  • Deliverables are much more valuable than the sum of the inputs
Too often, the focus of the 'business' is on the inputs being consumed, like cash-flow and resources consumed, whereas the more experienced among us keep an eye on input/output efficiency.

And what do we mean by I/O efficiency?
We mean how well input consumption corresponds to its planned value, and how well the corresponding outputs conform to (planned) expectations, when each is sampled--measured--observed in the same time period.

What about sinking and sunk?
Once the project grabs input and consumes it, that input is "sunk", and can't be changed or refunded
Most of us are familiar with the first law of 'sunk' resources: 'Don't use the sunk resource to make a decision about a sinking project". 

Those focused on the sunk resources are focused on inputs rather than outcomes; are focused on the rearview mirror rather than the windshield, and may not understand the opportunity for adjustments.

That is: the future of your project--if it has one--should stand on its own merits re how resources will be used in the future, not so much how they were used in the past.

Why this first law?
Because at the moment you are challenged--even a self-challenge--to justify your future by citing the past, that is the time to root cause analyze the efficiencies. Depending on the analysis, you will have an opportunity to make decisions to alter the likely future efficiencies, and you have the opportunity to 're-baseline'

The future may not "wash-rinse-repeat" what has already been sunk.



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

Saturday, November 18, 2023

Making a prediction?

Making a prediction?
Something to forecast?

Milton Friedman (deceased now), distinguished economist and notably conservative when it came to finances has this advice

If you're going to predict, then predict often!

Yes, it's a bit humorous. But it's also true, to wit: the future is uncertain, subject to change, and subject to change unexpectedly and perhaps even near-term. So, Friedman might have said:

  • Sampling theory tells us to same at least twice as fast as the changing situation we're engaged with.
  • If we can't reasonably estimate whether change is linear or exponential, then "sample early; sample often"
  • Long-term predictions are of low value (See: sampling theory, above)


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

Wednesday, November 15, 2023

What's the worst case?


Perhaps the most common question in risk management, if not in project management is this one:
"What's the worst case that can happen?"
Don't ask me that!
Why not?
Because I don't know, and I'd only be guessing if I answered.

So what questions can you answer about the future case?
  • I can tell you that a projection of the past does not forecast the future because I've made the following changes (in resources, training, tools, environment, prototypes, incentives, and .....) that nullify prior performance ......

  • I can tell you that I can foresee certain risks that can be mitigated if I can gather more knowledge about them (Such being a Bayesian approach of incrementally improving my hypothesis of the future outcomes). So, I have the following plan to gather that knowledge ......

  • I can tell you that there are random effects over which I have no control and for which there is no advancement in knowledge that will be effective. These effects could affect outcomes in the following ways ......

  • I can tell what you probably already know that the future always has a bias toward optimism (there's always time to fix it), and that there's always a tactical bias toward "availability" (one in hand is worth two in the bush ....) even if what's available is suboptimum.
Heard enough?
So go away and let me work on all that stuff!

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

Sunday, November 12, 2023

quality Assurance is free; QC is not

Philip Crosby is credited with the idea that "Quality is Free", and he made some money on the book by the same title ... still available from e-book sellers.

When I first heard that phrase -- around the time Crosby's book came out -- my thought was: If so, what is that line item in my budgeted WBS for quality planning and QC? It's not $0 for sure. So how is "quality free". Admittedly, TQM was everywhere at that same time (*)

Actually, the idea here is quality Assurance vs. quality control. The former is "free", perhaps even a profit center; the latter is always a cost, sometimes bolted on at the end.

Characterizing QA as a profit center has these business ideas embedded:
  • There is a direct cost for some QA activities, to be sure, but other aspects of QA as an assurance strategy is a mindset that informs PM planning and execution
  • There are attributable savings from QA -- taken holistically -- in the form of cost, schedule, and scope assurance that expectations will be met.
QA as a mindset
Perhaps QA should be written qA to emphasize that it's assurance we're after, in the context of "doing good; avoiding evil" of course!

The PM is always seeking  mission assurance. 
And the mission? 
The PM's mission is to meet sponsor expectations by returning a quality product or service in return for the sponsor's resources invested with the PM, taking calculated risks to do so. 

It's a balance sheet idea: sponsor investment balanced by resource transference into product + the baseline cost of risk (mostly the baseline cost of planned mitigation)

Two ideas inform "Assurance"
There are two ideas here to keep in mind at the same time: 
The first is that quality has these actionable artifacts :
  • Measurables that validate environmentally fit; functionally, effectively, and efficiently operable; safe and secure (**)
  • Value attained that is a multiple of cost (the whole is worth more than the parts; utility is >1)
  • Mission objectives of timeliness and scope that are achieved
And the second is that "assurance" embodies some ideas from risk management and some ideas from sampling theory
  • Schedule assurance by smart use (read: PM management) of slack to protect the critical path (some ideas on how to do this are embodied in "Critical Chain Theory" formulated by Goldratt
  • Cost-Value assurance by built-in reserves and attention to value earned by a dollar spent
  • Performance-to-scope sampling in real-time -- at a sampling frequency that's "inside the performance (work-package) timeline" -- to trap issues and correct deficiencies early when they cost the least, and make agile tactical data-driven decisions that assure strategic accomplishment.
Assurance is free:
Protect the critical path: manage slack by buffering for uncertainties at the critical milestones; have a bias toward "earliest start" rather than waiting; resource the CP before others
Mitigate uncertainties, in part, by allocating budget reserves to underwrite probabilistic event-impacts.
Stay ahead of unfolding events by sampling, measuring, and analyzing frequently enough to be inside the work-package timeline.
------------------- 
(*) Total Quality Management was a movement and a concept that quality ideas and expectations had to be well understood throughout the organization. That is: there had to be a consistent "deployment" from executive to doer of what was expected and also of what was to be done.

TQM audits were conducted to verify deployment (I was an auditor for a year or so).
After a while, the TQM moniker and a lot of the bureaucratic overhead faded away, but the overall concept is valid: everyone should think and do quality practices in a (culturally) consistent manner.

(**) There are a lot of ideas embedded in "effectiveness". Some go to reliable, predictable, non-chaotic performance; high availability achieved by long mean-time-to-fail and quick mean-time-to-repair; long term support after sale or delivery. 
Other ideas of effectiveness are financial: cost-effectiveness which means "good" utility for operating dollars.

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

Wednesday, November 8, 2023

Owner's rep: the why and what

Having spent the past nearly 10 years in an "owner's rep" role, I can endorse what the American Bar Association (to whom I would not ordinarily look for project management topics) says about being an owner's representative, why the construction industry in particular has room for the role, and why the public sector is in the game.

Of course, before 10 years ago, while I was in the defense systems domain, it was common to have an "SI", a "system's integrator" that more or less extended the reach and expertise of the PMO (or PEO), particularly coordinating scope and sequence for specialty contractors to come in at just the right moment with a unique skill.

From the ABA:
ABA on Owner's rep
The reasons for increased use of third-party owner’s representatives are likely driven by a combination of the growing technical complexity and economic risk associated with modern construction projects, the evolution of new and more complex project delivery methods, and increased specialization of design professionals who have historically served the role of owner’s representative.  Both private owners and public-sector awarding authorities are retaining project advisors to supplement their internal management and administrative capabilities and address gaps in services rendered by the design professional, commissioning agent, and construction contractor.

On public projects, use of owner’s representatives is proscribed by law in many states and local jurisdictions.  Where use of owner’s representatives remains discretionary, owners must consider whether they have the internal capabilities and resources to successfully manage the construction process and whether the additional expense of the owner’s representative will have a positive impact on the schedule, cost, and/or quality of the project.


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

Saturday, November 4, 2023

Risk Un-management

Assert: "The vast majority of identified project risks go unmanaged."
Really?
Is that assertion calibrated with historical performance? Actually not; it's more intuitive, after thinking about the numbers of risks a large-scale project encounters.

And, we're talking risks; not issues.
So when looking at this, keep the distinction in mind between a risk and an "issue"
  • Risks are events or outcomes that are characterized as having a probabilistic eventuality (meaning they may or may not occur) and a probabilistic impact, for which there is a root cause driving the uncertainties of outcome and impact. Example: There is a risk, when constructing a seawall, that storm surge may exceed some design limit, causing unusually severe damage, if a coincidence of high tide, moon, and storm peak should occur.

  • Issues are circumstances that encumber efficiencies, lead to rework, and generally hold back progress. Example: Dealing with the communication inefficiencies of language and time zone is an issue. Such is not a probabilistic; the circumstances are determined and somewhat fixed. The "costs" of time/language inefficiencies are to be baselined in the budget and schedule. 

Define unmanaged
When I say "unmanaged" I mean that a decision has been made, hopefully consciously, that the risk consequences will be addressed if and when an event occurs, rather than baselining a risk management plan to identify root cause and trying actively (that is, spend resources) to reduce impact and affect probable occurrence. 

Consequences
And so you decide not to manage some risks. Who then pays for unmanaged consequences? Per se, their cost is not in the baseline. The first-order answer is project reserves. A second possibility is warranty premiums, or product-return reserves. Unfortunately, the user/owner may pay as well (hopefully, it doesn't come back to you in a lawsuit, but I used to be in the product liability business).

Unmanaged is a decision
There are several reasons why risks might go unmanaged or not be actively mitigated:

Lack of Awareness: Sometimes, project stakeholders and team members may not be fully aware of all the potential risks associated with a project.

Limited Resources: Projects, especially smaller ones, might lack the resources (both in terms of time and personnel) required for comprehensive risk management.

Overconfidence: Project managers or team members might be overly optimistic about the project's success and underestimate the potential risks.

Inadequate Planning: If the project planning phase is rushed or lacks thoroughness, potential risks might not be identified and addressed adequately.

Poor Communication: Ineffective communication among team members and stakeholders can lead to misunderstandings about project risks and how to manage them.

Organizational Culture: In some organizations, there might be a lack of a risk-aware culture, where risk management is not given due importance.

Recognizing the value of risk management
Project management methodologies like PMI's PMBOK and PRINCE2 emphasize the value of risk management to project success. There are well documented processes for identification, assessment, and mitigation of risks throughout the project lifecycle. So also are a myriad of standards from ISO, the U.S. DoD, NASA, AIA, and on and on in every major domain and industry. Experienced project managers understand the significance of managing risks.

While there are instances where risks are not managed, many organizations and project managers are smart enough and experienced enough to know they must actively engage in risk management to enhance the likelihood of project success.



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

Wednesday, November 1, 2023

System Integrator (SI) Owner's Rep


In the government domain, the government often contracts for an SI -- system integrator -- whose scope of work is to be an independent evaluator of program plans and progress, an expert adviser to the program executive for risk management and value engineering, and a voice in the project office not beholden to the prime contractor(s), system architect(s), or other implementers. 

In large programs, the SI may work simultaneously with multiple prime contractors, overseeing their coordination, communications, consistency in approach, integration of scope, and guarding for "white space" gaps. The SI may even evaluate the integrated program for 'chaos' ... the unintended outcomes of an integrated 'whole'. 

In some limited situations, the SI may even develop an interface that seems tagged to white space.

In the commercial domain, a similar scope and role is often given to an "owner's representative". 

Necessary or Nice to Have?
Your first thought may be: Another scope of work .... do I really need this for project success? If I don't engage with a service provider for this scope, is this something I am going to have to learn how to do myself, and then allocate my resources to the task? Or, can I get by without it?

Quick answer: It's work that has to be done ... to some level of scope ... so either the PEO or PMO does it with in-house resources, or the PEO/PMO engages an SI who is expert in the scope and presumably not learning on the job on your nickel.

And, by the way, if you do engage with an independent SI, then cooperation with the SI on the part of your architect, prime contractor, and perhaps other stakeholders has to be made part of the Statement of Work (SoW) with those parties. Question worth asking: Does that cooperation come at a cost, monetized or functional?

What's the ROI on the SI engagement
So, whether you are a government program office or a business unit with a large capital project, what's the value-add of having an SI or owner's rep on the scene? Is there a monetized ROI to the cost of a SI, or is the advantage with a DIY model (do it yourself)?  

In many respects, it's the insurance model: High impact with low probability, to take a square from the risk matrix. Thus, a low expected value, but nonetheless the impact is judged unaffordable. 

The usual risk management doctrine is this: You've got a big (big!) project with a lot of moving parts (different contractors doing different stuff). Get yourself an SI! (At a cost which is usually a small multiple of the expected value, if you think of it in terms of insurance)

SI Scope
The SI is on alert for these 'black swan' impacts that could derail the program, extend the schedule, impact performance, or cost big bucks for rework. 

The SI comes on the job early, typically from Day-1, working down the project definition side of the "V" chart (see chart below)

The SI is an advisor to the PEO or PMO regarding threats to the cost, scope, schedule, or quality. If there are value engineering proposals to be fit into the program, the SI is usually the first to evaluate and advise about their applicability.

The SI is an independent evaluator ("red team") of specifications, looking for inconsistencies, white space gaps, sequencing and dependency errors, and metric inconsistencies

The SI is an independent technical reviewer for the PMO of the progress toward technical and functional performance. The SI may provide much of the data for earned-value analysis.

The SI can be an independent trouble-shooter, but mostly the SI is looking for inappropriate application of tools, evaluation of root cause, and effectiveness of testing.

The SI may be an independent integrator of disparate parts that may require some custom connectivity. This is particularly the case when addressing a portfolio. The SI may be assigned the role of pulling disparate projects together with custom connectors.

The SI may be independent integration tester and evaluator, typically moving up the "V" from verification to validation

In a tough situation, the SI may be your new best friend!
What about agile?
'Agile-and-system-engineering' is always posed as a question. My answer is: "of course, every project is a system of some kind and needs a system engineering treatment". More on this here and here.

And, by extension, large scale agile projects can benefit from an SI, though the pre-planned specification review role may be less dominate, and other inspections, especially the red team role for releases, will be more dominate.

V-model
Need to review the "V-model"? Here's the image; check out the explanation here.

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

Saturday, October 28, 2023

The bane of big projects

In the beginning, "people" are told: "It's too soon to know where we are in this project"

After the beginning, "people" are told: "It's too late to stop the project; there's too much sunk; we have to keep going"


Sampling the data
And so the bane of big projects comes down to poor sampling technique: 
Either the early details are not predictive because the early "efficiencies" of cost per unit of value earned have too little history to be useful as a long-term predictor; or you've accepted the first idea for too long, thereby failing to update efficiency predictions until the late details are too late to pull the plug on a bad bet.

Sunk cost decisions:
It's easy to write this, and far less easy to execute, but never make a decision about the future based on the sunk cost of the past. You can't do anything about recovering the actual expenditure, but you do have free will -- politics aside -- regarding more spending or not. 

History has value
On the other had, sunk cost has a history, and if you are good at what you do, you will use that history to inform your decisions about the opportunity of the future



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

Tuesday, October 24, 2023

More about proposals


Do you read Mike Clayton? You probably should.

Here is his idea of the 12 points of a perfect proposal:

What are the elements of a perfect proposal? Here are 12.
 
You
No one wants to hear all about you. See the next subtitle. That's who your audience wants to hear about... themselves. But (and it's a big 'but') they do need to know enough about you to know you are worth paying attention to. So, for a cold proposal, this means using the introduction or cover letter or some other means to establish your credibility - what my dad used to call your bona fides.

Them
This is what they want to know... What's in it for them? Show how you have their best interests in mind with this proposal. You understand their needs and desires and know how to satisfy them better than any alternative solution can.

Focus
Keep your focus on the specific situation. Any sign of standard 'boilerplate' descriptions, arguments, or evidence will make it look less about 'Them' and more about 'anyone'. 

Value
How will your proposal deliver and maximise value to them? The vast majority of business decisions revolve around the capacity to either make money or save money.

Benefits
But there can be other benefits too. Describe the non-financial value your proposal offers - and what this means to them. This, of course, means you need to take time to understand them and their requirements and priorities. 

Emotions
All that hard evidence gives them a reason to make the decision to accept your proposal. But it won't motivate them to do so. For that, you need to tap into their emotions. Find emotional hooks into pride, fear, duty, desire, ambition, loyalty, passion... Emotions drive decisions: reasons justify them.

How
So, you also need to show how your proposal will solve their problem, deliver their joy, or enhance their reputation. Make the link between what they want and what you are proposing as clear, simple, and short as you can. A 15-step sequence from the cause (your proposal) to the effect (their outcome) won't cut it. 

Process
Next they need to know what will happen if (when) they say yes. What will you do, what will they do, and how long would it all take? For confidence that your is the right choice, they need to see a plan that clearly works.

Context
This section lets them understand how your proposal fits into your life and theirs - your business and their own. This shows that you and they are compatible and is the equivalent of the more traditional (cheesy) 'how we are different to the competition'. Of course this differentiates you. It shows how this proposal is right for them and for you.

Business
Don't go all techy on a technical proposal. Remember who you are speaking to. If your audience is a business person or a group of businesspeople, focus on the business. If your audience is software engineers, focus on the business of software engineering: not the hardware. What is their business? That's how to frame your proposal.

Structure
I get it. You have a lot of ideas to get down. But, before you start, develop a structure that makes it compelling for them to follow. If they asked six questions in a sequence, then a great structure is to answer those six questions... in the same sequence. Make it easy for them to say 'yes'.

Quality
Finally remember Mark Anthony's advice: 'The evil that men do lives on. The good is oft' interred with their bones'. People remember your mistakes and easily forget all the good stuff. Make sure you check the quality of your proposal, not once, not twice... Better still, get the pickiest, most pedantic person you know to do it for you. You invested all that time. Now add a little more investment, to avoid throwing it all away!


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

Friday, October 20, 2023

Fear not!


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!
at

Tuesday, October 17, 2023

Einstein, AI, and the PMO

Consider this observation from Daniel Miessler:
AI is not competing with Einstein and Tolstoy..... AI is competing with:
  • The task not being done at all
  • It being done poorly
  • It being done inconsistently
  • It being done slowly
  • It costing too much
Like this blog? You'll like my books also! Buy them at any online book retailer!
at

Friday, October 13, 2023

Numbers are the PMO's best friend


Numbers are a PM's best friend
Is this news?
I hope not; I wrote the book Quantitative Methods in Project Management some years ago. (Still a good seller)

So, here's a bit of information you can use:
Real numbers: (**)
  • Useful for day-to-day project management
  • 'Real numbers' are what you count with, measure with, budget with, and schedule with.You can do all manner of arithmetic with them, just as you learned in elementary school.
  • Real numbers are continuous, meaning every number in between is also a real number
  • Real numbers can be plotted on a line, and there is no limit to how long the line can extend, so a real number can be a decimal of infinite length
  • Real numbers are both rational (a ratio of two numbers) or irrational (like 'pi', not a ratio of two numbers)

Random numbers

  • Essential for risk management subject to random effects
  • Not a number exactly, but a number probably
  • Random numbers underlie all of probability and statistics, and thus are key to risk management
  • Random numbers are not a point on a line -- like 2.0 -- but rather a range on a line like 'from 1.7 to 2.3'
  • The 'distribution' of the random number describes the probability that the actual value is more likely 1.7 than 1.9, etc
  • Mathematically, distributions are expressed in functional form, as for example the value of Y is a consequence of the value of X.
  • Arithmetic can not be done with random numbers per se, but arithmetic can be done on the functions that represent random numbers. This is very complex business, and is usually best done by simulation rather than an a direct calculus on the distributions. 
  • Monte Carlo tools have made random numbers practical in project management risk evaluations.

Rational numbers:

  • A number that is a ratio of two numbers
  • In project management, ratios are tricky: both the numerator and the denominator can move about, but if you are looking only at the ratio, like a percentage, you may not have visibility into what is actually moving.
 Irrational numbers
  • A number that is not a ratio, and thus is likely to have an infinite number of digits, like 'pi'
  • Mostly these show up in science and engineering, and so less likely in the project office
  • Many 'constants' in mathematics are irrational .... they just are what they are
 Ordinal numbers
  • A number that expresses position, like 1st or 2nd
  • You can not do arithmetic with ordinal numbers: No one would try to add 1st and 2nd place to get 3rd place
  • Ordinal numbers show up in risk management a lot. Instead of 'red' 'yellow' 'green' designations or ranks for risk ranking, often a ordinal rank like 1, 5, 10 are used to rank risks. BUT, such are really labels, where 1 = green etc. You can not do arithmetic on 1,5,10 labels no more than you can add red + green. At best 1, 5, 10 are ordinal; they are not continuous like real numbers, so arithmetic is disallowed.
Cardinal numbers and cardinality
  • Cardinality refers to the number of units in a container. If a set, or box, or a team contains 10 units, it is said it's cardinality is 10. 
  • Cardinal numbers are the integers (whole numbers) used to express cardinality
  • In project management, you could think of a team with a cardinality of 5, meaning 5 full-time equivalents (whole number equivalent of members)
 
Exponents and exponential performance
  • All real numbers have an exponent. If the exponent is '0', then the value is '1'. Example: 3exp0 = 1
  • An exponent tells us how many times a number is multiplied by itself: 2exp3 means: 2x2x2 (*)
  • In the project office, exponential growth is often encountered. Famously, the number of communication paths between N communicators (team members) is approximately Nexp2. Thus, as you add team members, you add communications exponentially such that some say: "adding team members actually detracts from productivity and throughput!"
 Vectors
  • Got a graphics project? You may have vector graphics in your project solution
  • Vectors are numbers with more than one constituent; in effect a vector is a set of numbers or parameters
  • Example: [20mph, North] is a two-dimensional vector describing magnitude (speed) and direction
  • In vector graphics, the 'vector' has the starting point and the ending point of an image component, like a line, curve, box, color, or even text. There are no pixels ... so the image can scale (enlarge) without the blurriness of pixels.
 ----------------------------
(*) It gets tricky, but exponents can be decimal, like 2.2. How do you multiply a number by itself 2.2 times? It can be done, but you have to use logarithms which work by adding exponents.
 
(**) This begs the question: are there 'un-real' numbers? Yes, there are, but mathematicians call them 'imaginary numbers'. When a number is imaginary, it is denoted with an 'i', as 5i. These are useful for handling vexing problems like the square root of a negative number, because iexp2 = -1; thus i = square root of -1. 


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

Tuesday, October 10, 2023

PMO co-pilot

It seems that every PM framework and tool set now has a co-pilot app fired up by a generative AI engine of some kind. And, it's not just our domain: MS Windows, various cloud services, and others all now have the requisite co-pilot.

In a few words, generative AI has arrived big time in project management for many of the same reasons it's arrived elsewhere:
  • Speedy results, if there is enough training data. And not just speedy, but incredibly fast by most standards of creativity
  • Deep dive data driven, not just a surface look. Stuff you may not have known was there is, in fact, there.
  • Multi-variate processing; if you have enough richness in the data, then generative AI can consider huge numbers of parameters when synthesizing or optimizing a result.

All three of those are big-time influencers in the PM world. Speed (with accuracy) may monetize right to the bottom line. Not only from labor savings, but from opportunity capture and exploitation only available from acting fast.

The big query+
PMOs have had data warehouse capability (big data storage, and complex retrieval query engines) for many years (decades, really). But this is very different because the query engine is not some SQL-based application, but is really a neural-network inquistor that is manifestly more powerful in it's ability to consider scope (data + parameters + alternatives), and synthesize outcomes that nowhere existed in the data warehouse. (Obviously a strength and weakness: truly innovative, but how do you validate an outcome that nowhere else existed?)

And so the query power, if you want to think in data warehouse terms, brings on a big shift in division of labor; some jobs will be demoted or disappear and others will be created out of whole cloth .. to wit: prompt engineer.

Assisted Brainstorming
As a practical matter, a simple way to start using a co-pilot in the PMO is to use the AI engine (co-pilot) for assisted brainstorming. It's really really useful in that task. Give it prompt; evaluate the answer; and then prompt again to expand or explain. And on it goes. In just a few minutes you may have litterally pages of ideas to drive project ideas. 

All things considered
The big deal for project management is the amazing scope -- that is, the number of influencing parameters -- that can be cranked into schedule optimization, cost estimation, and risk management. 
  • For schedules, you've got schedule logic, but then parameters for risk elements, resources, immendiately past productivity (cost and schedule efficiencies) and environment (tools, support systems, virtual connectivity, even the weather). There could be literally multi-thousands of optimizations evaluated, given the broad scope of parameters.

  • Resource parameters could include various talent-indicator parameters, sensitivity to teams and direction, track record re problem solving, drive and initiative assessments, etc. In some ways, a "big brother" input to scheduling which your 'boss' already has in their mind's eye. (This begs the question: how does these parameters get regulated and validated from an HR perspective?)

  • Cost history can be "adjusted" to current parameters to make history more relevant to the instant situation.

  • Risk management can be made more calibrated and therefore more quantitative, putting less emphasis on qualitative opinions and hunches. All manner of risk tools which are parameter driven can be made more robust and more relevant faster.

  • For monte carlo simulations, and similar simulation and statistical considerations, like optimizing Bayes 'guesses', a generative AI tool can create infinitely more data points, data patterns, and trends which are then evaluated for their statistical properties with monte carlo techniques.

And then there's the paperwork
Every PMO is backed up by reports, with data entry coming from all points, and multiple readers who want not only executive summaries, decision trees, and red-green indicators, but also full-length explanations and backup.

At some point, it's a matter of a prompt for which then a product pops out!  All on schedule; all produced, validated, and distributed without intervention.  This may be a good thing to have.

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

Saturday, October 7, 2023

NSA AI Security Center

General Nakasone, the Director, NSA, has announced the formation of the NSA AI Security Center in a speech at the National Press Club, as reported on the Security Week website:
Army Gen. Paul Nakasone said the center would be incorporated into the NSA’s Cybersecurity Collaboration Center, where it works with private industry and international partners to harden the U.S. defense-industrial base against threats from adversaries led by China and Russia.

“We maintain an advantage in AI in the United States today. That AI advantage should not be taken for granted,” Nakasone said at the National Press Club, emphasizing the threat from Beijing in particular.

DIRNSA went on to say it would become “NSA’s focal point for leveraging foreign intelligence insights, contributing to the development of best practices guidelines, principles, evaluation, methodology and risk frameworks” for both AI security and the goal of promoting the secure development and adoption of AI within “our national security systems and our defense industrial base.”

He said it would work closely with U.S. industry, national labs, academia and the Department of Defense as well as international partners.


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

Wednesday, October 4, 2023

Enterprise Agile


Applying agile methodology in your software project? Good!

Working for an organization large enough to be called an 'enterprise'? Probably that's good too.
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 small 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!
And where does that money come from? It comes from customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners and/or private investors (if privately held), or owners and public investors (if you're a publicly traded company)

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

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

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 funds you can dip into at your leisure and convenience. Enterprises don't work that way.

With enterprises comes rules and accountability
What makes an enterprise an enterprise is size and scale. And there is the rub: Sad to say, but size and scale is always more than a handful that a few 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. Such then brings rules, procedures, accountability, etc. into the frame.

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 three elements of the narrative you've heard before:
  1. Scope: what is it you are going to do, and how does that "doing" add value to the enterprise?
  2. Schedule: when can you likely produce results? (No single point estimates, of course. It takes a range!)urc
  3. Resources: how much do you need, and when do you need it? In other words, the resource ramp (up, but then inevitably down) We're speaking about cash flow, and resource allocations.
I can't do this!
You can't handle the narrative?
You can't describe what you need? (Or you stubbornly cling to the No Estimates paradigm?)
You can't connect the dots: value, resources, scope? 
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. The cover photo is below


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

Sunday, October 1, 2023

Setting up the strategy


Consider this military wit, and put it in the context of a PMO.  

"There is an old—and misleading—bit of conventional military wisdom which holds that “amateurs study tactics, while professionals study logistics.”

The truth is that amateurs study only tactics or logistics, while professionals study both simultaneously.

The most brilliant tactics ever devised are pointless when the supplies needed to execute them do not exist, while all the supplies in the world are useless when a commanding officer has no idea how to effectively employ them."

Quote from "Field Marshal: The Life and Death of Erwin Rommel"
by Daniel Allen Butler
Are you the professional or the amateur?
Consider what are "logistics" in the project domain:
  • Supplies and materials, of course
  • Utilities, communications, and facilities (you gotta sit somewhere)
  • Tools and training
  • Supporting activity from Finance and Accounting (they have the money!) 
  • Supporting activity from purchasing, inventory management, and receiving (they have the goods!)
  • Supporting activities from the various "ilities"
If you can get that wagon train all connected and working for you, then of course there is the small matter of strategy:
  • How strategic are you? Anything less than a year probably qualifies as tactics. Anything over three years and you should build in some tolerance for some business instability.
  • What is the lay-line to your strategic goal, and of course, what is your goal?
  • How much deviation from the lay-line can you tolerate for agile tactics (zig and zag along the lay-line)
  • Can you be strategic on some elements of the 'balanced scorecard' and simultaneously tactical on others(*)?
Got all of the above together? 
Good. Now(!) you can entertain tactical moves, knowing the support is there.

_________________________
(*) Balanced scorecard: Finance, Customer, Product, and Operating Efficiency

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

Wednesday, September 27, 2023

"Practicals" and not so practical


Have you noticed this?
Have you noticed that some people seem firmly planted and comfortable with their surroundings, but there are others that can't operate a hammer or a screwdriver?

Have you noticed that on many projects there is a unofficial segregation of the workforce something like this (*):
  • 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, virtual, and digital space (even if they go into the office)
Join things up: 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. 

Architecture is a good place to start. How could you build a new "anything" without both working together: Design, analysis, construction? 

Have you ever looked closely at a sweeping fly-over highway bridge, as a good example? 
  • 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!
at

Saturday, September 23, 2023

Wait! You're letting my people go?


Well, talk about cratering a schedule and resource plan!
Layoffs in the middle of a project will do it for you.

But wait!
There may be a silver lining here:
  • Communication complexity in and among project participants decreases as the square of participants. That could be a winner

  • You may be able to select the departees. That's tough in any circumstance, but it's also an opportunity to prune the lesser performers.

  • Some say that if you want to speed up a project, especially software, reduce the number of people involved (the corollary is more often cited: adding people to a team may actually slow it down)

  • There's an opportunity to rebaseline: All the variances-to-date are collected and stored with the expiring baseline. A new plan according to the new resource availability becomes a new baseline. Unfavorable circumstances can perhaps be sidestepped.
Of course, there are downsides:
  • If your customer is external, they may not relent on any requirements. You're stuck trying to make five pounds fit in a three pound bag.

  • There may be penalties written in your project contract if you miss a milestone, or overrun a budget. That just adds to the fiscal pain that probably was the triggering factor for layoffs.
Did you see this layoff thing coming?
  • On the project balance sheet, you are the risk manager at the end of the day. So, suck it up!

  • And there's the anti-fragile thing: build in redundancy, schedule and budget buffers, and outright alternatives from the git-go. And, if you didn't do those things in the first baseline, you've got a second bite at the apple with the recovery baseline.

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

Tuesday, September 19, 2023

I've got a plan: nobody cares


It's so damn frustrating!
You spend a lot of time planning, coordinating, evaluating ....
And then it's D-Day, circumstances intervene, and nobody follows the plan 😮 
(Well, they follow bits and pieces, but the plan as such is almost unrecognizable)

That's a few sentences to say what we all know:
No plan survives the first touch with reality
So, if this is all too obvious, what is it you do?
  • The first thing is to have a communication plan in hand before the execution begins so you can touch everyone you need to reliably and quickly. And this part of the plan should be bullet proof
  • The second thing is to know in advance where all the decision makers are going to be and how they are to be reached; and what authorities they have.

  • The third thing is to have supervision or tactical deciders in place where the work is being done to make the minute-to-minute decisions that might save the day. In other words, some decentralization of authority
  • Another thing is to have redundancy built in, as well as time or cost buffers, to be able to override, or fill-in the low spots. In other words, a plan with no margin is really not viable from the git go. 

  • If "it" fails this time, know when you are going to try again. Obviously, "failure" has to be obvious, measurable, without ambiguity, etc.
  • And if "it" fails, have a lessons-learned exercise ready to go.
     
  • The principle of "calculated risk" should be built-in: "When all matters are considered and weighted by value, the benefit of taking a risk should be (at least) strategically beneficial, even if not tactically beneficial (the battle was lost, but the engagement won the war)


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

Friday, September 15, 2023

Data: Rule #1


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 too many PMOs there are too many incidents of reports, data accumulation, measurements, etc which are the progeny of PMO doctrine. But the reality is: There actually is no plan for what to do with all this stuff that comes in. 

Sometimes, a data collection is just curiosity; sometimes it's just blind compliance with a data regulation; sometimes it's just to have a justification for an analyst job. 

But sometimes, there is a "feeling" that if such data is not coming in and available that somehow you're failing as a manager. Afterall, one view of management is to measure, evaluate, and act. If you're not doing the first step, how can you be managing effectively? Ergo: measure everything! Somehow, the good 'stuff' will then rise to the top. (I submit "hope" and "somehow" are not actually good planning tools)

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!

______________
(*) Statistical significance: The observed behavior in the data is unlikely to be just a random outcome; the data is predictability attributed to something specific which can be described statistically.

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