Agile and DCF

In my musings about agile, one advantage is that benefits come quicker, and therefore are less susceptible to the risks of future uncertainties, since the future is more uncertain than is the near term.

If benefits are monetized by cash flow, then finance guys have a term for cash benefits subject to the risk of time: discounted cash flow, DCF.

So what is DCF and how does it work? (You can find more about this in my posting at PMHut) In a few words, the idea of a 'discount' is to value less a benefit in the future when compared to a like benefit in the present -- the financial equivalent to a bird in hand vs a bird in the bush.

The future is where uncertainties lurk. The so-called 'cone of uncertainty'.  It's just not a deflated dollar; it's also market uncertainties, the varagies of customer delight, and competitive effects.

---

What's the Agile connection to DCF? Answer: incremental deliveries, each with some value to the customer or the business, and each delivered a little bit earlier than waiting til the end. Thus, more timely means less risky; thus, less discount.

I covered this in detail here:

 

Bookmark this on Delicious

Nothing good happens at a milestone

---

Nothing really good happens at a milestone (read: also, gate). It's that simple (is there any need to read on?)

 

Why so? Because too many things have to come together to have success. At a milestone (gate), seemingly independent activities have their fate joined. At the milestone, everyone is in, or else everyone is stymied.

 

In fact, I challenge my risk mangagement students (PMI's eSeminarWorld Advanced Risk Management) with this question: "Has anyone ever successfully achieved a milestone with either everyone ready to participate, or no deficiencies deferred forward?". After hundreds of responses, I've had one student answer affirmatively.

 

Here's one rule of thumb:

Joining together at a common event, like a milestone, is hazardous because of the concept of ‘merge bias’. Merge bias simply means there is a strong tendency to slip to the right at a milestone, thereby stretching the schedule.

• In other words, when you look at a schedule and you see a milestone, think immediately that there is a risk to shift right—that is, milestones are hazards to on-time performance.
• They are the first weakness to look at when assessing the schedule for risk
   

As long as were're doing rules of thumb, here's another:
It’s common sense that the more independent an activity is, the more freedom of action there is. After all, there is minimum need to coordinate outcomes and processes if no one else is depending on your production. So, by corollary, dependencies (like those imposed at milestones) limit choices, and place constraints where there would not otherwise be inhibitions.

 

Dependencies increase the effort that must go into coordination—team of teams, staff meetings, and the like—and this effort must come from some budget, so that means other budgets are reduced as dependencies go up.

 

And, don't forget distractions: potentially the distraction of more coordination could impact other value-add work.

---

 

Lies, damn lies, and statistics:
It’s no accident that milestones tend to shift to the right on the schedule. There is actually a mathematical explanation for this phenomenon that arises from the statistical behavior of risky activities.

 

In statistics, the explanation comes from behavior of intersections and unions of events. A union is an ‘or’ case; an intersection is an ‘and’ case. A milestone is an intersection of two or more joining tasks.

 

Statistics defines the intersection of independent events by the product of their probabilities.

 

Independence is a big deal to statisticians; less so to project managers: T
For the statistician, there is no general formulation for the statistics of an intersection if the events are not independent. If they are not, then the only practical way to determine the performance of the intersection—in our case, the milestone—is to simulate the project by running many trials.

 

For the project manager, Simulation is no big deal. There are add-ins for simulation in all the popular scheduling and budgeting tools.

 

And, if there is not independence, at least for PMs, the "product of probabilities" thing is often "good enough". What it really means is that we should not be trapped by the cognitive bias of overestimating success at the milestone: it's always going to be worse than expected.

---

So, what's a PM to do? First to mission: Defeat all unfavorable forecasts! DDo not sit back and accept the inevitability of shifting right.

• You can reorganize the schedule logic
• You can put in buffers
• You can retool, retrain, re-resource to change the odds
• You can have a process for carrying deficiencies forward without impairing tthe critical path

In short, you can act!

 

 

 

 

 

 

 

 

 

 

Take a look at this slideshare presentation for more information

 

 

 

Ideas for Managing at the Milestone

 

 

View more presentations from John Goodpasture.

Bookmark this on Delicious

C-R-A-C-K (as in Agile customer)

---

What's a CRACK Agile customer you might ask?

 

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

 

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

Good grief! Why keep this in the agile space? Doesn't eveyone want a CRACK customer? How could it be otherwise?

If you're curious about the agile/traditional thing, and agile stuff in general, take a look at other Boehm'isms on agile in his book, with Richard Turner, "Balancing Agility and Discipline: a guide for the perplexed", published by Addison-Wesley in 2004. It's got some really good things to offer.

 

Bookmark this on Delicious

Abduction, anyone?

If you're not a regular reader of BusinessWeek you may have missed the January 14th (2010) missive in their regular Innovations column. Here we have one that is close to the heart of many project managers:

the accidental nemesis to a really new-to-the-world idea, or as the authors put it: the 'accidental enemy'

In their column, entitled "Innovation's Accidental Enemies", authors Roger L. Martin and Jennifer Riel , academics at the Rotman School of Management at the University of Toronto , posit that too many executives manage when they should lead: to wit, they rely too often on inductive and deductive reasoning.  They fail to embrace abductive reasoning when confronted with a never-done-before idea for project excecution.  In doing so, they become the accidental enemy of a radically new idea.

What, say you, is abductive reasoning?  It's the third leg of inductive, deductive, and abductive reasoning.  One only needs to search a bit in Wikipedia to get the ideas.

Inductive and deductive reasoning are the two we're most familiar with; they align rules and data--either the rules beget the data, or the data begs the rules. These situations are a traditional manager's view of putting the enterprise's rules with the situational facts.  Nothing wrong with that---some of my best friends are inductive or deductive reasoners--but even though one or the other works well in many situations, they don't always work when innovation is the order of the day.

• Innovative ideas many times do not comport with established rules.  That lets out deductive reasoning. 
• Innovative concepts are often free of facts, and seemingly lack cohesion and coherence among the available data.  That lets out inductive reasoning.

So, what do you do when faced with seeming unrelated facts or ideas that don't appear to connect? Abduction reasoning may be an approach.  To reason abductively is to postulate or hypothesize a situation that might be rational or consistent for what is known, but it may require a few leaps over the missing. Thus, it may be necessary to fill in the plot holes, as it were.

Haven't we heard endlessly about connecting the dots?  Well, having a skill, and a tolerance, for the emergence of a new idea by abductive reasoning is key to having visionary foresight. In an article in Strategy+Business, authors Tim Laseter and Saras Sarasvathy call making something out of seemingly nothing (or a lot of somethings that don't seem to relate) "constructive transformation". (I've not heard that one before, but I'm always open to a new idea). According to their idea, constructive transformers:

