Sunday, October 14, 2018

Communications v content


"The New York Herald pointed out [that] the telegraph appeared to make it possible for the whole nation to have the same idea at the same moment. .... Henry David Thoreau raised an eyebrow: "We are in great haste to construct a magnetic telegraph from Maine to Texas; but Maine and Texas, it may be, have nothing important to communicate"
The New York Times

Nothing important to communicate? Then why is everyone staring at their screens all the time? Could it be simple addiction to having the same idea at the same moment as everyone else?

 


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, October 11, 2018

Situating reslience


"Scholars ... have situated resilience, the ability to sustain ambition in the face of frustration, at the heart of ... leadership growth. Why some people are able to extract wisdom from experience, others not, remains a critical question"
Doris Kearns Goodwin, Historian
"Leadership in Turbulent Times"

In another venue, we might say some people are naturally street smart, while others have seen it all -- but can't make anything of it.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, October 8, 2018

Physics v Engineering


The physicist ... is an expert in matter, motion, and energy, and has one simple task: to take energy from here and put it over there. [And] we have the engineer, who makes all things possible ....
Neil deGrasse Tyson, Astrophysicist

Ooops, did the eminence of astrophysics forget project managers?

  • Physicists may indeed move the energy ... who can forget "the bomb"?
  • And, the engineers may make it all possible, as indeed they did re "the bomb", 
  • But without the PMO there would be no money, no resources, no milestones to align the dots, and thus: no project! 



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, October 5, 2018

Run to the challenge


In the last posting, it was about heavy tails .... if it doesn't happen about now it grows less likely it will happen at all.

But, what if it does happen, all good management to the contrary? It could, you know.
 
Manage the consequences
  • As part of the management group you have to "run to the challenge", sort of a first-responder paradigm, but with much less bodily risk.
  • Gather yourself and assemble the pieces. Now what? You need the go-forward version of Plan B
    (Plan A is always "do nothing", just accept the circumstances) 
 Fight, fight, fight
  • Here's a thought: you might have to shift into the "fight mode", more aggressively managing consequences than you did the lead-up to the present circumstances.
Sunk cost
  • Whatever you "paid" so far, it's sunk and not retrievable -- unless insured. 
  • The cost of getting to the present situation should have no bearing on the cost and practicality of Plan B, or whether or not Plan B is even warranted. 
  • In other words, the cost of the fight should be valued only by the possible value of what could be obtained, not what has been sunk.
Cheer up! It could get better 😃




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, October 2, 2018

Is your tail heavy?



'Is your tail heavy' is the question raised at 'critical uncertainties' in a recent post.
It might be if you are a risk with some "memory" of the immediate past.

Risk with memory? What does that mean?
  • The immediate past influences the immediate future
  • The probability of the arrival of an outcome is not time-stationary: as time passes, the probabilities change
  • The distribution of the arrival time of an outcome is "heavy tailed", meaning that (usually) with more time: if it hasn't happened it probably won't happen  
In the posting (above), an example is the expected arrival of an email: Near term, it's expected. But, if doesn't get here soon, it may not get here at all

Project consequences:

  • Simple assumptions, like symmetrical bell curves, are unlikely to give a good picture of when a risky outcome may happen
  • Testing for an unlikely outcome may be easier and more economical than you might think: run a few tests; if it doesn't fail soon (infant mortality) it likely won't for a long while. 
  • Early on, consumer electronics exhibited such behavior. (If you could make it a few days, you were likely to make it a few years) 
Who knew 
Who knew heavy tails were the cheap way out of expensive testing??!



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, September 28, 2018

Plan A (or B, C, D)


There is always Plan A: "Do nothing"

  • This is actually different from "do no harm"; do-no-harm could be Plan B
  • Following that theme, sticking with Plan A could actually be harmful ... thus, Plan B could be not only less harmful but also could be essential for limiting harm

So, presume there is always Plan A, and good management principles say: there should be a Plan B
  • What about Plan C or D? Shouldn't decision makers always have alternatives to consider? Why be narrow? 
  • More important: why be self-delusional that there is "no other choice". No other choice, is, in a word: nonsense!
And, if you've decided on Plan A or B, and along comes the possibility of C or D with greater cost/benefit, can you change you mind and still be "strong and confident"?

  • ".... the ability to change one’s mind is a crucial mark of intelligence and maturity ... " (Bret Stephens)




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, September 25, 2018

Ratios! Some good; some evil



