Budget wisdom

---

"Priorities aren't redal unless budgets reflect them"

CIA Director Burns

Of course, Director Burn's assertion is spot-on and another version of "show me the money", or perhaps sticking with the intelligence domain: "follow the money".

This whole idea is the bane of strategic planning in which long-term plans outrun the budget authority and even outrun the budget planning, in other words: a floating apex, unsupported by a pyramid of budgets.

Nonetheless, lightening could strike. Having an idea on the shelf is not all bad. But if it's technology, it has a half life measured in a year or two. So, a constant dusting to keep current is required. Who knows: the money might show up.

---

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

Gambling for resurrection

---

Your project is in trouble.

You've spent all the money and have little to show for it.

There's a decision to be made: Shut it down, or take a gamble on resurrection?

A gamble on resurrection is a financial theory about risk taking that posits taking on more risk or leverage in a hope that circumstances -- mostly beyond your control -- will turn favorably and bail you out. (When visiting casinos, I remind myself that the glitz and glamour was all paid for by losers; so there must be a lot of them, and they must lose a lot of money). 

A gamble on resurrection is also a management theory that posits inventing or prioritizing an unrelated event in order to divert attention from the problem at hand. (so called "wag the dog" tactic)

Leaving aside any management diversions -- which risk reputation and integrity-- the economic practices at a decision point about shutting down, or not, modify the gamble in these ways:

Sunk cost rule:

The usual PM rule invoked at this decision point is to ignore sunk cost because you can't do anything about it. Focus only on the future. Is there a viable plan or not? If not, shut it down. 

Moral hazard rule:

If the decision is to shut down, that can't be made without consequences of accountability, else there is a moral hazard created that failure has no cost. 

Of course, the degree of moral hazard is a function of whether or not the project was planned as a high-risk adventure with an anticipated high rate of failure. Such is the essence of the "fail fast; fail often" theory that drives extreme risk takers.

Deleverage rule:

When developing a go-forward resurrection plan, rather shutting it down, the usual planning doctrine is to actually take less risk than the risk that got you here. In other words, you "deleverage" the risk-to-reward ratio and plan more conservatively.

---

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

I've got a plan: nobody cares

---

It's so damn frustrating!

You spend a lot of time planning, coordinating, evaluating ....

And then it's D-Day, circumstances intervene, and nobody follows the plan 😮 

(Well, they follow bits and pieces, but the plan as such is almost unrecognizable)

That's a few sentences to say what we all know:

No plan survives the first touch with reality

So, if this is all too obvious, what is it you do?

• The first thing is to have a communication plan in hand before the execution begins so you can touch everyone you need to reliably and quickly. And this part of the plan should be bullet proof
• The second thing is to know in advance where all the decision makers are going to be and how they are to be reached; and what authorities they have.
  
  
• The third thing is to have supervision or tactical deciders in place where the work is being done to make the minute-to-minute decisions that might save the day. In other words, some decentralization of authority
• Another thing is to have redundancy built in, as well as time or cost buffers, to be able to override, or fill-in the low spots. In other words, a plan with no margin is really not viable from the git go. 
  
  
• If "it" fails this time, know when you are going to try again. Obviously, "failure" has to be obvious, measurable, without ambiguity, etc.
• And if "it" fails, have a lessons-learned exercise ready to go.
   
  
• The principle of "calculated risk" should be built-in: "When all matters are considered and weighted by value, the benefit of taking a risk should be (at least) strategically beneficial, even if not tactically beneficial (the battle was lost, but the engagement won the war)

---

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

Nobody follows the plan!

---

It's so damn frustrating!

You spend a lot of time planning, coordinating, evaluating ....

And then it's D-Day, circumstances intervene, and nobody follows the plan 😮 

(Well, they follow bits and pieces, but the plan as such is almost unrecognizable)

That's a few sentences to say what we all know:

No plan survives the first touch with reality

So, if this is all too obvious, what is it you do?

