Wednesday, December 12, 2018

Behavior v Outcome



You have to give Jurgen Appelo high marks for imaginative illustrations that catch the eye and convey the thought. He says this is one of his best illustrations ever; he may be right. He calls it his "celebration grid". I imagine Jurgen will be telling us a lot more about this if it catches on.





But what he says about these grid points is the more important take away:

  • “Celebrate failure” is nonsense, because you shouldn’t celebrate failure that comes from mistakes (the red part). What you should celebrate is learning, and repeating good practices (the green parts).
  • Pay-for-performance tends to drive people away from experiments, toward the safe practices on the right, with little learning as a result. 
  • Hierarchies are good at exploiting opportunities, and endlessly repeating the same practices; but they learn very little. 
  • Networks are good at exploring new opportunities, and failing half of the time, but they’re not good at efficiently repeating practices.
File this under leadership for learning and motivation, change management, managing team dynamics, and carrot and stick.


Buy them at any online book retailer!

Sunday, December 9, 2018

Failure or faults?



Does software fail, or does it just have faults, or neither?
Silly questions? Not really. I've heard them for years.

Here 's the argument for "software doesn't fail":
Software always works the way it is designed to work, even if designed incorrectly. It doesn't wear out, break (unless you count corrupted files), or otherwise not perform exactly as designed. To wit: it never fails

Here's the argument for "it never fails, but has faults":
Faults refer to functionality or performance incorrectly specified such that the software is not "fit for use". Thus in the quality sense of "fit for use" it has faults.

I don't see an argument for "neither", but perhaps there is one.

However, Peter Ladkin is not buying any of this. In his blog at "the Abnormal Distribution", he has an essay, a small part of which is here:

What’s odder about the views of my correspondent is that, while believing “software cannot fail“, he claims software can have faults.

To those of us used to the standard engineering conception of a fault as the cause of a failure, this seems completely uninterpretable: if software can’t fail, then ipso facto it can’t have faults.
Furthermore, if you think software can be faulty, but that it can’t fail, then when you want to talk about software reliability, that is, the ability of software to execute conformant to its intended purpose, you somehow have to connect “fault” with that notion of reliability.

And that can’t be done.


Buy them at any online book retailer!

Thursday, November 29, 2018

Resume tic's


Want a job in "big business", or want to pursue "gigs" with the big guys?
Here's some resume tic's from the those that know the General Motors' needs:
The "new" GM will want workers who are highly creative and capable of working autonomously as well as collaboratively. 

The future employee will take initiative and have a strong technology background, good communication skills, and project management capability
Well hello! That's a prescription right out of the PM playbook
  • Communicate
  • Collaborate
  • Create
  • And, did I mention: initiate!



Buy them at any online book retailer!

Monday, November 26, 2018

Multi-lingualism


MIT is to open a new College of Computing.
That's nice for them

Of note, however, is this bit from L. Rafael Reif, MIT President, as quoted in the press
The goal of the college is to "educate bilinguals of the future"
And, to be clear, bilinguals are people whose 'other interests' are -- among others -- biology, chemistry, politics, history, and linguistics who are skilled in the techniques of modern computing that can be applied to them
Who said IT guys are one-dimensional? No longer; they can be bilingual
And, by extension, so can the project managers of the world be something other than PM-nerds
We can learn other languages as well!

Better yet: we can be multi-dimensional in both knowledge and wisdom -- what a concept!

Never stop learning is probably the right take-away!



Buy them at any online book retailer!

Friday, November 23, 2018

Great project management


Give pause to this insight:
"The mark of a great ship handler is never getting into a situation requiring great ship handling"
Admiral Ernest J. King
The paraphrase is obvious:
  • The mark of a great project manager is never getting into a situation requiring great great project management




Buy them at any online book retailer!

Tuesday, November 20, 2018

Initiative and independent action


