Empirical or Definitive

Ever heard of the cone of uncertainty?  The cone shows the historical error at certain time periods in a tropical cyclone forecast.  What happens today and what has happened in the past is pretty much all we know.  We can certainly use all kinds of scientifically proven processes or models to try to predict the future.  But, in the end, we won't know what tomorrow will bring until tomorrow.  If you are dealing with machines, you should be able to predict upcoming events with relative certainty.  If you are dealing with people or something like mother nature, the odds of predicting events with certainty are slim to none. We need to assume that baselines may change significantly during a project or in life.  In unpredictable environments, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.


You work and work and work, trying to lock in your scope, your schedule, and your budget before the project even begins.  You do everything you can to lay it all out, attempting to account for every possible variable.  Unfortunately, you don’t know what tomorrow will bring.  So, the further out the schedule goes, the greater the risk something is going to change.  What’s it going to be?  Is scope going to change or maybe the schedule will slip?  With the cone of uncertainty, whatever foreseen changes are ahead, there are going to be exponentially more unforeseen the further out the schedule goes.


In reality, you begin with the greatest unknown.  Even some of the unknowns aren't even known.  Just accept it!  You’re not the Amazing Kreskin.  You can’t predict the future.  The only thing that is guaranteed is something is going to change.  So, plan for that change.  Know the goal you’re trying to reach.  Keep your eye on that goal.  Now, do what you do.  Develop, lead, manage… it doesn’t matter.  What does matter is you see where you are right now, know where you want to go, and then at a measured time, see where you are again.  Make some adjustments and repeat.  You will find if you just accept the change, you can use it to your advantage to get closer and closer to your goal.


You can not predict the future, only plan for it.  You can not steer a hurricane, only plan for it.  You can not prevent change…  Can you guess what comes next?  That’s right, you plan for it.

What is in a Name

Hello my name is Derek HuetherThis weekend, I took the first step of rebranding myself. Some know me as Derek Huether the "PMP"; some as Derek Huether the "CSM"; some even refer to me as The Critical Path blogger or Zombie PM. With the real risk of the Federal Government shutting down this next week, I'd be an idiot if I didn't eat my own dogfood and have some kind of Risk Management strategy.  Though I may have to "accept" the risk, I will do what I can to mitigate it.

Because I am NOT a government employee, if there is a shutdown, I will NOT get paid.  When I heard about a possible shutdown, I remembered the similarities between grief and risk.  So, what needs to get done?  I need to get my resume and social links updated.  Wherever my name is, I need to make sure the message I'm sending reflects my current frame of mind.

When I look at LinkedIn profiles, it appears some people really love adding initials after their names.  I saw one fellow had no less than 6 acronyms after his name.  Though people in the industry may understand this alphabet soup, I think many are just annoyed by it.  I did a search on him and he really had nothing to say (publicly).  So, who is this guy?  What I see happening is he'll be loaded into a database with everyone else and he'll become nothing more than a keyword search.

Though I admit, that could happen to me as well.  I'll do what I can not to pander to it.  I think people should be hired because of their personalities or because they are good culture fits.  I wouldn't want to be hired because a hiring manager needed a body with a PMP or CSM.

I'm not going to turn my back on what I've learned over the years.  I will still champion the baseline information the pursuit of these certifications or accreditations exposed me to.  But, I'm not going to continue using them in my name.  It's just not who I am.

Conflict in Value Perception

Deployment StartThis weekend I witnessed a true conflict in value perception.  We're not talking values like: - We treat others with respect - We are humble

Rather, it's about what the Customer (Product Owner), the Vendor (Core Team), and the I (Facilitator) believe has value.  I see direct value, like actual delivery of product, and indirect value, like mitigating risk by facilitating communications.

We started a deployment cycle that is going to take some time.  The team activities are clearly defined and level-of-effort have been estimated.  Dates in which potential risks could arise have been identified.  This is all good.  Until an activity begins, we won't be certain if a risk will be fully realized.  This is why I'm a really big proponent of daily communications.  Every morning, we have a 15 minute (status) meeting.  (The culture demands that we call it a status meeting so I'm good with it.)  The extended team is distributed (3 locations) so this is a little challenging.

Though I stressed to everyone the importance of daily communications (at a minimum), this weekend I was a little shocked at what happened.  Deployment activities were taking place over the weekend.  There was a trigger point for a risk that had been identified.  During the Friday status meeting, the Customer informed the team that they would not be on the status call.  Though I had agreed to be on the status call, this was a bit of a paradox.  I am a facilitator.  Per the contract, I can not act on behalf of the customer.  IF the team ran into a roadblock over the weekend, the customer would not know until Monday morning.  We could potentially be delayed by two days until the customer could provide feedback and direction.

So, what happened over the weekend?  The team did indeed run into a roadblock.  But, they were empowered enough to get the work done.  Because risks had been previously identified, a mitigation strategy was in place.  The team was able to bring in team members, over the weekend, without having to consult with the customer.

I still believe if the deployment is going to be a success, all parties must be fully committed.  We're all in this together.  I'll never ask a member of my team to do something that I wouldn't be prepared to do myself.

Something David Bland said at the APLN DC meeting really resonated with me this weekend.  He said,

When dealing with distributed teams, keep the feedback loops tight.

David could not have been more right. We dodged a bullet this time around. Empowering the team allowed us to do this. But, the customer took an unnecessary risk, by intentionally lengthening the feedback loop from 24 to 72 hours.

Like the image? Find it at Pictofigo

The Hateful Cycle of Apathy Hits a Nerve

Have you ever stuck your neck out and get no support?  Did the trust among that team start to break down? I've seen it happen first hand and Geoff Crane wrote an awesome post over at Papercut Edge about it.  He called it the too-common cycle of apathy. The post hit a nerve with me. At my previous engagement, the Engineering Department was used to being railroaded by management. Promises were always made on their behalf and they found themselves working long hours and weekends. If they didn't make the goals, those who made the promises would never take ownership. If goals were miraculously accomplished, the same person(s) would jump into the spotlight. After I was brought on board, I didn't have a problem looking a Director or CIO right in the eye and telling them I disagreed with them. Sometimes they backed down and sometimes they didn't. But everyone at that company knew I was honest and would speak up if I didn't agree with something. Everyone knew I was looking out for my people, my department, and my company. I believe positive change rolls up hill, just as sh*t rolls down.  Though I'm no longer with that team, I have no regrets for backing them up and providing support when they needed it most. Those who bullied so many are no longer there either.  Though there was an attempt to silence my voice by decapitating my team, others in the organization saw through the ruse.

I think sticking your neck out is worth the risk. If I think you're right, I'll support you.  By doing that, I build trust with my teams. With trust, my teams will do anything for me. With that, anything is possible. What can I say, everyone is happy but the party you had to confront in the first place. Yep, it's certainly worth it.

Thank you Geoff for getting me fired up.  Now go check out his site!

image courtesy of Papercut Edge

How To Prevent Your Project From Hemorrhaging

Triage Your ChangesThis post is in response to a post written by Jennifer Bedell on the PMStudent blog about goldplating. Goldplating is very common in application development and can be very expensive. If you're dealing with Waterfall, it's a little more obvious when it's happening.  Some may argue, but I've seen it happen in Agile as well.  I've sat across the table from a vendor and asked, are you prepared to roll back every one of these changes?  Their eyes get big because why wouldn't the client want these changes?  Well, too many times a developer is in the code and they think, while here, why not make this additional change we planned to do next month.  Or, now that I'm here, it makes a lot more sense if I do it like this versus what we originally thought.

In short, Jennifer wrote about goldplating caused by testers. She asked

why is it always the developers who get blamed for goldplating? When you consider the cost of change increases as the project timeline progresses, it becomes evident that, in addition to increasing scope, goldplating by a developer can also be costly. Goldplating by a tester can occur when a tester goes beyond the stated requirements in an effort to produce a “quality” product. A tester may feel that their suggestion would improve the customer experience so they log this in the defect log.  While their suggestion may do exactly what they envisioned, if it was not within the scope of the stated requirements, it becomes a form of goldplating or “feature creep”.   A tester’s job is to ensure that a quality product is delivered, but many testers rely on their own definition of quality rather than using the requirements to define quality...

I’ve seen team members at every stage of the Software Development Life Cycle (SDLC) attempt to goldplate, with the best of intentions. Regardless of where you are in your development process, any time there is a requested change to the baseline, there should be a control mechanism.  I call that mechanism a triage. Be it the customer or a customer representative (Project Manager, Product Owner, or BA), someone needs to vet anything and everything which could impact the baseline.  These changes need to be prioritized and reviewed.  I'm not saying changes should not be made.  I'm saying they need to be properly vetted.  Changes impact the schedule, the budget, and in the end...customer satisfaction.

Without this control point, I think you’re guaranteed to see creep somewhere in your project and you will see it begin to bleed time, money, or both.

Yes, we certainly want to deliver the greatest value to the customer. But, creep increases risk and that’s not value.

Am I just a control freak or do you agree with me?