• The first thing is to have a communication plan in hand before the execution begins so you can touch everyone you need to reliably and quickly. And this part of the plan should be bullet proof
• The second thing is to know in advance where all the decision makers are going to be and how they are to be reached; and what authorities they have.
  
  
• The third thing is to have supervision or tactical deciders in place where the work is being done to make the minute-to-minute decisions that might save the day. In other words, some decentralization of authority
• Another thing is to have redundancy built in, as well as time or cost buffers, to be able to override, or fill-in the low spots. In other words, a plan with no margin is really not viable from the git go. 
  
  
• If "it" fails this time, know when you are going to try again. Obviously, "failure" has to be obvious, measurable, without ambiguity, etc.
• And if "it" fails, have a lessons-learned exercise ready to go.
   
  
• The principle of "calculated risk" should be built-in: "When all matters are considered and weighted by value, the benefit of taking a risk should be (at least) strategically beneficial, even if not tactically beneficial (the battle was lost, but the engagement won the war)

---

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

Be a sequentialist first; beware the accumulations!

---

I'm a sequentialist.

When planning a project, I think first about how to sequence the scope: do this first, then that. Or, do these things in parallel, followed by this or that.

MS Project, and similar tools, are the sequentialists go-to tool for planning sequences and establishing the sequential order of the project.

Not so fast!

What about cumulative, non-sequential, scope and effects?

For these, we need a cumulalist to help with the plan.

Accumulations of the cumulative

The obvious non-sequential scope is all the sundry overhead that descends on the project: HR stuff, regulatory requirements, environment maintenance, training, re-provisioning and refit, and on it goes.

 

But, stuff like that is all foreseeable, and to an extent, such requirements can be accounted for in the project plan.

 

Beware! Other things accumulate. Insidious accumulations aggregate to a cumulative effect on through-put, and thus cost and schedule, and perhaps even quality:

• General fatigue from the stress of solving problems and meeting deadlines
• Frustrations that mount up from dealing with the bureaucracy, other teams, outside consultants and contractors
• The weather (unless you live in paradise, like I do, in Florida)
  
• The pandemic 
• Network issues and connectivity constraints
• Security constraints and threats

Who's watching?

There are many sequentialists on every project, and in every sponsor organization, keeping watch on the march toward the final milestone. 

Fewer may be cumulalists keeping watch on the build-up of factors and effects that may have impacts on the progress of the sequence.

Beware the accumulation of cumulative effects!

 

 

---

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

Starving or stretching the Critical Path?

---

In project management school, the lesson on Critical Path includes Rule #2:

Apply resources first to the critical path, and subordinate demands of other paths to ensure the critical path is never starved.

But, of course, Rule #2 follows from Rule #1

Rule #1, if you haven't guessed is:
Create a schedule network so that the critical path is revealed.

But here's an issue: If you're only working with major milestones, then there are no network of dependencies, so there is no opportunity to apply something like Rule #1. It follows that there can be no Rule #2, and so no insight to schedule starvation. Yikes! 

No starvation, but a longer path?

Some of the time, Rule #2 has unintended consequences, like making the critical path longer! How does this happen?

The problem arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. Alas! The "parts" are not interchangeable. Mary and John are unique. Consideration must be given not only to the generic staffing profile for a task but also to the actual capabilities of real people.

Staffing and Schedule intersection

The intersection of the staffing plan with the schedule plan sometime brings up results that are not always as we want them. Intersection means overlap, and overlap means that the planning elements must be moved about so that each overlap is harmonious.

Take a look at the following figure for Rule #2: There are two tasks that are planned in parallel. If not for the resource requirements, these tasks would be independent, and if independent the critical path would be 50 days -- the length of Task 1. Task 2, as you can see, is only 20 days duration.

You can probably see that if not for the specific assignments of Mary and John, the critical path could be as short as 50 days, not 65 as shown.

Let's violate Rule #2 and invent Rule #3: Reorganize the network logic to take into account unique staffing applied to schedule tasks.

 

Using Rule #3, staffing does not actually start on what was the critical path, a violation of Rule #2. 

 

But the advantage of Rule #3 is that the overall schedule is shorter nonetheless. In this case, the critical path is only 55 days.

 

There is still inter-dependence among tasks. But a new critical path using Rule #3 more optimally incorporates the sequencing constraints of the original path and the staffing constraints brought about by Mary and John.

