Even The Best Plans Fail

Plans fail, and they tend to fail quite often.  In all walks of life, even the simplest plans tend not to unfold as originally designed.

Organizations spend a lot of money and time creating groups solely focused on ensuring that plans do not fail. Senior leaders hire individuals and give them the sole responsibility of managing plans to success.  It is quite the lucrative profession to be given such responsibility.

Recently, I asked our church pianist to perform special music at church.  Early in the service, a group of children came up to perform special music.  As they were singing, I walked over to the pianist to discuss a couple of things but before I could say anything he whispered in my ear “the kids are singing my song!”  I couldn’t believe it!  What were the odds that the children and pianist would choose to sing the same song on the same day? Pretty small.  But it had just happened.

So our best plans fail to go exactly as we thought they would when we drew them up.  It is rare that we are 100% certain that things will work out exactly the way we expect them to yet we often behave as if that’s the case. There is always the chance that something unforeseen will swoop in, alter the landscape and impact our plans.

How then do we proceed?  Do we stand a chance of getting anything done?  Do we have to spend all our effort trying to ensure that our plan unfolds as we originally designed it?

Back to my story… I was beginning to feel very concerned for our church pianist as I didn’t know what he would do given that the children were singing the song he had prepared.  At that moment he leaned forward and whispered “don’t worry I prepared two songs, I’ll sing the other one.”,  He had prepared two songs!  He had options!   His options allowed him to adjust when his original plan did not work out as he thought it would have.

When you develop plans, do you identify options for when things go wrong?  Do you explicitly consider the fact that even the best plans fail?  Some may consider options to be “contigencies”, “alternatives” or “backups”.   As I type this post, I’m at Owo-Ahiafor, Nigeria – my hometown.  When I planned the trip to Nigeria, I identified options for various pieces of the plan where things could go wrong.  Having options is part of developing a risk mitigation technique.  It’s common sense but then again common sense is often not that common.  Options should be identified based on the likelihood of the plan not working out as originally designed or based and/or on the impact (financial, social, physical) of the plan not working out.  In the case of my church pianist, the odds that the two songs he prepared would be sung on the same day, were pretty slim because it was a regular church service.  However, if it had been a concert, he may have needed three or four song options to reduce the odds even further.

At the organizational level, I’ve observed that many an organization will spend a lot of time creating plans and yet don’t spend the time to consider the fact that even the best plans fail, ergo, they have no options or scramble to find options when things don’t go according to the plan.  As a result of this, certain people in the organization are incentivized to make sure the plan works at all and any cost.  Often, they are not the individuals actually executing the plan leading to unnecessary friction within the organization.  I’ve lost track of how many times I’ve seen people recognized because they “rescued the plan”.  In previous posts, I’ve hinted that outcomes are what we truly care about.  The plan is often a means to an end.

Do you have two songs in case someone else sings the song you originally intended to sing.  Do you have options for when things don’t work out as planned?  As we head into 2015, remember, even the best plans fail.

 

Are Projects Your Only Option?

It’s often suggested to me  (via Twitter, LinkedIn, work – thanks Karen),  that I’m anti-project managers in Agile (or Lean).  This is incorrect (although I am opposed to the way many project managers (and managers in general) actually work but that’s a post for a later date).  I do however, have strong opinions on our usage of “projects” in software development.  It is the project approach that often leads to the engagement of project manager.  These feelings are right up with my thoughts on the usage of the word “resources“.

In the loosest sense of the word, a project can be anything.  It can be driving to work, taking a shower or entering time at the end of the day.  But we all know that’s a bit silly, we just call those activities.  The PMI institute has a definition for project which I like but then uses a software development example that muddies things a bit.

So what is a project?  I answer it this way: Is the scope (outputs) needed to achieve the outcome and end investing known – to a large degree – upfront?  If the answer is yes, then it feel project-y to me.  I’ll admit that this is probably incomplete, but it get’s me started in my assessment of what I am working on. For example, if I choose to remodel my kitchen and largely establish what done looks like from the onset, then I believe I have a project on my hands.  How about porting a database from Oracle to SQL Server or moving from Java to J++ to C# (yes I’ve done those things and they are not pleasant)? What about upgrading servers from one operating system version to the next or developing an integration pipeline with a partner so that they send/receive files to/from a system? How about developing and delivering a software solution based on defined scope as is practiced by custom software development shops – and is probably the example PMI is referring too.

These all seem project-y to me as the outputs needed for outcomes to be met and investment to end are known upfront.  The decision to stop investing is largely driven by the fact that certain outputs have been delivered. Hopefully outcomes are met as well.  This doesn’t mean that discovery doesn’t happen during the process (a good reason to leverage Agile and Lean techniques) but the path is largely charted.

On the other hand, what about building out a supply chain solution or a personal health monitoring platform or a tele-medicine platform (my latest project er I mean startup)?  What about starting a blog or having a family (ok now I’m stretching it)?  Are these projects?  Maybe if one takes a very liberal definition of the word yet I think not. These endeavors are journeys where the end is in often vague and obscure.  In a weird way, we actually hope there is no end (at least not soon).  We may have some ideas of the outputs needed but we also accept that we are (hopefully) going to spend a lot of time learning about more outputs needed to achieve our outcomes.   This is exactly why I spent over a decade at one organization developing a single product.  Tell me what’s temporary about that!!  We stop investing when we are no longer learning (or making money or having fun).

Should you be approaching your work a bit differently?  Are projects your only option?

PS: The project approach to software development can lead to a bunch of bad (organizational) habits but that’s for a later post as well.

Agile Is Not The Goal

Or is it?

Ok, it isn’t but I’m tired of reading posts or comments via various outlets that try to remind us that business agility  (or whatever) is THE goal and Agile is not.  While there is truth in that, I believe that such statements lead to the proverbial baby being thrown out with the bath water and we end up with faux Agile – afterall it isn’t THE goal is it?

I play the piano.  I’m in the middle of learning a jazz arrangement of “Georgia” and I have THE goal of peforming the piece by the end of the year.  Let me repeat, THE goal is to be able to perform the piece by the end of the year. In order to achieve THE goal, I actually came up with a goal of practicing the piece daily.  (This goal has basically led me to get up at 4am for the past couple of days to practice).  If I don’t meet the goal of practicing daily, THE goal of playing “Georgia” by year end is in jeopardy. Practicing daily is a goal I have to meet if I want to achieve THE goal. It’s that simple.  Now it’s really easy to making practicing daily THE goal and lose sight of the original goal.  If I do that, I probably won’t be performing “Georgia” at the end of the year as well.  So I recognize that “practicing daily” is a goal I set to help me achieve THE goal of performing the piece at the end of year and ensure that my daily practices help me get closer to THE goal.

If you believe Agile (as in Agile Manifesto Agile) will help you achieve THE goal (whatever your goals are), then employ Agile (as a goal) such that it helps you achieve THE goal.  If you don’t think it will help you achieve THE goal, don’t use it.  It’s that simple.

Or is it?