From Viscount Nelson, victorious British commander in chief at the naval battle of Trafalgar, we get this insight for initiative and independent action, as described by Admiral James Stavridis in his book "Sea Power":
Nelson knew he would not have clear and instantaneous communication ... [making] precise command and control impossible.
As [Nelson] said in his [planning] memorandum: "Something must be left to chance; nothing is sure ... "
"In case signals can neither be seen or perfectly understood, no captain can do very wrong if he places his ship along side the enemy ..."

So, there's some good stuff there for project managers:
  • Don't lean heavily on the idea you will always be in touch when it matters
  • Accept the idea that command and control systems have their limits; other processes work also
  • Do think it through and commit to a plan -- even though the plan itself may not survive first contact with project reality [some would call this making an estimate .... gasp!]
  • Set expectations and then unambiguously delegate authority to meet those expectations
Something to be avoided:
  • Nelson was killed in the battle, taking one risk too many 



Buy them at any online book retailer!

Saturday, November 17, 2018

Blitz-scaling


So, I'm just catching up with the buzz about blitz-scaling, the business model that says:
Get to scale fast! Actually, get to even larger scale even faster.
Blitz your way there!
Only the fastest to scale wins; there's hardly a spot for number two
One might ask: What's the debt and debris accumulated in blitzing scale?

Reid Hoffman has an answer in his book, titled no less than: "Blitzscaling: The lightning-fast way to massively valuable companies"
  • Conventional process-oriented decision making supported by "facts" and analysis of risk, discounted cash flow and the like, are out
  • What's in is speed, decisions based on instinct and partial data, and a willingness to pay the downside if risks don't work out
Ok, almost anyone could imagine that deregulating is going to allow speed with some broken glass along the way.
In the past Reid argues, business put a high value on not breaking the glass.
Efficient and predictable processes with predictable outcomes was king.
  • Remember the "Theory of Constraints" developed in the early '80s: Efficiency in resource utilization was the answer to better business
  • Remember: the customer is always right?
  • Remember: product quality counts very high --- 1950 quality ideas and 1990 error management (Defined process control; Quality is free, Six-sigma etc)
According to Reid: all good stuff, but too slow!
  • Speed is almost axiomatically opposite efficiency. Many resources will be wasted when you go as fast as you can
  • Don't let the customer get in the way; customers are notoriously cautious adopters
  • Quality can come later; get a product out there and set the frame 
If you read my post on the evolution of Agile, you'll recognize the connectivity of blitz-to-scale with the evolved principles




Buy them at any online book retailer!

Tuesday, November 13, 2018

Agile: revolution to evolution


20 odd years ago, Agile was a revolution in methodology and some say a revolution in business objectives, all set down in some now-well-known principles from the last '90s.

But, has there not been an evolution in the last two decades?

Mike Cohn, a spearhead in the Scrum world to be sure, says this:
Originally, agile meant valuing individuals and interactions, working software, customer collaboration, and responding to change.

Agile was about cross-functional teams working closely together to innovate new products or solutions that couldn’t have been developed any other way.

These days agile seems to be about
  • Improving productivity,
  • Reducing work in process,
  • Increasing velocity in any way possible,
  • Holding teams accountable for finishing everything they say they will, and,
  • Doing just enough that an organization can call itself agile without really being agile.
He's probably right on this.
So, what happened?

For agile to be anything other than a cottage industry, it had to marry up with serious business people who put up the money and expect effective functional results in-line with business objectives.

And, being a capitalist economy, projects have always had to line up with capitalist objectives:
  • Relentless drive to reduce cost, 
  • Produce more, and 
  • Drive the bottom line (profit margin)
The soft side of agile, the camaraderie of harmonious teams focused on product by and large, when modulated by capitalism, comes out looking like the Cohn view of evolutionary Agile.

It's not personal, it's business!



Buy them at any online book retailer!

Saturday, November 10, 2018

Alice, the Cat, and Agile



