Sunday, March 24, 2019

Agile for Project Managers: an analogy

It's been a few years since I wrote the material for the presentation below, but I find it timeless.

It's all about an analogy

It's all about how a self-directed team working on a mission of top-down importance and specification -- these imperatives coming from executive leaders -- get the job down sufficiently well (in Agile speak: well enough) to succeed

Buy them at any online book retailer!

Thursday, March 21, 2019

Some stuff you need quickly

Robert Gates, the former United States Secretary of Defense, in a September 2008 speech, said: 
Our conventional modernization programs seek a 99% solution in years. Stability and counterinsurgency missions—the wars we are in—require 75% solutions in months. The challenge is whether in our bureaucracy and in our minds these two different paradigms can be made to coexist”.

Since that speech, the Defense acquisition management system has been revised twice. Now, there is official sanction for faster methodologies with lower overhead.

Buy them at any online book retailer!

Monday, March 18, 2019

Against the Gods -- a review

"Against the Gods, The remarkable story of Risk" by Peter L. Bernstein is an excellent read and ambitious premise well delivered.

Perhaps the best general history of risk -- and presentation of the major concepts of risk -- that is understandable by all practitioners at any level.

The content is presented in a general historical order in major sections by epoch. The first being from the ancients to 1200, then the middle ages and Renaissance. Finally, then into the industrial revolution, and modern era.

Along the way, Bernstein recounts not only the emerging understanding of risk per se, but also the allied concepts of counting, numbers, chance, and of course, business management.

No math! (Almost no math)
There is not much math or statistics to trip up the qualitative mind! (Yea for that) But, the presentation of the evolution of our understanding of chance introduces many of the main characters and demonstrates their contributions with just enough math/quantitative examples to make it interesting.

Mystical and Divine... pressing on!
Much of this material describes the period 1700 - 1900 when much of the modern underpinnings of chance, probability, and statistics were developed and made understandable to the general business population. We learn, for instance, that it was in this period that the notion of risk in the modern sense emerged from the mystical and divine to the cause-effect concept.

While the parallel developments of mathematics, business practises--like insurance--and a math/cause-effect foundation for risk are presented with a storyteller's gift, I found Bernstein's recounting of the ideas that developed after 1900 to be the most interesting and insightful.

Along comes the psychologists
Of course, the story in this book ends just about the time that the ideas of Amos Trversky and Daniel Kahneman, first developed in the 1970's, are gaining popular acclaim in the 90's. Thus, in this part of the book we get a great explanation of the expansion of utility theory first developed in the 1700's but advanced into Prospect Theory by Tversky and Kahneman.

There is also excellent explanations of various biases and other cognitive maladies that intrude on the rational and objective. We learn a good deal about the failure of invariance--the idea that same manager can be risk averse and risk seeking depending on not only the point of view presented (glass half full/half empty) but also whether there is a sure loss or a sure win at stake.

Someone else likes it
Bernstein's expertise is in the financial world. John Kenneth Galbraith wrote of "Against the Gods": "Nothing like it will come out of the financial world this year or ever. I speak carefully; no one should miss it".

Buy them at any online book retailer!

Friday, March 15, 2019

Just changed, or transformative?

Change: things are different, or will be. Often a matter of process and function
Transformation: Change + values or philosophy that are changed as well

Some say that we still don't get it, some 12 years after notable John Kotter wrote his seminal article "Leading Change: Why Transformation Efforts Fail." Some say 30% or more fail. Of course, this begs the question: what is failure, or perhaps harder: what is success?

A piece I read by Ron Ashkenas says:
"Unlike change management, it [transformation] doesn’t focus on a few discrete, well-defined shifts, but rather on a portfolio of initiatives, which are interdependent or intersecting.

More importantly, the overall goal of transformation is not just to execute a defined change — but to reinvent the organization and discover a new or revised business model based on a vision for the future.

It’s much more unpredictable, iterative, and experimental. It entails much higher risk. And even if successful change management leads to the execution of certain initiatives within the transformation portfolio, the overall transformation could still fail."
Of course transformation is unpredictable! Who can say where a change in beliefs and values is going to lead? Who can say if such is really a good thing?

We can put parameters around objective change management stuff, but it's hard to measure, much less predict, non-objective phenomenon. About the best you can do is look at the A/B situation: A: the way it was; B: the way it is now.

A/B testing is a big thing in many projects these days.
How else to actually evaluate things?
So, is it change or is it transformation? Usually the former shows itself right away; the latter may be generational (See: transformative politics)...
You'll just have to wait and see; or better yet, get promoted and have someone else wait and see.

Buy them at any online book retailer!

