The innovators' lament ....

---

Recently heard: this lament from IT innovation workers:

[We] encounter ironclad corporate hierarchies and resistance to change, a paradox in [our] industry that thrives on innovation and risk-taking.

"They" want things in a particular order; they want case studies and past experience. IT doesn't work like that. There is no past experience. We have to reinvent ourselves every day.

As reported by Joseph Coleman

Golly! I think the corporate masters must have missed the Agile memo. 

They may also have missed some principles of risk management in the context of 'new to the world' development, to wit: 

Some things never work out; some things are a home run. Setting artful limits to the balance sheet is the key skill if you aren't willing to bet the business.

On the other hand .....

There's a case to made for a business case, even in the context of Agile methods. 

Unless you are spending your own money, you have an obligation to the financier to show some respect and responsibility for the funds they are providing, even if you keep overrunning and going back for more. In effect, "innovation" never met a budget it couldn't bust!

---

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

Teamwork: managing the whitespace

---

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

Don't let idle ruin cohesiveness

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 theory it's simple: keeping everyone productively busy means actively managing their downtime, aka the 'white space', between and amongst their planned activities.

White space and the matrix

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.

Backlog and whitespace

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.

Running cost of teams

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 as judged by users and customers greatly exceeds cost

Here's the memo: Manage for value! (Oh!, did I say I wrote the book?)

---

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

Are you accountable?

---

Are you accountable?

Most of us want to answer 'yes, of course!'; how could it be otherwise? 

Most of us would endorse these ideas:

I'm always accountable for what I do. 

I'm accountable for that which I am responsible.

(Subtext: this can only be true if my personal integrity does not allow me to push blame on to others for failures and missteps, or claim false credit for what others actually did)

Accountability attaches credit and blame.

In popular culture, it seems to be more about attaching blame: A common refrain: "Who's to be held accountable for this!?"

Actually, being accountable means accepting blame or consequences when valid, but also stepping up and accepting accolades when earned.

I like this from Henry Evans, the author of Winning with Accountability, who says accountability is “clear commitments that in the eyes of others have been kept.”

Evans has set the frame: the final judgment about accountability is with others. 

In this sense, the concept of personal accountability is somewhat of an "earned value" idea: 

• You have a 'planned' set of responsibilities to get things done.
• You 'earn' accolades or consequences as you account for your actions
• Others judge the earnings and apply the credit or debit

Thus, in all schemes of accountability, you have a part to play: It's on you to commit to your responsibilities. So, even though Evans' statement is not explicit about being responsible, the holistic idea of accountability stemming from commitment embraces responsibility.

But what I don't like about Evans' statement is that it could be interpreted as requiring 'achievement' (in the sense of a commitment kept) when, of course successful achievement is not a requirement for accountability. Only a commitment to execute responsibly is.

And so in the context I've laid out it's common to encounter these questions:

• What is accountability, or what is it to be accountable?
• Can there be accountability without responsibility?
• Can there be responsibility without accountability?
• Are you given accountability, or do you grab it and take it on?
• Is the apex of the pyramid always accountable for anything down in the pyramid? (See: Captain of the ship is accountable ..... )

I don't want to dig too much more deeply into the psychology of 'accountability', and realistically that would be a fools' errand because project and business culture drive a lot of the answers to the questions above.

So, without making a big thing out of the answers, I'll offer my thinking here:

• As Evans puts it, accountability is about taking personal responsibility for outcomes: "I got this!" "I'm the one you can count on to get it done" "I will be there to see it through". All statements of commitment.
  And with Tom Petty in mind: "I won't back down!".
  
  
• The accountability/responsibility questions are ageless; they've been around since forever! The usual answer is: 'If you want me to be accountable for outcomes, then give me the responsibility for plans and resources. If you crater my plan and matrix out my resources, then you're accountable and not me!
  
  
• If you're not the apex (most senior executive) of the pyramid, you might be 'assigned' accountability: 'This is your mission and no one else's;  go get it done, and tell me when you're finished'.
  
  Actually, if you're low to mid in the pyramid, there's probably a backup to you. If it's a big pyramid, you may be an interchangeable cog in the mechanism. Nonetheless, grab it and go!
  
  
• Most of time, 'seniors' are always happy to have accountability 'grabbers' in the mix. It makes it easier to allocate the mission requirements. And, you may quickly earn and retain the leadership label.
  
  But the 'grabbers' are sometimes seen as more interested in climbing the ladder than actually advancing the mission. So, some balance of eagerness and opportunity is required.
  
  
• Traditionally, the 'apex' is accountable for the performance of everything done in the name of the pyramid. This is accountability without personal responsibility for outcomes. The "commitment" embedded in the concept of accountability is interpreted as 'committed to ensuring a responsible person is found, assigned, and expectations for outcomes established".
  
  In the military particularly, and certainly on ships at sea, this idea is deep culture.
  
  But, that idea often gets lost. One chief executive famously said that success has many fathers, but a failure is an orphan.
  
  Worse is the chief executive who denies accountability for all but successes. That is morally corrupt and a morale killer.

---

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

How many ways to say "Cost"?

---

How many ways are there to say "Cost"?

Certainly, more than one!

When "they" ask: 'How do YOU manage cost?", your answer is: 'It's complicated' because there are so many varieties of 'cost'.

Project managers certainly have at least this list:

• Estimated cost (of course, an estimate has to be made in the context of a plan: scope and schedule and resource plans)
• Baseline cost (estimated cost at the beginning of a planned period)
• Re-baseline (Sunk cost, plus a "new" estimate for the ensuing period)
• Cost variance (the difference or departure of actual cost from the baseline)
  
  
• Planned value (baseline cost input to the project, over time, allocated to planned functional or feature achievement)
• Earned value (as a proportion of Planned Value actually completed)
• Cost performance Index (as a 'cost efficiency' measure of how well cost input earns value)
  
  
• Actual cost (measured at a point in time, regardless of achievement)
• Sunk cost (aka actual cost incurred)
• Direct cost (costs attributed to this project, and this project only)
• Indirect or overhead cost (common costs shared across many projects, proportionally)
  
  
• Labor cost (a component of direct cost; does not include overhead labor)
• Standard cost (used by service organizations and Time & Materials proposals to 'fix' or standardize the "labor cost by category" to a single dollar figure within a range of costs for that labor category. *)
• Material and contracted services cost
  
  
• Throughput cost (only that part of direct cost required to actually construct value outcomes; often used in combination with Standard Cost)
• Construction cost (aka Throughput cost, but sometimes also total of direct costs)
  
  
• Incentive cost (paid as direct payments to individuals and contractors for specific performance achievements)

Finance, accounting, and business management have a few more:

• General and Administrative cost (G&A), mostly for "top-level headquarters" expenses
• Marginal cost (cost of one more item that does not require more of 'something else' to enable)
• Cost margin (difference between cost of sales and revenue associated with those costs)
  
  
• Discounted cost (cost after a reserve for risk, usually calculated over time)
• Depreciated cost (cost accumulated over time, as different from cost in the moment)
• Cost of sales (direct cost to generate sales)
  
  
• Activity Based Costing [ABC] Overhead costs allocated to specific activity, plus direct costs of the activity.

---------------------------------

(*) Standard Cost: As an example, for Labor Category 1, the salaries may range from $1 to $10, but the Standard Cost for this category may be $7 because most in this category have salaries toward the upper end. Standard Cost is not necessarily an arithmetic average within the category; it is a weighted average

---

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

Utility maximalist

---

Is your instinct to be a 'utility maximalist'?

If so, you are someone who wants to ring every dollar of functional effectiveness out of every dollar spent.

And why not?

Is the alternative just a waste of money?

About Utility

Utility, for this discussion, is the value placed on a functionality or feature or outcome compared to its actual cost input. 

Ideally, you would want more utility value than cost input, or at worst, 1:1. But sometimes, it goes wrong, and you get way less out than you put in. (*)

Show me the money

Here's the rub: Utility value is not always monetized, and not always monetized in conventional ways, though the cost input certainly is. So because utility usually has subjective components ... in the  eye of the beholder, as it were .... utility value often comes down to what someone is willing to pay.

As a PM, you can certainly budget for cost input

But you may have to take in a lot from marketing, sales, architects, and stylists about how to spread that cost to maximize utility and thereby maximize the business value of each input dollar spent. 

Kano is instructive

If you are a utility maximalist, you may find yourself pushing back on spending project dollars on "frills" and "style".

 

If so, there is something to be learned by by grabing a "Kano Chart" and looking at the curves. They are utility curves. They range from a utility of "1" (cost input and value output are equal) to something approaching an exponential of value over cost. 

The point is: investing in the "ah-hah!" by investing in the utility of a feature or a function will pay business benefits.

Art, beauty, and other stuff

Utility brings in art, beauty, and non-functionality in architecture, appearance, and appeal. Some call it "value in the large sense", or perhaps "quality in the large sense".

But utility also brings in personality, tolerance, and other human factors considerations

Utility maximalist leadership

It's not all about style, feature, and function.

Some leadership styles are "utility maximalist"

• Short meetings
• No PowerPoint
• Bullets (like these!) over prose
• Short paragraphs; one page
• Impersonal communications (social media, email, text)
• No 'water cooler' chat

Wow! Where's the 'art' in that list? Not much collegiality there. How do innovation and radical ideas break through?

How effective can that culture be across and down the organization (yes, some organizations have hierarchy)

On the other hand ....

• Tough decisions with significant personnel and business impacts may be more effectively made with high utility
• High utility does not rule out an effective leader soliciting and accepting alternatives. 
• High utility does not mean bubble isolation; that's more about insecurity. 

But high utility in management does mean that you give (or receive) broad directives, strategic goals, resources commensurate with value, and authority. The rest is all tactics. Get on with it! 

 

_________________________________

(*) The classic illustration of utility is the comparison of the poor person and the wealthy person. Both have $10 in their pocket. The utility of $10 is much greater for the poorer person. In other words, the value of $10 is not a constant. Its value is situational. There are mostly no linear equations in a system of utility value.

And for the 'earned value' enthusiast, utility is not a measure of EV. In the EV system, all $ values have a utility of 1; value is a constant. And all equations are linear. 

For instance, the cost performance index, CPI, is a monetized ratio of the intended (planned) cost input and the actual cost realized, where "value" is held constant. 

EV is that part of the value to be obtained by the intended cost that can be considered completed or achieved at the point of examination.

---

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!

Influence and discriminating factors

---

When it's OPM -- other people's money -- the client gets to make the priority judgments.
I call them "influencers and discriminators" In this table, you'll find commentary that defines or explains the five influencers.

Influencer	Commentary
Resources	Money, staff, infrastructure, intellectual property or access Real, virtual, remote, dedicated or shared
Time	Calendar, duration, milestones, value-add points
Scope	Client deliverables; business deliverables; project debris Agile CUD: create, update, delete agility
Quality	Fitness to use; fitness to standards; fitness to “best value”
Risk	Risk to the client; risk to the business. Impact and likelihood. Black swan effects Anti-fragile

A typical priority set might be as shown below. Best use of resources and attention to quality rank highest in this example. But there are other situations. Read on to the next charts

So, here's how this might look if schedule were all important. Sometimes, if you miss a milestone, you've missed the entire reason-for-being of the project. In that case, schedule has to stand out above all others.

Or, maybe it's cost management. If you're in the public sector spending the taxpayers' money, then it is often the case that resource management rises to the top, as in the chart below.