I've heard it many times that this little ditty is the essence of why Agile is problematic with its dearth of plans, estimates, etc:
"Would you tell me, please which way I ought to go from here?
'That depends a good deal on where you want to get to,' said the Cat.
'I don't much care,' said Alice.
'Then it doesn't matter which way you go,' said the Cat.
'So long as I get SOMEWHERE,' Alice added as an explanation.
'Oh, you're sure to do that,' said the Cat"
- Lewis Carrol from "Alice's Adventures in Wonderland"
Not so fast!
  • No Agile project is sans a Narrative or Vision or epoch story
  • No Agile project is without some tie to the business, and thus a business outcome or influence,
  • No Agile project is without some commitment of resources from the business -- folks I know don't work for free

On the other hand
  • Some Agile projects have trouble getting off the stage; to wit: Are we done yet?
  • Some Agile projects spend the money and get little done, certainly little for the business
  • All Agile projects benefit from some degree of planning and estimating, if only to frame the project onto the right first step.

Alice and the Cat are not Agilists!


Buy them at any online book retailer!

Wednesday, November 7, 2018

The Agile Canon



I thought this posting on the "Agile Canon" was worthy of passing along in its entirety. So, there's the link for a pretty good read on the most important elements of a canon that all should be interested in adopting:

  1. Measure Economic Progress: Outcomes, means to measure, means to forecast
  2. Proactively Experiment to Improve: Assess options, embrace diversity and variability, execute experiments to improve
  3. Limit Work in Process: Visibly track work by category, communication delays are a form of WIP
  4. Embrace Collective Responsibility: don't blame others, don't blame others by name, don't blame the circumstances, accept and embrace responsibility for outcomes
  5. Solve Systemic Problems: Be de-constructive to the root cause, be aware of both static and dynamic influences


Buy them at any online book retailer!

Sunday, November 4, 2018

Leveraging customer relationships



One of my students offered this strategy for establishing, maintaining, and leveraging relationships with the customer. I thought it was pretty good, so here's the idea:

1. Customer Account Responsible (ACR) -- who ... is the Account Manager
for the domain, market or dedicated to the customer (big accounts) responsible for:
  • Account relationships,
  • Opportunity identification,
  • Commercial management,
  • Communication management.
Normally the SPOC for a business development effort.

2. Customer Solution Responsible (CSR) – This role is held by various people
depending on the company type – Solution Architects, Solution Consultants,
Solution Managers etc – and they have the responsibility of:
a. End-to end solution integrity
b. Collection of and documentation of requirements from the customer – Executive,
Business, Technical and Users requirements – Securing the sign off on the
requirements scope with the ACR and CFR to the customer.
c. Prioritization of the requirements with the respective customer responsibilities,
in order of increasing importance, and determining the “fit to need” alignment of
the requirements
d. Map solution requirements to the vendor solution/product portfolio, and
determine the Delta, and how to fill those Delta.
e. Hand off complete solution design documentation to the project execution team,
and provide input to the executing team (CFR) for project execution planning.
f. Including and manages SME’s , Product Owners etc and their deliverables as
needed in various verticals that are needed to address the solution design and
product lifecycle


3. Customer Fulfillment Responsible (CFR) – this is normally the PMO organization that turn the solution into reality inside the customer organization/premises/site:
  • Project management team,
  • Service Delivery team,
  • System Integration team,
  • Field Engineers,
  • Technical Architects etc
PMO is are responsible for:
  • System Integration and Final Acceptance testing
  • Validation with the customer, and
  • Finished Product Handover to the customer Project/Service Operations team.
At this stage the solution ceases to be a project, and is included into the Customer Operational and Support Lifecycle Management.



Buy them at any online book retailer!

Thursday, November 1, 2018

Does software actually fail?


Does software fail, or does it just have faults, or neither?
Silly questions? Not really. I've heard them for years.

Here 's the argument for "software doesn't fail": Software always works the way it is designed to work, even if designed incorrectly. It doesn't wear out, break (unless you count corrupted files), or otherwise not perform exactly as designed. To wit: it never fails

Here's the argument for "it never fails, but has faults": Never fails is as above; faults refer to functionality or performance incorrectly specified such that the software is not "fit for use". Thus in the quality sense of "fit for use" it has faults.

I don't see an argument for "neither", but perhaps there is one.

