Tuesday, September 21, 2021

Ghost writer and communicator

So, you work in project communications, perhaps directly for the PM. 
Great job, and it can be a lot of fun being creative.

In the 'old days', that probably meant long-form press releases and updates to the project web page or communications dashboard.

Today, it's those plus social media; scripts and plans for podcasts and videos; and other duties as assigned (ODAS)

But, if you're a ghost writer for the 'boss', who gets the credit? Do you have a byline as a contributor? And, does the boss get the credit for imaginative and effective writing or production when it's really you?

Welcome to the world of ghost writing. 
The person you're writing for gets the credit, usually, and you're lucky if you're recognized outside your PMO. You probably knew all that coming into the job. Why else is it called 'ghost' writing?
But what if you disagree in some fundamental way with the content of the communication you've been asked to write or produce? What then?

Two cases:
  1. Opinion: It's not your opinion you're opining. You can write 'B' for the public, but believe 'A' privately.
  2. False facts: If not about 'beliefs' but rather about misleading or even factually incorrect material, you have an obligation to push back. 

Life is too short

If you can't live with the material you're writing, then don't. Find new material; and find a way to persuade the boss to let you use it.

And if all that doesn't work, you may have to fire the boss! (Aka: get a new job)

Buy them at any online book retailer!

Friday, September 17, 2021

Projects and capitalism

'Capitalism' is in the news. And, not for the first time we're hearing about how corporations have an obligation more reaching than just the traditional shareholder value -- meaning profit maximization.

Community impact is now in the mix, more so than in the past, and that may mean capitalism will be paying attention to multiple factors beyond profit maximization:
  • Environment -- a steady standby, to be sure
  • Diversified workforce -- at least as diversified as the local community
  • Job stability -- meaning, careful about robotics displacing workers
  • Job location -- meaning, careful about remote working, virtual teams, and the lot
  • Educational opportunity -- perhaps a mentorship with the local intern program or university
  • Social justice -- meaning a safe workplace, and support for social justice in the community
Regardless of whether you think business should take these on, you probably think that these are 'C-Suite" issues -- isn't that what we pay them the big bucks for?

Not so fast!
There is flow-down to consider. Since at least 1992 -- ancient history for many of you -- the "Balanced Scorecard" has been a feature of business score keeping. And with it, a deconstruction and flow-down of corporate goals throughout the business.

And so, we can anticipate that such will reach to the PMO. 

Wait! In the PMO, our thing is cost-schedule-scope-quality. Where do we fit that other stuff in?
  • First effect: Scope -- some of these things will inevitably get cranked into our scope statement. Fair enough. But, scope connects to cost and schedule ..... don't forget that!
  • Second effect: Cost -- it takes money to do some of these community things.
  • Third effect: Velocity, meaning rate of throughput, meaning: schedule. No doubt some of these community things are going to slow us down .... but, perhaps a trade worth making.
Measuring the PMO
At the end of the day, project metrics should -- and will -- reflect this larger landscape. 
As examples of how such capitalism objectives might flow down to the PMO, maybe we don't remote as much as we could and keep a more robust local presence. Such will increase velocity because bandwidth has been added to team interactions and communications, and cost may be reduced a bit because remoteness is not free
Maybe we adjust the supply chain to be locally more than we need to -- in effect: buy local.
Maybe we hire less experienced but local people and invest in their development. Such may adversely effect velocity and cost in the short run but pay community benefits in the long run.

Steady on! Maybe we need a business culture from the C-suite that supports all this!

Buy them at any online book retailer!

Monday, September 13, 2021

The Incompetence Dodge

There are so many 'laws' that govern Project Management one wonders how to keep track of them all.
Now comes "The Incompetence Dodge", originally formulated by Sam Rosenfeld and Matt Yglesias. Their domain was foreign policy, but their idea can be recast to project management.

Simply put: if your idea failed, you need not look to the quality of the idea; you simply blame others for implementing your idea incompetently. 

Simple tactics, and the dodge
With such a simple tactic, any errors of strategy on your part are transferrable to others as errors of tactics!
Thus, you dodge around bad ideas by the ruse of incompetence by others.

How long can this go on?
How long? It depends on whether you are in charge of the time or the clocks.
If you've got time on your side, you can run out the clock, maintaining the dodge forever.

And, here's the really good part: you don't need jump on incompetence right away. You can wait and see which way it goes. 
  • If your bad idea is somehow rescued by brilliant execution, you can claim victory. 
  • But, if it goes awry, you can jump on incompetence and avoid personal defeat!

Bottom line: you can be blameless!

Buy them at any online book retailer!

Thursday, September 9, 2021

Negative feedback: good or evil?

The question is posed: Is negative feedback good or evil?
Answer: Good!
Yes, 'negative' is good.

Ooops: did I mention what feedback is? Generally it is a sample or portion of an outcome, or something quite similar but directly related to an outcome.

Here's the thing: 'Positive' feedback is reinforcing, agreed, but that may not be a good thing. The primary purposes of 'feedback' are to: 
  • correct behavior (not always, or even mostly, human behavior), 
  • prevent 'runaway' and chaotic responses, 
  • confirm outcomes as expected, and 
  • enhance the predictability of outcomes. 