From a contracting perspective, you open the envelope and pick the "least cost that's technically acceptable". Sometimes that's a bit harsh because long-standing relationships might get tossed, but when cost is the standout, and all proposals are otherwise acceptable, then pick the lowest cost.

---

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

Avoid 'this' scheduling mistake

---

'The mistake' to avoid in scheduling is to construct a milestone-success situation that strictly depends upon two or more tasks scheduled (planned) to finish at the same time.

So, what's the big error here?

• First, as regards milestone success, each of the tasks leading into the milestone is a risk to success (success means: it is achieved on time)
• Second, total risk is the product of all the input risks (as seen by the milestone) . 
• So, whereas each task coming into the milestone may not be too risky, say by example 90/10 (*), three tasks of 90/10 each would present a risk to the milestone such that success is reduced to about 73/27 (**)

What are you going to do about this?

Bring on the time buffers! (***)

• You might be able to add a buffer on one or more of the input tasks to raise the success of that task to 99/01, or so
• You might be able to add a buffer following the milestone, such that any late success is absorbed by the buffer (This tactic is called "shift right" by schedule architects)

Reconsider the schedule architecture

• You might be able to reorganize the schedule to eliminate this milestone
• You might be able to shift resources, activities, or other criteria to change the properties of the milestone

What if there are common vulnerabilities among the tasks?

• Common vulnerabilities means the tasks are really not independent; there are couplings between them.
• The "math" of independent events, as given in the footnote below, is less accurate.
• Generally, the 'tail' situations are more prominent, meaning the central tendency around the most probable finish time "smears" out a bit, and thus possibilities further from the central figure are more prominent.

----------------------

(*) 90 successes out of 100, or 90% chance the task will finish on time, or early.

(**) Here's a footnote to those estimates: It's assumed the two tasks are independent, meaning:

• They don't share resources
• They don't have the same vulnerabilities to a common risk
• The progress, or not, in one does not affect progress in the other

(***) A scheduled event of zero scope, but a specific amount of time, aka: a zero-scope time box.

---

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

A flat project no more?

---

, 
The world was flat, but perhaps no more.

The same applies to projects.

In the flat system, we have these properties:

• There is no "place". Anybody and anything can be anywhere that there is connectivity
• Capital flows (largely 'cost' in the project world) are nearly borderless. They are quick, inexpensive transactions that can move the money to the cost center at a stroke
• Cost centers locate to the most efficient areas, and such searches for cost effectiveness can be somewhat dynamic
• Insofar as components have to have some 'national identity', assembly or manufacturing is "colored" by these requirements.
• Supply chains (actually, not a chain but a mesh of nodes and links) link everything; nodes and links are optimized to provide maximum efficiency and fault resistance.
• Supply, manufacturing, and assembly are anti-hierarchical. They are borderless-flat
• The 'US dollar' is supreme, and safe; everybody trades relative to the dollar.
• Labor is somewhat fungible. There are trained workforces, of course, but similar workforces are interchangeable.
• Labor loyalty is weak; labor moves around, seeking maximum return on personal interests
• Risks are global in their spread

The Covid crises emphasized many of these properties. 

But, as they say: 'Covid is over' (except perhaps in China)

Now, in the post-Covid world we see also some counter-forces to the flat world, and by extension, the flat project:

• Return to the office
• Dress the part
• Work reasonable hours; rebalance work and off-work
• Be a team player, less of an individualist
• Set up borders and boundaries to 'contain' activity within a physical sphere or economic or national zone, as it were
• Contain risks to the home front
• Promote loyalty
• Keep the money at home
• Pay more as a cost input, but also expect the customer to pay more to the top line in the name of 'buy local'

If you see this coming, you may want to rebaseline for less flatness!

---

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

A leadership doctrine

---

When applying the principle of "calculated risk", leaders should pick subordinates with the intellectual subtlety to evalutate strategic and operational problems in their full context.

They should be given the latitude to judge just how much risk is appropriate given the value of the objective and the balance of resources.

Paraphrased from the writings of historian
Craig L. Symonds

---

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

Layoffs in the middle of your project?!

---

Well, talk about cratering a schedule and resource plan!

Layoffs in the middle of a project will do it for you.

But wait!

There may be a silver lining here:

• Communication complexity in and among project participants decreases as the square of participants. That could be a winner
  
  
• You may be able to select the departees. That's tough in any circumstance, but it's also an opportunity to prune the lesser performers.
  
  
• Some say that if you want to speed up a project, especially software, reduce the number of people involved (the corollary is more often cited: adding people to a team may actually slow it down)
  
  
• There's an opportunity to rebaseline: All the variances-to-date are collected and stored with the expiring baseline. A new plan according to the new resource availability becomes a new baseline. Unfavorable circumstances can perhaps be sidestepped.

Of course, there are downsides:

• If your customer is external, they may not relent on any requirements. You're stuck trying to make five pounds fit in a three pound bag.
  
  
• There may be penalties written in your project contract if you miss a milestone, or overrun a budget. That just adds to the fiscal pain that probably was the triggering factor for layoffs.

Did you see this layoff thing coming?

• On the project balance sheet, you are the risk manager at the end of the day. So, suck it up!
  
  
• And there's the anti-fragile thing: build in redundancy, schedule and budget buffers, and outright alternatives from the git-go. And, if you didn't do those things in the first baseline, you've got a second bite at the apple with the recovery baseline.

---

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

Buffer your sponsor expectations

---

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

Take a look at this figure:

What have we got here?

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

First, the left side
On the left side of the balance sheet is the sponsor's investment in the project. Investment need not be all monetized, and it need not be all tangible. Sometimes 'good will' -- the accountant's name for the intangible gut feeling that this thing is worth more than book value (market-valued assets) -- counts for a lot. (Think: sponsor commitment, even when the going gets tough)