However, Peter Ladkin is not buying any of this. In his blog at "the Abnormal Distribution", he has an essay, part of which is here:

What’s odder about the views of my correspondent is that, while believing “software cannot fail“, he claims software can have faults. To those of us used to the standard engineering conception of a fault as the cause of a failure, this seems completely uninterpretable: if software can’t fail, then ipso facto it can’t have faults.
Furthermore, if you think software can be faulty, but that it can’t fail, then when you want to talk about software reliability, that is, the ability of software to execute conformant to its intended purpose, you somehow have to connect “fault” with that notion of reliability. And that can’t be done. Here’s an example to show it.
Consider deterministic software S with the specification that, on input i, where i is a natural number between 1 and 20 inclusive, it outputs i. And on any other input whatsoever, it outputs X. What software S actually does is, on input i, where i is a natural number between 1 and 19 inclusive, it outputs i. When input 20, it outputs 3. And on any other input whatsoever, it outputs X. So S is reliable – it does what is wanted – on all inputs except 20. And, executing on input 20, pardon me for saying so, it fails.
That failure has a cause, and that cause or causes lie somehow in the logic of the software, which is why IEC 61508 calls software failures “systematic”. And that cause or causes is invariant with S: if you are executing S, they are present, and just the same as they are during any other execution of S.
But the reliability of S, namely how often, or how many times in so many demands, S fails, depends obviously on how many times, how often, you give it “20″ as input. If you always give is “20″, S’s reliability is 0%. If you never give it “20″, S’s reliability is 100%. And you can, by feeding it “20″ proportionately, make that any percentage you like between 0% and 100%. The reliability of S is obviously dependent on the distribution of inputs. And it is equally obviously not functionally dependent on the fault(s) = the internal causes of the failure behavior, because that/those remain constant.



Buy them at any online book retailer!

Monday, October 29, 2018

Validation and Verification -- in Agile? Really?


Validation and Verification: traditionalists know these ideas well. Do they still have relevance in the Agile space?
My opinion: Yes!

Traditional V-and-V: the way it is

Traditional projects rely on validation and verification (V-and-V) for end-to-end auditing of requirements:
  • Validation: the requirements ‘deck’ is validated for completeness and accuracy.

    If there are priorities expressed within the deck, these priorities are also validated since priorities affect resource utilization, sequencing, and schedule.

  • Verification: After integration testing, the deck is verified to ensure that every validated requirement was developed and integrated into the deliverable baseline; or that changed/deleted requirements were handled as intended.


Agile: what's to verify; what's to validate?

The BIG QUESTION: Is the strategic intent of the narrative answered? Is the business case on a path to success?

After all, the grand bargain in Agile is that flexibility for tactical implementation is allowed insofar as there is faithfulness to the strategic intent. Tactics are fluid; strategy is not.

Agile V-and-V: the way to do it

Certainly, Agile projects are less amenable to the conventional V-and-V processes because of the dynamic and less stationary nature of requirements.
  • Validation: After the business case is set, the top-level narrative is in place, and the overall strategy of the project is framed, some structured analysis can occur on the top level requirements.
  • If there are priorities expressed within these business case requirements, these priorities are also validated
  • Conversational-style requirements -- aka, stories -- are also validated, typically after the project backlog or iteration backlog is updated.
  • Verification: After integration testing, the deliverable functionality is verified to ensure that every validated conversation was developed and integrated into the deliverable baseline; or that changed/deleted conversations were handled as intended.
  • During development, expect some consolidation of stories, and expect some use (or reuse) of common functionality.

    Thus, recognize that Agile may not maintain a fully traceable identify from the time a conversation is moved into the design and development queue to the time integration testing is completed. However, the spirit of the conversation should be there is some form. It’s to those conversational forms that verification is directed.
The last thing to do is circle back to the narrative: Is the big question verified? If so: victory!
If not, back to the sponsor for guidance and direction



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 26, 2018

What time is the 3pm meeting?



Have you ever been asked: "What time is the 3 pm meeting?" 
You're thinking: "This guy is on something; or he's texting while talking!"