Tuesday, March 12, 2019

So, who's responsible for Customer?

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

Saturday, March 9, 2019

The project balance sheet -- not for accountants!

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

Take a look at this figure:

What have we got here?

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

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

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

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

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

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

Oops! the PM is the ultimate risk manager.

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

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

Buy them at any online book retailer!

Wednesday, March 6, 2019

Speak softly; big stick leadership formula

  • Hit the ground running
  • Consolidate control
  • Ask questions of everyone wherever you go
  • Manage by wandering around
  • Determine the basic problems of each organization and hit them head-on
  • When attacked, counterattack
  • Stick to your guns
  • Spend your political capital to to reach your goals
  • When your work is stymied or done, find a way out
As quoted by Doris Kearns Goodwin in "Leadership in turbulent times"


Buy them at any online book retailer!

Sunday, March 3, 2019

Loosen the coupling

Looking for schedule success?
Easy! Loosen the coupling!

Remember the "shift right" phenomenom in scheduling?
If two or more events are tightly coupled to a milestone -- meaning no slack -- then a slip of any event pushes the milestone, to wit: shift to the right
 And, the risk is exponential with the number of events:
The risk of two events is the risk-squared (where risk is probability of success)
Two risks of 80% success each are about 64% likely as a simultaneous pair
What's a project manager to do?
Answer: schedule loosely (add buffers to one or more events). This is the main take away in the "Critical Chain" concept, but it's also a fundamental principle in system engineering
  • Shock absorbers are needed between critical parts that require some independence of action
No better example of this is in the management of subcontractors that are not captive to your project. They often march to their own drum, putting their interests first. And, why not?

For project success (scheduling being an important success parameter), when dealing with subcontractors, loosen the coupling! Buffer everything they are supposed to do -- if you can. You'll be less disappointed.

Buy them at any online book retailer!

Thursday, February 28, 2019

Jack or Jill?

A study I read about started this way:
  • Draw a picture of an effective leader

Almost without exception, the picture was of a man.

Ooops: what about the lady leaders? There's certainly no lack of role models in both politics and business, from Angela Merkel -- Chancellor of Germany -- to  Mary Barra -- CEO of General Motors

Another study had people listen in to a business meeting where actors, call them Jack and Jill, among others, were discussing strategy, issues, business details, etc
  • Invariably, Jack was given high marks for leadership, even if the script for Jill was nearly identical 
Indeed, we learn this:

“It didn’t matter whether women spoke up 1) almost never, 2) rarely, 3) sometimes, 4) often, or 5) almost always,” Kyle Emich, a professor at Alfred Lerner College of Business and Economics at the University of Delaware, and one of the authors, wrote in an email.

“Women did not gain status for speaking up, and subsequently were less likely (much less) to be considered leaders.” 

The conclusion of those who study this stuff is that we're very much influenced by stereotypes learned from an very early age. In a word: culture. And, only time and performance will change culture significantly

Ok, so what does this mean? Don't speak up? Don't "lean in"? It's all not valued?
I hope not; there will not be change without engagement, so press on!

Buy them at any online book retailer!

Sunday, February 24, 2019

It's a bell shape, unless it's not

Jurgen Appelo is, by his own description, "a Dutch guy" who is somewhat of a humorist, an illustrator, and a proponent of Agile. He also writes a lot about complexity, and the effects of complexity on systems and projects.

In his posting, "The Normal Fallacy", Appelo takes on both misconceptions and lazy thinking, and reinforces the danger of thinking everything has a 'regression to the mean'.

It's a bell, unless it's not
Appelo tells us to not have a knee jerk reaction towards the bell-shaped Normal distribution.  He's right on that one: the bell-shape distribution is not the end-all and be-all but it does serve as a useful surrogate for the probable patterns of complex systems.

Why?  Because many, if not most, natural phenomenon tend to have a "central tendency" or preferred state of value. In the absence of influence, there is a tendency toward the center. This really isn't lazy thinking; in fact, it's a useful default when there is a paucity of data.

But if no central tendency?
In both humorous and serious discussion he tells us that the Pareto concept is too important to be ignored. The Pareto distribution, which gives rise to the 80/20 rule, and its close cousin, the Exponential distribution, is the mathematical underpinning for understanding many project events for which there's no average with symmetrical boundaries--in other words, no central tendency.

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

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

So far, so good.  BUT.....

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

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

Even so, many "next events" do cluster
But project managers are concerned with the collective effects of dozens, or hundreds of dozens of work packages, and a longer time frame, even if practicing in an Agile environment.  Regardless of the single event distribution of the next thing down the road, the collective performance will tend towards a symmetrically distributed central value. 

