Kill Your Weak IT Projects Now | E-Oasis Alerts

Blaine Berger of E-Oasis (@eoasis for you twitterheads) wrote this article back in November and I’ve gone back and re-read it several times in the months since then. It’s still as relevant now as it was the day he wrote it.

Almost every company of any size has IT (Information Technology) projects at various stages of completion. Many of these may have substantial resources dedicated towards them and yet they wander in the desert of incompleteness. Can you afford this?

Too many projects carry on via shear inertia. Project Managers and business leaders need to have the courage to ask the difficult questions when no one else will:   Does the business case for this project still hold up?  Would we be better off stopping this project and redirecting the resources somewhere else?  (Or go for the gusto and ask “Why are we even doing this project?”)

You may ruffle a few feathers but that’s only because people don’t like having the spotlight turned on. It’s the right thing to do.

As Blaine says:  Kill your weak IT projects now. It may be painful, but it’s long overdue and you know it.

Arno Van Leest stumbled across this gem today.  Please excuse all the misspellings, he’s English.  ;-)

from:  http://www.visitor-tracking.com/pm-jokes.php#pmp

Project Managers are a fortunate lot, for, as everyone knows, a project manager has nothing to do; that is, except…

• To decide what is to be done;
• to tell somebody to do it;
• to listen to reasons why it should not be done,
• why it should be done by somebody else,
• or why it should be done in a different way;
• and to prepare arguments in rebuttal that shall be convincing and conclusive.

And then:

• To follow up to see if the thing has been done;
• to discover that it has not been done;
• to enquire why it has not been done;
• to listen to excuses from the person who did not do it;
• and to think up arguments to overcome the excuses.

And then:

• To follow up a second time to see if the thing has been done;
• to discover that is has been done incorrectly;
• to point out how it shall be done;
• to conclude that as long as it has been done it might as well be left as it is;
• to wonder if it is not time to get rid of the person who cannot do a thing correctly;
• to reflect that in all probability any successor would be just as bad, or worse.

And finally:

• To consider how much more simply and better the thing would have been done had he done it himself in the first place;
• to reflect satisfactorily that if he had done it himself he would have been able to do it right in 20 minutes and that as things turned out, he himself spent two days trying to find out why it is that it has taken somebody else three weeks to do it wrong.
• To realise that such an idea would have a very demoralising effect on the project team, because it would strike at the very foundation of the belief of all employees that a project manager has nothing to do.

On Sunday, October 19th I had a meeting with Colin Powell.  The event was one that had been on our calendars for several months and one that I was personally looking forward to as General Powell was going to share his insights on leadership and project management with me.  The fact that 4,000 other Project Managers and leaders were in the room was beside the point – he was the keynote speaker at the 2008 North American PMI Global Congress.

General Powell’s presentation was absolutely amazing.  He had a very down-to-earth style that was engaging and entertaining, but he spoke with authority and gravity on topics from world politics to (my favorites) project management and leadership.

Below, in no particular order nor coherent gathering are my notes from his presentation.  The quotes are as exact as I can make them.  I hope you find them as inspiring and empowering as I did.

• What I really wanted to say this morning (referring to his announcement of support for Barack Obama) is that every American should study the issues, study the candidates, study their conscious, make up their own mind, and then GO VOTE!
• Education is one of the most important political forces in the world today.
• What do I miss about being Secretary of State?  I miss having my own 757!  (said with comedic sadness over having to use commercial air travel)
• The greatest strength we have (America), our greatest power, is our openness.
• Leadership doesn’t change from 40 troops to 3 million, from private sector to non-profits, the purpose of a leader is to put your followers in the best position for success.
• Followers need to believe in something, a mission, a goal, and get behind the leader’s passion and enthusiasm. 
• Be the example of leadership in your organization.  Treat everyone with respect.  The janitor is not just a janitor, he is a key part of your organization and it’s image!
• Take care of your troops.  Be a person of selfless service.
• Don’t just motivate your followers (a one time activity), inspire them (so that they are self motivating).
• Inspiring people implies rewards, but they need not be purely financial (raises and promotions) – recognition, kind words, and hand written notes of gratitude will go a long way.
• Match your intensity to the task at hand.  Never look tired, afraid, or spent.
• Make sure everyone knows what’s expected and what role they play on the team.
• You know you’re a good leader when your people follow you if only out of curiosity!  (People will follow you because they trust you, even when the path you are taking looks impossible to them.)