These latter advantages come from so-called 'negative' feedback.

NOTE: providing feedback has its own jargon: We say: feedback closes the loop (the loop is from outcome back to the source that drives the outcomes), or the 'loop is closed'

Now the tricky part: Strength and timing are everything. 
To close the loop effectively, the strength (or amplitude) of feedback, and the timing (or phasing) of feedback has to be such that the feedback provides a countermeasure to the potentially errant outcome, the net effect being an outcome just as predicted, void of the bad stuff.
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.

Buy them at any online book retailer!

Sunday, September 5, 2021

Sketching out the architecture

I was recently directed toward an interesting site (blog, presentations, etc) by Simon Brown, and his download presentation about "sketching the architecture" that more or less reinforces my idea that:

 "If you can't draw it, you can't build it."

Box model
From this idea flows my "box model" approach to setting down high level narrative (business story with context), major functions (boxes) and the interconnecting process (network).

Now, Brown tells a similar story -- with more depth re design -- with an idea he calls C4. C4 is a box model that Brown claims enables agility in architecture:
  • Context
  • Container
  • Components
  • Classes

One thing in Brown's version is an assertion that multiple views may be needed to convey the architecture completely. To this end he posits views like:

  • logical vs conceptual;
  • process vs functional; and others.

In Brown's world, these different views are tools to "... manage complexity and highlight different aspects of the solution."

For instance, logic shows interconnections with conditions (if, then, else, etc) and process shows work flow, as an example.

These ideas of Mr. Brown are profound:
  • We can visualize our process but not our software.
  • In [Brown's] experience, software teams are unable to visualize the software architecture of their systems.
  • Pictures are the simplest form of documentation.
  • Sketches are not complete models.
  • Abstraction is about simplifying, not creating a different representation.

Buy them at any online book retailer!

Wednesday, September 1, 2021

The Requisite Law of Variety

Now, this could be a bit stuffy, but it's actually quite readable: "The Requisite Law of Variety"

Reduced for a quick understanding, 'the Law' is an interesting concept to consider, to wit:
  • Essential Elements (E): these are outcomes, results, or other artifacts that you want to have some control over; or they are controls and mechanisms that you have to influence outcomes and results and disturbances
  • Disturbances (D): these are events or actions that impact E .... usually there are a lot of these!
  • Regulation (R) or controls: these are the means or actions to limit the impact of D's. Even in the Agile world, there are some controls or protocols to regulate the pace and rhythm
  • Passive capacity (K): in effect, buffers and elasticity that limit the fragility of the system and allow for some absorption of D without breaking E 
The Law is a bit mystical when expressed as math, essentially saying:
"the the variety -- or set -- of the E's that you need or value should be greater than
  • the variety -- or set -- of disturbances (D) reduced, absorbed or mitigated by regulation (R) and
  • other, or further, disturbances reduced by buffers or elasticity (aka: passive capacity, K)."
Practical project management
In other words, the practical advantage to a PM for having a big variety of Es is that Es overwhelm a smaller variety of Ds (or diversifies or dilutes the impact of Ds ) because big E implies a lot of different outcomes that are important, and a big tool set with which to work (*)

Risk management point of view:
So, whereas, some variety of Ds may have impact of some part of the Es, not all Es will be affected. Thus, the larger the variety of Es, the less impactful is a much smaller variety of Ds.

Value proposition point of view
If there is only one thing that is important to you as a project outcome, all your value is in that one thing. Consequently you have set up a vulnerability such that a single disturbance could wipe out your value proposition.  That is way too fragile!

And, 'having only one thing' violates the Law of Variety which intones that the variety of Es should be greater than the Ds that could impact E.

Anthony Hodgson puts it this way:

[The Law of Variety] ... leads to the somewhat counterintuitive observation that the regulator [or PM] must have a sufficiently large variety of actions in order to ensure a sufficiently small variety of outcomes in the essential variables E.

This principle has important implications for practical situations: since the variety of perturbations a system can potentially be confronted with is unlimited, we should always try maximize its internal variety (or diversity), so as to be optimally prepared for any foreseeable or unforeseeable contingency.

If you are familiar with the ideas of "anti-fragile" in system design, this last sentence is a good alternate phrasing for what makes systems anti-fragile, i.e. resilient

(*) In effect, the Law of Variety provides opportunity to define project success in several ways. If one of the Es doesn't work out, perhaps another one will. 

Some might say that with such a strategy, every project can be successful, or none a total failure: you just need to find a good E to hang your hat on. 

With such reasoning, it's not hard to conclude that 'project success' or 'failure' metrics are tricky. For more on this debate, look to the endless commentary on the Standish Reports of project success.

Buy them at any online book retailer!

Saturday, August 28, 2021

The worst error in scheduling

The worst error in scheduling is to have a milestone depend upon two or more tasks scheduled (planned) to finish at the same time.
Here's a footnote to that witticism: 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
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
(*) 90 successes out of 100, or 90% chance the task will finish on time, or early.

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)
  • You might be able to reorganize the schedule to eliminate this milestone, or one or more of its input tasks.