For example, I've copied a picture from a statistics text I have to show how fast the central tendency begins.  Here is just the sum of two events with Exponential distributions [see bottom left above for the single event]:

Good enough
For project managers, central tendency is a 'good enough' working model  that simplifies a visualization of the project context.

The Normal curve is common surrogate for the collective performance.  Though a statistician will tell you it's rare that any practical project will have the conditions present for truly a Normal distribution, again: It's good enough to assume a bell shaped symmetric curve and press on.

Buy them at any online book retailer!

Thursday, February 21, 2019

Looking for stuff on PM?

You say: "I've got to give a presentation about [some] topic in Project Management. Where do I find the stuff I need?"

I say: Look no farther than

There you'll find some 45 presentations available for free download.
Attribution: If you use my stuff, please do me the courtesy of an attribution and a reference to the material on

The most viewed is this one on risk management: "Top Five Ideas from Statistics that help project managers".

But actually my favorite, almost as popular, is: "Agile for Project Managers: A sailor's look at Agile"

Oh! Did I mention the books? Illustrated below, and available at all on-line retailers

Buy them at any online book retailer!

Monday, February 18, 2019

Agile and R/D

I was recently asked if Agile and 'R/D' go together.

The issue at hand: how do you reconcile agile's call for product delivery to users every few weeks with the unknowns and false starts in a real R/D project?

Good question! I'm glad you asked.

Let's start with OPM ... Other people's money ... And the first question: What have you committed to do? There are two possible answers:

(1) apply your best efforts; or (2) work to "completion".(*)

"Completion" is problematic -- if not impractical -- in the R/D domain: completion implies a reasonable knowledge of scope;  heavy "R" implies a very limited idea of the means to accomplish an end goal; "D" is the flip of that.

The best example of "best effort" is "Time and Materials" -- T/M. If you're working T/M your obligation -- legally at least -- is best effort, though you may feel some higher calling for completion.

The most constraining example of "completion" is Firm Fixed Price -- whether by contract or just project charter. FFP is almost never -- dare I say never? -- appropriate for R/D

And so now let's layer on Agile ... "what's in" and "what's out" vis a vis R/D:
Among the agile practices that are "IN" (in no particular order)
  • Conversational requirements ("I want to cure cancer")
  • Prototypes, models, and analysis (even, gasp! Statistics and calculus, though some would argue that no such ever occurs in an agile project)
  • Periodic reflection and review of lessons learned
  • Small teams working on partitioned scope
  • Trust and collaboration within the team
  • Skills redundancy
  • Local autonomy
  • Persistent teams, recruited to the cause
  • PM leadership to knock down barriers (servant leadership model)
  • Lean bureaucracy
  • Emphasis on test and verification
  • Constant refactoring
  • Frequent CI (integration and regression verification with prior results)
And, among the agile practices that are "OUT"
  • Definite narrative of what's to be accomplished (Nylon, as an example, was an accident)
  • Product architecture
  • Commitment to useful product every period
  • Intimate involvement of the user/customer (who even knows who they might be when it is all "DONE"?)
There may be a longer list of "OUT"s, but to my mind there's no real challenge to being agile and doing R/D.

(*) Of course, (1) may be embodied in (2) -- why wouldn't you always apply your best efforts? -- but in the R/D domain (2) is often not a requirement and may be a bridge too far: -- got a completion cure for cancer? "Completion" means more than just effort; it has elements of accomplishment and obtained objectives.

Buy them at any online book retailer!

Friday, February 15, 2019

Garbage in .....

Garbage in; garbage out... GIGO to the rest of us

Re GIGO, this issue is raised frequently when I talk about Monte Carlo simulation, and the GIGO thing is not without merit. These arguments are made:
  • You have no knowledge of what distribution applies to the uncertainties in the project (True)
  • You are really guessing about the limits of the three point estimates which drive the simulation (partly true)
  • Ergo: poor data information in; poor data information out (Not exactly! the devil is in the details)
Here are a few points to consider (file under: Lies, damn lies, and statistics):

First: There's no material consequence to the choice of distribution for the random numbers (uncertain estimates) that go into the simulation. As a matter of fact, for the purposes of PM, the choices can be different among tasks in the same simulation.
  • Some analysts choose the distribution for tasks on the critical path differently than tasks for paths not critical.
  • Of course, one of the strengths of the simulation is that most scheduling simulation tools identify the 'next most probable critical path' so that the PM can see which path might become critical.
Re why the choice is immaterial:  it can be demonstrated -- by simulation and by calculus -- that for a whole class of distributions, in the limit, their infinite sum takes on a Normal distribution.

  • X(sum) = X1 + X2 + X3 +.... +XN, where N is a very large number, X(Sum) is Normal, no matter what the distribution of X is
As in "all roads lead to Rome", so it is in statistics: all distributions eventually lead to Normal. (those that are practical for this purpose: single mode and defined over their entire range [no singularities]),

To be Normal, or normal-like, means that the probability (more correctly, the probability density function, pdf) has an exponential form. See: Normal distribution in wikipedia

We've seen this movie before in this blog. For example, few uniform distributions (not Normal in any respect), when summed up, the sum took on a very Normal appearance. And, more than an appearance, the underlying functional mathematics also became exponential in the limit.

Recall what you are simulating: you are simulating the sum of a lot of budgets from work packages, or you are simulating the sum of a lot of task durations. Therefore, the sim result is summation, and the summation is an uncertain number because every element in the sum is, itself, uncertain.

All uncertain numbers have distributions. However, the distribution of the sum need not be the same as the distribution of the underlying numbers in the sum. In fact, it almost never is. (Exception: the sum of Normal is itself Normal) Thus, it really does not matter what distribution is assumed; most sim tools just default the Triangular and press on.

And, the sim also tends to discount the GIGO (garbage in/garbage out) problem. A few bad estimates are likewise immaterial at the project level. They are highly discounted by their low probability. They fatten the tails a bit, but project management is a one-sigma profession. We largely don't care about the tails beyond, certainly not six sigma!

Second: most folks when asked to give a 3-point simply take the 1-pointer they intended to use and put a small range around it. They usually resist giving up anything so the most optimistic is usually just a small bit more optimistic than the 1-pointer; ....  and then they put something out there for the most pessimistic, usually not giving it a lot of thought.

When challenged, they usually move the most-likely 1-pointer a bit to the pessimistic side, still not wanting to give up anything (prospect theory at work here). And, they are usually reluctant to be very pessimistic since that calls into question the 1-pointer (anchor bias at work here). Consequently, you get two big biases working toward a more optimistic outcome than should be expected

Third: with a little coaching, most of the bias can be overcome. There is no real hazard to a few WAG because unlike an average of values, the small probability of the tails tends to highly discount the contribution of the WAGs. What's more important than reeling a few wild WAGs is getting the 1-pointer better positioned. This not only helps the MC Sim but also helps any non-statistical estimate as well.

Bottom line: the garbage, if at the tails, doesn't count for much; the Most likely, if a wrong estimate, hurts every methodology, whether statistical or not.

Buy them at any online book retailer!

Tuesday, February 12, 2019

Technical debt -- a working definition

Technical debt: we've all written about it; I've described it in my book, Project Management the Agile Way (see below), but I guess the industry has never settled on a formal definition.

I've always thought of it as a "punch list" that is a "debt" that must be retired in the future .... stuff that needs to get DONE or fixed so that we can say to the sponsor: hey, it's DONE and the QUALITY is built in.

I saw this definition recently.

In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term, but set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability [SIC].

Frankly, it's a little too formal and I think it actually misses the point that debt may be as simple as a low level test not completed; a color not made right; a functionality with a bug that occurs very infrequently, etc.  Nonetheless, there it is for your consideration

If you click back to the original source, you pick up on this explanation which adds a bit of color commentary, to wit:

This metaphor is in essence an effective way of communicating design trade-offs and using software quality and business context data in a timely way to course correct.

While other software engineering disciplines such as software sustainability, maintenance and evolution, refactoring, software quality, and empirical software engineering have produced results relevant to managing technical debt, none of them alone suffice to model, manage, and communicate the different facets of the design trade-off problem at hand.

Of course, I take a bit of issue with the last phrase "design trade-off problem at hand": technical debt is not exclusively -- or even -- about design trades per se; as before: it could be as simple as a low level test not completed. One wonders if the guys who wrote this stuff have actually ever done it.

Buy them at any online book retailer!

Saturday, February 9, 2019

Two doors: risk and decision managers

A narrative*

Imagine two doors to the same room:
  • One labeled risk manager; the other labeled decision maker.
  • Though the risk manager's door, entry is for the inductive thinker: facts, experience, history looking for a generality or integrating narrative
  • Through the decision maker's door, entry is for the deductive thinker: visionary with a need to articulate specifics for the vision
Adding to the narrative:
  • Pessimists with facts enter through the risk manager's door
  • Optimists with business-as-we-want-it enter through the decision maker's door
Then what happens?
They seek each other (hopefully, if minds are open). In the best of situations, they meet in the middle of the room where this is buffer space and flexibility.

