Posts Tagged ‘WBS’

Can Agile cause damage?

Yes.

Is Agile a good method?

Yes.

How can both statements be true?

Let’s look.

First, let me say I have a great respect for RAD, Extreme Programming, Agile, etc., because the methods reflect acceptance of and dealing with a common reality.  That reality is the gap between initiatives or high-level project statements (40,000 foot view) and what it takes to get the job done (working in the trenches). Life moves at such a fast pace there is little time or tolerance to do definitive estimating, i.e., laying out ALL work in work packages of 80 effort hours or less and stringing them together logically to create a network diagram. The pressure that is usually put on the team comes from the desire to see action and deliverables being generated as quickly as possible. The belief is time might be wasted planning due to analysis paralysis. There’s something more to it, though.. the senior management has the desire to move ahead with more initiatives and wants to delegate its responsibility to think things through at a detailed level. In other words a greediness can be present to get as much from the team with as little input as possible.

The Agile method creates a realistic solution to such a situation by getting the team to work quickly with the caveat that the recipient of the deliverable will be available to sign off on progress made and give clear indication of what they desire next.

Baby Steps

The problem that can arise is reflected humorously in the movie, What About Bob, where a successful psychiatrist (for this blog representing the team) loses his mind while attempting to deal with a highly dependent, manipulative, obsessive-compulsive patient (representing the customer, end-user, or sponsor).

In the movie, the psychiatrist is famous for his book, “Baby Steps,” which defines how patients can be moved back to health by making small, corrective changes in their behavior. The problem is the patient takes advantage of the psychiatrist’s dedication to get more of what he wants without taking responsibility and making any changes in his own behavior.

No, this does this mean that customers, senior managers, and end users are mentally deranged. The situation is more in line with having to deal with a demanding, ever-changing business environment and expecting IT to keep up with the demands. If these demands are legitimate then what is the problem?

Flexible or Fragmented?

The issue has to do with the potential of taking a good thing too far and having it turn into a weakness. This is the basis of an interesting psychological tool, the Strength Deployment Inventory (SDI). Flexibility IS important as is acceptance of the difficulties associated with doing long-range detailed planning. So, again, Agile provides a definite “plus.” The problem arises when there is an over-reliance on the intense, tactical approach. What can happen is reinforcement of a nearsightedness regarding requirements along with the belief the team can work without getting immediate feedback on their work. If the team reacts to this and pumps up to get more intense about making the method work a negative feedback loop can build which is of no help to the project.

The Solution: Balance

In the end stability is needed. Why? When the success of a method exists solely in the dynamic of extreme, short-term actions there is the risk of no end-to-end stability. Documentation becomes increasingly difficult to perform because many targets are moving simultaneously. The organization can behave as if it has ADHD.  On the flip side, strategizing without getting into the details risks going nowhere.

The solution lies in getting back to some classic project management approaches to insure a coherent strategic overview is maintained and system performance is truly auditable. It is similar to laying roof shingles. A line needs to be drawn as a reference point across the entire roof. If not, roofers can lay shingle by shingle and swear they are following a straight line. However, after going 15 or 20 feet in this manner they can drift from the straight line with absolutely no awareness they are doing so. This drift eats time and money.

A 5,000-year-old quote from the Upanishads sums it well:

“By standing still we overtake those who are running.”

—

Tagged as: active garage, agile, center for change management, Change Management, gary monti, iterative, Network Diagram, planning, Project Management, Project Management Methodoligies, Waterfall, WBS

Expected Monetary Value (EMV) connects the customer with the team, as we saw in the previous blog. This tool is very powerful. The numbers are as serious as a heart attack (the reason will be shown later). This blog addresses the mechanics of the EMV model providing a whirlwind tour of the associated calculations.

Remember, the goal is getting the team more power to help the client by tying risk with quality and projecting changes in performance corresponding to changes in the risk terrain.

Probabilities and Closed Systems

At the core, an EMV calculation comprises probability times impact to get a weighted number:

10% (probability) x $1000(impact) = $100(EMV)

Let’s put it to use in a closed system.

CLOSED SYSTEMS. In closed systems the probabilities add up to 100% (summation rule) and options are mutually exclusive which is also referred to as being mutually dependent. For example, if you toss a die there is a 1 in 6 chance of getting a “1.” If you get a “1” that also means you did not get 2, 3, 4, 5, or 6.