Ratio's ... as commonly applied ... often violate the higher law: "Do good; avoid evil"

Poster child for the evil ratio:
Wouldn't it be nice if we could ban % Complete from the lexicon of project management!

% Complete is a ratio, numerator/denominator. The big issue is with the denominator. The denominator, which is supposed to represent the effort required, is really dynamic and not static, and thus requires update when you replan or re-estimate -- something that almost never happens, thus consigning the denominator to irrelevance.

Why update?
Because you are always discovering that stuff isn't as easy as it first looked. Thus, we tend to get "paralyzed" at 90% (no progress in the numerator, and an obsolete denominator)

Doesn't changing the denominator mean you're changing the plan along the way? Yes, but the alternative is remain frozen on a metric/plan you are not tracking (or tracking to)

What's the fix?.

Personally, I prefer these metrics, none of which are ratios. And, why do I like this set of non-ratio? Because there is a good mix of "input" which is always of concern to the PM and the sponsors, and "output" which is always of concern to users and customers, and is the value generator for the business. Thus, this set keeps an eye on both the input and the output.
Backlog
  • Objects planned, or baseline (input)
  • Objects completed (output)
  • Objects abandoned (unnecessary requirement or deferred)
  • Objects added (new)
  • Objects remaining (output)
  • Objects variance (baseline - outputs)
Resources
  • Budgeted consumption (input)
  • Budgeted usage (input)
  • Resource remaining (output)
  • Resource at completion (usage + output)
  • Variance (consumption - completion)


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, September 21, 2018

Hybrid Agile ... what's that?



What's the hybrid thing?
It's agile coexisting in the same project with a traditional methodology, presumably for the swim lanes that are not software.
Some call hybrid agile as: agile in the waterfall

Are hybrids practical? After all, the traditional is top down planned, most requirements up front, much system testing at the end, etc. Agile is the not-traditional. Can you fashion a hybrid out of these two?

Actually, hybrids are very practical, if one internalizes the "hybrid operating principle"

Hybrid Operating principle
Agile projects are simultaneously strategically stationary and tactically iterative and emergent

I mean by “strategically stationary” that:
  • Whenever and wherever you look, the project has the same strategic intent and predictable business outlook.
  • Strategically stationary is not unique to agile, of course -- traditional methods actually impose stationariness, and business planners do also.  
Strategic intent is what is expressed by the business for the opportunity and vision of the project.
Strategically predictable business outlook
is the outcome that is expected of the project, typically expressed as the mission, but also found on the business scorecard.

I mean by tactically iterative and emergent that:
  • Flexibility is delegated to development teams to solve issues locally;
  • Teams are empowered to respond to the fine details of customer demand while respecting strategic intent in all respects; and
  • Teams are expected to evolve processes in order to be lean, efficient, and frictionless in development.
And this all leads where?
The overlay of strategy with tactics

The upshot of a tactically emergent and iterative risk response is that we may find that actions in the moment are a seeming variance to the strategy—that is, the project plan. But, over time, we may take other actions that converge on the strategy. In effect, we overlay the strategy with tactical expediency at the moment.

What are these actions?

For the Agile work stream, the most common tactical move is adjustment of the iteration backlog, the repository of “stories” or use cases that are the gist of requirements in the Agile methodology. 

Another form of tactical maneuvering is the result of technical or functional debt: those small items which have been left behind on a “punch list” to be completed before the project ends.

And why are these actions taken?

Most commonly, because the customer/user sees a better way to achieve a functionality; sees an unnecessary story that can be dropped; or has been given information about a requirement, heretofore unidentified, that should be added to the backlog.

These debt may cause small changes which may seem to lead off the strategy, but more often they help to converge to the strategic intent.




What more on agile? Available now! The second edition ......... "Project Management the Agile Way: making it work in the enterprise"


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, September 18, 2018

Pert v Monte Carlo ... some still care



A note from a reader of some of my stuff on slideshare.net/jgoodpas:
"... I just read your slide presentation on using stats in project management and am a bit confused or perhaps disagree ... that using Monte Carlo will improve the accuracy of a schedule or budget based on subjective selections of activity or project
a) optimistic, realistic and pessimistic ($...Time) values,
b) a probability distribution (3 point triangular) and
c) arbitrary probability of occurrence of each value.

If I understand your presentation Central Limit Theory (CLT) and the Law of Large Numbers (LLN) when applied using Monte Carlo simulation states that accuracy is improved and risk more precisely quantified.