(**) A scheduled event of zero scope, but a specific amount of time, aka: a zero-scope time box.

Buy them at any online book retailer!

Wednesday, August 25, 2021

Can you spend $1M in a month?

Here's the challenge: On your project, can you spend $1M in a month?
Take a minute and think about it.

  • If you've got 100 people with an annual payroll of $15M, then yes, it's possible, even likely
  • If you've got 20 people with an annual payroll of $3M, then maybe, with overtime and some material charges.
Got your answer?

Then here's another challenge: If you can spend $1M in a month, can you do a $1M project in a month? Are they one and the same thing?
  • It's hard to get 100 people up and moving coherently to start and finish something in a month (that $1M may disappear into "start-up" inefficiencies)
  • It's not too hard to get 20 people moving, but you might have to really work on motivation if you think you're going to spend $1M on people, but there may be tools, training, facilities, etc that will absorb funds.
So, having thought about it, maybe if you really need your 100-person team, 2 months and $2M is a better thing to have;
And, if you only need your 20-person team, even with overtime, you will be hard pressed to spend as much as $1M

What does all this mean?
You've just made some 'estimates' (gasp! that dreaded word)
Perhaps a bit crude and rude, but at least the 'breadbox' is somewhat defined

Never let it be said that nearly every minute of the day we are not making estimates:
  • How long to get to the computer (home or office)
  • How long for that meeting
  • How much time to spend on email
  • How much to spend on a car, hotel, or even a cruise
  • On, and on, estimating!

Buy them at any online book retailer!

Saturday, August 21, 2021

Which comes first .... A or B?

This is not about the A/B argument in Agile methods. 
This is about get the elements of project scope sequenced in the right time order 
  • Does "A" come before "B", or not, and 
  • Is there a dependency between "A" and "B"? 
  • If not, then the sequencing question may be moot. If they are truly independent, then they can be scheduled for convenience, or according to some other dependency, "C"
But if the "A" before "B"? question is viable, then ...
Sequencing is the first task in forming a schedule, but only after you figure out the scope.
A before B
If you understand the nature of A and that of B, then if there is a dependency between them vis a vis time order, then getting A done before B sounds easy, but sometimes it makes you wonder!
  • Is there a preamble to B that should be done before A is completed?
  • Are the resources for A and B in conflict or not available; such could affect the "preamble" activity.
  • Can B really start after A, or are there other dependencies on the start of B?
  • Do I really want B to start, or do I want to pause and start C somewhere else? 
  • If I start B, immediately after A, have I introduced unnecessary risk or other impacts?
Schedule depends on sequence
So, if you're thinking about sequencing, you're probably also thinking about schedule: how long it's going to take?
Or, the other way around: if you are working on a schedule, you have to get the sequence down first. 
From time to time, arguments boil up about scheduling tools, like MSProject and others. The usual thinking is that these tools are "so last century" and haven't kept up with more agile planning techniques. 
And, worst of all, these older tools promote waterfall (gasp!) scheduling, which is demagoguery for finish-to-start precedence. 
Finish-to-start precedence is a sequencing concept. If you pooh-pooh such precedence, I challenge you to put up the roof before the walls are in place.

It's all about the sequencing
First, you have to know what you are going to do. To wit: you can't sequence that which you don't know about, and furthermore, even then there may be sequencing errors you discover once you understand the full extent of the scope.
For any project, step 1 is to assemble (or define) the elements of scope by some affinity criteria. (Using the roof-after-walls example, get all the roof stuff in one grouping, and all the wall stuff in another grouping. That way, you can sequence the roof group after the wall group.)

Advice to PMO

At the PMO level focus on the major sequences that drive toward value-add milestones.

Buy them at any online book retailer!

Tuesday, August 17, 2021

Of clocks and time

What does this mean?
You have the clocks, but I have the time!

It means:

  • If you are a tactical thinker, and I have the patience for the strategic, then I'll win in the end
  • You may win all the battles, but I'll win the war (See: American revolution war with England)
  • You may misunderstand the fundamentals of the project nemesis. You may be too lazy to understand; you may be the one that kills the messenger; you may be drinking your own Kool Aide (See: group think, bubbles, silos, small inner circle, etc)
  • You have mistaken the tree for the forest
  • You have a serious case of 'confirmation bias'

Buy them at any online book retailer!

Thursday, August 12, 2021

Let it be mensurable!

To be mensurable is to be 
  • Measurable
  • Calculable
  • Estimable
  • Determinable
And, why do we care?
Enter: risk management

To compare two dissimilar risks violates the rule that risks to be compared must be similarly mensurable.

In a recent post, Matthew Squair, writing at 'critical uncertainties' makes the point that early on ....
(and I quote Squair)

".... lockdown sceptics were pointing out that your risk of drowning in a pool, in California, was much higher than that of dying from Covid 19 so why to worry? if you feel this is intuitively wrong, in fact wronger than wrong, you're right.

One of these risks is based on an independent probability. That is if I drown in a pool it's not going to have an affect on the probability of my neighbour drowning. But, on the other hand if I have Covid 19 you'll find the probability of my neighbour having Covid 19 is dependent on that; that is, the probabilities are dependent.

In one we truck along with a base rate of events unaffected by each other, in the other the events can affect each other and the risk can suddenly blow up.

To be very clear the two risks are immensurable and not directly comparable."

He goes to point out that many such immensurable comparisons are being made in the Covid space, such as the risk of getting Covid itself compared, incorrectly, to the risk of blood clot from a vaccine, etc.

Buy them at any online book retailer!

Monday, August 9, 2021

Tactics and strategy

Consider this military bit or wit, and put it in the context of a PMO dealing with tactics and strategy, as well as tactics and logistics on complicated and complex projects. Are you the professional or the amateur?

"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

Buy them at any online book retailer!

Thursday, August 5, 2021

How do YOU manage cost?

'How do YOU manage cost' is a bit different from 'how is cost managed'?

I was  recently asked the YOU question in a way that begged for an 'elevator speech' reply (only 30 seconds for the answer):  
  • My goodness! 30 seconds to reply? 
  • Isn't that question even older than project management itself? 
Let's have a conversation
The best way to answer is to have a conversation, because the response is all tied up in values: 
  • Is cost the dominant leg in the cost-schedule-scope-quality trade space? 
  • Or, is the proposition to always manage to a 'best-value' formulation? 
If value is what we are willing to pay for, then best-value may not be the lowest cost but it may be the best bang for the buck!

Is cost an input or a result?
The mistake most made is to manage cost like it is an input, rather than a result. 

Managing at the input means watching the cash flow in comparison to the budget plan for cash consumption. This will provide comfort to the CFO, but it does little for the other stakeholders. The cash flow could be right on plan, cash consumed exactly as planned, and yet the project could be churning pointlessly and producing nothing. 

Where does the value come from?
There is no value proposition at the input, so continuing to focus on the input side of the project process is strictly a CFO task.

Value is produced at the output. By now, everyone should know this. To manage cost is to manage three variables: 
  1. budgeted cash flow at the input (aka, gasp! an estimate)
  2. actual cost in the process, and 
  3. value of the actual outcomes. (*)
(*) aka, value earned in  the project view, but also business value if you can relate to the 'balanced scorecard' concept.

Forecasts and estimates (dare I say these words?)
By the way, forecasts are the weakest link! Does history ever repeat? Milton Friedman, distinguished economist, opined: "if you are going to predict, then predict often!" Meaning: hey, things change!

Who's in charge?
It's a lucky project manager that actually gets to control the labor cost to only that which is needed to produce the intended value. 

This is another of those conversations we need to have. 
  • How many times have people been placed on projects because they would otherwise be on overhead and vulnerable to release? 
  •  How many times have people been retained on projects, the so-called marching army, because PM's have been told they can't get them back if they release them? 
  •  Smart management anticipates labor redundancies, but also labor losses that might impact the EV: vacation, sick leave, other duties as assigned!

It's a lucky project manager that actually controls the overhead expenses of their project. In point of fact, many projects are encumbered with liquidating enterprise expenses disproportionately to use. It's part of the game, so smart cost managers anticipate the impact of changing overhead positions.

Now the challenge remains to get this all into 30 seconds so that it will sound good on the elevator!

Buy them at any online book retailer!

Sunday, August 1, 2021

You are a fiduciary

Alex Korda, a British businessman in the late 1930s, was quoted as saying about a project budget, with a shrug:
“A lot of money—other people’s money, of course, but still a lot.”

Let me offer some advice: when it's other people's money (OPM), it could be career-shortening to shrug off the budget or the budget overruns.

And, by the way, as a PM, you have a fiduciary responsibility to always act in the best interests of your "client". In this case: whoever's money it is. If it is not yours, then you should walk a mile in their shoes and handle their money the way they would.

Buy them at any online book retailer!

Thursday, July 29, 2021

The best thing you can do to manage risk?

You ask: What's he best thing I can do to manage risk?
Make time your friend. 
Insert time buffers in your schedule around every uncertain event, around milestones that are critical to success, and around major blocks of scope that determine whether project objectives will be met.

Time is your friend if it is allocated in your schedule to give you space to work, and rework, mitigations. Time is your friend if you have the space to accommodate the less optimum outcomes. 

But time is not your friend if you've not allowed for the consequence of coupling between risky outcomes, and have not provided a buffer space to work the work-arounds.

Beware of shift-right!

What's "shift right"? 

If a milestone success is determined by the likelihood of multiple independent outcomes finishing together, then the likelihood of the milestone finishing on-time is degraded by the product of their likelihoods. To restore the confidence in the milestone schedule, it has to be shifted to the right.

Example: Two independent outcomes of 80% confidence each result in a 64% confidence in their joint success

So, if you buffer that milestone in the first place, then the "shift right" is built-in from the beginning and is not a shock when it happens.

Buy them at any online book retailer!

Monday, July 26, 2021

Let's hear it for bureaucracy!

If you can't trust your people
Or, you don't know your people well enough to trust them
And, you can't replace the former
Nor do you have time to get to know the latter .....

Then the management solution is simplicity itself:
Invent a bureaucracy and assign them to it!

Bureaucracy is the management alternative to trust. 
  • Rules, regulations, and punishment do all the work. No fuss, no muss!
  • Sometimes, incentives are useful, so don't leave them out.

Now admittedly, bureaucracy cuts against the flat, agile grain which is "the way to do it" for modern managers. 

But, beyond a point, flat is too flat, and agile is too agile.
Let's be realistic:
  • Many can not handle complete freedom, 
  • Have questionable judgement, 
  • Are misaligned to strategic goals and imperatives, and 
  • Generally spend time and money without regard to the fact that neither the time nor the money is theirs.
Bring on the bureaucrats!

Buy them at any online book retailer!

Friday, July 23, 2021

The only two things you need to know about statistics

Number One: It's a bell, unless it's not
For nearly all of us when approaching something statistical, we imagine the bell-shape distribution right away. And, we know the average outcome is the value at the peak of the curve.

Why is it so useful that it's the default go-to?  

Because many, if not most, natural phenomenon with a bit of randomness tend to have a "central tendency" or preferred state of value. In the absence of influence, there is a tendency for random outcomes to cluster around the center, giving rise to the symmetry about the central value and the idea of "central tendency". 

To default to the bell-shape really isn't lazy thinking; in fact, it's a useful default when there is a paucity of data. 

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

Number Two: the 80/20 rule, etc.

When there's no average with symmetrical boundaries--in other words, no central tendency, we generally fall back to the 80/20 rule, to wit: 80% of the outcomes are a consequence of 20% of the driving events. 

The Pareto distribution, which gives rise to the 80/20 rule, and its close cousin, the Exponential distribution, are the mathematical underpinnings for understanding many project events for which there is no central tendency. (see photo display below) 

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

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

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

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

Otherwise, fall back to the Pareto concept. It's good enough.

Buy them at any online book retailer!

Tuesday, July 20, 2021

Plausible denial

What follows is an all-to-sad commentary on government. 
But what if "government" was "PMO" in this quotation? That would be really sad. 

Perhaps "lie" is too strong; perhaps 'self-delusional' or some other less in-your-face spin is more the case. But you get the point: the unvarnished truth is sometimes just too much for the moment. Time is necessary to find your way back on the center stripe. And to make time, some spin of the truth is required.

Perhaps; but plausible denial: that's running from responsibility. That can not be condoned.

“It is a truism that all governments lie: they lie to each other, they lie to their own people, they frequently lie to themselves. 

But a fundamental premise of functional government is that such deception .... must be an exception rather than a norm: to rule effectively, a government must be able to maintain at least a minimum level of credibility; by the same token, it must inevitably fail when it chooses to function on plausible deniability alone"

Daniel Allen Butler

Buy them at any online book retailer!

Saturday, July 17, 2021

Two choices

To a senior manager:
"What is the best way to manage a project?”
In response:
“You’ll find that there are always two possible decisions open to you,” the senior manager replied crisply. “Take the bolder one—it’s always best"

Daniel Allen Butler (paraphrased a bit)

Buy them at any online book retailer!

Wednesday, July 14, 2021

Perfect proposals (by Clayton)

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

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.

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

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.

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. 

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.

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. 

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.

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.

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.

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

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!

Buy them at any online book retailer!

Wednesday, July 7, 2021

What is boldness?

"About boldness: Some might say “impulsiveness,” yet what is boldness but impulse leavened by calculation?

Daniel Allen Butler

Calculation? Where does that come from?
Experience is where it comes from. 

And what can we say about experience?

Steve Jobs would say it's one of the two coins that we get paid: One is cash, and the other is experience.
Others say it's the accumulated wisdom of all your encounters, good and bad

So, can you be bold without experience to base the calculation?
Yes, but then you are going by the "book" (others experience), or guessing or hoping or, in the worst case: foolish!

Buy them at any online book retailer!

Monday, July 5, 2021

The first rule of data

You can't have too much data .... correct?
Actually, not correct.

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! 

The data plan
You may be shocked to learn that often there is no data plan! 
My experience: In the PMO there are often too many incidents of reports, data accumulation, measurements, inquiries, etc. for which there actually is no plan for what to do with it. 
  • Sometimes, it just curiosity; 
  • Sometimes you're out of your lane and it's really none of your business to know
  • Sometimes it's just blind compliance with a data regulation; 
  • Sometimes it's just to have a justification for an analyst job
  • Sometimes it's a misguided idea that "there can't be too much data".

The tests:
  •  If someone says they need data, the first question is: "How does it add value to what you are doing, and do you have a plan to effectuate that value-add?"
  • The second question is: "Do you have a notion of data limits: enough, but not too much to be statistically significant, and control limits for useful -- or not -- metrics."

