10 Agile Strengths

Just to be fair to both side of the agile issue, my first post on agile "top ten" was about agile weaknesses, though I broke my own rule and started on a negative theme. However, as regular readers of this blog know, under the right circumstances, I am an agile proponent. Just check the sidebar for all the agile articles on this blog.

So, here's my top ten reasons why agile has worked for me [of course, the agile community has the manifesto that is the community wisdom on this]. And because something is on this list does not mean it can't also be on a more conventional methodology list:

1. Agile is a "best value" method: it's doctrine is centered on value and accomplishment for the customer and user, not so much adherence to cost and schedule--though the sponsor's investment can not be exceeded, so cost is at least capped

2. Agile respects the urgency and importance of priorities conveyed by the customer/user, most prominently by incremental delivery and flexible sequencing

3. Agile respects the power of emergence and iteration to drive innovation, provided the customer buys-in

4. Agile puts the customer in the driver's seat for the value agenda of the project.  By doing so, the project is more "Juran" than "Deming" in its quality orientation.  The PM does not forfeit the responsibility to manage the application of resources and the risks of accomplishment--thus the PM's mission: deliver the most value for the invested resources, taking reasonable risks to do so

5. Agile is more bottom-up than top-down as a matter of doctrine.  There's a bit of the "wisdom of the crowds" in the way that small teams are given opportunity to find solutions, and there's a bit of small unit tactics--as practiced by the largest command and control organization of them all....the U.S. military--that put a lot of minute to minute decision making with the bottom of the WBS.

6. Agile has the potential to more effectively align business planning-and-execute cycles with project cycles.  Business cycles are often scheduled well in advance and are often calendar driven [it's July, so let's kick-off the AOP process for the next FY].  Projects, with their uniquely different scope, one to the next, benefit from agile alignment with the business.

7. Consistent performance by small teams of participants that work together continuously is highly valued. Such consistency means that PMs can depend on throughput benchmarks that are statistically meaningful.  Benchmarks then enable throughput accounting.

8. Agile respects the objective behind earned value: Say up front what you are going to do, and then do it.  No partial credit.  Either it works or it doesn't.  Of course, EV is best applied at the time-box level since agile doctrine allows and encourages personal flexibility within a time-box.

9. Agile respects the common sense that all requirements can not be known at the outset, particularly when the outcomes are intangible and subject to an evolving understanding.

10. Agile gets the benefit stream flowing sooner, so the time displacement between need and delivery is manageable at lower risk.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Award Fee, Incentive Fee, Fixed Fee

If your project does any contracting, then you're no doubt aware that fee--aka "profit", aka "incentive"--is either a cost, part of an investment, or a project management tool that can help drive results...no surprise: the latter is my bent. 

But there's a new 'hat' to go with these 'old hats':  a relatively new project idea of incentive built around prizes [more about that later]

And, there's been no repeal of the law of unintended consequences: people [and organizations] will act to maximize their benefit, some times in contravention of established processess and protocols.  Although people have friends, they also have interests. More important: organizations only have  interests.  Incentives set in motion and influence behaviors--personal and organizational--and sometimes those behaviors are unintended and unacceptable.

My advice:

• Never put incentives in place without doing a behavior countermeasures analysis [what would you do to maximize your benefit?  What would others do?]. 
• And, as simple as it sounds, do not put incentives in place that conflict with each other [an example from my own contractor experience: cost incentive and best value incentive on the same contract]
• And, never put incentives in place where the situation is compromised with conflicts of interest.

Firm Fixed Price
Maybe you do all your contracting as 'firm fixed price'--FFP. In that case, you'll have no insight to the fee, but be assured, it's there.

Actually, in FFP you are paying two fees: one is the contractor's forecast profit on the forecast cost; the second is the contractor's charge for accepting the transfer of risk from the project to the contract. Think of this second fee as an insurance premium, except that you, as project manager, have no insight to the premium you're paying. Your recourse is to obtain competitive bids and let market dynamics set these fees for you

Other fee arrangements
On the other hand, if you are not contracting FFP, but using a more imaginative vehicle that gives you some insight and control over the incentives, then you have a decision to make: incentive fee, or award fee?