"... use the vagaries of fate to help them proactively shape their environment."

The genius of innovators is not to let their management impulses overwhelm their instincts to inspire, motivate, and empower.

Marc Andreessen--innovator and venture capitalist extraordinaire--said something similar in a recent interview: the mission of technology companies is to innovate, in effect: to continuously renew, even if it means to renew with legacy destruction.

Recall this witicism from RAdmiral Grace Hopper [esteemed software leader who, among other things, invented the 'bug']:

"Things are managed; people are led"

Bookmark this on Delicious

That agile governance thing

---

We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don't let yourself be lulled into inaction.

Bill Gates

I wonder if Bill's quote is on Ballmer's wall somewhere next to MS's strategic plan for mobile computing?

You have to wonder if their governance, given their size, is open enough to innovation? Surely, all the look-ahead trend setters are not exclusively in Silicon Valley.

Maybe they need to be more agile?

Governance and agile methods may seem like an oxymoron—but not so. A means to govern is essential for orderly project functioning. Without governance, the advantages of adaptive and evolutionary methods could be overwhelmed by functions bolted together haphazardly and rendered operationally ineffective, expensive to maintain, and not beneficialdisadvantageous to customers and stakeholders

Governance 'should's'
•A governance program should be purposeful about maximizing the business potential of a project.