EMV calculation. Here’s an example that also brings in financial consequences. A vendor has a 70% chance of needing to do rework and it will cost you $1000 extra. The other 30% of the time the work is as expected with $0 added cost. The total probabilities for this system are 100% (70 + 30). Now, the expected value for this system is;

(.7 x $1000) + (.3 x $0) = $700.

Let’s make it a little more complicated. Say there’s a 70% chance the vendor needs to do rework costing $1000, 20% chance the work is as expected at $0 cost, and a 10% chance the vendor design exceeds customer expectations and you get a $2000 bonus (cost reduction). The percentages for this system add up to 100% (70+20+10). The expected value for the additional cost to this system is now:

(.7 x $1000) + (.2 x $0) + (.1 x -$2000) = $600 + $0 – $200 = $500.

Open Systems And The EMV Model

An open system has a set of four calculations providing context for making decisions:

• Baseline
• Total Project EMV
• Worst Case
• Best Case

These provide a range of numbers with the Best- and Worst Case being the bookends and the Baseline and Total Project EMV lying in between. Let’s define an open system and jump into the calculations.

OPEN SYSTEMS. Imagine 3 dice. The summation rule applies for each die but the dice are independent of each other and move freely. In other words, you can still get a “1” on dies B and C even when there is a “1” on die A. Substitute “subcontractors” for “dice” and the stage is set to continue on to the calculations!

Baseline. The baseline sums the costs across the WBS (work breakdown structure). Here’s an example:

You are to provide a circuit board for your client using three subcontractors using the following estimates:

The firmware contractor, Dewey, Cheatum, and Howe, estimates $50,000.

The software contractor, Karen Sympathy, estimates $100,000.

The board manufacturer, Flyby Knight, estimates $80,000.

The Baseline simply sums the estimates:

($50,000 + $100,000 + $80,000) = $230,000

Total Project Expected Monetary Value (TPEMV). The TPEMV combines the baseline with any needed reserves to achieve the desired quality and delivery date. Imagine you are trying to determine what your risk reserves should be in order to protect the margin on the project while meeting the desired quality:

• The firmware contractor, Dewey, Cheatum, and Howe, has a 50% chance of needing $5,000 extra to achieve the desired quality;
• The software contractor, Karen Sympathy, has a 90% chance of performing adequately for $10,000 less than the estimate;
• The board manufacturer, Flyby Knight, has a 70% chance of trying to squeeze you for and additional $10,000 to get the desired quality and delivery date.

The question is, “How much extra money should you add to your fix fee bid to make sure the margin is protected?” Here’s how to do it:

For Dewey, Cheatum, and Howe there is a need for an extra (.5 x $5000) or $2500.

For Karen Sympathy there is some cushion to the tune of (.9 x $10,000) or -$9,000.

For Flyby Knight these is need for an extra (.7 x 10) or $7,000

The net of this is $2,500 – $9,000 + $7,000 = $500 in risk reserve.

TPEMV = Baseline + risk reserves = $230,000 + $500 = $230,500.

Worst Case. But what if everything bad that could happen actually did? In that case you need to do a Worst Case calculation and do 100% calculations for the threat and 0% for the opportunity, i.e., leave Karen Sympathy out and assume the worst for Dewey, Cheatum, and Howe and Flyby Knight.

Increase your bid by (100% x $5,000) + (100% x $10,000) or an extra $15,000.

Worst Case = Baseline + 100% threats = $230,000 + $15,000 = $245,000

Best Case. The Best Case leaves out the threats and adds in the opportunities at 100% or (100% x -$10,000) = -$10,000 for Karen Sympathy. The bid then changes to:

Best Case = $230,000 – $10,000 = $220,000

This has been brief. If you have any questions feel free to contact me. The EMV model is a great way to connect with stakeholders and work rationally while keeping relationships intact.

Oh, about that heart attack. The Securities and Exchange Commission (SEC) was founded during the Great Depression because people offering stock for sale only showed the Baseline and Best Case numbers and a more robust model was needed – the EMV model. Risks and reserves have to be reported. Unfortunately, we are climbing out of a repeat of the same situation caused by ignoring the model.

—

Tagged as: active garage, Baseline, Change Management, EMV, EMV model, gary monti, Project Management, SEC, Security and Exchange Commission, stakeholders, The Great Depression, TPEMV, WBS, Work Breakdown Structure