Incentive and Award Fee
Incentive fee arrangements have historically been used to reward behavior--or, at the very least, forestall bad behavior.  But most incentive fee arrangements are on cost or schedule, something entirely objective, and not on value per se.  In fact Federal contracting requires that incentive fee be applied first to cost before other considerations.

However, award fee arrangements--around for at least thirty years--are designed to place incentives on value to the contract beneficiary--value being a larger concept than just cost.  Value does not always have to be objective, and the value proposition can change over the course of the contract, providing the project manager with a much more nimble tool that the rather blunt instruments of fixed fee and cost-driven incentive fee. 

It's obvious that award fee is more difficult to administer.  First, for each award fee period during the contract [and periods do not have to be equal length], as project manager, you are obliged to furnish the criteria for earning fee to contractor.  And, at the end of the period, the contractor is obliged to furnish proof of performance that you then are obliged to evaluate fairly. 

The evaluation is almost always 'analog'--that is, fee is awarded on a sliding scale, rewarding just that part of performance that is meritorious.  This means that the award fee is always at risk, and some is likely to be 'lost' at each award period. Sometimes, 'lost' fee can be 'rolled over' to provide a end-of-contract incentive.

Prize Fee
And now comes a relatively new entrant: prize fees  [new, if you don't count what the British offered in the 18th century for a better way of measuring longitude].  Many have heard about the "XPrize" phenomenon that began with a $10M prize for a reusable space craft that could reach 100KM altitude, now extended to other endeavors. 

But now, some corporations looking for corporate solutions to everyday problems are going the prize route: witness 55,000 entrants for Netflix's search for a better algorithm to suggest movies to its subscribers.  A recent article has described an almost exponential increase in doing projects the prize way...to wit: the ultimate agile way.  State a vision, put up the investment, set a milestone, and get out of the way!

And, they're not all millions for billionaire financiers like Paul Allen.  Some serious results accrue with prizes as small as $10K.  And generally it's been observed that any prize activity brings a lot of activity--critical thinking and innovation--even from the losers.  In fact, the losers line up at the patent office.

Maybe there's something to this for the agile visionary.

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

10 Agile Weaknesses

I'm an agile proponent, but I'm a 'small "a"' agilist. I've done "it" in an an enterprise setting, and I've written about my experience with it. So, Donald Patti's blog on PMHut caught my eye: "Ten Weaknesses of the Agile Methodology".

From my experience, his is a sober assessment that is worth a read since to be successful with agile you need to think about the mitigations.

However, to help you along, in a couple of days, I'll give you my 10 Agile Strengths to counterbalance Patti's list.

I'll leave to Donald's blog to explain these, but here are his ten, some of which [like #2, #3] sound like they should be--could be advantages but they can be weaknesses in the wrong circumstances.

And, be careful reading too much into some of these, like #7. 7 is really referring to refactoring. Refactoring is a way to meet quality standards; by other names it's been around long before anyone thought of agile per se:

1. Agile is rarely practiced
2. Heavy customer interaction is needed
3. Agile thrives with co-located teams
4. Agile has difficulty scaling
5. Agile is weak on architecture planning
6. Agile has limited project planning and measurement
7. Agile requires more rework
8. Challenges making contractural commitments
9. Agile increases potential threats to business continuity and knowledge transfer
10. Agile lacks the attention to outside integration

Other than that Mrs. Lincoln, how did you like the play?

 Bookmark this on Delicious

Are you on LinkedIn? Share this article with your network by clicking on the link.

Contract concepts Part III

This is Part III of our series on contract concepts.

Today: "The Elements Of A Contract"

A contract is mutual agreement, either oral or written, that obligates two or more parties to perform to a specific scope for a specified consideration usually in a specified time frame. The operative idea here is mutual agreement.

A contract cannot be imposed unilaterally on an unwilling supplier. In effect, as project manager you cannot unilaterally declare the project to be in contract with a supplier, have an expectation of performance, and then return later and claim the supplier is in breach for not performing. At first blush this may sound absurd, but unacknowledged purchase orders and email directives are not contracts until they are accepted by the performing party.

Therefore, it is generally understood in the contracting community that the following five elements need to be in place before there is a legal and enforceable contract:

• There must be a true and valid offer to do business [with a supplier] by the project or contracting authority

• There must be a corresponding acceptance of the offer to do business by the supplier’s contracting authority

• There must be a specified 'consideration' [something of value to be exchanged] for the work to be performed. Consideration does not need to be in dollar terms. Typical contract language begins: “In consideration of _________, the parties agree…………”

• The supplier must have the legal capacity and ability to perform. That is the supplier may not materially misrepresent their ability to perform.

• The statement of work must be for a legal activity. It is not legal to contract for illegal activity.

 Bookmark this on Delicious

Are you on LinkedIn? Share this article with your network by clicking on the link.

Contract concepts Part II

This is Part II of our series on contracts.

Today: The main ideas embedded in contracts, organized in three basic concepts:

1. Completion vs best effort:  It may seem strange to those outside the contracting community, but sometimes a contractor doesn't have to complete anything or everything--or at least there is no contractual obligation to complete anything or everything. Contracts for indefinite [to include agile or evolutionary] scope, uncertain requirements, basic research, exploratory risk reduction, and other such objectives only require a "best effort" from the contractor.  Obviously, the contractor is going to get a big "atta-boy" if they do complete something, but requiring a contractor to 'complete' the work requires a pretty good definition of the work in the first place.

On the other hand, if the scope is firm [or firm enough] then the contractor should be required to complete the work, and the contractor should have no reticence to accept the responsibility and obligation to complete the work.

2. Fixed price vs cost reimbursable: the contract price can be fixed [that is, made firm] if the contractor can be given a reasonable expectation of all that is required of performance and delivery; otherwise, it is unwise and impractical to 'fix' the price.  Contracts with elastic price are called 'cost reimbursable', although that is a simple label for a whole class of elastic contract vehicles. 

The chart below says the project can transfer 'all' the cost risk to the contractor in a fixed price contract.  That's not really the case since the project can't ever transfer all the risk--to wit: the contractor may still fail to perform.  So, if the project retains some of the performance risk, [and all of the performance responsibility] then the project retains some of the cost risk as well. 

Nevertheless, if the performance and delivery is fixed--in other words, the value proposition of the contract is known and fixed--then the cost [representing value] can be fixed for that contract instance.  [Next-Gen tanker aircraft, anyone?]

3. Time and materials: this is a pay-as-you go strategy; there's no commitment to completion, but a worthy contractor should commit to best effort.

Next: Contract concepts Part III
 
Click on the image for a more readable picture

 Bookmark this on Delicious

Are you on LinkedIn? Share this article with your network by clicking on the link.

Contract concepts Part I

So, you think you need to do a contract to get the project done.  A lot of projects use contracts, no doubt of that.  But, sometimes the contract objective is not all it seems to be.  Sometimes, a contract is a policy choice rather than a technical choice. 

Be aware: Contracts between suppliers and the project team are commonly employed to accomplish three objectives:

• Change the risk profile of the project by transferring risk from the project team to the supplier. Presumably a due diligence examination of the supplier’s ability to perform confirms that the supplier has a higher probability of accomplishing the scope of work in acceptable time at reasonable cost than does the project team.
   
• Expand the capacity of the project and perhaps add to the capability of the project by hiring the help by means of a contract.
   
• Implement policy regarding sharing the project opportunity with participants in the supply chain. If the contract is related to a public-sector project, public policy regarding small business and minority business participation may be operative on the project team. In the private sector, there may be policy to involve selected suppliers and customers in projects, or there be policy to not involve selected participants in the project.

We would all hope that deciding whether or not to use a contract is itself a matter of following decision process and adhering to a decision policy.  For the most part, that would leave politics out of it.  Presumably, the policy says in one form or another: "decide in a manner that is most advantageous to the accomplishment of the project goals".  Who could object to that?

 Bookmark this on Delicious

Are you on LinkedIn? Share this article with your network by clicking on the link.

Your schedule is Your Swiss Army Knife

A few years ago I did a presentation that was one part tongue-in-cheek and one part serious about the fact that the typical schedule tool makes the project schedule a Swiss Army knife of information.  The missing 'tool' is quantitative risk analysis.  The presentation is about how to add that important element

Here are the charts

Bookmark this on Delicious

Share this article with your network by clicking on the link.

Our friend Bayes -- Part IV

This is the last of our series on Bayes Theorem of conditional probabilities. If you missed Part I, II, or III, click to go directly to them.

We ended Part III with this grid:

Graphically, the situation is represented in the figure below. Note how the light blue area is 54.8% of the total area; it is the test success area. Note there is a sliver of light blue, representing 2% B+ | A-, in the 'bad weather column'.  The ratio of the good/bad weather is 60/40, per the example in this series.

To fully understand the figure and the example we have been discussing, it's important to realize that the dependent event, testing, occurs in an opportunity space that is defined by the independent event (or condition), which in this case is the weather.  So, good results are forecasted to be attained in 54.8% of the opportunity space.

In this part, we address a few Tricks and Traps:

• It's often confusing to properly identify 'A' and 'B' and the cause-and-effect between them.  After all, in our example of test results and the weather, we hypothesize a dependency, but is there really an effect from the alledged cause? 
• The single largest confusion is misunderstanding the difference between 'B+ | A+' and 'B+ and A+'.  One is a conditioned probability and the other is the chance of an intersection between conditions. 
• Validating the independence and dependence of the events or conditions in the Bayes' Grid is sometimes no easy task. 
• Validation of the grid is the single most important analytical thing to do.  The Grid will not numerically add properly if the events are not defined correctly because the observation data won't fit properly into the Grid.
• The grid has four unknowns, A+, A-, B+ and B- so four equations are needed.  Usually three independent relationships, and the data observations to go with them are required. In our example, we observed the weather, the 90% test success during the 60% chance of good weather, and the 2% test success during bad weather.  We were able to compute other relationships without observations.
• You can enter Bayes' Grid with with different sets of observations.  The ones in our example are typical but other observation sets are possible.

Bayes' Grid is not my invention; it's been written about for years and can be found in many statistics books.  Another web link that explains it pretty well is under this click.

Bookmark this on Delicious

Share this article with your network by clicking on the link.

Scaling up

Here's a favorite quotation that gives pause to the 'big thinker'

We must not, in trying to think about how we can make a big difference, ignore the smalll daily differences we can make which, over time, add up to big differences that we often cannot foresee

Marian Wright Edleman

 Bookmark this on Delicious

Are you on LinkedIn? Share this article with your network by clicking on the link.

Our friend Bayes -- Part III

In this Part III [of IV] of our series on Bayes we complete the Bayes Grid. If you missed Part I or Part II, you can click to catch up.

Bayes' Grid
Here's where we left off in Part II. 'A' is an independent probabilistic event, in this case the weather, and we have empirical observations that give us the probability of good weather, 'A+', as 0.6 .  We are seeking information about the project test results, B, for which we have one project observation: the conditional situation of  'B+' when 'A+' is present, 90% probable.  And again, this is not an intersection of two events--good weather and good results happening in the same timeframe--it's a dependency: good results because of good weather.

Now, as we said in Part II, without another independent observation, we can go no farther. 

New observation
Let's assume that in the course of testing, the test manager observes that given bad weather conditions, 'B+ | A-', the B+ success rate is 2%, thus showing that even given the condition of "the weather is not favorable", there are positive test results. 

Take note: the 2% success of 'B+ | A-' may be erroroneous results.  In other words, the test may be designed to fail if the weather is not good [ie, test results are dependent on weather which is our theme for this example].  Or, there may be a misunderstanding of cause and effect.  In any event, again we return to Bayes' equation:

P(B+ | A-) = P(B+ and A-) * P(A-) = 0.02

Solving for the intersection, we find

P(B+ and A-) = 0.008

Using the result from above and the grid math to compute 'B- and A-' = 0.392, we now have this grid:

Grid results

The computed figures in the light blue column adjacent to the test results arise from the grid math that requires all columns and rows to add.

We also can validate this grid: the dark blue cells sum to 1.0.  They sum to their counterparts in the light blue by column and row, and the light blue columns and rows sum to 1.0.  All space has been accounted for.

We now have a result for the elusive B+: We see that 54.8% of the time the test results will be good, and 54% of the time good results will coincide--that is, intersect--with good weather.  In fact, if the weather is good, as it is 60% of the time, then we forecast 90% test success.

To be continued
In the final Part, we'll address a few tricks and traps in this method, and provide some insight to the what the grid is telling the risk manager.

Bookmark this on Delicious

Customer Satisfaction

Here's a quotation on customer satisfaction that says a lot for my way of thinking:

If the customer is not satisfied, he may not want to pay for our efforts. If the customer is not successful, he may not be able to pay. If he is not more successful than he already was why should he pay?

A quote from Niels Malotaux

Bookmark this on Delicious

Share this article with your network by clicking on the link.

Our friend Bayes -- Part II

In Part I of this series, we developed the idea that Thomas Bayes was a rebel in his time, looking at probability problems in a different light, specifically from the proposition of dependencies between probabilistic events.

In Part I we posed the project situation of 'A' and 'B', where 'A' is a probabilistic event--in our example 'A' is the weather--and 'B' is another probabilistic event, the results of tests. We hypothesized that 'B' had a dependency on 'A', but not the other way 'round.

Bayes' Grid

The Figure below is a Bayes' Grid for this situation. 'A+' is good weather, and 'B+' is a good test result. 'A' is independent of 'B', but 'B' has dependencies on 'A'. The notation, 'B+ | A' means a good test result given any conditions of the weather, whereas 'B+ | A+' [shown in another figure] means a good test result given the condition of good weather. 'B+ and A+'  means a good test result when at the same time the weather is good. Note the former is a dependency and the latter is a intersection of two conditions; they are not the same.

  

The blue cells all contain probabilities; some will be from empirical observations, and others will be calculated to fill in the blanks. The dark blue cells are 'unions' of specific conditions of 'A' and 'B'. The light blue cells are probabilities of either 'A' or 'B'.

Grid Math

There are a few basic math rules that govern Bayes' Grid.

• The dark blue space [4 cells] is every condition of 'A' and 'B', so the numbers in this 'space' must sum 1.0, representing the total 'A' and 'B' union
• The light blue row just under the 'A' is every condition of 'A', so this row must sum to 1.0
• The light blue column just adjacent to 'B' is every condition of 'B' so this column must sum to 1.0
• The dark blue columns or rows must sum to their light blue counter parts

Now, we are not going to guess or rely on a hunch to fill out this grid. Only empirical observations and calculations based on those observations will be used.

Empirical Data

First, let's say the empirical observations of the weather are that 60% of the time it is good and 40% of the time it is bad. Going forward, using the empirical observations, we can say that our 'confidence' of good weather is 60%-or-less. We can begin to fill in the grid, as shown below.

In spite of the intersections of A and B shown on the grid, it's very rare for the project to observe them. More commonly, observations are made of conditional results.  Suppose we observe that given good weather, 90% of the test results are good. This is a conditional statement of the form P(B+ | A+) which is read: "probability of B+ given the condition of A+".  Now, the situation of 'B+ | A+' per se is not shown on the grid.  What is shown is 'B+ and A+'.  However, our friend Bayes gave us this equation:

P(B+ | A+) * P(A+) = P (B+ and A+)  = 0.9 * 0.6 = 0.54

Take note: B+ is not 90%; in fact, we don't know yet what B+ is.  However, we know the value of 'B+ and A+' is 0.54 because of Bayes' equation given above.

Now, since the grid has to add in every direction, we also know that the second number in the A+ column is 0.06, P(B- and A+).

However, we can go no farther until we obtain another independent emprical observation.
 

To be continued

In the next posting in this series, we will examine how the project risk manager uses the rest of the grid to estimate other conditional situations.

Share this article with your network by clicking on the link.

 Bookmark this on Delicious

Our friend Bayes -- Part I

Our friend Bayes, Thomas Bayes, late of the 18th century, an Englishman, was a mathematician and a pastor who's curiosity led him to ponder the nature of random events.

There was already a body of knowledge about probabilities by his time, so curious Bayes went at probability in a different way. Until Bayes came along, probability was a matter of frequency:

"How many times did an event happen/how many times could an event happen". In other words, "actual/opportunity".

To apply this definition in practice, certain, or "calibrated", information is needed about the opportunity, and of course actual outcomes are needed, often several trials of actual outcomes.

Bayes' Insight
Recognizing the practicalities of obtaining the requisite information, brother Bayes decided, more or less, to look backward from actual observations to ascertain and understand conditions that influenced the actual outcomes, and might influence future outcomes.

So Bayes developed his own definition of probability that is not frequency and trials oriented, but it does require an actual observation. Bayes’ definition of probability, somewhat paraphrased, is that probability is...

The ratio of expected value before an event happens to the actual observed value at the time the event happens.

This way of looking at probability is really a bet on an outcome based on [mostly subjective] evaluations of circumstances that might lead to that outcome. It's a ratio of values, rather than a frequency ratio.

Bayes' Theorem
He developed a widely known explanation of his ideas [first published after his death] that have become known as Bayes' Theorem. Used quantitatively [rather qualitatively as Bayes himself reasoned], Bayesian reasoning begins with an observation, hypothesis, or "guess" and works backward through a set of mathematical functions to arrive at the underlying probabilities.

To use his theorem, information about two probabilistic events is needed:

One event, call it 'A', must be independent of outcomes, but otherwise has some influence over outcomes. For example, 'A' could be the weather. The weather seems to go its own way most of the time. Specifically 'good weather' is the event 'A+', and 'bad weather' is the event 'A-'. 

The second event, call it 'B', is hypothesized to have some dependency on 'A'. [This is Bayes' 'bet' on the future value] For example, project test results in some cases could be weather dependent. Specifically, 'B+' is the event 'good test result' and 'B-' is a bad test result;  test results could depend on the weather, but not the other way 'round.

Project Questions
Now situation we have described raises some interesting questions:

• What is the likelihood of B+, given A+? 
• What are the prospects for B+ if A+ doesn't happen? 
• Is there a way to estimate the likelihood of B+ or B- given any condition of A? 
• Can we validate that B indeed depends on A?

Bayes' Grid
Curious Bayes [or those who came after him] realized that a "Bayes' Grid", a 2x2 matrix, could help sort out functional relationships between the 'A' space and the 'B' space. Bayes' Grid is a device that simplifies the reasoning, provides a visualization of the relationships, and avoids dealing directly with equations of probabilities.

Since there's a lot detail behind Bayes' Grid, we'll take up those details in Part II of this series.

Photo credit: Wikipedia

Facts and the future

"Facts do not cease to exist because they are ignored"

Aldous Huxley

Huxley's point is a good one: inconvenient truths, to paraphrase a popular idea, are like the tree falling in the forrest: there is still a sound, even if nobody is around to hear it.

But they are only facts if they are in the past. To quote David Hulett: "There are no facts about the future, only estimates"

So beware: the past holds the facts; the future holds only estimates, and estimates are only known within a range of uncertainty.

Bookmark this on Delicious

Share this article with your network by clicking on the link.

Sausage making

It seems like the popular media and the spread of real-time networking has exposed sausage making [i.e. "the process"] to many new initiates that had no idea "that's how it's done". To many, the details of "getting there" are disconcerting, even disgusting. Unfortunately, many get caught up by the drama of the process and overlook the value of the results.

Projects are not immune: many stakeholders are exposed to project processes like never before. Dashboards, elaborate workflow engines, tweets from embedded associates, and all other manner of project detail is now 'out there'.

The key to success in the more transparent environment is the same key as before: focus on results and accomplishments. Be sure that value is only earned--and credit given--for results, not for process and effort.

In the end, the process will be forgotten; even heroic efforst will be forgotten, but results--delivered to users, customers, and stakeholders--will be a permanent memorial to the success of the project.

Photo: wickenden/flickr

Bookmark this on Delicious

Share this article with your network by clicking on the link.

Favorite quote: Time

"There is no undo button for our oceans of time"

Tom Pike
"Rethink, Retool, Results"

Projects are one-time endeavors; there's only one change to get them right!

Bookmark this on Delicious

Share this article with your network by clicking on the link.