We here in the backyard of the seemingly larger-than-life Walt Disney World* pay some attention to the management paradigms coming out of our corporate neighbor.

And, so the Disney response to that question is instructive, as given in this blog post from the Disney Institute, which I sum up as:

'Any interaction provides an opportunity to add value and improve quality of communications'
“What time is the 3 o’clock parade?” On any given day in the Magic Kingdom at Walt Disney World Resort, you might hear Guests asking our Cast Members this seemingly peculiar question. And, while the question appears to have an obvious answer, we also know that frequently the true question lies beyond the obvious.

As our Guests are often excited and distracted ..... So, Cast Members will ask some additional questions to uncover what it is that the Guest really wants to know…such as, “What time will the parade get to me?” “When should I start waiting to get a good viewing spot?” and “Where is the best place to stand?”

Instead of simply repeating the obvious answer—the actual parade start time—back to the Guest, our Cast Members take this opportunity to .... share with the Guest what time the parade will pass by certain locations in the park, offer possible vantage points to view the parade or advise when to leave another area and still arrive at the parade on time.

This is important, because rather than dismissing the “3 o’clock parade?” question as something trivial and offering a blunt response, Cast Members understand that it offers the opportunity to exceed the Guests’ expectations .....
.... the “3 o’clock parade” question is commonly used to help Cast Members understand that their answer can either end the conversation, or it can begin a quest for richer discovery.
....

*Did I mention:7 parks, 29 hotels on property, 40,000 acres, and tens of thousands of "cast members
And, I am an un-paid volunteer for Disney Sports Attractions


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 23, 2018

Program success dashboard



Looking for project dashboard that really provides insight at a glance?

This one from John Higbee might be the answer

If you've not a Higbee person, maybe you've not seen it. Take a look at John Higbee's presentation about "Program Success Probability" . (*)

Take notice of the neat arrangement of program success divided left and right by internal and external factors.

On page 5 of Higbee's slides, you'll find this image:

Dynamic colors
This presentation is intended as a dashboard. The colors are dynamic on a Red-Green-Yellow-Gray (not evaluated) scale. The scale has to be defined (calibrated) for each program in order for management to be able to get a proper take-away.

Trendy
Trends are shown in each block with arrows. Again, trends must be defined for each program, i.e. what is the meaning for an up-pointing arrow?

Of course, Higbee goes on in the presentation with more detail and more examples of dashboard presentations, for example the more-or-less standard presentation of sliding bars to show progress vs plan

For the Gov in all of us
Since this presentation is for a government audience, it includes dashboards for contractor performance and even contractor business success

Bottom line: an interesting suggestion for dashboards are in this presentation, along with at least one gov'y's idea of what's important.

-------------------
(*) Search this site for other Higbee presentations; you'll find others you might be interested in.



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, October 20, 2018

Quantum science projects





“God does not play dice with the universe.”
― Albert Einstein, The Born-Einstein Letters 1916-55

“So Einstein was wrong when he said, "God does not play dice." Consideration of black holes suggests, not only that God does play dice, but that he sometimes confuses us by throwing them where they can't be seen.”
Stephen Hawking
Science and engineering projects
If you line up with Hawking, and are looking for a start in the quantum world, read this:
GAITHERSBURG, Md.—The U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) has signed a cooperative research and development agreement (CRADA) with SRI International to lead a consortium focused on quantum science and engineering. SRI International is a nonprofit, independent R&D center headquartered in Menlo Park, California.

Read More



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, October 17, 2018

Bad Haircut



The bad haircut 
What do you say when your colleague comes in with a bad haircut? (*)
Jump on it? Criticize it?
Threaten abuse?
Probably none of the above; probably you ignore it or make some civil remark

The bad idea 
What if the same person comes in with a bad idea? Now what?
Probably you can't ignore it, but your commentary can be civil, inquiring, benefit of the doubt and all that (Speak softly and carry a big stick ... our guy Roosevelt; and look at what he accomplished)

 _______________

(*) 2018 season opening episode of "Blue Bloods"




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, 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