'Yours' simply means it's resources and commitments owned and given by others to the project. It's the 'your's side of the balance sheet that's somewhat akin to the right side of the financial balance sheet (money owed to creditors and money invested by owners).

Then, the right side
On the right side is the 'mine' side of the project balance sheet, akin to the left side of the financial accounting sheet (assets of the enterprise). The right side is the project side:

• Estimates and evaluations of the project manager
• Uses for the investment and resources to be entrusted to the project manage -- in effect deliverables and other artifacts, and perhaps some intangibles as well*

All about facts
 And, take note: the left side, the sponsor's side, is the fact-free zone: it's a top down allocation of resources to the vision. It is the ultimate utility expression of the sponsors: what's valuable, and how valuable, even if not entirely objective.

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

The gap (and the buffer)
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. 

Ah! But the gap is also a buffer between the project facts and the limits imposed top-down by the sponsor. Like all buffers, it's designed to absorb shocks and unknowns on the project side that might drive actuals above the plan. 

And how large is the gap (risk) buffer? Only as large as needed to create a balance--that is, a deal with the devil--so that the project can go forward, and only so large as needed to absorb the shocks you would normally expect.

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.

---

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

Proposals follow Strategy

---

Have you written a strategic plan?

Got your strategy in mind now?

It's time to implement. One way to do it is to propose the work to your sponsor or to your client.

So, now you need a proposal. 

Do you read Mike Clayton? You probably should.

Here is his idea of the 12 points of a perfect proposal:

What are the elements of a perfect proposal? Here are 12.

 

You

No one wants to hear all about you. See the next subtitle. That's who your audience wants to hear about... themselves. But (and it's a big 'but') they do need to know enough about you to know you are worth paying attention to. So, for a cold proposal, this means using the introduction or cover letter or some other means to establish your credibility - what my dad used to call your bona fides.

Them

This is what they want to know... What's in it for them? Show how you have their best interests in mind with this proposal. You understand their needs and desires and know how to satisfy them better than any alternative solution can.

Focus

Keep your focus on the specific situation. Any sign of standard 'boilerplate' descriptions, arguments, or evidence will make it look less about 'Them' and more about 'anyone'. 

Value

How will your proposal deliver and maximise value to them? The vast majority of business decisions revolve around the capacity to either make money or save money.

Benefits

But there can be other benefits too. Describe the non-financial value your proposal offers - and what this means to them. This, of course, means you need to take time to understand them and their requirements and priorities. 

Emotions

All that hard evidence gives them a reason to make the decision to accept your proposal. But it won't motivate them to do so. For that, you need to tap into their emotions. Find emotional hooks into pride, fear, duty, desire, ambition, loyalty, passion... Emotions drive decisions: reasons justify them.

How

So, you also need to show how your proposal will solve their problem, deliver their joy, or enhance their reputation. Make the link between what they want and what you are proposing as clear, simple, and short as you can. A 15-step sequence from the cause (your proposal) to the effect (their outcome) won't cut it. 

Process

Next they need to know what will happen if (when) they say yes. What will you do, what will they do, and how long would it all take? For confidence that your is the right choice, they need to see a plan that clearly works.

Context

This section lets them understand how your proposal fits into your life and theirs - your business and their own. This shows that you and they are compatible and is the equivalent of the more traditional (cheesy) 'how we are different to the competition'. Of course this differentiates you. It shows how this proposal is right for them and for you.

Business

Don't go all techy on a technical proposal. Remember who you are speaking to. If your audience is a business person or a group of businesspeople, focus on the business. If your audience is software engineers, focus on the business of software engineering: not the hardware. What is their business? That's how to frame your proposal.

Structure

I get it. You have a lot of ideas to get down. But, before you start, develop a structure that makes it compelling for them to follow. If they asked six questions in a sequence, then a great structure is to answer those six questions... in the same sequence. Make it easy for them to say 'yes'.

Quality

Finally remember Mark Anthony's advice: 'The evil that men do lives on. The good is oft' interred with their bones'. People remember your mistakes and easily forget all the good stuff. Make sure you check the quality of your proposal, not once, not twice... Better still, get the pickiest, most pedantic person you know to do it for you. You invested all that time. Now add a little more investment, to avoid throwing it all away!

---

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

Leading from the bottom of the funnel

---

This is about funnels, but we start with the concept of an apex.

In every book written about project management, the PMO is at the apex of a pyramid. Sometimes, as in Agile project methodology, the pyramid is flatter than most, but always there is an identifiable top figure.

Fair enough.

But Robert Gates, former Defense Secretary [and holder of many other government titles] writes that he often felt like the pyramid was inverted and thus took the look of a funnel. In the funnel model, the 'decider' is at the bottom of the funnel, with others pouring stuff in. 

 
Funnel v. Pyramid
How can it be that the top person is at the bottom, figuratively?

Gates explains: 

In the pyramid model, stuff is either pushed up for political cover, or because protocol demands that the decision lies higher, or because the apex person is pulling stuff up that they want control or inspection of it.

But in the funnel model, the top person is like the paper at the bottom of the bird cage: everything is pouring in from the top; and everybody on the project is busy doing the pouring. 

Fortunately, only a bit funnels all the way through, but gravity seems to be in charge. 

It's inexorable.

Filters in the funnel
Fortunately, the funnel can work like the pyramid, only with gravity. There can be and should be filters in the funnel. The minor stuff is trapped early and doesn't make it through. The top person -- at the end of the funnel -- can pull stuff "down", and there is some gravity effect: stuff naturally falls to the bottom for action.

And so for the PMO, the management points are:

• In the funnel model, things move by default.
  There's an expectation on the part of anyone pouring stuff in at the top that it will eventually come to the attention of those 'at the bottom of the funnel'.
  Gravity is just the consequence of applying energy to get stuff up to the top of the funnel and pouring it in.
  
  