And information?
Well, the usual definition is that information is data, perhaps multiple data, integrated with context and perhaps 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 for value-add before spending resources to collect, process, and disseminate data.

Buy them at any online book retailer!

Monday, June 28, 2021

The funnel and the pyramid!

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

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. 
But, rather than "anyone can", you move to "everyone should" pour something in. 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.

Buy them at any online book retailer!

Friday, June 25, 2021

Do you trust the other side of the transaction?

The other side: the counter-party
In a transactional relationship, the other party to -- or participating in -- the transaction is your counter-party.
In project situations, there are usually many counter-party transactional arrangements, such as contractors and suppliers with transactional relationships. And within the business there may be transactional relationships among business units and the PMO. 
Oh! And don't forget the money: there may be financiers of the business or project which have a counter-party relationship to the project.

Fair enough. But now comes counter-party risk: the risk that the other party to the transaction, or perhaps you yourself, will not be able to hold up their side of the transaction.
About counter-party risk
So, you are about to enter into a transaction with another party. What might be the risks?
  • Trust: you may not know the other party well enough to convey trust, a willingness to believe what they say without the protections of a written agreement.
  • Ability to perform their side of the transaction may be in question. Do they have all the requisite tools, resources, and experience? Is something required of you in order for the other side of the transaction to be completed?
  • Willingness to perform their side of the transaction when the whole deal comes under stress may require backup
  • Lead, or being led? Really, who's in charge in this relationship? Can you say you really understand what you are getting into?  Warren Buffet famously said words to the effect: 'I never invest in businesses that I don't understand' 
What is your strategy; what are your tactics; what -- or who -- can you trust?
  • You might be able to trust if you can verify: Observable, measurable evidence that your counter party is doing their end of the bargain
  • Your strategy should be to keep the counter-party fully engaged with intent to fulfill their side of the bargain.
  • Your tactics should be to put in place standard risk management tools: Written agreements with incentives and penalties, and opportunity to observe and measure; sober assessments of their track record on similar activities; and perhaps insurance for consequential damages if the counter-party fails.
  • Always have Plan B in-hand: what if the counter party fails? What then? Can you exist or terminate the transaction? 
  • Are the terms spelled out for mutual agreement? Is it 'liquid' or is there a timeline for exit that has to be accounted for in planning?

Buy them at any online book retailer!

Monday, May 17, 2021

Trust, but not trusting

"They say" that trust is essential to any project team working effectively. To not trust is to layer on ineffective and non-value add efforts at surveillance, double checking, micro-management, etc and so on.

Yet, nearly all projects of any significant scope are organized hierarchically:
  • Some one is in charge
  • Others "report to ..."
  • Rules are a tool; they can substitute for face-to-face encounters
  • Trust is not really required because 'rules' enforce acceptable behaviors
  • Break the rules, and there are consequences. But, the consequences are usually time-limited. You get out of the dog house after you've served your time

Not so fast!

Hierarchies may be the on-paper way of organizing, but 'getting things done' requires networks; and networks are definitely not hierarchical. 

But networks run on trust, not rules. No trust ... no network, or least no network membership.

  • Oh, yes, there are consequences, but, no, there are no time limits. 
  • You may be in the dog house a very long time.

 And so here we are:

  • On paper: hierarchies and no trust required. Rules are all that is needed; and consequences if the rules are broken
  • In fact: networks are how people work; rules aren't need. But, if trust is broken, there are consequences. And those consequences are very long term.  

Buy them at any online book retailer!

Wednesday, April 14, 2021

Supply chain bollocks!

If you're working projects in the construction industry then you know what I'm talking about: supply chain constraints and missed or stretched schedules everywhere.
It may be time to dust off two ideas that are actually timeless:
  1. "The theory of constraints"
  2. "The Critical Chain"
Now as it happens, both of these ideas come from the same industrial theorist: Eliyahu Goldratt; and he wrote books -- well received and widely read -- about each one (*).

Theory of Constraints
Goldratt had two big ideas in his theory
  1. There's no point piling up "inventory" ahead of a constraint, only to have that "inventory" languish and possibly expire before it's sell-by date.
    This means don't work feverishly in one part of the project, only to have another part of the project constrain the utility of that work.
    Resources will be unnecessarily committed to tasks that could be done at another time.
    It's better to put those resources to work -- perhaps even on another project -- where their outcomes can be readily used. Matrix management anyone?

  2. If the constraint is really impacting outcomes in a material way to project objectives, then subordinate everything else to the task of mitigating the constraint.
    In a few words: don't accept the fact of the constraint; do something!
The Critical Chain
Most project managers have heard of this one. Even PMI talks about it. The ideas are these:
  1. Figure out the chain of events and tasks that comprise the path to the most important project outcomes. Often, such is the 'critical path' as defined by PDM methods, but not always. Unfortunately, "critical" and "important" do not have a common definition. Let's focus on "important" as the critical chain , and leave "critical" to PDM.

  2. Create 'buffers' -- or schedule slack -- between any activity that joins the important critical chain path. The buffer is there such that those less important activities do not impact the performance of the critical chain, even if they run over and thereby consume their buffers.

  3. And, create a buffer at the end of the critical chain such that any variance along the way is absorbed by the buffer. In schedule speak this is known as "under promise and over perform"

  4. Finally, and somewhat controversially in the age of Agile, centralize the oversight of the 'buffer budget' so that the budget is applied to the most important project objectives as determined by the high command in the project office.