It seems to me that this violates a law that I learned a long time ago...garbage in-garbage out. Is this true? ...."
I replied this way about accuracy:
  • Re 'accuracy' and MC Sim (Monte Carlo simulation): My point is (or should have been) the opposite. The purpose of MC Sim is to dissuade you that a single point estimate of a schedule is "accurate" or even likely. Indeed, a MC Sim should demonstrate the utility of approximate answers
  • Project management operates, in the main, on approximations... ours is the world of 1-sigma (Six Sigma is for the manufacturing guys; it doesn't belong in PM).
  • Re the precision/accuracy argument: My favorite expression is: "Measure with a micrometer, mark with chalk, and cut with an axe", implying that there is little utility in our business (PM) for precision, since most of our decisions are made with the accuracy of chalk or axes.
  • A MC Sim gives you approximate, practical,and actionable information about the possibilities and the probabilities (all plural) of where the cost or schedule is likely to come out.
  • And, to your point, the approximate answers (or data) should be adequate to base decisions under conditions of uncertainty, which is for the most part what PMs do.
So, what about MC Sim itself?
  • Re your contention: " ... selecting the distribution, optimistic, pessimistic and realistic values must be accurate for Monte Carlo to provide more accurate results." Actually, this contention is quite incorrect and the underlying reason it is incorrect is at the core of why a MC Sim works.
  • In a few words, all reasonable distributions for describing a project task or schedule, such as BETA (used in PERT), Normal (aka Bell), Rayleigh (used in many reliability studies, among others), Bi-nominal (used in arrival rate estimates), and many others are all members of the so-called "exponential family" of distributions. You can look up exponential distributions in Wikipedia.
  • The most important matter to know is that, in the limit when the number of trials gets large, all exponentials devolve to the Normal (Bell distribution).
  • Thus, if the number of trials is large, the choice of distribution makes no difference whatsoever because everything in the limit is Normal.
  • If you understand how to do limits in integral calculus, you can prove this for yourself, or you can look it up on Wikipedia
How large is large?
It depends.
  • As few as five sometimes gives good results (see image) but usually 10 or more is all you need for the accuracy needed for PM.
  • Consequently, most schedule analysts pick a triangular distribution, which does not occur in nature, but is mathematically efficient for simulation. It is similar enough to an exponential that the errors in the results are immaterial for PM decision making purposes.
  • Some other picks the uniform distribution like shown in the image; again for mathematical convenience
Should I worry about 'when' and 'where'?
  • Now the next most important matter to know is that a sum of exponentials (BETA, Rayleigh, whatever) -- like would be the case of a sum of finish-to-start tasks -- has the same effect as a number of trials.
  • That is, if the project is stationary (does not matter when or where you look at it), then a string of repeated distributions (as would be in a schedule network) has the same characteristics as a single distribution tried many times.
  • And, each member of the string not be the same kind of distribution, though for simplicity they are usually assumed to be the same.
  • Thus, whether it's one distribution tried many times, or one distribution repeated many times in a string of costs or tasks, the limiting effect on exponentials is that the average outcome will itself be a random variable (thus, uncertain) with a distribution, and the uncertainty will be Normal in distribution.
And, about that garbage
  • The usual statement about GIGO assumes that all garbage has equal effect: Big garbage has big effects; and little garbage has little effects; and too much garbage screws it all up.
  • This is certainly the case when doing an arithmetic average. Thus, in projects, my advice: never do an arithmetic average!
  • However, in a MC SIM, all garbage is not equal in effect, and a lot of garbage may not screw it up materially. The most egregious garbage (and there will be some) occurs in the long tails, not in the MLV.
  • Consequently, this garbage does not carry much weight and contributes only modestly to the results.
  • When I say this I assume that the single point estimates, that are so carefully estimated, are one of the three estimates in the MC Sim, and it is the estimate that is given the largest probability; thus the MLV tends to dominate.
  • Consequently, the egregious garbage is there, has some effect, but a small effect as given by its probability.

What about independence and correlations?
  • If the distributions in the MC Sim are not independent then results will be skewed a bit -- typically, longer tails and a less pronounced central value. Independence means we assume "memoryless" activities, etc so that whether a string of tasks or one task repeated many times, there is no memory from one to the other, and there is no effect on one to the other other than in finish-to-start there will be effects on the successor start time.
  • Correlations are a bit more tricky. In all practical project schedules there will be some correlation effects due to dependencies that create some causality.
  • Again, like loss of independence, correlation smears the outcome distribution so that tails are longer etc.
  • Technically, we move from the Normal to the "T" distribution, but effects are usually quite inconsequential. 
Where to get the three points if I wanted them?
  • My advice is in the risk management plan for the project, establish a policy with two points:
    1. All tasks on the calculated single point critical path will be estimated by experts and their judgment on the task parameters go in the sim
    2. All other tasks are handled according to history re complexity factors applied to the estimated MLV (most likely value, commonly the Mode): that is, once the MLV for a non-critical task is estimated, factors set by policy based on history, are applied to get the estimates of the tails.
  • Thus, a "complex task" might be: optimistic 80% of MLV and pessimistic 200% of MLV, the 80% and 200% being "policy" factors for "complex" tasks.
  • This is the way many estimating models work, applying standard factors taken from history. In the scheduling biz, the issue is not so much accuracy -- hitting a date -- as it is forecasting the possibilities so that some action can be taken by the PM in time to make a difference.
  • Providing that decision data is what the MC Sim is all about. No other method can do that with economic efficiency

PERT v MC Sim
Now, if the schedule is trivial, there is no real difference in the PERT and MC Sim. Take, for example, a dozen tasks in a tandem string of finish-to-start.
  • The PERT answer to the expected value of the overall duration and the MC Sim will be materially identical.
  • The sum of the expected values of each task is the expected value of the sum. So, the SIM and the PERT give identical answers insofar as an "accurate" expected value.
  • But that's where it ends. PERT can give you no information about the standard deviation of the outcome (the standard deviation contains the reasonable possibilities about which you should be worried), nor the confidence curve that lets you assess the quality of the answer. 
  • If your sponsor asks you run the project with an 80/20 confidence of finishing on time, where are you going to go for guidance? Not to PERT for sure.
  • And, if your sales manager says bid the job at 50/50, you have the same issue... where's the confidence curve going to come from?
  • And, most critically: PERT falls apart with any parallelism in the schedule in which there is no slack.
Thus, some 30 years ago PERT was put on the shelf, retired by most scheduling professionals

I'm almost out of gas on this one, so I'll end it here.


The image shows the outcome of 5 independent uniform distribution summed, as in a finish-to-start schedule sequence.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, September 14, 2018

Introverted ... and at a conference



OMG! If you're an introvert, attending a 3-day conference where you're expected to network and bring back new relationships, contacts, and business intelligence. Looking forward to that has got to be nothing but dread. Three days of small talk and useless chit chat about the weather? God awful!

Agree?

So, a few useful ideas are found here in a hbr.org essay entitled: "How Introverts Can Make the Most of Conferences" by reporter Dana Rousmaniere interviewing Susan Cain, author of "Quiet: The Power of Introverts in a World That Can’t Stop Talking" 
  • Take a recharge break. Take more than one. Leave the building for a change. Even for extroverts, conferencing is exhausting
  • When approaching a stranger, try to land on a topic of mutual interest. That way, you don't have to talk about the weather
  • Open the conversation with something that is common in the environment, like the speech just heard.
  • "Relax into extroversion" when you find a topic that stimulates your curiosity. That is: extend the conversation
  • Be a speaker or panel member, or submit a paper to the proceedings. If there's such an opportunity, grab it! Nothing like a little public speaker exposure... it gets easier with experience.
And, to add something to Ms Cain's advice, you can also be in your company's product booth, or a walk-around person handing out souvenirs.

And, remember this, many of the people you will meet are likewise introverts looking for way to break in. So, most of whom you approach will be in your situation and looking for a connection.

In other words, it's a target-rich environment.





Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, September 11, 2018

Plausible or probable?



Ponder this for a moment:
Adding detail to the description of an uncertainty may make it seem less probable (the more you know, the less you think it will happen than a more abstract version), though it may make it more plausible

Now move forward to that first tool of choice among risk managers, the risk register. The logic is this:
As detail abounds and abstraction abates, plausibility augments but probabilities must be adjusted; and, in general, probabilities go down.
Try this on for an example:
Scenario -- you are looking at number of interns or co-ops with an idea of placing them in various roles in your project, perhaps business analysis, engineering, or training and business readiness.

Adel is 22 years old, very smart, technically accomplished, studied (among many subjects) philosophy and music, has a strong sense of who she is, and is very detail oriented. She has leadership presence and personal charisma
Adel is a professional; she could be successful in some aspects of engineering, finance, business analysis, etc. or even marketing.

The question -- What do we think of Adel? Among those professional roles mentioned, which is the most likely? If engineering, then is she more likely a software designer/engineer who applies the female touch to typically qualitative requirements (needs and wants), or else is she a professional in some other aspect of engineering?

Most of us would look at it this way:
  • Music is a good segue to software; music has patterns, logic, rhythm, and detailed structure -- all attributes of software as well
  • Philosophy is about understanding beliefs, values, ways to think, and ideas -- all elements of human factors
  • And, she's technically accomplished
Most of us would conclude: Adel is very plausibly a software engineer; perhaps she would be very good at human factors engineering. Finance and business analysis seem just too dry for someone who's into philosophy and music. Of course, you can't dismiss marketing out of hand....

Yes! that's it. Adel is most likely a software designer/engineer. That's the highest probability in the distribution of plausible possibilities.

Not so fast
What about other engineering disciplines? Sure, it's possible, but is it probable? Look at how plausible the fit is to software design engineering.

Venn et al
Let's look at the Venn diagram:
  • Among all roles for women, Adel is a professional
  • Among all professionals, Adel is possibly an engineer
  • Among all engineers, Adel is possibly a software design engineer
  • Among all software design engineers, Adel is possibly a specialist in human factors engineering
Every time we add detail, the plausibility improves (given Adel's profile), but the share of the population goes down each time. If this were red balls in an urn with white balls, each level of detail would mean fewer red balls.

What if we are just comparing two abstractions of about equal detail, as in marketing v engineering? The rule does not apply: we've not changed the level of detail from one to the other. We're just comparing two possibilities.

Moving to the risk register
Every time we are challenged to add detail to the risk register, we may well improve plausibility (why else add detail?), but the rule is: that finer grain is less probable than the more abstract idea from which it was derived.

So, what's the problem here? The problem is we confuse plausible with probability. Just because an uncertain event seems very plausible doesn't correspondingly mean it is very probable.

Read more
This discussion is given in much richer detail in Daniel Kahneman's book: "Thinking fast and slow".



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com

Read my contribution to the Flashblog

Saturday, September 8, 2018

What flavor is your scope creep?




Can there be scope creep in Agile? Doesn't agile define it away in a stroke: "Scope is whatever is prioritized in the backlog that fits within the budget (OPM, other people's money) and the time. The backlog changes all the time, but that's not creep, it's just backlog management."

What I just wrote is a "best value" definition of scope. But, sometimes it doesn't sell.

I credit my agile students with these observations about "creep", to wit:

Project scope creep: it may be well and good that a true pure play on agile has no conception of scope creep, because the backlog is simply rebuilt as a zero-base-backlog (ZBB) after every iteration -- if not after each iteration, then certainly after every release.

Consequently, after every release, you should be able to stop and be satisfied you've delivered the best possible stack of high value objects. Amen!

Resource scope creep
On the other hand, if you can't get commitment for dedicated teams because the resources are needed elsewhere, then you are saddled with the overhead and inefficiency of rolling out and rolling in resources. This is resource scope creep -- spending more on resources' training, recruiting, and assimilation than the budget allows.

Clearly, this is a different flavor than project scope creep.

And, it's been around since forever!
Who's not heard of "resource plug-and-play"? The plug-and-play process: just define a role, line up the role with appropriate resumes, pick one, plug him/her in, and you're off to the races!

  • For more on plug-and-play, see the work of F.W. Taylor and "management science" wikipedia.org/wiki/F._W._Taylor

Agile to the rescue!
The fix is in: a pure play in agile means having fully dedicated teams that use the inevitable white space in the team schedule to improve the product -- more testing, more refined refactoring, working completely through the technical debt -- but not to get off the team and go elsewhere, only to return later.

Ooops!
The idea of giving up on matrix and other plug-'n-play resource schemes is pretty much opposed by managers not willing to give real agile a try.

Shifting from input to output
Again, it's an input/output focus tension... managing the white space by moving resources around is an input focus; leaving resources in place to use the white space for quality is an output focus.

Traditional schemes often put resource managers in charge of finding resources for the project manager. Obviously, those resource guys are going to focus on getting their job done according to their metrics. Agile schemes are a bit different: once the resource manager has given up the resource to an agile team, it's the team leader who's responsible for getting good productivity and managing the white space on behalf of a best-value product



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, September 5, 2018

3-point estimates ... good for you!



Here's my three point estimate paradox:
We all know we must estimate with three points (numbers)... so we do it, reluctantly
None of us actually want to work with (do arithmetic with) the three points we estimate

In a word, three point estimates suck -- not convenient, thus often put aside even if estimated -- and most of all: who among us can do arithmetic with three point estimates?

But hey! Three point estimates are good for you ... they are the broccoli of projects

First question (are you whining? ): where does this really matter in the domain of project management?
  • When adding up a budget or calculating the duration of a schedule
  • When doing a risk register and someone says to multiply impact x probability

Second question: how do you go about it? Actually, you can build a couple of simple templates in a spreadsheet to do the arithmetic. Then fill in the 3 points, and presto! -- a summation or product (add or multiply) pops out.

The budget
To understand this, start with the basics:
  • Suppose I have two work package budgets, one is fixed and one is uncertain. I use a 3-point estimate for the latter. I need the total budget
  • As an example, with numbers:
    • Fixed budget = 10
    • Uncertain budget 3-pts: 5, 8, 12
    • Possible totals: 10+5; 10+8; 10+12
    • With no other information, pretend you are a Bayesian. You would say your "a priori" is that all 3 totals are equally possible. Thus: 1/3 * (15+18+22) = 18.3
Now, you can see it's easy to extend this to both numbers being uncertain: in that case, you would then do 9 possible totals and divide by 9.

The risk register
Multiplication is the issue with the risk register, typically I x P. Say what you will, but both I and P are uncertain, and usually P is the most uncertain. We usually have no real basis for assuming a probability since we usually have insufficient history to establish a reasonable frequency (1/P)

As an example with numbers, suppose I've been told that with some risk my budget is going to be cut by $50. For our purposes, we can take this impact as a single point "certainty". What's uncertain is whether or not there's much chance it will happen.
  • Fixed impact = 50
  • Uncertain probability (better thought of as a confidence of a some % or less): 10%, 30%, 50%
  • Possible IxP products (this figure, or less): $5, 15, 25 (P is dimensionless, so IxP has the dimensions of I)
  • Again we can do our Bayes thing (no information for the 'a priori') and come with the average IxP: 1/3 (45) = $15
  • This extensible to uncertainty of both numbers wherein there will be 9 products
Monte Carlo
Is anybody going to do this on a real project with a spreadsheet? Likely not. But, this is the way a Monte Carlo simulation works and the MC Sim is common among projects run quantitatively.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, September 2, 2018

The case for "little data"



"Big Data" is the meme of the day, but most projects run on "little data", the sort of data that fits into the constraints of spreadsheets like Excel. It's everyday stuff that drives estimates, scorecards, dashboards, task assignments, and all manner of project analytics.

So, assuming you using Excel as a spreadsheet for doing actual calculations and data entry, and not a row-column table version of Word, you will find that you to do some analytics and data analysis from time to time.

Pivot tables are one spreadsheet data tool, but that's not the discussion today. Today, it's filters, which is the Excel name for the process and tool, but which the database people -- familiar with SQL for row by column -- would call a query.

And so, how to do a filter in Excel, something practical for the project manager? There are Youtube's galore on the subject, but here's a neat, step by step, illustrated process that goes from the simple to the advanced.

Just what the PMO need to get into the data business

Some other rules
Beyond what you will read in the linked article, there are a few data rules that will make life simpler
  • Every column should have a header or title that is unique, even if just column1, column2, etc
  • Only one data value in a cell. Thus, first and last names should be in separate columns; so also city and state. But maybe also captain and ship's names. This is called "normalizing" the data
  • Keep the static data in separate row/column areas from the data that changes. So, if a ship sails to San Francisco on a certain date, the ship's description goes in one area; the city description in another; but the city/date/ship is dynamic and belongs in a third area.
  • Don't put 'word processing' paragraphs or labels in the middle of the data. In other words, maintain the integrity of row by column
  • It's good to have at least one column that is guaranteed to be uniquely valued in each cell, like a row ID
  • If you can avoid using "spaces" in the data, that's good. It makes the query more sure. So, "column1" instead of "column 1"
 


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, August 30, 2018

Get ahead by leaving behind ...



Nick Tasler has a posting on the HBR Blog Network with an intriguing title: "To Move Ahead You Have to Know What to Leave Behind" 

His theme is summed up this way in an early paragraph:
The Latin root of the word "decide" is caidere which means "to kill or to cut." (Think homicide, suicide, genocide.) Technically, deciding to do something new without killing something old is not a decision at all. It is merely an addition.

So, what do the hoarders among us do? We save everything; kill -- or throw away -- nothing! Actually, we find deliberately making these trade-offs -- keep this; discard that -- so energy absorbing (Tasler says: exhausting) that we just layer on new change.

This behavior leads to what Tasler calls "trickle down trade-offs" in which there is sort of a push-down stack with the most current issue on top and the not-dealt-with issues more or less far down the stack.

Many of have seen this in action -- and we joke about planning an exit strategy before the stuff at the bottom finds its way back to the top!

No! .. that's not management -- that's escape. To be effective, we must all acquire instinct and be thought of as 'trained killers' of excess (think: Lean!)


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, August 27, 2018

Did someone say: Baseline?



In one of my past Agile classes I facilitated this discussion re baselines:

Student 1:
 "I have a new Operations Director, and he says once you've missed a date, you re-baseline, and the item is no longer indicative of a bad/out of date status.
In previous positions, we didn't always or weren't allowed to do that, so that they could track the original dates vs. current progress.
Just wondering how others handle this."

Student 2, in reply:
"When I baseline a project, it is once and done. How can one measure truly the progress and planning of a project if the baseline is reset every time a date is missed? I agree that this would indicate a false sense of progress, a false green.

The only exception I can think of is if the project plan introduces a significant change that is approved by the project board and sponsor that impacts greatly the objectives and especially the schedule.... "

My facilitation:
Not exactly!
Re Student 1: if  you've missed a date, that's a variance. The baseline is still the plan you are managing to so long as you are trying to recover the schedule.

Re Student 2: "once and done" doesn't work either. There may be many reasons to rebaseline as the project goes along. It's not like you have a budget of 're-baselines' and you can only use so many. However, the key to the whole thing is the second point: "... significant change approved by the [controlling authority..]"

So here's the thing: first common sense always applies. In most non-trivial situations you have two plans at all times:
  1. The baseline which is the agreement between the sponsor (business) and the project
  2. The operating plan which is the day-to-day plan derived from the baseline
As project manager, you must have a strategy to merge or bring together the operating plan and the baseline so that at the end of the day, the baseline is the plan of record... all variances of record are measured against the baseline.

Now, if it becomes the situation that the baseline is no longer valid -- approved changes, etc -- such that there is no practical way to merge the ops plan with the baseline, then you rebaseline:
  1.  Record and archive all variances to the baseline -- B1
  2. Replan the project; this replan becomes the second baseline -- B2
  3. At the project conclusion, sum the variances. Add the variances from the former baseline B1 with the variances accumulated in B2. These become the cumulative variances of record.
To wit: you get no free lunch on variances just because you re-baselined. And, this is the deal in Agile or traditional... no escaping there either.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, August 24, 2018

Getting to done, even in Agile!




Now we're getting somewhere! No less an Agile/Scrum eminence than Mike Cohn -- author of some really good books and articles -- has come out with a newsletter on -- are you ready for this? -- what's the meaning of DONE in Agile.

His acronym, a bit a poor choice to my mind, is "DoD"... definition of done. But, there you have it... perhaps a new GAAP "generally accepted agile practice" for agile-done

In the past, my "definition of done", as it were, has been these three questions:
  1. Is it done when the money or schedule runs out?
  2. Is it done when the sponsor or product manager says it's done?
  3. Is it done when Best Value* has been delivered?
    * The most … and the most affordable … scope within the constraints of time and money
If you can't read my bias into these questions, I line up firmly on #3.

Cohn instructs us differently
A typical DoD would be something similar to:
  • The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
  • The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
  • The code was either pair programmed or peer reviewed.
  • The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
  • The feature the code implements has been documented in any end-user documentation such as manuals or help systems. 
Cohn hastens to add:

"I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels."
Now, I find this quite practical.. Indeed, most of Cohn's stuff is very practical and reflects the way projects really work. In other words his theory is tested in the crucible of a trying to make money or fulfill a mission by writing software. How swell for us who read Cohn!



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, August 21, 2018

Alliance networks?


On the HBR Blog Network, Andrew Shipilov has a eye-catching post on "hub and spoke" project networks, or alliances between project partners, as he describes them.

(Say "network" to me, and I always jump first to a mind's-eye image of a "mesh", but actually that's one of several general ways to think of networks, and in most situations not a good general model for governance.)

When simple is too simple: Shipilov posits that simple hub-and-spoke arrangements in truly complex and challenging systems, with the prime contractor and an SI (system integrator) at the hub, inhibits critical interactions between the other partners, each of which is on a spoke. He attributes some project failures to this governance model.

What to replace it with? After all, hub-and-spoke is the essence of prime contractor command-and-control over the myriad sub-contractors, to say nothing of the legal details of who has privity of contract.

Some complexity required: For the really complex project, Shipilov recommends the "alliance network" wherein there are multi-lateral relationships between the major partners. Each partner is actually the hub for a traditional "simple" hub-and-spoke.

Shipilov maintains that the multi-lateral relationships between the major partners provides opportunity for, and even promotes innovation, data exchange, and cooperation.

About the alliance network, we are told there are these advantages:
"First, alliance partners are more likely to deliver on their promises.  If information flows freely among interconnected partners, how one firm treats a partner can be easily seen by other partners to whom both firms are connected. So if one firm bilks a partner, other partners will see that and will not collaborate with the bilking firm again.

Second, integrated networks facilitate fine-grained information exchanges because multiple partners have relationships where they share a common knowledge base. This shared expertise allows them to dive deep into solving complex problems related to executing or implementing a project."
Fair enough. But one big caution: Who is actually in charge? Someone has to be king of the hill, more or less controlling the strategic narrative. It could be the customer (read: source of the money), as in the government for defense system and public works projects, but it could be a "prime contractor" or an equivalent commercial "big dog", the so-called alpha-partner. Shipilov doesn't really address this …. but you will have to.




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, August 17, 2018

Storyboards -- a great technique


A great technique for writing proposals, papers, or books -- as I do a lot -- is to storyboard the ideas.

My favorite expression: "If you can't draw it, you can't write it!"

Here's Einstein on the same idea:
I rarely think in words at all. A thought comes and I may try to express it in words afterwards
If you're not a storyboard person, check out this website for insight...


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, August 14, 2018

Systems! And then there were systems



I was reading Matthew Squair's course materials on System Safety Fundamentals when I came across this slide:
"Life was simple before World War II. After that, we had systems."
Rear Admiral Grace Hopper (USN)


Ya gotta smile at that witicism!

The Admiral Dr,of course, is best known for inventing the system "bug" when she literally found a dead bug in in an inoperative computer system.

And, she used to hold up an 11.8" piece of wire to show the length travelled by an electron in a nanosecond. (*) Shorter is better! Thus, the sub-micron circuitry of today.

She retired from the Navy at age 79 in 1986 after serving about 50 years.

(*) To be more precise, about 11.8 inches in a vacuum; slower in wire, of course.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, August 10, 2018

They say: Story is almost everything


"Alasdair MacIntyre argued many years ago, you can’t know what to do unless you know what story you are a part of.

Story is more important than policies."

"You can get a lot of facts wrong if you get your story right."
Quoted by David Brooks

That last observation -- good story, wrong facts -- sounds off key, but consider: facts are in the rearview mirror; only estimates lie ahead. If you are a visionary -- see: E. Musk -- you don't want to be too encumbered by facts (i.e., historical approaches). You need freedom to envision!

Not so fast!
Facts and "wrong facts" aren't the same thing. Misusing facts to support a story -- even futuristic and new-to-the-world stories -- is, in some quarters, not-less-than fraud. See myriad SEC cases where investors and employees bought into a narrative based on false facts. One might even think (gasp!): Bernie Madoff!

Now in a different context -- a history of political imperialism -- I've heard the same thing: "They" say: Conceive the narrative, paint the grand picture, and then find facts -- or, if you have too many facts, discard those that are inconvenient."Remember the 'Maine'!"

If you are risk averse, story-sans-facts is not the formula for you! You've got to be willing to live with a disaster if real substance doesn't come along in time to bail you out and validate the story. Story teller beware!



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, August 7, 2018

Is this a mix? Agile, oil, and gas



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

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

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

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

Of course, there's "one big thing":
You can't go around self-organizing (agile speak) willy-nilly! There's regulatory constraints everywhere and safety-first doctrine hanging on every move.

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



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, August 4, 2018

Hello! Robots have limits!


Elon Musk, lamenting at the June shareholder meeting about Tesla production
“One of the biggest mistakes we made was trying to automate things that are super easy for a person to do, but super hard for a robot to do,” he said. “And when you see it, it looks super dumb. And you are like, wow! Why did we do that?”



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog