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.

Definitive

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.

Empirical

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.

Summary

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

This 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

This 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

This 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?

The FedGov Fail Day 3

As we enter the 3rd day of Washington DC being shut down, I ask myself why.  It's 2010, for crying out loud!  You'd think they would find a way to keep things operational.  Just because government employees can't report to physical locations, doesn't mean they can't work, right?  From the OPM.gov website, Federal agencies in the Washington, DC, area are CLOSED. This means...

• Federal agencies in the Washington, DC, area are closed. Nonemergency employees (including employees on pre-approved leave) will be granted excused absence for the number of hours they were scheduled to work. This does not apply to employees on leave without pay, leave without pay for military duty, workers' compensation, suspension, or in another nonpay status.

• Telework employees may be expected to work from their telework sites, as specified in their telework agreements.
• Emergency employees are expected to report for work on time.
• Employees on alternative work schedules are not entitled to another AWS day off in lieu of the workday on which the agency is closed.

---

Now, this post isn't necessarily about government employees, a majority of whom will just stay at home and get paid.  Don't get me wrong, I care a lot about my government counterparts.  Some of them work darn hard and are up late at night keeping things running.  This is about all of us who support the government.  In a day and age when the government needs to be nimble and innovative, I sit here knowing I'm not necessarily going to get to bill an hour of my time, while the Federal agencies in the Washington DC area sit idle.  No, I certainly can't do 100% of what I was hired to do but I have things I could have caught up on.  I have a constant rotation of priority deliverables that arrive in my inbox, ready for my review and recommendations.  I don't need to be on site to read a document about cost and schedule variance on CLIN 123, in order to deliver value.  But guess what, that's exactly the case.  If I'm not physically on site, I have to get special approval to do any work and bill any time.

As Jhaymee (@TheGreenPM) Wilson tweeted today, the recent Snowmageddon in DC brings visibility to the Federal Government's lack of a risk management policy, which includes teleworking.  I believe the policy should include contractors.  My FedGov PMO identified a strategy to keep us operational, in the event H1N1 hit the agency.  The strategy was a mandate from higher in the government.  So why then wouldn't there be a plan to keep us operational in the event of inclement weather?  This just proves, in cases like this, the Federal Government doesn't plan to fail; It just fails to plan.

The Critical Path Week in Review

This week I really wanted to turn up the volume of things I wrote about.  I have a lot to say (and write) about project management and if you missed reading my blog on a given day and don't have an RSS feed or follow me on Twitter, you'd have to go searching in the archives to find it.  I don't think that's good enough.  I should make it easy for you to read what I write.  Hopefully, this week in review will help you find something new while you enjoy your coffee or tea.

1/28/2010

Seeing Value From The Customer Perspective

I don’t care if you’re using Agile, Waterfall, or other methods to deliver value.  What is important is you understand your process and what mechanisms provide the greatest value to the customer.  Just because a process does not appear valuable to you, it does not mean the process does not provide value...

1/29/2010

Refine Your Process If You Must Deviate From It

If you’re looking for a free Microsoft Visio template of a Sprint process workflow, which you can edit at will, you can download it here.  As I mentioned in my post Seeing Value From The Customer Perspective, if you think you need to deviate from a documented or understood process, rewrite or refine your process to account for the deviations...

1/30/2010

The Impact Of Social Networking On Project Management

Good leaders do not operate in a vacuum. They exchange ideas and information with people. Offer free information and it will come back to you tenfold. Listen to knowledgeable people and then make a more educated leadership decision... In this post I compared the traditional communication paths and how that process is turned on its ear, thanks to social networking...

1/31/2010

This Is How You Know When To Kill A Project

A personal rant about paper telephone books and how I never realized, until now, who the real customer was. There is a very similar parallel between the newspaper industry and the printed phone book industry.  They both believe or promote the scarcity of information.  That scarcity justifies cost.  To the contrary, we now live with an abundance of information.  That information is freely distributed and reaches a broader audience...

2/1/2010

The December Numbers Are In For PMPs

Yes, the December numbers are in.  December 2009 numbers for Project Management Professional (PMP®) certifications were published and it looks like there will be over 400,000 holding the certification in 2010...

	December Totals
New PMPs (December 2009)	5,403
New PMPs (YTD)	75,107
Total Active PMPs	361,238

2/2/2010

And The Best Methodology Is

I recently commented on two blogs that address similar topics.  Jesse Fewell wants to empower teams to succeed, equip managers to lead, and enable executives to unlock the secrets of high performing organizations.  Jesse wrote a blog post offering the real reasons behind the methodology wars.  It’s an insightful post and I would recommend you go and read it...

The other blog post was from Mike Cottmeyer, someone I turn to on a regular basis to find inspiration and wisdom within the industry.  Mike wrote a blog post asking Why is Agile so hard to sell? Again, it is a very good read and you should set aside some time to read some of his writings...

The Pain Of IE6 And Application Development

There are legacy applications out there that were built on IE6 and it’s not an easy migration.  There are some Agencies which ONLY use IE6 and the users don’t have permissions to install a new browser.  So, what do you do?...

2/3/2010

Updated 10 Step Help To Submit PMP PDUs

All PMPs need 60 PDUs during a CCR cycle so don’t put it off until the last minute.  I document the process on how to claim your require 60 PDUs...

2/4/2010

Using Common Sense With Documentation

Though I really love good documentation, going heavy on it does not guarantee a successful project.  My recommendation is you spend a little time identifying documentation that truly meets your needs.  More importantly, identify documentation that truly meets your customer’s needs...

2/5/2010

Managing Risks and Opportunities

Washington DC is in the process of getting 20-30 inches of snow, over the next 24 hours.  Though I know you can’t foresee all possible issues which may occur over the course of a project, you should make an honest attempt to identify them in order to open a dialog with your stakeholders.  Has weather ever delayed your project or pushed it over budget?...

Managing Risks and Opportunities

Washington DC is in the process of getting 20-30 inches of snow, over the next 24 hours.  The forecast hasn't changed all week.  If anything, it's gotten worse!  At no time did the weather service say this weather event was going to miss us.  The Beltway has been in the cross-hairs of this system since the computer models discovered its formation.   That leads me to write about risks and opportunities.  Actually, for today, it's just risks.  When working on a larger project, you should always have a discovery session early on that will capture potential risks and opportunities.  Once these events are identified, you should quantify their values.  You'll also want to capture the probability of each. Once you've captured a risk (or opportunity), its value, and its probability, you'll know better if you'll be planning acceptance, avoidance, mitigation, or transference.  I'll save that process and definitions for a later time.  Right now, I want to talk about snow.

Yesterday at the meeting I hosted, we discussed our contingency plan for today.  Even before the meeting, we knew we were going to get hit with this weather system and it would impact the schedule.  This was no longer a risk but an issue.  The issue was relevant because our vendor has a contract deliverable due today.  Inclement weather was not annotated in their risk register so it was up to us tell them how this would play out.

Though I know you can't foresee all possible issues which may occur over the course of a project, you should make an honest attempt to identify them in order to open a dialog with your stakeholders.  Local schools systems plan for snow days.  They have documented strategies to deal with these events because they've learned their lessons.  Shouldn't your projects as well?

This snow storm is going to mess with a lot of people and a lot of projects, over the course of the next few days.  I hope we all learn a lesson from it.

Has weather ever delayed your project or pushed it over budget?  I would love to hear about it.

Regards,

Derek