703

John Sviokla examines Google’s acquisition of travel information company ITA in his post Friday and wonders if they might be taking their eyes off the ball.  He stops short of saying Google’s “jumping the shark” with this move, but in view of the growth of Facebook and even LinkedIn, it’s still an interesting question.

References to “jumping the shark” have been coming out of nowhere lately to this term that refers to the point in the life of a TV show that it starts going downhill.  The term itself comes from the Happy Days episode when Fonzie attempts a water ski jump over a shark.  Jumping the shark happens when network leadership senses that something needs to change and starts doing silly things or making cosmetic changes instead of examining what got them there in the first place and fixing anything there that’s broken.  For more on the subject, TV Guide lists 19 ways that shows jump the shark and hundreds of examples.

As John suggests, there is a decent analogy for businesses.  If Google takes its eye off the ball and starts making off-strategy acquisitions, maybe they are jumping the shark.  I was wondering if there are similar signs for IT projects.  When project leadership senses that something isn’t quite right, do they step back and evaluate the overall plan, approach, schedule, and business case or do they tweak a few things and hope that it will get better?

Thinking through a few good and bad projects, some projects that were starting to slip took both routes - some fixed the core and some just put some makeup on the pig.  Thinking of the latter case, here are some signs that your project might be jumping the shark.

Changed the Project Manager

It’s important to know if it’s the project manager who is unable to lead the project or the project plan and approach that’s broken.

Cut Major Amounts of Scope

Scope is an ongoing focus for me.  It is maybe the most important design aspect of a project because each scope element has business value associated with it.  However, “cutting scope” is also one of the most widely discussed remedies on project teams - from the most junior team member to the leadership - when things get tough.  Trying to get things on track by cutting large amounts of scope may make the project seem more manageable but it will also likely gut the business value delivered.

Fired the Consultant

I can’t think of a time in which a consultant was asked to leave or whose contract was not renewed before a project finished where the project was successfully completed as planned (yes, this is a self serving, albeit true point).  The best case after firing a consultant may be to kill the project and start again.  Trying to continue to execute a project planned to optimize the skills and approaches of a 3rd party but without that 3rd party is not a good idea.

Renamed the Project

This is more common than you would think.  One of my insurance clients has renamed their policy administration system replacement project at least twice and it’s still a few years away from completing.  A few years ago, I worked with a wireless telecom firm who named their transformation program with their company name and the year - like “WidgetCo 2007.”  Needless to say, when their schedules started to slip, they changed the name and removed the date to de-emphasize how long they had taken.

There are certainly reasons for doing these things, but doing them as fixes for an unhealthy core won’t help.  Make sure you are changing your project approaches, operating model and staffing for the right reasons and are not “jumping the shark!”

cc licensed flickr photo shared by Iggy.

703