Here's the main idea to take away: 

Any lack of independence among tasks will stretch the path upon which those tasks are scheduled

---

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

Sequential vs Cumulative

---

I'm a sequentialist.

When planning a project, I think first about how to sequence the scope: do this first, then that. Or, do these things in parallel, followed by this or that.

MS Project, and similar tools, are the sequentialists go-to tool for planning sequences and establishing the sequential order of the project.

Not so fast!

What about cumulative, non-sequential, scope and effects?

For these, we need a cumulalist to help with the plan.

Accumulations of the cumulative

The obvious non-sequential scope is all the sundry overhead that descends on the project: HR stuff, regulatory requirements, environment maintenance, training, re-provisioning and refit, and on it goes.

 

But, that is all foreseeable, and to an extent, such overt actions can be accounted for in the plan.

 

Other things accumulate, leading to a cumulative effect on through-put, and thus cost and schedule, and perhaps even quality:

• General fatigue from the stress of solving problems and meeting deadlines
• Frustrations that mount up from dealing with the bureaucracy, other teams, outside consultants and contractors
• The weather (unless you live in paradise, like I do, in Florida)
  
• The pandemic 
• Network issues and connectivity constraints
• Security constraints and threats

There are many sequentialists on every project, and in every sponsor organization, keeping watch on the march toward the final milestone. 

Fewer may be cumulalists keeping watch on the build-up of factors and effects that may have impacts on the progress of the sequence.

Beware the accumulation of cumulative effects!

 

 

---

Buy them at any online book retailer!

Smart and Not-so-Smart

---

Harry’s poker-playing friend claimed that probability theory, and how to play your cards according to the rule book, was the easiest thing in the world.

But what separated smart players from the not-so-smart was the ability to understand how their opponent was thinking ...

Harry Hole, Detective,
according to author Jo Nesbo

Now, in project terms, we would like to think we don't have to worry about opponents. But, of course, that's not the case. Most practical projects at scale have a nemesis, either technical, managerial, or political.

Also, it would be great if we could all grasp "Game Theory" which lays out methodologies for assessing what your opponent is likely to do in the context of what you might be likely to do. [You can read some about this in Chapter 12 of my book, cover illustration below, "Maximizing Project Value"]

In effect "Game Theory" combines probabilities, rules for applying game rules, and methodologies for  making an 'informed estimate' of what others might do.

Stability and equilibrium
If you are working with probability theory in your project, then you are thinking and acting with some uncertainty in mind. As our detective friend says in the opening quote, just understanding some of the 'rules' around uncertainty estimates is not enough.

Coming to some sort of stable (and predictable) position in the project environment is perhaps the most advantageous outcome one could expect in an environment of uncertainty. 

 Perhaps the most practical utility of Game Theory, as applied to projects, is developing equilibrium as a stable and desirable outcome. Odd as it sounds, equilibrium is often achieved by accepting a sub-optimum outcome as a compromise outcome between 'adversaries'. 

And why would you settle for sub-optimum? You settle because the alternative is more costly without compensating benefit.

The "Nash Equilibrium" 

The Nash Equilibrium is an example of such an outcome, and it is explained in Chapter 12. In essence, you and your opponent agree to a compromise plan for which their is no net upside for either of you to divert from the plan. In other words, at the Nash Equilibrium, things are worse for you (and your adversary) if either of you make a change.

The counterpoint is obvious: as long as there are incentives for a more advantageous deal, stability will always be on the knife's edge. Recognizing whether or not you've achieved a Nash Equilibrium may be the smartest thing you can do.

---

Buy them at any online book retailer!

Plan v Objective

---

"In war [projects] nothing goes according to plan, but always remember your objective"

Israeli general

Good advice.

And, of course, your objective always is -- or always should be:

Apply your resources to maximize their value added while taking the least risk to do so.

But our general's admonition begs the question:

Is "nothing goes according to plan" the same as there's "no value in planning"? And, if so, why plan in the first place? Why not maximize agility?

Or, why not be Bayesian about it: Make an educated guess to begin, and then replan with new information or circumstances?

The usual answer