How does the inductive and deductive interact?
Risk management does not set policy for the project office; it only sets the left and right hand boundaries for the vision, or for the project policies.
The space in between is where the decision maker gets to do their envisioning, moving about, perhaps even bouncing off the walls, constrained only by the risk boundaries.

(*) Sound familiar? I hope so. You'll find a similar explanation known as the "project balance sheet" in Chapter 6 of "Maximizing Project Value: A project manager's guide". (Oh -- the book cover is shown below!)

In that balance sheet metaphor, the right side is for the fact-based inductive manager; the left side is for the visionary. And, since those two never agree fully, there is a gap.

And the gap is where the risk is. Risk is the balancing element between the vision and the facts. And who is the risk manager: the project team -- not the visionary. (That's why we pay the PMO the big bucks: to manage the risk!)

Wednesday, February 6, 2019

Burning up the team

Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like you suggest lend objectivity to the process (not playing favorites, etc).

Losing productivity
Of course, the real issue is one that agile leader Scott Ambler has talked about: the precipitous drop in productivity once you reach about 70% throughput capacity of the team. Up to this point, the pace of output (velocity) is predictably close to team benchmarks; thereafter, it has been observed to fall off a cliff.

Brook's Law -- it's not been repealed
Other observers have put it down as "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . Read: "Mythical Man-month" for more from Brooks

Did I mention Physics?
In the physics of wave theory, we see the same phenomenon: when the "load" can not absorb the energy applied, the excess is reflected back, causing interference and setting up standing waves. This occurs in electronic cables, but it also happens on the beach, and in traffic.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference.
Many have told me: the way to speed things up is to reduce the number of teams working and the number of staff applied.

WIP Limits
In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity. The problem arises with sponsors: their answer is universally: throw more resources in, exactly opposite the correct remedy

6x2x1, or other
One of my students said this: "Daniel Pink  has an excellent book called "Drive: The surprising truth about what motivates us" that talks about inspiring high productivity and maintaining a sustainable pace.
One of the techniques is the 6x2x1 iteration model.
This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

You can also run a 3x4x1 model for four week iterations.
Proponents of this approach have observed that the development teams will often tackle tough problems, implement significant improvements and generally advance the project during these free play periods. Without the time crunch to complete the story points the team also refreshes itself."

And now, we rest!

Buy them at any online book retailer!

Sunday, February 3, 2019

Getting "reskilled"

Dispatches from Davos 2019
There's a revolution afoot

The panel discussions are about "human-centered A.I", and the "Fourth Industrial Revolution" in an article reported by Kevin Roose

And, thinking about it, would you want A.I. to be other than human-centered?

Strategic thinking:
 “Earlier they had incremental, 5 to 10 percent goals in reducing their work force. Now they’re saying, ‘Why can’t we do it with 1 percent of the people we have?’”

Getting there (as reported)!
One common argument made by executives is that workers whose jobs are eliminated by automation can be “reskilled” to perform other jobs in an organization.

They offer examples like Accenture (*), which claimed in 2017 to have replaced 17,000 back-office processing jobs without layoffs, by training employees to work elsewhere in the company. 

Chat now
Got some back-office processing in your project office, or supporting your project office? The automated on-line chat is coming to a project near you!

(*) Full disclosure: A few years ago, I worked in a PMO largely staffed by Accenture (I was the customer; they were the consulting partner)

Buy them at any online book retailer!

Thursday, January 31, 2019

I've got to write a RFP

Ever been asked to write an RFP (request for proposal)? It may not be as easy as you think. My metric is about 2-3 hours per finished page, exclusive of specifications. Specs are normally just imported. So, it could take you the best part of a week to put an RFP in place.

My outline is given in the Slideshare presentation below

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

Source identification: Sources, per se, are not part of the RFP, but sources are its audience. And the RFP is written for a specific audience, so sources certainly influence the RFP

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

Of course, there's sole source (the only one in the world who can do it) or selected source (the only one in the world you want as your contractor), but more often an RFP regulates competition among multiple sources.

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

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

    The flexibility of best value (or, glass half empty: lack of objectivity) comes with its own risk: the award, if in the public sector, is subject to protest about how the best value was determined.
Risk transfer: what technical, functional, and business risks are you going transfer to the contractor via the RFP, and are you prepared to pay for that transfer? In effect, you're buying insurance from the contractor. All other risks are your to keep; you can be self-insured, or pass them off to an insurance party.

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

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

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

Specifications: How's and what's: Specs are where you can speak to measures of "how" insofar as you tell the contractor how something is to be measured; or you can speak to measures of what insofar as you tell the contractor what the metrics are and what the metric limits are

Requirements: And last but not least, the infamous Requirements backlog or matrix. Requirements are usually made a part of the SoW  as detailed "what's" or they can be a specification onto themselves.

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

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

Buy them at any online book retailer!

Sunday, January 27, 2019

Kanban at the Kitchen Table

Dana Rousmaniere and Frank Saucier collaborate in an interview to talk about kanban methods for the home. And, of course, it's all built around a kitchen table white board with some sticky notes.

Have you done this at home? I have; and it works... you wouldn't expect otherwise.

But, Frank carries it a bit further than I want to go. He has structured family meetings with a checklist agenda, and then daily check-ins on project tasks.
Whoa! that's a bridge too far for my wife ... no micromanagement here.
In fact, Frank admits: "There's sometimes some moaning and groaning... "

The larger point
But, of course, there's a larger point here: Almost everything we do, formally or informally structured, as some sequence and flow -- just think about driving to work, or walking in to open your home office at the beginning of the work day (or night)

Flow and process... sequential steps; they are the building blocks of everything

Now, the lean and kanban advocates are all about improving flow, thinning out the non value-add, and simplifying the process so that work flow and work process are pretty much birds of a common feather.

Then comes scale, even in the kitchen
Who can argue with lean? Does anyone really want to do the non-lean stuff, even if they have to? No one so long as the work flow on the kanban does not require coordination with other kanban's... in that case, we move on to scale, and scale brings overhead, and overhead brings flow control, and so we all slow down.

You don't see this much on the kitchen table, unless your home project is part of a larger project for a community organization -- then comes the bureaucracy of scale.

You might say that velocity and scale have a inverse correlation, perhaps even a causation -- larger scale, lower velocity

Is it too low tech?
"I like to use low-tech tools, because it’s more important to learn good habits than it is to learn to use a tool. That said, there are plenty of digital ways to do the same thing — a good, free tool is Trello, which is essentially an online Kanban board.

But, I find that with digital tools, a lot of great ideas get buried, and the simple act of moving a post-it across a visual board is very kinesthetic. I’ve also noticed that teams have better discussions when they’re around a physical board." Frank
What's the payoff?
With Frank I agree (from personal experience in the kitchen)
  • Get priorities squared away
  • Manage distractions
  • Teach others the tools as a life skill
  • Richer communications

Buy them at any online book retailer!

Thursday, January 24, 2019

Measure the measurable

Without Metrics you're just another guy with an opinion - Stephan Leschka, Hewlett Packard*

I get it; and mostly, I agree with Mr. Leschka
BUT, there are a few other rules:
  • Don't measure -- meaning: don't invest the effort to collect and analyze -- that which you don't manage
  • Don't measure the unmeasurable -- meaning, don't assign false values and dimensions to that which is fundamentally subjective and intangible.
  • And, if your metrics are not statistically significant, you may still be just a guy with an opinion
What about this?
  • In spite of many books to the contrary: Everything is not measurable. 
  • And, even it is measurable, it may not be necessary or important to measure it. 
  • It may not be practical or economically sensible to measure it. That's why we invented sampling!
It's not always just about the numbers! (But, we knew that, didn't we?)
Of transactions and strategy
One might say: In the capitalist environment we manage, most of us subscribe to the school of transactions and dollars: all (most?) things of value have a price. And, if that is so, then all things of value can be measured. 
BUT: all is not transactional!
Some think long-term (are we shocked by such a claim?)
Some opinions and some issues are strategic: a blend of interests, principles, values not held in dollars, and effects which are to be legacy for those that follow. 

