In an instant

Every once in a while, a series of events goes across my radar that stimulates my otherwise dormant brain into thinking.  This past week, I watched a cool fireworks display at a friend’s lake house while also watching neighbors shoot bottle rockets at each other, my son’s bicycle tires and seat were stolen from his bike outside a restaurant he was eating in, and I read an article in the NY Times about rampant stroller theft in New York.

Let’s take the bike first.  It was chained up.  Well, apparently, to be more accurate, the frame was chained up, but obviously not the wheels or seat.  When I asked my son about what happened, he said, “I was only inside for a little while.”

On to strollers…  I guess there are some pretty high-end strollers for sale these days, running upwards of $400-500.  Nice!  And I guess one of the attractions is that they are pretty heavy duty but sadly not that easy to carry up a flight of stairs.  So there’s a tendency among stroller-owners to leave them outside while they run up to their apartments to drop off groceries or dry cleaning before getting on with other errands, which makes sense especially when you already have an infant in your arms.  I imagine that’s all the time a stroller thief needs to make off with the goods, which I am told are easily sold on Craig’s List.  Nice again!

Finally, not to put a damper on 4th of July celebrations, but there are always a few stories of over-enthusiastic or careless revelers who lose a finger, an eye, or worse from a fireworks ‘mishap’ this time of year.

As a leader, one of the most important things you can do is to continuously assess, manage and mitigate risks in your organization.   What that means is, you have to be out in front – questioning what is prudent, thinking of ways to create “insurance policies” against the unthinkable, and generally being a wet blanket.  The thanks you will get for this is not much more than walking out your office every day and seeing your stroller/bike/finger is still there.  When you consider the alternative, I hope that’s thanks enough…

Here’s to a safe second half of 2011!

Advertisements

Instructive yes, hypocrite no

It occurred to me that I left one rather important detail about my last post out.  And that would be the answer to the inevitable question:

Hey moron, if you estimate hours and do fixed price work, which is essentially inevitable in consulting, what’s your solution to this dilemma of hours and revenue management?

Not wanting to be a hypocrite or someone who points out challenges with no solution, here’s what I recommend:

For purposes of this discussion, I will assume there are three separate milestone payments in the contract. 

1)  Consider each milestone and its associated payment like a separate “mini-project.”  Estimate the hours for that mini-project and consider that the baseline.  Include planned payments and the average cost of your employees, including benefits, etc.  SHARE THAT NUMBER WITH THE WHOLE TEAM.  Repeat for all additional milestones.  You should end up with something like this:

Milestone	Estimated Hours	Fixed price payment due upon completion	Avg total cost of employees per hour	planned gross  profit
1	500	50000	51	24500
2	1000	100000	51	49000
3	500	50000	51	24500

2) start the project

3) keep track of actual hours

4) at the end of each milestone, add a column to the table and put the total hours expended to achieve the milestone.  SHARE WITH THE WHOLE TEAM.

5) calculate your ACTUAL Profit based on the actual hours worked to achieve that milestone.

6) start the next milestone.

7) at the end of the project, calculate your total profit.  SHARE WITH THE WHOLE TEAM.

8 ) review the estimates versus actuals with at least the project leadership team, evaluate where you did well and where you could have improved/been more efficient.

9) If you used less hours than what you estimated, celebrate!

10) If you used WAY more hours than you estimated, kick yourself for estimating poorly, not the project team.

11) take the word “overage” out of your vocabulary forever.  There’s no such thing…

Are we there yet??

Think about the worst road trip you ever made. Maybe you and a few friends were driving to spring break in Florida from Michigan in an old, unreliable car and it broke down somewhere in Tennessee and it took you 4 days to get it fixed and get there. Or maybe, like me, you were driving to a friend’s wedding in Cleveland and you hit a snowstorm and all of a sudden you were going 5 miles per hour for miles on end. Or maybe you hit traffic on your way to the Hamptons over Labor Day and a 2 hour drive turned into a sweaty, frustrating, 4 hour ordeal…

Here’s my point. Those things happen. But when you sit down to plan out a trip and use Mapquest, for example, it doesn’t predict any of the problems we listed above. It simply takes your starting point, your destination, the approximate number of miles in between, and an average speed and calculates your arrival time. Mapquest operates in what we might call a ‘best case’ scenario. No flat tires, no horrific traffic jams, no accidents, no thunderstorms, etc. And that’s OK. Because any prudent traveler with a really tight schedule where being late would be a real problem (like a wedding, flight, or graduation ceremony, to name a few) usually leaves ample time in addition to what they were told by Mapquest “just in case…”

So why don’t project leaders planning software development or other IT projects do the same thing?? How many projects have you been on where:

a) No one held a meeting to brainstorm all the things that could go wrong?
b) Someone held that meeting, shared the list, and left it at that?
c) Someone held that meeting, shared the list, quantified the risks, but forgot to incorporate those risks into the project timeline?

Next time you are working on an IT project that is late, ask yourself some tough questions. Are we really late, or did we simply build a project plan that was a ‘best case’ scenario? Did things happen along the way that your experience told you could really derail things (like a flat, traffic or an accident) and you just ignored them as you merrily entered tasks and durations into Microsoft Project? Is it POSSIBLE that it was your OWN FAULT that you just missed your flight???

There are lots of techniques for dealing with this in project planning. Monte Carlo simulations and other probabilistic methods offer ways to develop a range of finish dates, rather than a single finish date. Or even two project plans: one that’s best case, and one that’s worst case. Present them both to your stakeholders. See which one they like better (I am guessing the best case one, but at least you tried…) And just remember that most project planning tools are like Mapquest: start, finish, distance and average speed. If you don’t take it upon yourself to model in the other unknowns, as Jimmy Buffett said in Margaritaville, “hell, it could be my fault…”