The usual answer to those questions is that the value of the plan is in the planning, that is: discovering one or more paths to victory! One or more ways to accomplish the objective.

And, if there is more than one way to get there, then whatever plan is adopted is not totally fragile; an alternative is available if things go really wrong.

That all said, planning is about doing these tasks and investing intellectually in their development:

• Establishing the scope detail that fills out the objective .... or narrative
• Anticipating the risks and devising mitigations .... or not (some risks can be ignored)
  
• Assembling resources; training staff and robots [AI is in the training frame these days]
• Establishing a sequence for doing the work
  

Such that, when the plan goes awry, it can be reconfigured -- perhaps on the fly -- and re-baselined, always with the most strategic objective in mind.

And, did I mention that the foregoing is Bayes-style planning methodology: always update your first estimate with new information, even it makes the first estimate look a bit foolish or optimistic

Yogi said:

Yogi said a lot of things, but he said this that seems to apply:

"If you don't know where you are going, you may be disappointed when you get there."

In our business, you might write it thus:

"If you don't [or won't] plan what you are going to do, you may be disappointed in what you wind up doing"

And, you might miss the objective altogether. You spent all the money -- presumably other people's money [OPM] and you didn't do the job! [That's usually a challenge to your career]

---

Buy them at any online book retailer!

Plans and improvisation

---

"As they say ... the best-thought-out battle plans fall apart as soon as the first shot is fired.
Then you improvise"
"Unless that first shot went through your head!"

Dialogue from Nelson DeMille's novel "The Deserter" 

---

Buy them at any online book retailer!

If you can't draw 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 materials 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!

---

Buy them at any online book retailer!

Getting it done

---

"Others may have plans; I have deadlines"

Amy Klobuchar

 Senator

This sentiment has been expressed in other forms, most famously by many:

• Plans don't survive first touch with reality
• Plans are nothing; planning is everything

The big idea:
Plans are the process; outcomes are the value.

Manage with milestones
Detail planning is good -- it brings out the interdependencies and sequencing demands. But such attention to detail is inefficient, even counter-productive during execution. Much more better in my experience to manage to milestones, which is, in effect, "managing to deadlines".
 
The point of projects is to create value. 
Ultimately, the plan is project detritus; the outcome is the only lasting memorial to success

---

Buy them at any online book retailer!

Plan A (or B, C, D)

---

There is always Plan A: "Do nothing"

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

So, presume there is always Plan A, and good management principles say: there should be a Plan B

• What about Plan C or D? Shouldn't decision makers always have alternatives to consider? Why be narrow? 
• More important: why be self-delusional that there is "no other choice". No other choice, is, in a word: nonsense!

And, if you've decided on Plan A or B, and along comes the possibility of C or D with greater cost/benefit, can you change you mind and still be "strong and confident"?

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

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Ratios! Some good; some evil

---

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

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

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

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

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

What's the fix?.

Personally, I prefer these metrics, none of which are ratios. And, why do I like this set of non-ratio? Because there is a good mix of "input" which is always of concern to the PM and the sponsors, and "output" which is always of concern to users and customers, and is the value generator for the business. Thus, this set keeps an eye on both the input and the output.

Backlog

• Objects planned, or baseline (input)
• Objects completed (output)
• Objects abandoned (unnecessary requirement or deferred)
• Objects added (new)
• Objects remaining (output)
• Objects variance (baseline - outputs)

Resources

• Budgeted consumption (input)
• Budgeted usage (input)
• Resource remaining (output)
• Resource at completion (usage + output)
• Variance (consumption - completion)

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

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

Read my contribution to the Flashblog

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!

Read my contribution to the Flashblog

Can agile teams be virtual?

---

Somebody asked: can a virtual team do Agile?

• 15 years ago, the answer might have been no. 
• Seven years ago, more less pre smart phone and smart-phone networking, the answer was probably yes, but with reservations. 
• Now, the answer is "Of course", with some adjustments. 

Here are my thoughts on this.

The communications channel:

Virtual teams often begin by emulating the behavior and circumstances of real teams. But can they?

The first thought is communications. Real teams can handle a much greater N2 communication intensity because much communication is person-to-person, and much of person-to-person communication is non-verbal.

What is N2? It's really N-squared. It's the approximate number of ways objects can communicate. The real formula is N(N-1). There are 5*4 ways 5 people can talk among themselves.

Non-verbal face-to-face is a very high bandwidth channel -- speed of light really -- capable of communicating a large information message instantly, although the messages are often highly encoded and subject to inaccurate decoding among strangers or nearly strangers. Nonetheless, it's much easier to sort out the cacophony of discussion if you can put face and voice and context together. (Anyone who's participated in a large video conference knows the difficulty of segregating voices and getting them associated correctly)