Buy them at any online book retailer!

Monday, January 21, 2019

Shakespeare on project management

When we mean to build,
We first survey the plot, then draw the model;
and when we see the figure of the house,
Then must we rate the cost of the erection
which if we find outweighs ability,
What do we then but draw anew the model
In fewer offices, or at least desist
To build at all?
William Shakespeare
Henry IV, Part2, I.iii,1598
First seen at heardingcats

Buy them at any online book retailer!

Friday, January 18, 2019

Quantitative risk for the new guy on the street

Repetition and review are good--Malcom Gladwell says it takes 10,000 hours to be expert at anything--so here's a few words that will take a few minutes on three important quantitative concepts every risk manager should know:

Concept 1: Centrality
Most phenomenon of interest to projects, particularly naturally occurring phenomenon, tend to cluster around a central value, given enough samples or examples. Obviously, this let's out the so-called long-tail 'black swans', but project managers can go a long way if they understand that central clustering is the norm ... in effect, the default.

The measures are average and expected value. The former is applicable when the data is known; the latter when the data is probabilistic and the numerical value is not known until an event occurs. In calculating the average, each value is equally weighted; in calculating the expected value, each value is weighted by its probability.

Concept 2: Variation
Yes, things cluster, but that simply means that around the central value there is a range within which things are nearby the center, but not exactly on the center.