• There are 4 major political forces at work in the world today:
  1. Economy – the creation of wealth
  2. Energy – which fuels the growing economies
  3. Ecology – we must grow the economies in an environmentally responsible way
  4. Education – “The US had better get serious about this!”
• Great leaders face reality, they don’t hide from it.  (Face up to tough decisions and conversations.  Don’t be afraid to cut weak team members or to abort failing plans.)
• Be a situational leader – understand your team, build upon their strengths and help them with their weaknesses. 
• When someone can’t pull their weight you have to manage them out, if you can’t then you’re not a leader.  The troops are waiting for you (they know dead wood when they see it, they expect you to fix it).
• Leadership is born but it can be improved through training.

I can’t even begin to touch the stories he told, the humor he brought to the presentation (including doing impressions of Ronald Reagan, Arnold Schwarzenegger, and the Prime Minster of Japan), nor the self deprecating quality he displayed.  If you ever have the opportunity to hear General Powell speak, do make every effort to see him, you won’t be disappointed.

Here’s a link to PMI’s report on Colin Powell’s keynote address.
Also check out these blog entries:
Powell’s Impression – by Brantlee Underhill
Colin Powell At Congress – by Kelley Hunsberger

I echo the comments of “Zabin” on that 2nd blog posting:

General Colin Powell’s keynote address set the tone of excitement, passion and inspiration for the rest of my experience at the 2008 PMI Global Congress. He was engaging, articulate, genuine, passionate, down-to-earth and awe inspiring. He gave you the feeling like you were having a conversation with a close friend. Sharing his wisdom and life lessons in a way that, I believe, touched each person in that room. Thank you General Powell…thank you PMI!

Risk management is perhaps the most difficult and misunderstood part of project management.  In project management circles there is the classic “triple constraint model” – it’s every PM’s duty to balance Cost, Schedule, and Scope.

PRINCE2 defines a full 6 constraints that must be managed, adding

• Benefits
• Risk
• Quality

In the truest sense the PM can hold the big three (cost, schedule, scope) constant if they increase risk, decrease benefits, or decrease quality.  One of the great things about PRINCE2’s approach is the extra focus it brings on Risk Management.

The trouble is that PRINCE2 doesn’t give much advice on how to actually DO risk management.  There are discussions of risk logs (and the related issue logs), risk classification, and even risk tolerance.

However, there is little practical guidance on how to manage risk in projects.  I’ve heard lots of good thoughts from peers in industry but there’s no codified body of knowledge (yet – both OGC and PMI are working on their versions).

In my experience, most executives aren’t ready for a conversation on risk appetite and risk tolerance.  I find that many PMs present risks to their stakeholders, believing the execs understands the implications but in fact there is a huge gap which is left undiscussed.   The executives often aren’t looking for mitigation plans and offering contingency budgets or schedule tolerance, instead they are saying “Ok, I get it.  Don’t let that happen!”  

As a PM you need to recognize the difference between risk acceptance and risk acknowledgement.  Know which you’ve been given – if it’s merely acknowledgement you need to put a comms plan in place quickly… you need to bring those executives around until they actually accept the risk.  Either that or you’d better cook up some darn fine mitigation plans that will let you still nail your baselined cost, schedule, and scope!  Otherwise it’s your career (or at least your reputation) you’re gambling with should your risks become issues.   What happens in Vegas may stay in Vegas, but what happens on your project will follow you!

Risk Acceptance or Risk Acknowledgement – know the difference or let it ride!

My team often hears the mantra “NO ZOMBIES” from me. If you run in Project Management circles surely you know what I’m talking about… The projects that just won’t die. No matter what you do you can’t put them down, they just keep coming at you. The undead.

What causes these zombie projects?  How did they transform from the good wholesome initiatives you started with into these creatures from the crypt that torment you so?

In a word… scope creep.  (yeah, I know that’s 2 words).

You never meant for it to happen but you’ve let your project get away from you and it’s taken on a life of it’s own. All the things you thought were agreed to, all the things you assumed were “understood” have gone out the window. Your customer is now talking about features you’ve not planned for and requirements you’ve never heard of. All you can do now is slip your schedule and ask for more resources to get it done.