• But in the pyramid model, gravity works against you.
  The default is: nothing moves to the top.
  If you want it to move up, there's work to be done!
  
  

If you like the idea of a funnel, how would you create it?

Just open your door! The funnel model is somewhat like "my door is always open" (even if virtual) ; anyone can "pour" something in. 

 

Anyone 'can' or Everyone 'should'?

Another funnel strategy is move from "anyone can"  to "everyone should" pour something in. 

Mind you: filters are needed.
And to mitigate frustration, if something is filtered out, some feedback to the initiator is required as to why it got filtered. (Crap! Don't you hate those form letters!?)

As the 'decider' you don't have to pull very much in if you operate like a funnel; stuff will get to you. If you like the funnel effect, you say that's good.

Perhaps, but only if you have the methods, tools, discipline, and staff to sort it out.

If you don't, turn things upside down and operate like a pyramid. Gravity is your friend; a lot of stuff just won't rise to the top

---

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

Threat unknown

---

Most of the postings on risk management don't deal with the post-risk consequences that befall the people who are charged with managing risks. 

But guess what? Very often the axe falls, even though a best effort was given.

So what are some of the human factors of risk management?

Of course the stress level rises when the stakes are amped if there are life-at-risk possibilities, or bet-the-business risks. Consider space launches, deep sea dives, major construction or demolition, or even some military project with lives at risk. And of course there is the ever present cyber threat to business continuity.

Reasonable protocol

Put yourself in this situation, following this protocol:

• As an experienced PM, you are aware of the nature of certain classes of threats that could affect your project, perhaps catastrophically. 
• And as an experienced PM, you've asked for any specific knowledge available about these classes. After all, many threats are reducible by acquiring more knowledge about them.
• But what if nothing has arisen or been reported about any specific threat for the foreseeable future? Is there anything to do?
• And so, you put these classes of threats on the back burner among the "aware but unmanaged" 

Then, stuff happens!

From the class of the unmanaged, a threat pops up and becomes real; the project is impacted, perhaps severely.

The human factors questions:

• Are you culpable for this most unfortunate outcome to your project -- you are the PM after all?
• Were you negligent for not managing this threat? 
• Can you be negligent for not taking action to mitigate a threat about which you had no certain knowledge? 
• Does negligence always require that you willfully ignore facts given to you?
• Even if not negligent, are you still responsible and accountable for the outcome?

It depends:

 Strictly from a legal point of view, there are four common elements to negligence:

• Duty
• Failure to perform your duty
• Damages 
• Causation

The latter is the most difficult, of course. Causation is often confused with coincidence and correlation. The idea that separates causation from correlation is the so-called "confounding factor": Something that influences or connects, but does not directly cause an outcome. If the confounding effect is "1" on a scale of 1 to 0, then correlation becomes causation; "0" is coincidence; everything in between is correlation.

But the issue in the this post is around the second point: Failure to perform your duty.

• You asked for knowledge to reduce the threat; none was forthcoming.
• You were told that nothing was forecast for the foreseeable future.
• You chose to "be aware but not actively manage"

Did you do your duty?

In part, you will be judged on what-came-next. What did you do when the threat emerged?

Tricky business, this. There's no clean answer.

---

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

NSA warns about Taiwan tensions

---

Does your project depend on supplies from Taiwan?

Is your project doing project work in Taiwan?

You should be thinking about how to be anti-fragile (*) if the balloon goes up according to national security officials.

Fall 2022 brings this from NSA:

NSA Director of Cybersecurity Rob Joyce has some critical lessons on how companies can withstand an escalation in China-Taiwan tensions and what such conflicts matter in the first place.

"We had advance warning of the Russia invasion" of Ukraine, said Joyce during a keynote at Mandiant's mWISE security conference today. "What would you do if tomorrow you got advanced warning of a China-Taiwan conflict? What business decisions would you have to make?"

_________________

(*) Anti-fragile: able to sustain and survive shocks to your plan without catastrophic failure of the overall project

---

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

Setting strategy

---

Consider this military wit, and put it in the context of a PMO.  

"There is an old—and misleading—bit of conventional military wisdom which holds that “amateurs study tactics, while professionals study logistics.”

The truth is that amateurs study only tactics or logistics, while professionals study both simultaneously.

The most brilliant tactics ever devised are pointless when the supplies needed to execute them do not exist, while all the supplies in the world are useless when a commanding officer has no idea how to effectively employ them."

Quote from "Field Marshal: The Life and Death of Erwin Rommel"

by Daniel Allen Butler

Are you the professional or the amateur?

Consider what are "logistics" in the project domain:

• Supplies and materials, of course
• Utilities, communications, and facilities (you gotta sit somewhere)
• Tools and training
• Supporting activity from Finance and Accounting (they have the money!) 
• Supporting activity from purchasing, inventory management, and receiving (they have the goods!)
• Supporting activities from the various "ilities"

If you can get that wagon train all connected and working for you, then of course there is the small matter of strategy:

• How strategic are you? Anything less than a year probably qualifies as tactics. Anything over three years and you should build in some tolerance for some business instability.
• What is the lay-line to your strategic goal, and of course, what is your goal?
• How much deviation from the lay-line can you tolerate for agile tactics (zig and zag along the lay-line)
• Can you be strategic on some elements of the 'balanced scorecard' and simultaneously tactical on others(*)?

Got all of the above together? 

Good. Now(!) you can entertain tactical moves, knowing the support is there.

_________________________

(*) Balanced scorecard: Finance, Customer, Product, and Operating Efficiency

---

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

AI clip art is coming to a PPT near you

---

"Generative AI" is mainstreaming seemingly everywhere since coming on the scene in 2018 as described by a paper from OpenAI.

Introduced in 2020, we've had GPT-3, a text-to-text auto-generation system, commonly used in natural language translation where context is integrated into the translation; and for text generation from simple prompts. (*)

The next thing up the generative AI ladder is text-to-image. And for that the AI folks have multiple competing systems: DALL-E-2, Midjourney, and Stable Diffusion. And some have started to 'generative AI' video built on top of Stable Diffusion.

Microsoft has had a strong investment position in generative AI for some years with its partnership with OpenAI. Now we see some of this effort mainstreaming for the casual user. Several posts like this one have announced the coming generative AI capability in MS Powerpoint -- built off DALL-E -- for generating clip art from text prompts.

In combination with text-to-text for presentation animation, this could be a biggie for presentations, proposals, marketing material, and really anywhere imagery is used throughout the project. This is especially interesting when you get to architecture and physical design.

 

Of course, for the casual user, this may be a bridge too far, meaning that without some experience the tweaking required to get a clip art that is really illustrative of your point, this may be too much trouble -- at first.

But for the power user, AI may be just the trick for really clever and appealing art to illustrate project materials. 

--------------------

Look here for more on GPT-3

---

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

The first two questions in Risk Management

---

Doing a little risk management?

Here are your first two questions:

1. Can I afford the downside? (Interpret that question with these rewordings: In effect, can I afford to let the risk go unmanaged, or can I afford to take the risk, given I have a choice?)
   
   
2. Can I improve the chances that the risk event won't happen, or can be somewhat mitigated, if I can obtain more knowledge? (This is the classical epistemological question in risk management)

Given all the climate issues of hurricanes, fires, tornadoes, and melting ice sheets, who's not asked those questions, not only for their personal situation, but also for their business and project situations?

In Florida, around the Kennedy NASA spaceflight center and the Canaveral Space Force Base, those questions are always Topic A. For the hurricane Ian in September, 2022, at great expense and loss of schedule, the Artemis I rocket was rolled back several miles from its launch pad to the safety of the Vehicle Assembly Building. 

• Increasing knowledge of the hurricane approach clarified and quantified the risk to the on-pad vehicle
• Loss or damage to the vehicle was perhaps not "unaffordable" but certainly would have been costly not only in absolute value, but enormously costly in utility value (public perception of NASA decision making; cost of investigations; threats to budgets; etc).
  Ergo: NASA mitigated by avoiding the risk of the on-pad of exposure.

Actually, if you follow the pre-launch protocol of any of the NASA, Space Force, or private launches, they are manifestly one of asking those two questions on literally hundreds of risks, threats, and vulnerabilities. 

But of course, it's not only launching space vehicles where these two questions come into play. Almost everything from going to work in the morning to running any kind of project day-to-day is going to engage these two questioins.

---

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

A comment on Architecture

---

"Architecture" has been in the PM-domain commentary more and more as rapid and flexible methodologies compete with more experienced ideas.

• It's been said, correctly, that architecture is where functional utility is addressed first (*)
• And it's been said, again correctly, that architecture generally imposes, usually conforms to, and applies the construction and integration rules for the domain of the project. (**)
• It's been said, repeatedly by me and others, that every project has architecture (and an architect) even if somewhat buried in other tasks and roles, because everything virtual or real has an architecture

But beyond rules and utility there are myriad components to architecture

• It expresses the art contained within the domain. In software, there is definitely art!
• It expresses the culture of the context in which the product or outcome will live
• It provides coherence and organization to the entity under development

Architecture and system engineering share a lot of the same goals for organization, coherency, and predictable performance. 

• System engineering focuses hard on interoperability of the sundry pieces and parts, making interfaces work smoothly, and being the keeper of the flame of cybernetics, anti-fragile, and anti-chaos. 
• And system engineering often morphs into system test for validation and verification.
• Whereas architecture often morphs into softer elements such as appealing design and fit-to-culture.

All said, as long as what you are building is itself divisible -- and pretty much everything above the atomic level is -- then there are both architectural considerations of integration and system engineering choices at interfaces.

What about rapid and evolving methodologies?

These usually are focused at a level below architecture and system engineering. Usually the focus is on rapid or evolutionary development. In the case of Agile methods, there is a lot of flexibility allowed within the general constraints of interfaces. Architects and SEs work at the black-box level; Agilists work on the internal white-box solution

____________________

(*) "Utility" is the measure of effective value vs actual value. If you don't like it, if you can't live with it, or if it means little to you, it has little utility to you, although others may find its actual value quite satisfactory. The classic explanation is a poor person with $10 in their pocket vs a rich person with $10. The utility of $10 to the poor person is very much more than it is to the rich person.

(**) One only has to look into the architecture issues of the Sydney opera house to appreciate how the architect pushed conformity to construction rules to the limit 

---

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

Join the 'practicals' with 'virtuals'

---

Have you noticed this?

Have you noticed that some people seem firmly planted and comfortable with their surroundings, but there are others that can't operate a hammer or a screwdriver?

Have you noticed that on many projects there is a unofficial segregation of the workforce something like this (*):

• The "practicals" who live and work and think in the physical world (whether in the office, or not)
• The "virtuals" who live and work and think in the remote, virtual, and digital space (even if they go into the office)

Join things up: Leverage the differences and make it an "And":

In the best of all cases, the win-win is to leverage the conjunction of 'practicals' and 'virtuals' as a reinforcing join of culture, skills, and interests. 

Architecture is a good place to start. How could you build a new "anything" without both working together: Design, analysis, construction? 

Have you ever looked closely at a sweeping fly-over highway bridge, as a good example? 

• How do they get those massive iron beams to gently curve over hundreds of feet and join seamlessly with the next? 
• How do they get the concrete columns to have just the right arc to give the roadway above the right degree of bank on the curves? 
• How would the CAD ever match up with the 'physicals' who drive the rivets and build the molds if they didn't work together ... rather than apart.

Practicals Versus Virtuals

'Versus' doesn't buy you anything

Instead of the joy of a 'reinforcing join', the opposite may be a dis-attraction, rejection, or tension between strangers from two spaces: physical and virtual.

In systems terms, there may be little or no throughput, poor gain on resources committed, and outright hostility. Obviously, there is nothing to be gained by being at loggerheads about the differences in experience, attitude, and values. Those who can type should also be able to use a screwdriver; but it works the other way around also. 

But, in fact, the cultural divide can be a chasm: pay, promotion, recognition, status, security to name a few of the HR issues, but also respect, arrogance, and elitism that unwittingly divide rather than unite, to say nothing about herd loyalty and commitment to win-loss.

If there were an answer ...

If there were an answer for this, other than self-awareness and walk-in-their-shoes exercises, I would put it down in the next paragraph

But, there is no next paragraph .....

++++++++++++++

(*) Credit to Ross Douthat for the idea of 'practicals' and 'virtuals'

---

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

About data; here's the first rule

---

The first rule of data:

• Don't ask for data if you don't know what you are going to do with it

Or, said another way (same rule)

• Don't ask for data which you can not use or act upon

 And, your reaction might be: Of course!

But, alas, in too many PMOs there are too many incidents of reports, data accumulation, measurements, etc which are the progeny of PMO doctrine. But the reality is: There actually is no plan for what to do with all this stuff that comes in. 

Sometimes, a data collection is just curiosity; sometimes it's just blind compliance with a data regulation; sometimes it's just to have a justification for an analyst job. 

But sometimes, there is a "feeling" that if such data is not coming in and available that somehow you're failing as a manager. Afterall, one view of management is to measure, evaluate, and act. If you're not doing the first step, how can you be managing effectively? Ergo: measure everything! Somehow, the good 'stuff' will then rise to the top. (I submit "hope" and "somehow" are not actually good planning tools)

The test:

 If someone says they need data, the first questions are: 

• What are you going to do with the data?
• How does the data add value to what is to be done
• Is the data quality consistent with the intended use or application, and 
• Is there a plan to effectuate that value-add (in other words, can you put the data into action)?

And how much data?

Does the data inquisitor have a notion of data limits: What is enough, but not too much, to be statistically significant (*), informative for management decision making, and sufficient to establish control limits?

And information?

Well, the usual definition is that information is data, perhaps multiple data, integrated with context, and interpreted for the current situation.

So, the rule can be extended: If there are not means to process data into information, is the data necessary to be collected?

Bottom line: To state the obvious: always test a request for data collection for value-add before spending resources!

______________

(*) Statistical significance: The observed behavior in the data is unlikely to be just a random outcome; the data is predictability attributed to something specific which can be described statistically.

---

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

A word about threats and risks

---

Daniel Miessler has an interesting essay about threats, vulnerabilities, and risks that is worth a quick read.

He summarizes this way:

•  A Threat is a negative scenario you want to avoid
• A Threat Actor is the agent that makes a Threat happen
• A Vulnerability is a weakness that can be exploited in order to attack you
• A Risk is a negative scenario you want to avoid, combined with its probability and its impact
• The difference between a Threat and a Risk is that a Threat is a negative event by itself, where a Risk is the negative event combined with its probability and its impact

All good, but then what do you do about any one of these?

Begin with knowledge acquisition.

Any threat, risk, or vulnerability that is susceptible to reduction by knowing more about it is probably worth the investment to gather the available information, or conduct experiments, models, or simulations to put data into an analysis process 

Such activity is applying the skills and processes of epistemology which is the theory of knowledge, especially with regard to its methods, validity, and scope. 

Most important for project management, "epistemology is the investigation of what distinguishes justified belief from opinion." (Oxford online dictionary)

And, to carry it a bit further, such risks, threats, and vulnerabilities are often called epistemic risks, etc.

Truly random effects

If your knowledge study convinces you that more knowledge won't improve the mitigation, then you are in the realm of random effects which are largely unpredictable -- that is, random -- within certain boundaries. 

There are two major categories of such randomness that project managers deal with:

1. The central tendency type of randomness wherein random effects tend to cluster around a central figure, and outliers fall off and away from the central figure. This leads to the so-called "bell curve" which is usually not a perfect bell, but nonetheless the centrality is evident in the data
   
   
2. The "power law" type of randomness wherein random effects are "one-sided" and fall off roughly as the square of the distance from the main lobe. The Pareto histogram is a familiar example, as is the "80-20" histogram.

The best way to identify which of these two phenomenon is your situation is by experimentation, observation, simulation, and modelling to develop data and thereby determine the "fit".

---

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

Stabilize your project

---

Stability!

It counts for a lot.

It implies -- for behaviors and management decisions -- predictability, reliability, under-control (but not risk-free, of course), coherent narrative, steady-state goals, and a strategy that is understandable to those who have the job of implementing it.

Perhaps you are aware, as many are, that stability requires feedback to effect error correction and trap excesses and blind alleys. 

Ah yes!

We know about feedback.

Open loop systems -- those with outcome but no feedback -- are prone to many uncontrolled and unexpected responses. Who can predict what a stimulus will do to a system that has no feedback? Actually, that's a really tricky task.

So, what about feedback? 

What's to know?

• Timing is everything! Getting the feedback "phased" in time such that it has a correcting effect rather than a destructive effect is vital. The former is generally called "negative feedback" for its corrective nature; the latter is generally called "positive feedback" for its reinforcing rather than corrective nature. And, when its too late, it's generally called ineffective.
  
  
• Amplitude, or strength, or quantity is next: It has to be enough, but not too much. Tricky that! Experimentation and experience are about the only way to handle this one.

What could possibly go wrong?

Actually, a lot can go wrong.

No feedback at all is the worst of the worst: the 'system' is 'open loop', meaning that there are outcomes that perhaps no one (or no thing) are paying attention to. Stuff happens, or is happening, and who knows (or who knew)?

Timing errors are perhaps the next worst errors: if the timing is off, the feedback could be 'positive' rather than 'negative' such that the 'bad stuff' is reinforced rather than damped down. 

Strength errors are usually less onerous: if the strength is off, but the timing is on, then the damping may be too little, but usually you get some favorable effect

Practical project management

Feedback for correcting human performance is familiar to all. Too late and it's ineffective; too much over the top and it's taken the wrong way. So, timing and strength are key

But, the next thing is communication: both verbal and written (email,etc). Closing the loop provides reassurance of the quality and effectiveness of communication. You're just not talking or writing into the wind!

And, of course, in system or process design, loops should never be open. Who knows what could happen.

I should mention:

The study of feedback systems generally falls within what is called 'cybernetics'. As described by sciencedirect.com, MIT mathematician Norbert Wiener defined cybernetics as “the study of control and communication in the animal and the machine." 

From Wikipedia, we learn: The core concept of cybernetics is circular causality or feedback—where the observed outcomes of actions are taken as inputs [ie, feedback] for further action in ways that support the pursuit and maintenance of particular conditions [ie, 'ways that support' requires the correct timing and strength]

---

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

You've been asked to write a strategic plan (ugh!)

---

Who wants to write a strategic plan?

Really, nobody, unless you are a professional planner and that's your livelihood.

But, what if you're asked to write, or help write, a plan?

Of course, you can "google" it; and you'll find no lack of help with templates and outlines and even some process.

But here's a bit from my experience.

Ask for the narrative

Asking for the narrative from whomever has asked for the plan is everybody' s favorite first step.

But it may not be as easy as story-telling:

• Maybe the sponsor knows they are in a bad spot, but doesn't know where the future is. This is a really hard one, since the future could be anywhere
• Maybe the sponsor knows what the future should be, but has no idea of how to get there. This is the easier one, since at least there is a target to aim for
• Maybe the sponsor is in name only; maybe the 'strategic plan' is called for in the standing protocols or bylaws, and the sponsor actually doesn't feel the need for the plan. This is also a hard one because committed resources to get the plan done will be problematic
• Maybe the sponsor thinks a strategic plan is just a 3-year budget plan. This will take some work to get that mindset reset.

Nonetheless, all that said and internalized, you actually do need a narrative in order to provide an organizing framework.

What are some of the questions?

The right questions to ask are situational. That should be intuitively obvious. Private sector, civil government, police-fire-military, non-profit, religious, and on we go. A lot of diversity.

Frame the questions in context with the traditional four sectors (Balanced Scorecard):

1. Financial objectives
2. Products and services, now and 'then'
3. Customers and customer service, now and 'then'
4. Operations and operational effectiveness

Financial is just not accounting. The fundamentals of the business model may be at stake. Maybe your industry is changing so rapidly, you exit for new territory.

Customers support the business model, yes, but ....  The business model exists to serve customer needs. Maybe they just don't need what you have, so something new is needed. What are the characteristics of a new or different customer base?

OE (operational effectiveness) is the tricky one for many:

• Will you need the workforce you have now?
• Should the workforce be younger or older; more or less expensive; more or less diverse; and with new or just improved skills? Can you even ask some of these questions?
• Will you emphasize remote or local, W-2's or contractors?
• Will you need the facilities you have now? Buy or lease new? Here or somewhere else? 
• "Lean" was supposed to be the OE answer, but times have changed. What's the secret sauce for effective operations going to be?

There's a lot of stuff that goes into a strategic plan. Good luck with that!

---

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

Quiet Quitting

---

One of the human resources trends going about is "Quiet Quitting". 

Has this come to a project on your street?

As in all such trends, there are numerous versions which heretofore might have been labeled "work life balance"

So, here is a bit of what to look out for:

• The 'union' version: Work to rules. Nothing above and beyond the call. Put in the required time; do as good a job as possible; then leave it all and go home. No emails and texts off hours
• The 'frustrated' version: Do the absolute minimum to get by; don't volunteer; maintain a low profile. 
• The 'anti-burnout version': Work really hard, but then leave on time; no weekends or late hours; leave it all when you leave.

Remote and virtual work can be problematic

• Some say the 'quiet quitting' is more pronounced with remote workers where job hours are super flexible
• Some companies are pushing back by 'return to the office mandates'

But then there's this:

From time to time, we all need to rebalance, rethink, and recharge. 

Many projects are recognizing the need and providing buffers and recharge time

In other words, many projects are getting ahead of "quiet quitting"

---

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

Don't risk the team (in extremis)!

---

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

Formula  solution
Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like that lend objectivity to the process (not playing favorites, etc). Note: more on this in the "6x2x1" model discussed last

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

Other observers have put it down as a variation on "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . In this case, it's too many people on the team with too many interferences. It's been observed that to raise productivity, reduce staff!

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

Ever wondered why you are stopped in traffic miles from the interference while others up ahead are moving? Answer: traffic load exceeds the highway's ability to absorb the oncoming cars, thereby launching reflections of standing waves that ebb and crest.

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

WIP Limits
In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity.

Sometimes the problem arises with sponsors: their answer is universally: Throw more resources in, exactly opposite the correct remedy

6x2x1 model
One of my students said this:

"Daniel Pink  has an excellent book called Drive, the surprising truth about what motivates us. In the book, Pink talks about inspiring high productivity and maintaining a sustainable pace.

One of the techniques is the 6x2x1 iteration model. This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

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

I don't know, but Pink's thesis may have been the genesis of the Google and Microsoft "time off" plans I've already mentioned, or maybe the experience of those plans found their way into Pink's thesis. Either way, time off matters!

---

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