It's more likely things are close to the center than not: that's an effect of centrality on variation

The measures of variation are variance and standard deviation.  Variance is a figure-of-merit related to the distance, or error, between a point in the range and the central value. Standard deviation is a more direct measurement of distance, having the same dimensions as the points in the range.  Engineers refer to the standard deviation as the root-mean-square, or RMS value.

Concept 3: Position
Sometimes it's enough to know just the position of a data value in the range.  Names associated with position are quartile and percentile, and the so-called 'Z' position. 

Z is just a value in the 'standard range' divided by the standard deviation.  [A 'standard range' has a '0' average] For project management purposes, the 'Z-position' extends +/- 3 units from the average or expected value for most situations.

Dividing a range into 4 quartiles requires defining 3 boundary points: Q1, Q2, and Q3.  Quartile is all about count, not value per se.  Just rank all the values in the range in ascending order.  Divide the count into quarters.  Q1, Q2, and Q3 are the count values that divide the range.

If a value is in the first quartile, that means that 75% of all the values in the range are greater than the Q1 value, and by extension 75% of all the values are greater than any value in the first quartile.

Buy them at any online book retailer!

Tuesday, January 15, 2019

Agile strong -- a reveiw

Trying to remember how you got here?
Understanding why you're sticking around is also important

So, here's my top ten reasons why agile has worked for me

1. Agile is a "best value" method: it's doctrine is centered on value and accomplishment for the customer and user, not so much adherence to cost and schedule--though the sponsor's investment can not be exceeded, so cost is at least capped

2. Agile respects the urgency and importance of priorities conveyed by the customer/user, most prominently by incremental delivery and flexible sequencing

3. Agile respects the power of emergence and iteration to drive innovation, provided the customer buys-in

4. Agile puts the customer in the driver's seat for the value agenda of the project.  By doing so, the project is more "Juran" than "Deming" in its quality orientation.
Thus the PM's mission: deliver the most value for the invested resources, taking reasonable risks to do so

5. Agile is more bottom-up than top-down as a matter of doctrine.  There's a bit of the "wisdom of the crowds" in the way that small teams are given opportunity to find solutions, and there's a bit of small unit tactics--as practiced by the largest command and control organization of them all....the U.S. military--that put a lot of minute to minute decision making with the bottom of the WBS.

6. Agile has the potential to more effectively align business planning-and-execute cycles with project cycles.  Business cycles are often scheduled well in advance and are often calendar driven [it's July, so let's kick-off the annual planning process for the next FY].

7. Consistent performance by small teams of participants that work together continuously is highly valued. Such consistency means that PMs can depend on throughput benchmarks that are statistically meaningful.

8. Agile respects the objective behind earned value: Say up front what you are going to do, and then do it.  No partial credit.  Either it works or it doesn't. 

9. Agile respects the common sense that all requirements can not be known at the outset, particularly when the outcomes are intangible and subject to an evolving understanding.

10. Agile gets the benefit stream flowing sooner, so the time displacement between need and delivery is manageable at lower risk.

Buy them at any online book retailer!

Saturday, January 12, 2019

Bigger pie, or more slices?

Leadership v Followership
I've been revisiting Michael Porter this week here at "Musings".
I was struck by Porter's description of leadership v followership in technology:

About that pie:
  • Leadership increases the size of the "pie", but 
  • Followership only reslices the pie.
  • Followers accept "zero-sum"; 
  • Leaders change the sum.

Buy them at any online book retailer!

Wednesday, January 9, 2019

F.W. Taylor: should we care?

How many project managers are still laboring with the aftermath of Fredrick Winslow Taylor, more popularly known as F.W. Taylor?

Taylor Who?
You might ask: Who was Taylor?
Good question
F.W. Taylor was one of the first to study business systematically -- an original "operations research" guy. He brought 'Taylorism" into the business culture in the years leading up to World War I. By 1915, his ideas were considered quite advanced.

But, here's news you can use: much of what he divined is still around and affecting projects! Read on ....

Taylorism, so called
Taylor set about to invent "scientific management", a revolutionary movement that proposed the reduction of waste through the careful study of work.

Taylor came up with the original 'time-and-motion' studies, perhaps one of the first attacks on non-value work.

Peter Drucker, a management guru par excellence who coined the term 'knowledge worker', has ranked Taylor, along with Darwin and Freud, as one of the seminal thinkers of modern times. ["Frederick Taylor, Early Century Management Consultant", The Wall Street Journal Bookshelf, June 13, 1997 pg. A1].

Ooops, what about Agile?
The essence of Taylorism is an antithesis to agile principles but nonetheless instructive.

Counter to what we know today, Taylor believed that workers are not capable of understanding the underlying principles and science of their work; they need to be instructed step-by-step what to do and how to do it; and nothing is left to chance or decision. Rigid enforcement is required.

Managers have a role
However off-base that idea, Taylor was close to the mark with his doctrine about value-adding work. According to Taylor, managers must accept that they have responsibilities to design efficient and effective process and procedures.

Waste must be eliminated!
Every action requires definition and a means to measure results.

OMG! Not a popular guy
Taylor was not well like by workers and it's not hard to see why. But Taylor's ideas and practises brought great efficiencies and profitability while providing customers with products of predictability of quality.

Do it once, right
I like what Steve McConnell says about quality and the software relationship. Building off Taylor's ideas of 'do it once right', though he does not mention Mr. Taylor, McConnell, author of the respected book "Code Complete" states the " general principle of software quality is .. that improving quality reduces development costs .... the best way to improve productivity is to reduce the time reworking..."

Beck gets it right
Kent Beck, writing in his book "Extreme Programming Explained - Second Edition" has a pretty strong idea about the legacy of Taylorism and its lingering effects on the knowledge industry.

He says of Taylor that he brought a social structure we continue to unconsciously apply, and warns against the message that Taylorism implies: workers are interchangeable; workers only work hard enough to not be noticed; quality is an external responsibility

Buy them at any online book retailer!

Sunday, January 6, 2019

Agile C.R.A.C.K. customers

Dr. Barry Boehm, a noted software methodologist with a long and illustrative career at TRW, DARPA, and USC, and author of the COCOMO model and Spiral methodology, writes about the ideal customer for agile projects.

Boehm's perspective:

-- Collaborative: they will engage with their customer peers and with the development team
-- Representative: they know the product or system requirements and can represent their constituents accurately
-- Authorized: they can make the decisions needed to keep velocity up, and their decisions stick!
-- Committed: they take their job seriously and make every effort to advance project success
-- Knowledgeable: they can understand what the developers are telling them in the context of the business or market situation.

More from Boehm on Agile:
Take a look at other Boehm'isms about agile in his book, with Richard Turner, "Balancing Agility and Discipline: a guide for the perplexed", published by Addison-Wesley in 2004

Buy them at any online book retailer!

Thursday, January 3, 2019

Dangling participle

Still, as Hanson Baldwin summed up the Italian campaign, “All roads led to Rome, but Rome led nowhere.
Hanson Baldwin, Historian
describing the WW II campaign in Italy, 1943 - 44

Accomplishment without purpose -- a dangling achievement
And, the lesson for project managers is:
Beware the strategic objective that isn't actually strategic at all.
  • It looks strategic at the moment
  • It's called strategic
  • Perhaps just a tactical diversion?
  • We go "there", but the dots don't connect; or, can't be connected; or there's nowhere to go from here
AKA: "The bridge to nowhere"; a dead end; wild goose chase? Down a rabbit hole? A floating apex? Perhaps ... some may be just tactics that didn't work; the real issue at hand is strategy that doesn't connect well to business objectives

Value adding?
And so, even if it dangles, could achievement have larger strategic value in some way, shape or form?

Yes, and no.
Which is the fate of -- and means to recognize -- such dangles: arguments in favor and and arguments against; seemingly forever on both sides of the issue; each with proponents, unconvinced and unconvincing. (The campaign in Italy is still argued to this day .... why did we do it? **)

What if?
History can not be rewound and replayed; there are too many unseeable connectors and influencers that might come into play in the alternative narrative. But, the broad strokes of "what if" might be instructive, and so why not play it through?
  • We achieve the objective
  • Now what?

Dangling participle? An actionable activity without an identified actionee

** Churchill's strategic vision was to defeat Germany from the east, through the Balkans, holding back the Russians from overrunning eastern Europe, and yet driving through East Germany to Berlin. The Italian campaign was a necessary entry into the Balkans, according to Sir Winston
Roosevelt's strategic vision was to drive through France for a quicker and more economical victory than slogging through the Balkans and challenging the Russians in the bargain.

In the competition of these two competing visions, Rome -- captured the day before D-Day in France -- became an objective achieved, but unconnected to the grand strategy (Roosevelt won the argument)

Buy them at any online book retailer!