Consequently, when planning for virtual teams, bear in mind that virtual teams don't have the luxury of infinite bandwidth. Even with up to date video, the non-verbal is communicated in a lossy channel. And here's the thing: you don't know how much is lost. Thus, more time is needed in the schedule to compensate for the bandwidth constraints.

Velocity impacts:

Some teams relish the hub-bub of real time communications, and others do not. Good practice is to benchmark the virtual velocity before beginning the first iteration. Look for virtual velocity to be slower, and productivity less. 

Perhaps the virtual team needs to be larger, or given smaller bites to work on. (Ooops: Adding people to a slow team makes it slower ... Read: "The Mythical Man month, 20th anniversary edition")


Assigning team work:

Assigning work to virtual teams should follow this simple rule: partition work according to its natural boundaries that minimize and simplify interfaces.

Albert Einstein has been quoted to the effect: "Make everything as simple as possible, but not too simple".

But over simplification is hazardous also. Who's got the "big picture" in mind? The solution can lose cohesion and the bigger picture becomes so obscured that effective solutions are not possible to build from the too-small parts.

Iteration Planning and tracking:

The iteration planning meeting is the agile mechanism for assigning work. All the team's complement attends. The same applies to a virtual team.

Tracking progress and identifying problems:

Only the daily stand-up meeting is affected by the communications unique to virtual teams. The less efficient electronic channels may have to be compensated by extending the time-box of the daily stand-up.

The burn-down and trending data is part of the team scorecard posted electronically as opposed to marking a whiteboard in a team space.

I end where I started:  "Of course", with some adjustments.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Illuminating the path

---

Here below I shamelessly reprint a posting from herdingcats.
Why? Because Glen's point about the purpose of plans is to illuminate possibilities; not to constrain critical thinking, common sense, and accommodation for changing facts, is profound.  Everyone who practices project management or team management should understand that.

From herding cats:

In the space of two days I had evolved two plans, wholly distinct, both of which were equally feasible. The point I am trying to bring out is that one does not plan and then try to make circumstances fit those plans. One tries to make plans fit the circumstances 

George Patton

General, U.S. Army

"Any suggestion that plans and planning are not part of project management, no matter the approach - agile or traditional - wilfully ignores the purpose of a plan. That purpose is not the force the team to follow a path, but to illuminate the possible paths that can be followed to reach the goal."

end quote (emphasis added)

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Protect the most valuable milestone

---

Want a happy client? (Who doesn't?)

• Don't be late!

Which means: establish -- mutually -- the most valuable milestone (as seen by the client) and then ... protect it! How? with a buffer.

The buffer is unscheduled time used to capture the unforeseen overflow of work from the backlog, or to work off essential debt collected along the way. The buffer placed as shown should remove most of the uncertainty from the time-delivery of the milestone content -- backlog worked down to "done".

Procrastination
Here's the most egregious violation of the simple buffered-milestone idea:

There's a buffer, as required by the project planning policy...  but it's in the wrong place.

• It sets up a "latest start" (planned procrastination)
• It provides no value to the ensuing backlog. 
• The most valuable milestone is unprotected. 
• You can pretty much bet that milestone is at risk.

 Squandering the buffer time with procrastination is the worst planning and execution error in risk management. Only an uninformed or unenlightened manager would do that

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

No plan .... no worry!

---

Planning is an unnatural process, it’s much more fun to get on with it. The real benefit of not planning is that failure comes as a complete surprise and is not preceded by months of worry.
‒ Sir John Harvey Jones

My thanks to herdingcats for posting that bit of insight where I could find it.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog