Monday, June 18, 2018

Agile and Plan-Do-Check-Act


This is not as stuffy as it sounds:

Plan-Do Check-Act --
  • Plan-do-check-act (PDCA) envisions planning--just enough, and gasp! perhaps an estimate as well--for what is to be done, then doing it—that is the plan-do.
  • Next, measure results—measuring is the check activity (did someone say: accountability?)—and
  • Then act on the measurement results. To act in the PDCA sense means to reflect upon lessons learned and provide feedback for corrective actions to the next iteration of the plan.
Seems intuitive, of course, but in its written form, perhaps only 70 years old (only!) W. Edwards Deming gets most of the credit. Deming--working in Japan and else where in the mid-20th century--introduced very practical ideas of process control as a means to limit variations in product quality.

And, who's not all about product quality?

Deming was a product guy; he came at product quality from the point of view of the product:

Make the product the same way each time and make it work within limits that are acceptable to the customer. But, developing software is not a repetitive cycle (make it the same way each time) although processes are repetitive and they can be somewhat the same quality each time.

The modern poster child for defined process control is Six Sigma, but let's not go there; let's go to Agile

Agile Thinking
Ken Schwaber—a leading SCRUM methodologist—objecting to defined process control, puts it this way, “[defined process control] is based on processes that work only because their degree of imprecision is acceptable… When defined process control cannot be achieved because of the complexity of the intermediate activities; something called empirical process control has to be employed.”

In Schwaber’s view, software is too complex to expect defects to be contained within predefined error limits. Empirical control is the answer; empirical control is derived from observed facts, adapted to the situation, and not determined by preplanned limits from previous projects.

Edwards Deming's impact on agile projects
A project management tip: Deming introduced the PDCA cycle, which is can be wholly embraced by agile teams
• The cycle really applies to all agile iterations. The plan-do is equivalent to the planning session followed by development, test, and integration.
• Especially relevant is the check-act that provides measurement and feedback for continuous improvement.
• Deming focused on eliminating unsatisfactory results before they reached the customer. In agile parlance, every object must pass its unit, functional, and system test, and be acceptable to the customer's idea of quality in the large sense: function, accuracy, available, and appealing

http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, June 13, 2018

Of myth and mystique


I've always held that the key to power and influence is to have and maintain a certain mystique that provides some remoteness ( think: access control ), unpredictability, and mystery about the leader. (Too much familiarity reveals too many weaknesses, etc)

Now comes myth, to add to the mystique:
"In theory, if some holy book [perhaps the body-of-knowledge of the PMO] misrepresented reality, its disciples would sooner or later discover this, and the text’s authority would be undermined. Abraham Lincoln said you cannot deceive everybody all the time.

Well, that’s wishful thinking. In practice, the power of human cooperation networks depends on a delicate balance between truth and fiction. If you distort reality too much, it will weaken you, and you will not be able to compete against more clear-sighted rivals.

On the other hand, you cannot organise masses of people effectively without relying on some fictional myths. So if you stick to unalloyed reality, without mixing any fiction with it, few people will follow you. "
"Homo Deus: A Brief History of Tomorrow" 
by Yuval Noah Harari

Hmmm -- sounds like he's talking about the messaging required to motivate; the justification for certain means to achieve ends; and the fact that the truth -- unvarnished -- maybe unattractive. But, beware: as Harari says it's a delicate balance, with risk as the balancing element. Too much fiction, and you're not credible

But, consider this also from Mr Harari:
"... creating stable human hierarchies and mass-cooperation networks [is possible] as long as people believe [in the myth]

All large-scale human cooperation is ultimately based on our belief in imagined orders.

These are sets of rules that, despite existing only in our imagination, we believe to be as real and inviolable as gravity ..... making it easy to predict the behaviour of strangers and to organise mass-cooperation networks."


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, June 9, 2018

All all PMs capitalists?



Capitalism is not as popular as it once was. Nonetheless, it's still relevant.

We ask:
Are PMs all capitalists? Should we be? We could be: we work for money, and we spend other people's money (OPM) to drive outcomes, reaching for "success" all the time, and fearful of failure (consequence: we may not get another chance to be the leader)

But, do we have a conscience? Do we care what we are working on? If we were asked to build the first "bomb" would we do it for the science and engineering, and leave the policy and philosophy to others?

I've certainly had friends who've "opted out" of some programs. When I worked in the US DoD as a program manager, there things that gave me pause. Likely, most of us have paused at the juncture of capitalism and society at large.

McKinsey has a post on more or less this topic. Here's a thought that goes to the PM business:
Human creativity develops a variety of ways to solve ... problems, but some inevitably work better than others, and we need a process for sorting the wheat from the chaff. We also need a process for making good solutions widely available.

Capitalism is the mechanism by which these processes occur. It provides incentives for millions of problem-solving experiments to occur every day, provides competition to select the best solutions, and provides incentives and mechanisms for scaling up and making the best solutions available.

Meanwhile, it scales down or eliminates less successful ones. The great economist Joseph Schumpeter called this evolutionary process “creative destruction.”

The orthodox economic view holds that capitalism works because it is efficient. But in reality, capitalism’s great strength is its problem-solving creativity and effectiveness. [emphasis added] It is this creative effectiveness that by necessity makes it hugely inefficient and, like all evolutionary processes, inherently wasteful.

Capitalism inevitably leads to the dichotomy of "win-win" or "win-lose": Solve everyone's problems, but each less optimally; or solve one problem optimally and let the others suffer. Classic game theory! (See Chapter 12 of my latest book on Maximizing Project Value").

Clearly, as PMs we don't relish "pulling our punch" and serving up the less optimum knowingly.

McKinsey -- somewhat unhelpfully -- leaves us with this issue but no real solution:
.... the solutions capitalism produces are what creates real prosperity in people’s lives, and that the rate at which we create solutions is true economic growth, .... entrepreneurs and business leaders bear a major part of both the credit and the responsibility for creating societal prosperity.

But standard measures of business’s contribution—profits, growth rates, and shareholder value—are poor proxies. Businesses contribute to society by creating and making available products and services that improve people’s lives in tangible ways, while simultaneously providing employment that enables people to afford the products and services of other businesses. It sounds basic, and it is, but our economic theories and metrics don’t frame things this way
Here's another way to frame this that is familiar to PMs who read this blog: the focus of projects should be on outcomes first, inputs (like cost, schedule, specifications, shareholder value etc) second.

As "outcomists" we can be cognizant of the larger landscape. As "inputists" we can be responsible for being good stewards of resources. But, outcome dominates input... in my opinion.



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, June 5, 2018

"Off the cuff" is a better style


Every project manager speaks to groups in public... it goes with the territory. But, what happens if someone drops in unexpectedly and an off the cuff briefing or speech or speaking opportunity portends?

If this is not your strong suit, here's some worthy advice from John Coleman writing at the hbr.org network blog:
  1. Define a structure: The pressure of extemporaneous remarks comes from their ambiguity. What do I say? What do I not say? The worst and most stressful business speeches are those that ramble without purpose. In forensics we’d tackle this issue by quickly drafting a structure on a note card to support our main point — often an introduction, two or three supporting points, and a conclusion.
  1. Put the punchline first: When I worked in consulting, one of the cardinal rules of communication was “punchline first.” Any presentation should have a clear thesis stated up front so that listeners can easily follow and interpret the comments that follow.
  1. Remember your audience: All it takes is a few lines to make an audience feel acknowledged and a speech feel fresh. Tie the city in which you are speaking into your introduction. Draw parallels between the organization you’re addressing and one of the stories you tell. Mention someone by name, connecting them to the comments you’re offering.
  1. Memorize what to say, not how to say it: How many times have you practiced exactly how to say something in your head then frozen up or completely forgotten in the moment? The trick was this: We’d focus on memorizing key stories and statistics, rather than practicing our delivery. If you spend your time on how to say something perfectly, you’ll stumble through those phrasings
  1. Keep it short: Blaise Pascal once famously commented, “I have only made this letter rather long because I have not had time to make it shorter.” While it seems like the challenge of speaking with limited preparation would be finding enough to say, the opposite is often true. When at a loss for words, many of us underestimate the time we need — cramming in so many stories and points that we run well over our time and dilute our message. No one will appreciate your economy of words more than your listeners, so when in doubt, say less.


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, May 31, 2018

Some "$10 words" in Risk Management



When you get into risk management a bit, there are some biggies that get thrown around -- I call them $10 words -- and there are two that more or less divide risk management along the lines of
  1. The unknown that is possibly knowable with some legwork
  2. The unknown that is likely to remain unknowable
First case
For the first case, this is all about knowledge, the nature of knowledge, and how better to improve knowledge. Generally, this is called "epistemology" (ka-ching: $10 please) -- understanding the nature and scope of knowledge.

Risks that are subject to a better understanding by simply (I say simply, but often it's not simple) digging out more information are called "epistemic risks"

More simply yet, epistemic risks are those you can do something about -- they are actionable by nature of greater understanding and knowledge development.

In other words, epistemic risks are those for which the uncertainty can reduced -- if you spend the money to try.

And here's another opportunity to make $10: epistemic risks can be set in an organized framework of knowledge, said knowledge frameworks are called ontologies, and so epistemic risks are sometimes called ontological risks (OMG! this just gets better and better)

Second case
For the second case, it's all about the hidden, latent, unknowable (you may not find out what you don't know to ask, etc) that just happens by chance. For example, games of chance, like dice, you simply have no way of knowing what is going to come up next. There's no question you can ask to find out. And, the games are "memoryless" and thus independent; the former outcome has no bearing -- seemingly -- on the next outcome.