•Governance should be dedicated toward minimizing the risks to business performance.

•A governance program should enable and promote innovative and imaginative solutions, and

•Governance should deter behavior that strays too far from norms.

In short, a governance program exists for five reasons that are in effect the governance mission statement:

Governance Mission

1. To oversee and approve investment on behalf of business beneficiaries;

2. To codify decision-making rights to enable make it possible for teams to have autonomy and freedom of maneuver;

3. To enable and promote innovation, evolution, and technical excellence within the framework of architecture and operating norms;

4. To be the ultimate arbiter of risks that affect business performance and accountability; and

5. To provide accountability for compliance to mandatory standards.

Governance is built on quality principles. Four principles guide an effective governance implementation:

Governance Principles

1. Proportionality: Governance should be applied proportionately to the amount at stake.

2. Clarity: Governance should provide clarity for mission and purpose, scope boundaries, decision-making authority, and decision rights.

3. Subsidiarity: Governance should respect the principle of subsidiary function: governance should not intrude into the management of functions that are best left to functional and project managers.

4. Lean: Governance must be lean, timely, and responsive, respecting agile principles to provide enough, but ‘just enough’, oversight and control to accomplish the governance mission.








A project management tip: Decision policy for the project manager

• The simplest policy for decision making is... always make a best-value decision based on the collective value of the risk-weighted factors

• When deciding among alternatives, pick the alternative that informs the business most favorably, even if there is suboptimum result for the project

Bookmark this on Delicious

Wicked isn't evil

---

I've been thinking about some unreasonable problems. Some call them 'wicked'. The wicked problem isn't evil. The wicked problem is one where the issues interlock and become interdependent, perhaps even circular: the infamous Catch 22. There's no definitive statement of the problem. In fact, until the problem a solution is proposed, you may not know what the problem is!

In a wicked situation, the solution defines the problem

Climate change may be the ultimate wicked problem of our age. Where do you start? Where do you end? Everyone has a stake, and so everyone is going to be touched; some will lose and others won't.

Actually, in the public policy domain, wickedness is all too common. So, what does a project manager do?

There are a few things that seem to work

• Assemble a coalitionn of the willing. Keep the number of stakeholders as small as possible
• Lead with a solution rather than the problem; solve things bottom up. The solution finds its problem, as it were
• Create a sense of urgency so momentum builds
• Keep the scope contained; do small-ball things to get started

Some get at this problem with the IBIS, the issue based information system. You can learn more by viewing my IBIS slide share (below) or take a read through this posting from Eight to Late. You'll read this:

IBIS consists of three main elements:

• Issues (or questions): these are issues that need to be addressed.
• Positions (or ideas): these are responses to questions. Typically the set of ideas that respond to an issue represents the spectrum of perspectives on the issue.
• Arguments: these can be Pros (arguments supporting) or Cons (arguments against) an issue. The complete set of arguments that respond to an idea represents the multiplicity of viewpoints on it.

There are some graphical tools that go along with this, and they are discussed and displayed in the posting.

The Wicked Problem

View more PowerPoint from John Goodpasture

Bookmark this on Delicious

Central vs decentralized change management

When I talk to project managers about protocols for change management, they all gravitate to central management. The reasoning is consistent: they see a need for a holistic systems consideration of any project change. Who can blame them for that?

And, when I talk to team leaders, they tell me the workflow through central management is too slow, the experts are not "up there", and we (team leaders) have to explain it all to 'them' anyway. They make the same decision we would, so where's the value add?

And, of course, as in all things like this, the answer is: YES.

It's all a matter of judgment about impact. Of course there's a place for the systems view, and of course the team is very capable of trapping many small changes before they clog the workflow to the high command.

But I'm really surprised at the few PMs or team leaders who see it this way. It seems all or nothing in their mind. I wonder what's in the water there're drinking. To me, it's all about reasoned delegation--do only what only you can do.

Bookmark this on Delicious