Does this sound like your project?  If so, then it may already be too late…

Zombies are notoriously hard to put down.  You will need tenacity, bravery, and stamina to survive.  How can you prevent these otherwise nice projects from turning into zombies in the first place?  It all comes down to controlled project startup.  Getting your project off to the right start will put you in control for the duration and control is what keeps a project tamed and resistant to zombie tendencies.  Here are the basics you’ll need to put in place:

1. A clear business case defining why the project is being undertaken
   
   It’s critical for you, your project team, and your project board (#3 below) to be in agreement on the project’s business case.  If you don’t understand why a project is being done then you can’t make good decisions when issues arise or the environment changes.  Should you add more resources to pick up speed?  Should you slow down and focus on quality?  Should you stop doing the project altogether?  These kinds of project management decisions can only be made when you are fully informed about the business case for the project.
    
2. A clear list of requirements detailing what is to be done (scope)
   
   With the business case well understood you must turn your attention to the project’s scope.  This need not be an exhaustive list of every possible deliverable and characteristic, but it needs to have enough detail that it’s clear what you are to do (and as importantly, what you are NOT to do).  If you’re installing servers in a datacenter, do you need to setup the network first?  If you’re building a rocket, are you responsible for finding the fuel source?  If you’re designing a bridge are you also in charge of the landscaping around it?  You need to have a solid definition of what the customer expects before you can deliver to those expectations.                       

   In my opinion, this is the most common failing among PMs.  The typical scenario: The project sounds straight forward enough, everyone already knows what needs to be done, and the customer is anxious for you to get on with it.  The PM often succumbs to these pressures and launches into the project without ever taking the time to document what is really being asked for.  Later your customer will want changes or more features and you’ll find you’ve really got nothing to support your position that these changes aren’t what you’d agreed to previously.
    

3. A project governing board with representation of the business deliverables, the customer needs, and the resources who’ll do the work.
   
   PMs typically do a good job of identifying their customer (usually the business) and some stakeholders (typically users) but they often miss bringing in an equally critical and balancing role, that of the supplier.  If your governing board is made up only of the customers and users they’ll be quick to agree to any change that gets them more features or earlier delivery with little regard to how that will impact the team doing the work.  You have to have the supplier at the table to represent the other side of these project demands.  The supplier has to have the authority to add resources to a project if changes are agreed to and the seniority to not get over-run by the customer or user representatives.         

    

4. A signed agreement by all the people in on the board on the business case and project scope (as well as schedule, budget, quality expectations, initial risks, etc).
   
   It’s not enough to know your business case, define your scope, and install a properly designed project governance board.  You must get them to sign an agreement to all of this.  The business case, scope, schedule, budget, and project board operating roles and responsibilities must all be documented and signed if you want to be able to enforce them later.   Project executives are busy people with lots of demands on them and they’ll be quick to forget the date they agreed to or the pot of money they promised you.  If you have the documentation trail to hold them accountable to those agreements, then you’re in control and that’s a good place to be! 

PRINCE2 (Projects IN Controlled Environments) has an absolutely fantastic section on Project Startup (SU) that covers all this and more.

Now when your customer wants to change the rules, or add new features, or modify the schedule, or slash your budget, you are in a position of power rather than on the defensive.  You have something to help keep everyone on track and not let them get distracted by shiny new interesting bits of work.  And if you should decide as a project governance team to accept a change, all you have to do is update your document to capture the new state of the project expectations and get everyone to sign-off on the new agreement. (Don’t forget that step or you’ve just flushed all your good work down the toilet)  

With these things in place, when the time comes to put your project to rest you won’t be plagued by questions of whether or not you’ve delivered everything and if you’re really done.  You can put your project away peacefully without a single zombie sighting.

Happy hunting!

NB – if you’ve already got a zombie project, is it really to late for you?   I’m so glad you asked!  The answer is “of course not!”  Here’s how put a zombie down:  Set-up the same controls described above!  This time instead of doing a project start-up what you’ll be doing is defining “here’s what’s left to be done”.   You draw a firm line and let the past be the past, setup a new “going forward” agreement and drive to that agreement.  It’s never too late to document expectations, and once you have them, you have control.  

Zombies Be Gone!

As an IT Project Manager, it’s important for you to understand availability, how customers view it, and frankly what’s realistic.

You’ll hear people say “I want five 9s” or “My app needs four 9s” of availability.  In my experience, most people don’t really know what this means…  5 9’s is the in-flight-magazine gold standard for availability.  Everyone thinks their app needs 5 9’s of availability, but do they understand it?  Let’s take a look at the math:

Nines of Reliability: (Hours / Minutes / Seconds) of downtime per year

• 2 9’s (99%) = up to 87.6h / 5256.0m / 315360.0 seconds of downtime per year.
• 3 9’s (99.9%) = up to 8.76h / 525.6m / 31536.0 seconds of downtime per year.
• 4 9’s (99.99%) = up to 0.876h / 52.56m / 3153.6 seconds of downtime per year.
• 5 9’s (99.999%) = up to 0.0876h / 5.26m / 315.36 seconds of downtime per year.
• 6 9’s (99.9999%) = up to 0.00876h / 0.53m / 31.536 seconds of downtime per year.
• 7 9’s (99.99999%) = up to 8.76E-4h / 0.05m / 3.1536 seconds of downtime per year.

5 9’s means less than 5 1/2 minutes of downtime per year!  Now, how long does it take a server just to boot once?   Take in a high-end server, put a lot of boards in it, memory, CPUs, hang a lot of storage on it, and the POST alone will take 10+ minutes.   Just one reboot in a year and 5 9’s are out the window.

Five nines of availability of a single component is a incredibly hard goal to attain.  Five nines availability of service is possible, but it depends on an almost perfect architecture, super reliable methods of failure detection and failover, and very tight controls on change and access.

Even if an app and server combo somehow got 100% uptime, a network outage, a human error, or even a storm that takes out building power will drop your availability below 5 9’s.   

Many companies will define services in terms of criticality – mission critical, business critical, business operational, and so on.  You need to understand your company’s definitions and see if and how they relate to the 9’s of availability.  Often these definitions talk more about RTO and RPO for the service.

• RTO – Recovery Time Objective – The length of time a service can be down before it impacts business functions.  This could be thought of as a link to the 9’s of availability, but typically an RTO talks only about the acceptable duration of a single outage, not the number of allowable outages over time.
• RPO – Recovery Point Objective – The amount of data loss that can be tolerated before business is impacted.  For instance you might be able to lose the previous 4 hours of data entered before the system went down.  The business will have to re-enter that data once the system is operational again – this might be acceptable for a payroll system.  On the other hand the business might not be able to tolerate ANY data loss, all records must be fully recovered, perhaps in your ERP system.

Again, none of this really ties to the business buzzword bingo of the 9’s of availability.  This is not to say we should not strive for such things, just make sure you understand what’s being asked of you and what your org can commit to.

At this point if you don’t have Toto’s “99″ stuck in your head, I’m vastly disappointed in you.  (iTunes Music Store link)

To be honest, it’s not the US Congress, it’s the PMI Global Congress, but still, I’m pretty excited!

My friend and PRINCE2 guru (everyone should have a PRINCE2 guru) Jay Siegelaub and I will be co-presenting our thoughts on using the PRINCE2 methodology to define a PMO (that’s Project Management Office for those of you not into the whole PM scene).  Jay has been training my company in PRINCE2 for many years now and we’ve shown tremendous business benefit through its use.  Over the last 18 months we’ve been building an IT PMO, running the implementation as a PRINCE2 project.  It’s been great fun and the lessons learned drove quality and acceptance into the Project Management processes we’ve developed.

We put our presentation proposal together back in December and have been anxiously awaiting a decision.  Today we learned that we were accepted as presenters.  So now “all” that remains is to write a paper, develop that into a slide deck (I’m wondering how the Beyond BulletPoints approach could be useful here….), prepare for the presentation, and then show up and deliver it to a room full of Project Management wizards!  All this while holding down our day jobs and living on opposite sides of the country.  What, me worry?!  :-)

Honestly, I couldn’t be more excited.  And hey, I’m betting these people will appreciate the topic more than the US Congress would have anyway.