Such risks are called aleatoric risks, from the word aleatory meaning "related to random choice or outcome"

The good news, if there is any, is that aleatoric risks have probability distributions that is quantitative description of their random outcomes. If you can discover something about the distribution, you have something to work with re mitigating effects.

Operationally, you can't really reduce the uncertainty surrounding aleatoric risks, but you can immunize your project to the random or chance outcomes -- within limits of course -- by providing slack, buffers, redundancy, loose coupling, etc. In other words, to make the project less fragile and susceptible to the shock of a such a risk outcome.




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, May 28, 2018

Fixed price contracting and Agile



In my book, Project Management the Agile Way, now in its 2nd Edition, I make this statement in the chapter on contracts:

Firm Fixed Price (FFP) completion contracts are inappropriate for contracting agile.

I got an email from a reader challenging that assertion, to which  responded:

I always start by asserting that agile is a "fixed price" methodology. But, there is a big difference between a contract for your best effort at a fixed price, and a fixed price contract for working product, to wit: completion (agile manifesto objective)

There's no problem whatsoever in conveying best effort at fixed price through a contract mechanism; it's quite another thing to convey fixed price for a working product.

Agile is a methodology that honors the  plan-driven case for strategic intent and business value; but agile is also a methodology that is tactically changeable -- thus emergent in character -- re interpretation of the plan.


Using the definition that strategic intent is the intended discriminating difference to be attained in the "far" future that has business value, a project can be chartered to develop the product drivers for that discriminating difference. Thus,  think of agile as iterative tactically, and plan-driven strategically. The sponsor has control of the strategy; the customer has control of many of tactics.

Re FFP specifically, I was aiming my arguments primarily at the public sector community, and particularly the US federal acquisition protocols. The public sector -- federal or otherwise -- usually goes to a great deal of trouble to carefully prescribe contract relationships, and the means to monitor and control scope, cost, and schedule.

In particular, in the federal sector, only the "contracting officer" -- who is a legal person usually -- has the authority to accept a change in the written description of scope, a change in the cost obligated, or a change in the delivery schedule and location. The CO ordinarily has one or more official "representatives" (CORs) or technical representatives (COTRS) that are empowered to "interpret" changes, etc,

In the commercial business domain, the concepts of contract protocols are usually much more relaxed, starting with the whole concept of a CO and COR -- many businesses simply don't have a CO at all... just an executive that is empowered to sign a PO or a contract. Thus, there are many flexibilities afforded in the private sector not available to public sector

When I say "fixed price", in effect I am saying "not cost reimbursable". Cost reimbursable is quite common in science and technology contracts in the public sector, but almost never in the "IT" sector, public or private. So, I find that many IT execs have little understanding why you might write a contract for a contractor to take your money and not pledge completion.


Working from the perspective of "not cost reimbursable",  I make the point about a FFP completion contract as distinct from other forms of fixed price arrangements, like best effort. In my opinion, agile is not an appropriate methodology for a completion contract in the way in which I use the term, to wit: Pass me the money and I will "complete the work" you describe in the contract when we sign the deal.

However,  there are FP alternatives for a traditional completion effort, the best of the lot in my opinion being a FP framework within which each iteration being a separate and negotiated fixed scope and fixed price job order wherein the job order backlog is planned case by case.

However, even in such a JO arrangement, the customer is "not allowed" to trade or manage the backlog in such a way that the business case for the strategic value is compromised. The project narrative must be "stationary" (invariant to time or location of observation); although the JO nuts and bolts can be emergent.


Typically if the agile principle of persistent team structure is being followed, where the team metrics for throughput (velocity x time) are benchmarked, then the cost of a JO is almost the same every time -- plus or minus a SME or special tool -- and thus the "price" of the contract is "fixed" simply by limiting the number of JOs what will fit within the cost ceiling.


There are other factors which are vexing in the public sector in a FP contract arrangement:
1. Agile promotes a shift in allegiance from the specification being dominant to the customer needs/wants/priorities being dominate. Try telling a CO you are not going to honor the spec as the first precedence!

2. Following on from a shift in allegiance, what then is the contractual definition of "done". Is the project done when the money runs out (best effort); when the backlog is exhausted (all requirements satisfied); or the customer simply says "I've got what I want"? This debate drives the COs nuts.

3. How does a COTR verify and validate (V and V)? In the federal sector, V and V is almost a religion. But, what's to be validated? Typically, verify means everything that is supposed to be delivered got delivered; validated means it meets the quality standard of fitness for use. If the scope is continuously variable, what's to be verified? What do you tell the CO?

4. Can the "grand bargain" be contracted? I suggest a "grand bargain" between sponsor and PM (with customer's needs in the frame) wherein for a fixed investment and usually a fixed time frame the PM is charged with delivering the best value possible.

Best value is defined as the maximum scope (feature/function/performance) possible that conforms to the customer's urgency/need/want as determined iteratively (somewhat on the fly). Thus requirements are allowed to be driven (dependent) by customer's direction of urgency/need/want and available cost and schedule (independent).


Where the customer doesn't usually get a vote is on the non-functional requirements, especially those required to maintain certifications (like SEI level or ISO), compliance to certain regulations (particularly in safety, or some finance (SOx)), or certain internal standards (engineering or architecture)


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, May 24, 2018

About facts, one more time



My favorite expression about facts and estimates--given to me by Dr. David Hulett who was the PMI chair for PMP Chapter 11--is this one:
There are no facts about the future
Now, I see this one posted at Critical Uncertainties, attributed to Friedrich Nietzcshe:
There are no facts, only interpretations 

And, so what do we make of this ... particularly in our current era of "alternative facts"?

Begin here: set aside the idea of "alternative facts"; then consider:
It's all about bias -- we all have a biases, and thus can we ever say anything with true objectivity?

Well, yes, of course, there are immutable international standards for measurements; and measurements certainly make up a lot of "facts", though even here we find arguments about angels on the head of a pin (See Einstein, and the theories of relativity that demonstrate the flexibility of time and space)

And, of course, just put a measuring probe on some things changes them so much that we can't objectively measure them.

And then there is quantum physics with those theories of non-deterministic location; and entanglements that seem provide connectivity where there is none.

Should I go on?

Probably Nietzcshe had it right.



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, May 21, 2018

We don't do manifestos


I wrote this a couple of years ago; not much has changed:

You gotta love the first bullet from this conclusion by Stephen Welby, Deputy Assistant Secretary of Defense for Systems Engineering, speaking at the AFEI Agile for Government Summit, November 21, 2013

When he says in the 4th bullet point "upcoming revisions to 5000.2", he is referring to the DoD instruction for operation of the Defense acquisition system, revised in the fall of 2013, and then revised again in January, 2015.

This latest version of the instruction describes six models of how to acquire systems, the third of which, Model 3, describes an incremental methodology that is "agile" like. Of course, there are a lot of non-development swim lanes and pre- and post- tasks, as you would expect in an organization accustomed to working at large scale.

There are, of course, a myriad of "how to" acquisition guides for the program manager. Mitre, a DoD think tank contractor, has a decent acquisition guide written in 2014.


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, May 18, 2018

Ride a dead horse


A paraphrase:
The code of tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount. In the [project office], we often try other strategies with dead horses, including the following:
  • Buying a stronger whip;
  • Changing riders;
  • Saying things like ‘this is the way we’ve always ridden the horse;
  • Appointing a committee to study the horse;
  • Arranging a visit to other [PMOs] to see how they ride dead horses;
  • Increasing the standards to ride dead horses;
  • Declaring the horse is better, faster, cheaper dead; and finally 
  • Harnessing the dead horses together for increased speed 
Thomas Penfield Jackson


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, May 15, 2018

Distorted reality field


Imaginative innovation requires acceptance of a distorted reality field
Paraphrase of an observation and commentary by Walter Isaacson

"Distorted reality?
How does that fit with "we're all in this together"; committed scope-cost-schedule-quality; risk management; and "other people's money"?

When I think PMO, I think: Orthodox PM; rules; constraints; commitments; and all the rest
I'm not thinking "distorted reality"

But wait! How about "imagineering"? Disney has it; so could you! Just put the distorted realists off in their world, throw in money, delete for clarity (DFC) all bureaucracy; and sit back, but don't look down.

You might get the next big thing; you might get an Edsel.  




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, May 12, 2018

The essence of bureaucracy?


All projects of any scale are bureaucratic, meaning:
  •  there is some pecking order, 
  • some chain of decision making -- especially when there is "other people's money" funding the project -- and 
  • some means for assigning responsibilities (followed, consequentially, by measurements and accountability)
And so, I was struck by this passage which asserts the "essence of bureaucracy": (my emphasis added)
"... with writing all of [the project] minutiae are written somewhere, and the assemblage of relevant documents defines the identity and power of [the project office].

Writing has thus enabled humans to organise entire societies in an algorithmic fashion. ...  In illiterate societies people make all calculations and decisions in their heads.

In literate societies people are organised into networks, so that each person is only a small step in a huge algorithm, and it is the algorithm as a whole that makes the important decisions.

This is the essence of bureaucracy."
"Homo Deus: A Brief History of Tomorrow" 
by Yuval Noah Harari
In other words: The algorithm made me do 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

Friday, May 11, 2018

Observation and imagination


... in a nutshell, [this] was Lenonardo's signature talent: the ability to convey, by marrying observation with imagination, "not only the works of nature but also infinite things nature never created"
Walter Isaacson in his history "Lenonardo da Vinci"

And, how many of us have Lenonardo's instincts of observation -- on the one hand -- which are then drivers for something unimagined?
  • How would you handle a Lenonardo on your team? (Did I mention his total disregard for schedule; his somewhat arrogant approach to customers; and the fact he finished modestly few projects)
  • How does your stuffy project office handle the imagination thing, one might ask? (I'm sure observations are just fine in the PMO)
In an earlier posting on Leonardo, I quoted another historian:

Alas! This man will do nothing at all, since he is thinking of the end before he has made a beginning. ... In his imagination, he frequently formed enterprises so difficult and so subtle that they could not be realized and worthily executed by human hands. His conceptions were varied to infinity
On the other hand, speaking of ".... conceptions varied to infinity". Is that all bad?
  • Who knew we needed a smart phone before someone imagined it? 
  • And, thousands of other examples over history, probably going back to the bow and arrow -- and before (See: imagining ancient pyramids, and yes, some of them were used for grain storage to buffer bad harvests)



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, May 8, 2018

A grand bargin: Agile in the enterprise



In my book, Project Management the Agile Way, now in its second edition, I make this statement in the chapter on contracts:

Firm Fixed Price (FFP) completion contracts are inappropriate for contracting agile.

I got an email from a reader challenging that assertion, to which I responded:

I always start by asserting that agile is a "fixed price" methodology. But, there is a big difference between a contract for your best effort at a fixed price, and a fixed price contract for working product, to wit: "fixed scope completion"

There's no problem whatsoever in conveying best effort at fixed price through a contract mechanism; it's quite another thing to convey fixed price for a working product of fixed scope.

Agile is a methodology that honors the  plan-driven case for strategic intent and business value; but agile is also a methodology that is tactically changeable -- thus emergent in character -- re interpretation of the plan.


Using the definition that strategic intent is the intended discriminating difference to be attained in the "far" future, a project can be chartered to develop the product drivers for that discriminating difference. Thus,  think of agile as iterative tactically, and plan-driven strategically.

The sponsor has control of the strategy; the project team has control of many of the tactics.


Re FFP specifically, I was aiming my arguments primarily at the public sector community, and particularly the US federal acquisition protocols. The public sector -- federal or otherwise -- usually goes to a great deal of trouble to carefully prescribe contract relationships, and the means to monitor and control scope, cost, and schedule.

In particular, in the federal sector, only the "contracting officer" -- who is a legal person usually -- has the authority to accept a change in the written description of scope, a change in the cost obligated, or a change in the delivery schedule and location. The CO ordinarily has one or more official "representatives" (CORs) or technical representatives (COTRS) that are empowered to "interpret" changes, etc,

In the commercial business domain, the concepts of contract protocols are usually much more relaxed, starting with the whole concept of a CO and COR -- many businesses simply don't have a CO at all... just an executive that is empowered to sign a PO or a contract. Thus, there are many flexibilities afforded in the private sector not available to public sector

When I say "fixed price", in effect I am saying "not cost reimbursable". Cost reimbursable is quite common in science and technology contracts in the public sector, but almost never in the "IT" sector, public or private. So, I find that many IT execs have little understanding why you might write a contract for a contractor to take your money and not pledge completion of the original scope.


Working from the perspective of "not cost reimbursable",  I make the point about a FFP completion contract as distinct from other forms of fixed price arrangements, like best effort. In my opinion, agile is not an appropriate methodology for a completion contract in the way in which I use the term, to wit: Pass me the money and I will "complete the work" you describe in the contract when we sign the deal.

However,  there are FP alternatives for a traditional completion effort, the best of the lot in my opinion being a FP framework within which each iteration being a separate and negotiated fixed scope and fixed price job order wherein the job order backlog is planned case by case.

However, even in such a JO arrangement, the customer is "not allowed" to trade or manage the backlog in such a way that the business case for the strategic value is compromised. The project narrative must be "stationary" (invariant to time or location of observation); although the JO nuts and bolts can be emergent.


Typically if the agile principle of persistent team structure is being followed, where the team metrics for throughput (velocity x time) are benchmarked, then the cost of a JO is almost the same every time -- plus or minus a SME or special tool -- and thus the "price" of the contract is "fixed" simply by limiting the number of JOs what will fit within the cost ceiling.


There are other factors which are vexing in the public sector in a FP contract arrangement:
1. Agile promotes a shift in allegiance from the specification being dominant to the customer needs/wants/priorities being dominate. Try telling a CO you are not going to honor the spec as the first precedence!

2. Following on from a shift in allegiance, what then is the contractual definition of "done". Is the project done when the money runs out (best effort); when the backlog is exhausted (all requirements satisfied); or the customer simply says "I've got what I want"? This debate drives the COs nuts.

3. How does a COTR verify and validate (V and V)? In the federal sector, V and V is almost a religion. But, what's to be validated? Typically, verify means everything that is supposed to be delivered got delivered; validated means it meets the quality standard of fitness for use. If the scope is continuously variable, what's to be verified? What do you tell the CO?

4.  I suggest a "grand bargain" between sponsor and PM (with customer's needs in the frame) wherein for a fixed investment and usually a fixed time frame the PM is charged with delivering the best value possible. Can the "grand bargain" be contracted?  Sure, we usually call it "best value"

Best value is defined as the maximum scope (feature/function/performance) possible that conforms to the customer's urgency/need/want as determined iteratively (somewhat on the fly). Thus requirements are allowed to be driven (dependent) by customer's direction of urgency/need/want and available cost and schedule (independent).


Where the customer doesn't usually get a vote is on the non-functional requirements, especially those required to maintain certifications (like SEI level or ISO), compliance to certain regulations (particularly in safety, or some finance (SOx)), or certain internal standards (engineering or architecture)




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, May 4, 2018

Overfit v underfit


You've got data!

That's a good start. Now, working back to cause for these effects, what model fits the data? If you get the model right, you can forecast (gasp! estimate) what comes next.

You can make two errors, both of which could be costly, but one more than the other:
  1. Underfit the data. Meaning: a "too tight" fit such that some data fits very well, and other data not so well. The danger here is that the "good fit" stuff may actually be only a selection of outliers and ill effects. Thus, the real causation is missed
  2. Overfit the data. Meaning: a "too loose" fit such that too many ill effects and outliers are included and thus too many causations are possible and the model is too sloppy to be meaningful
Now, in practice, the "underfit" is most common. Why? Because with the tight fit it looks really good on a PowerPoint slide and thus wins the day in the briefing.

But, come reality, the underfit model breaks down, and the estimating naysayers say nay to estimating. Who can blame them?

... it may look superficially more impressive until then, claiming to make very accurate and newsworthy predictions and to represent an advance over previously applied techniques. This may make it easier to get the model published in an academic journal or to sell to a client, crowding out more honest models from the marketplace. But if the model is fitting noise, it has the potential to hurt the science."
"The Signal and the Noise: Why So Many Predictions Fail-but Some Don't" 
by Nate Silver


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, April 30, 2018

Uncertainty is non-negotiable


"Uncertainty is an essential and nonnegotiable part of a forecast. .... sometimes an honest and accurate expression of the uncertainty is what has the potential to save [big things].... However, there is another reason to quantify the uncertainty carefully and explicitly. It is essential to scientific progress, especially under Bayes’s theorem."
"The Signal and the Noise: Why So Many Predictions Fail-but Some Don't" 
by Nate Silver
Now, some say: "we don't estimate; we don't forecast".
Of course, that's nonsense. Everyone estimates, if even only in their head
  • How long will it take me to write this blog?
  • How long will it take me to go to lunch?
  • How long will it take me to do almost anything I can think of? 
But, Mr Silver leads all discussion of uncertainty, estimates, and forecasts around to Bayes Theorem, which can be laid out this way as a process:
  • Formulate an issue or question or hypothesis
  • Make an early guess as to outcome
  • Experiment to gather evidence as to whether or not the guess is reasonable
  • Re-formulate based on evidence -- or lack thereof
  • Repeat as necessary 
In fact, in another part of Silver's book, he says this -- a cautionary statement for project managers:
"In science, one rarely sees all the data point toward one precise conclusion. Real data is noisy—even if the theory is perfect, the strength of the signal will vary. And under Bayes’s theorem, no theory is perfect. Rather, it is a work in progress, always subject to further refinement and testing. This is what scientific skepticism is all about."
And, one last caution from author Silver -- which reinforces the ideas of the Bayes process and also makes the point -- often ignored or overlooked --  that there is often little enough data inside one-time projects to support textbook statistical approaches:
"As we have learned throughout this book, purely statistical approaches toward forecasting are ineffective at best when there is not a sufficient sample of data to work with." 


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

Saturday, April 21, 2018

Teamwork -- managing the white space



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

Inevitably, keeping the team together to promote cohesiveness raises the question: how to keep everyone busy all the time -- other than 'painting rocks' (which is the way the Army used to do it). In the popular vernacular of project management, keeping everyone productively busy means actively managing their downtime, aka 'white space', between and amongst their planned activities.

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

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

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.
  • Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
  • Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
  • So also bring in mock testing, special event prototyping, and, of course, that bane of all:
  • Maintenance of team records.
One big advantage of managing by teams: the cost is relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each. Of course, many PMs are NOT comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:
The cost of a project is not its value; in a "good project", value greatly exceeds cost
Here's the memo: Manage for value! (Oh!, did I say I wrote the book?)



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, April 18, 2018

The Project Balance Sheet




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!

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

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.


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, April 15, 2018

If you can't draw it, ..... (can you build it?)



Many creative people will tell you that new ideas begin -- often spontaneously -- with a mind's sketch that they then render in some kind of media.

Fair enough -- no news there. We've talked about storyboards, etc before.

But then the heavy lifting begins. How to fill in the details? Where to start?

My advice: Draw it first.
If you can't draw it, you can't build it!

And so the question is begged: What's "it"

Three elements:
  1. Narrative
  2. Architecture
  3. Network

And, one more for the PM:
  • Methodology

Digression: My nephew reminds me that now we have 3-D printing as a prototype "drawing" tool. Indeed, that's his job: creating 3-D prototypes.

Narrative: (an example)
Bridge stanchion with strain sensor and sensor software

Architecture:
Let's start drawing: Actually, I like drawing with boxes. Here's my model, beginning with the ubiquitous black box (anyone can draw this!):

Black Box


Of course, at this point there is not much you can do with this 100% opaque object, though we could assign a function to it like, for example: bridge stanchion (hardware) or order entry shopping cart (software)

And so given a function, it needs an interface (blue); some way to address it's functionality and to enable its behavior in a larger system context:


Interface


And then we add content (white):

Content


Except, not so fast! We need 'room' for stuff to happen, for the content to have elasticity for the unforeseen. And, so we add a buffer (grey) around the content, but inside the interface, thus completing the model:

  • Black: Boundary
  • Blue: Interface or API
  • Grey: Buffer
  • White: functional content


You could call this an architecture-driven approach and you would not be wrong:

1. First, come the boxes:
  • Define major functional "boxes"... what each box has to do, starting with the boundary (black): what's in/what's out. This step may take a lot of rearranging of things. Cards, notes, and other stories may be helpful in sorting the 'in' from the 'out'. If you've done affinity mapping, this boundary drill will be familiar.
  • Our example: three boxes consisting of (1) bridge stanchion (2) strain sensor (3) sensor software
Then comes the interface:
  • Then define the major way into and out of each box (interface, I/F, blue). If the interface is active, then: what does it do? and how do you get it to do it?
And then comes the "white box" detail:
  • The buffer, grey, captures exceptions or allows for performance variations. In effect, the buffer gives the content, white, some elasticity on its bounds.
  • And then there is the actual functional content, to include feature and performance.
Network

2. Second big step: networks of boxes

  • Think of the boxes as nodes on a network
  • Connect the 'black' boxes in a network. The connectors are the ways the boxes communicate with the system
  •  Define network protocols for the connectors: how the interfaces actually communicate and pass data and control among themselves. This step may lead to refactoring some of the interface functionality previously defined.
  • That gets you a high-level "network-of-boxes" . Note: Some would call the boxes "subsystems", and that's ok. The label doesn't change the architecture or the functionality.
3. Third big step: white box design.

Define all the other details for the 'white box' design. All the code, wiring, and nuts and bolts to build out the box.
  • Expect to refactor the network as the white box detail emerges
  • Expect to refactor the white box once development begins. See: agile methods
And, not last: Methodology:

The beauty of this model is that each box can have its own methodology, so long as interfaces (blue) and boundaries (black) are honored among all boxes. In other words, once the boundaries and interfaces are set, they are SET!

The methodology can then be chosen for the white box detail: perhaps Agile for the software and some form of traditional for the hardware. This heterogeneous methodology domain is workable so long as there is honor among methods:

Interfaces and boundaries are sacrosanct!

Now What?
Estimate the work (yes, estimate: you really can't start off spending other people's money without an estimate); segment and sequence the work; and then build it, deliver it, and you are DONE!


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, April 12, 2018

Friction -- a consequence of debt


And, so now we've all come to the point in the art and science of project management that not only do we have a myriad of biases that have been listed and explained and examined over the past 30 years, but now we have debts. The new one (for me) is social debt, as described by Philippe Kruchten


He tells us:
Damian Tamburri, from VU in Amsterdam, has introduced the notion of social debt, as a counter part of technical debt [ICSE2013 workshop].

Social debt is .... the accumulation over time of decisions about the way the development team (or community) communicates, collaborates and coordinates; in other words, decisions about the organizational structure, the process, the governance, the social interactions, or some elements inherited through the people: their knowledge, personality, working style, etc

Now, put social debt together with technical debt -- all the myriad of little things left undone -- and you get the idea of the friction in the project -- that is: impediments to velocity; inefficiencies in productivity. And, like friction in the physical world in which energy is wastefully converted to heat, only to dissipate without adding value, these debts absorb project energy.

So, what price -- actually, for the PM: cost -- is non-value-add of friction? First, friction spreads the tails of the Monte Carlo simulation of cost and schedule, and potentially shifts the mean cost and schedule to the right. Second, and certainly a root cause of the first point, friction holds back productivity and gives rise to lost energy (to overcome friction) and lower velocity (less throughput)

Fair enough. But, what do we do about it?
  • New project? Take a look at the history of overcoming debt and make adjustments to the knobs and switches of your project model
  • Got flexibility? Reorganize, retrain, change environment or tools, or add SMEs (or dismiss the high-friction nemesis)
  • On-going project? Rebaseline. That may cancel a lot of the social debt built up in the existing project. In effect: reboot
  • Risk management? Sure, think of both technical and social debt as a risk to be managed




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, April 9, 2018

One generation back


It's been a whole generation?




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, April 6, 2018

Expert forecasts, or not


More from Nate Silver:
"The more fundamental problem is that we have a demand for experts in our society but we don’t actually have that much of a demand for accurate forecasts.”

Could this be the issue? (Silver continues:)

"As [many] see it, [project] forecasters face three fundamental challenges.
  • First, it is very hard to determine cause and effect from [project] statistics alone.
  • Second, the [project circumstance] is always changing, so explanations of [project] behavior that hold in one [ ] cycle may not apply to future ones.
  • And third, as bad as their forecasts have been, the data that [project analysts] have to work with isn’t much good either."
Is this the justification for "no estimates?"

Nope, it's a caution about the real world. Other people with the money expect an estimate before work begins.

Have you ever had work done on your car or home without asking for an estimate? I hope your answer is No; and I hope you understand: stuff happens, even so.




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, April 3, 2018

Scale down, or "too small to succeed?"



What about scaling down?
Most of the posts I read are about scaling up to ever larger projects, but what about scaling down? What if you are doing bug fixes and small scale projects with just one or two people? Is a methodology of any help, and if you're working with software, can Agile be helpful scaled down?

To the first point, my answer is: Sure! A methodology -- which is just a repeated way of stringing practices together -- can help. Why invent the 'string' (methodology) each time you do something? Just follow the same practices in the same sequences each time. Thus, you can have a methodology for just driving your car... perhaps the ultimate team-of-one.

Small scale Agile
Re agile and small scale: Really, the agile manifesto does not inherently break down at small scale; nor do the agile principles. It's actually easier to go smaller than to go larger.

But, not so fast! What about:...
  • Teams and all the stuff about team work if you are only one or two people?
  • Pair programming?
  • Redundancy and multi-functionalism?
  • Collaboration and communication by osmosis with others?
Admittedly, you give up a few things in a team-of-one situation -- perhaps pair programming and redundancy -- but there's no reason to give up the other ideas of agile:
  • close coordination and collaboration with the customer/user
  • a focus on satisfying expectation over satisfying specification
  • quick turn around of usable product
  • personal commitment and accountability
  • collaboration with peers and SMEs on a frequent and informal basis
  • lean thinking
  • Kanban progression and accountability
Got redundancy?
The hardest thing to deal with in a too-small team is lack of redundancy -- or not being anti-fragile -- and lack of enough skill and experience to work over a large domain. It's pretty obvious that one person team has a single point failure: when you're away, the team is down. Such a failure mode may not tolerable to others; such a failure mode is obviously fragile, unable to absorb large shock without failing.

And, one person's experience only extends so far... thus limiting the domain and extent of possible solutions (leading, sometimes, to: "if all you have is a hammer, then everything is a nail" misuses and abuses of whatever your skill set is. I once had a person who was a loner and also an expert with MSAccess... no matter the problem, he seemed to solve it with Access!)

Management challenges
As managers we are responsible for making it work. So in the situation of really small teams, there can still be, and we should insist upon:
  • an opening narrative
  • a conversation about requirements and approach (to include architecture)
  • peer review by other experts
  • code inspections and commitment to standards
  • rotation of assignments among context to drive broadening
  • reflection and retrospective analysis



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, March 30, 2018

Eric vs Erica


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 -- CEO of Germany -- to  Meg Whitman -- CEO of HP Enterprises

Another study had people listen in to a business meeting where actors, Eric and Erica, among others, were discussing strategy, issues, business details, etc
  • Invariably, Eric was given high marks for leadership, even if the script for Erica 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




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