Pages

▼

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

Monday, September 11, 2023

The language of "Cost"


How many ways are there to say "Cost"?
Certainly, more than one!

When "they" ask: 'How do YOU manage cost?", your answer is: 'It's complicated' because there are so many varieties of 'cost'.

Project managers certainly have at least this list:
  • Estimated cost (of course, an estimate has to be made in the context of a plan: scope and schedule and resource plans)
  • Baseline cost (estimated cost at the beginning of a planned period)
  • Re-baseline (Sunk cost, plus a "new" estimate for the ensuing period)
  • Cost variance (the difference or departure of actual cost from the baseline)

  • Planned value (baseline cost input to the project, over time, allocated to planned functional or feature achievement)
  • Earned value (as a proportion of Planned Value actually completed)
  • Cost performance Index (as a 'cost efficiency' measure of how well cost input earns value)

  • Actual cost (measured at a point in time, regardless of achievement)
  • Sunk cost (aka actual cost incurred)
  • Direct cost (costs attributed to this project, and this project only)
  • Indirect or overhead cost (common costs shared across many projects, proportionally)

  • Labor cost (a component of direct cost; does not include overhead labor)
  • Standard cost (used by service organizations and Time & Materials proposals to 'fix' or standardize the "labor cost by category" to a single dollar figure within a range of costs for that labor category. *)
  • Material and contracted services cost

  • Throughput cost (only that part of direct cost required to actually construct value outcomes; often used in combination with Standard Cost)
  • Construction cost (aka Throughput cost, but sometimes also total of direct costs)

  • Incentive cost (paid as direct payments to individuals and contractors for specific performance achievements)
Finance, accounting, and business management have a few more:
  • General and Administrative cost (G&A), mostly for "top-level headquarters" expenses
  • Marginal cost (cost of one more item that does not require more of 'something else' to enable)
  • Cost margin (difference between cost of sales and revenue associated with those costs)

  • Discounted cost (cost after a reserve for risk, usually calculated over time)
  • Depreciated cost (cost accumulated over time, as different from cost in the moment)
  • Cost of sales (direct cost to generate sales)

  • Activity Based Costing [ABC] Overhead costs allocated to specific activity, plus direct costs of the activity.
---------------------------------
(*) Standard Cost: As an example, for Labor Category 1, the salaries may range from $1 to $10, but the Standard Cost for this category may be $7 because most in this category have salaries toward the upper end. Standard Cost is not necessarily an arithmetic average within the category; it is a weighted average


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

Thursday, September 7, 2023

Risk management mistakes for the beginner


First comes the planning
You've followed all the standard protocols for setting up your risk management program.
You've put slack in your cost estimates, and you've put slack-buffers in your schedule plan.
All good.
Risks have been listed, prioritized, and the minor ones to be 'unmanaged' set aside (minimize distractions)
Otherwise, mitigation planning has been done.
All good.

Now comes execution
There are a lot of ways to screw up risk management. No news there, but ,,,,,
Rookies sometimes do these things, but, of course, you won't:
  • Rookies ask for, or accept, single-point estimates from team leaders, work package managers, or analysts. This is a big mistake!

    Estimates should be given as a range of possibilities. No one works with single-point precision, and no one works without control limits, even in tried-and-true production regimes.

    And you should recognize that 'far-future' estimates are almost always biased optimistically, whereas near-term estimates tend to be neutral or pessimistic.

    Why so? First, "the future will take care of itself; there is always time to get out of trouble". And second, near-term, "we have all the information and "this" is what is going to happen; there is little time to correct matters".

  • Rookies sometimes consume the slack before it's time. What happens is that rookies fall into the trap of "latest start execution" when it comes to schedule; and, in cost management, rookies often put tight controls on last rather than first, or early on. Then, when they need slack, it's already been consumed. Oh crap

    Experience and wisdom always argue for using slack last, hopefully not worse than 'just in time'
  • Rookies fall for the "1%" doctrine. In the so-called "1% doctrine", a very remote but very high impact event or outcome has to be considered as a 'near certainty' because of this risk matrix math: "very very small X very very large = approximately "l" (*).  Or, said another way: "zero X infinity = unity (or 1 or 100%)". 

    Accepting that doctrine leads rookies to spend enormously to prevent the apocalypse event. But actually, 'nearly 0' is a better approximation than 'nearly unity' (in arithmetic, 0 times any finite number is 0)

    What about the 'infinity' argument? Well, actually 'zero x infinity' is at best matter of 'limit theory' for one thing. And that's not easy stuff. But actually, anything times infinity is 'indeterminate' and thus not a workable result for the PMO. (**)

    Put the math aside. Isn't this about risk-managing a 'black swan' event you can actually imagine? Perhaps, but that doesn't change the conclusion that 'nearly 0' is the best value approximation.

----------------------
(*) In probability statements, "1" is understood to be all possibilities, or a confidence of 100%

(**) But more specifically, general laws of mathematics are not applicable to equations with infinity. It's commonly understood that if you multiply any number with 0, you get 0, but if you multiply "infinity" with 0, you get an indeterminate form, because infinity itself is not determined yet. Our science currently has 7 indeterminate forms; infinity is one of them. 

Of course, the good news is that we've advanced beyond the ancient Romans who have no Roman numeral for zero. It was not considered a number by them.




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

Monday, September 4, 2023

Teams: White space and slack


One of the big differences between a team and a group is cohesiveness around the goal:
There's no success individually unless there is success collectively

Don't let idle ruin cohesiveness
Inevitably, keeping the team together to promote cohesiveness raises the question: 
How to keep everyone busy all the time -- other than 'painting rocks' (which is the way the Army used to do it)?
In theory it's simple: keeping everyone productively busy means actively managing their downtime, aka the 'white space', between and amongst their planned activities.

White space and the matrix
In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

Backlog and whitespace
That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.
  • Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
  • Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
  • So also bring in mock testing, special event prototyping, and, of course, that bane of all:
  • Maintenance of team records.
Running cost of teams
One big advantage of managing by teams: the cost is relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each. 

Of course, many PMs are NOT comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:
The cost of a project is not its value; in a "good project", value as judged by users and customers greatly exceeds cost
Here's the memo: Manage for value! (Oh!, did I say I wrote the book?)


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