(*) "The Goal" is the business novel that explains the theory of constraints
"Critical Chain" is also a business novel

Buy them at any online book retailer!

Sunday, April 11, 2021

AGILE: mixing methods

There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty.

This quote comes from a nicely argued case -- from the agile blog 'leading answers' -- for mixing agile methods in rather traditional businesses, like the oil and gas exploration/production business

If ever there was a business that benefits from Boehm's Spiral Model, OGM (oil, gas, minerals) is certainly one. (Disclosure: I hold some OGM leases in Texas, so I've a bit of personal experience with this)

So, what have you got here?
  • A lot of risk acknowledged up front (can't know everything -- thus the opening quote)
  • A need to run with pilot projects before committing to production
  • A need to tie into legacy systems (in the OGM case, distribution systems)
  • A lot of deliverables that can be done incrementally and then integrated
  • Small (it's all relative re small) teams, co-located, personally committed, with risk hanging on every move.
  • A degree of local autonomy required to meet the challenges of the moment
Sounds like an environment that needs agility, if not agile methods, on a lot of the stuff.

Of course, there's "one big thing":
You can't go around self-organizing (agile speak)willy-nilly! There's regulatory constraints everywhere and safety-first doctrine hanging on every move.

So, yes, there is a big bureaucracy that watches over... it's certainly more intrusive than a coach or a servant-leader (more agile speak)  (I'm sure they never heard this stuff in an oil field or an offshore rig!). In fact, I'll bet the rig boss is a force to be reckoned with!

Buy them at any online book retailer!

Thursday, April 8, 2021

When mysteries are progress

Got a mystery in your project?
Can't figure out what's happening, or
Can't find the root cause -- after following all the methodologies -- for what you measure or observe?

Perhaps you are making progress!
Stuff happens; don't deny; it's yours to figure out why
Once you do, you may have discovered something quite fundamental about the project outcomes 

There are lots of examples:
  • There is a lot of dark matter in the universe; why is there more dark matter than visible matter?
  • There are missing particles in the Standard Model of particle physics; where are they?
  • Why does the speed of light not conform to Newtonian physics (Einstein worked that out, fortunately)
  • Why does your bridge collapse after you built it with a lot of steel?
  • Why do team mates fly off the handle when you mention X or Y? (Note: no religion or politics in project teams)
 So, there are a lot of examples. What do you do about it?
  • Try Bayes methods of hypothesis testing ... make a prediction (perhaps, gasp!, a guess for lack of something better); test for results; change a parameter and look again. Repeat ....

  • Try models: why does the model work and the system doesn't? (NASA calls something like this 'model based system engineering -- MBSE')

  • Get out of the frame and look from a different vantage point. That's what Einstein did.

  • Try forensic engineering or investigation. This is micro-engineering at the nut and bolt level.

  • Change direction and do something entirely different (not retreat; just advance in a different direction)

Buy them at any online book retailer!

Monday, April 5, 2021

Leading without risk

Leading -- leadership -- without risk; without taking on risk?!
It can't be done.
End of posting.

Perhaps a bit more:
To be a leader is to put yourself out front ... exposed, as it were
And, out front you'll find there are no easy answers.
If there were such, leadership would be more like management: Follow the rules; stay within the guides; take little personal risk to reputation and career; work for a salary instead of a compensation plan.

But, to be known as a leader is too put at risk not only yourself but your project as well. 
And, you can't buy insurance for that sort of stuff.
If you can't step out front ... expose yourself to risk of failure and to making a wrong decision from time to time, then you should look for another line of work.
Need even more?
In fact, a whole book was written on just this theme:
Ronald Heifetz wrote "Leadership without Easy Answers"
Highly readable and very instructive. 

Buy them at any online book retailer!

Friday, April 2, 2021

When there's no Plan B

If there's no Plan B, then the first rule is "Make Plan A work!"
And it might require that you be aggressive about making Plan A work ... no fooling around.

No Plan B

Wait! Isn't there always a Plan B somewhere?
A general officer once told me: If there's no Plan B, invent it!

Insure for failure?

Maybe you can insure against the failure of Plan A. Perhaps that's your Plan B -- just get your money back, even if you forego the functional outcomes of a successful Plan A. 

But you can't go through life buying insurance for every risk. At some point, you need to ask the 'affordability' question. If affordable, don't insure it; otherwise, look at mitigations.

Losing function

But functional or relationship loss is altogether different. You can't buy insurance for that one. There really may be no Plan B.
What then?

When there's no Plan B, then you change behaviors

It's all well and good to follow the first rule: Make Plan A successful.

But mitigating a functional or relationship loss is often and largely about personal interactions, behaviors, personal risk taking, and pushing limits.
And only you can sort this; only you can assess the cost to yourself -- not necessarily dollars.

Think about the cost if there's no Plan B!

Buy them at any online book retailer!

Tuesday, March 30, 2021

Got to keep moving!

For some, boredom is the great fear. Got to keep moving!
"He had a function, an excuse for activity. For a few hours at least he wouldn’t be bored. ... he drank the coffee, which was still too hot. He reflected that the fear of boredom had driven him the whole of his life."
Ann Cleeves, Novelist

The fear or boredom was a driver ...
Frankly, I know how he feels

Add value
It shouldn't be motion for motion's sake
It should be about the utility of what you are doing
I need an activity plan for every day ... how will this day add value to what I am about?

About utility
Utility is the marginal difference between face value and the value you -- or someone else -- puts on what your are doing or offering. 

If you think about it, almost anyone can offer up face value if they have the skills for that domain, but if you are in constant motion -- avoiding boredom -- then that activity should be directed at more than just face value.

Even if it's just reading a book, the question is: how much better off are you for having engaged in that activity? For me, I read a lot of history because I think there are lessons there to be applied forward that will add value to my endeavors. And, of course, I might avoid a risk I might not otherwise understand.

If you are driven to activity ...
Make it count for something.


Buy them at any online book retailer!

Saturday, March 27, 2021

Risking the team

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

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!

Buy them at any online book retailer!

Wednesday, March 24, 2021

Backlog blocked?

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling is the culprit.

Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.
  • Loose coupling: there is some effect transference, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
  • Tight coupling: there is almost complete transference of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost no energy is lost flexing the frame.
In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.
Managing coupling is a task in risk management because coupling may introduce unwanted risks in the project or the product.

If coupling is a problem, how to solve it?
If coupling is a benefit, how to obtain it?
First, there's buffers to loosen coupling
The buffer -- if large enough -- absorbs the effect. For an excellent treatment of buffers in the PM domain, see Goldratt's  book "Critical Chain Method" for more about decoupling with buffers

Second, there are coupling objects
  • To avoid coupling, buffers may not do the trick.
  • But to enable coupling, we need some connectivity
In either case, think of objects, temporary or permanent, that can effect the coupling. A common example is seam in one fabric joining to another. The seam forms a "rip-stop" which prevents a ripping all down the fabric. 
One system that uses such a rip-stop is the sails on a boat: rip-stops are sewn into the sail fabric to prevent a total failure in the event of damage in one section, and thereby to decouple the damage from one section to another.
Now, move that idea from a sail to a backlog, using object interfaces for isolating one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in "Environment A" without strongly influencing "Environment B". 
Some caution advised: this is sort of a "us vs them" approach, some might say stove piping.

The case for tight coupling
Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:
  • Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
  • Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.
Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

Buy them at any online book retailer!

Sunday, March 21, 2021

Mentioned in Dispatches

In the British Army of yesteryear, it was an honor to be "mentioned in dispatches" from the front lines to the general HQ and the public at large

And so, I'm honored to be mentioned as one of the 130 top PM "influencers" of 2020 in a posting at the digital project manager site.

I can attest to many of those mentioned, many of whom I follow or subscribe-to myself, many of whom I have quoted in this blog. So, I stand in good company of many accomplished individuals in our field who have contributed to our professionalization. 

I commend to you this listing of PMs you might want to become acquainted with in your project work

Buy them at any online book retailer!

Tuesday, February 23, 2021

Agile means ....

Agile means:
  • ‘Agile’ means small teams, working collectively and collaboratively, with this mission: 
  •  To deliver frequent, incremental releases of innovative functions and features, prioritized for need and affordability;
  • Evolved iteratively from a vision according to user reflection and feedback;
  • And produced at the best possible value.(*)
Agile ideas to keep in mind
  •  Requirements are too important to be left to the beginning; they must be evolved with user interaction and interpretation as all the implications come into view
  •  Process emerges to fit the circumstances; control metrics are empirically determined, not defined by historical performance in the manner of Six Sigma (**)
  • Planning is very important but following the plan is not as important as satisfying the customer
Agile works better when...
  • Agile is the better method when requirements are changing, unknown, or unknowable until seen (I won't know it until I see it).
  • Agile methods are best when in situations of fewer than a handful of small teams, typically fewer than 50 developers
  • Agile methods work better in-house than through the constraint of a contract
  • Agile works better with co-located teams than though the cultural translation and limited communications channel of a virtual team

(**) Six Sigma is a ‘defined control’ methodology consisting of a multi-step problem identification practice and a defect control standard formally stated as requiring less than 3.4 million defects outside control limits per million opportunities.  The actual control limits are determined by analysis and by historical measurements

(*)  In this posting, innovate functions and features encompasses product base, product, system, deliverables, and outcomes; these terms are frequently used interchangeably.   

They all refer to whatever it is that the user or customer owns or uses at the conclusion of the project.  The projects applicable to Agile methods are software intensive, but may have many and complex hardware components.  

Buy them at any online book retailer!