Where is the Return on Investment?

In my Project experiences, I have been able to produce solid ROIs, but it is not as common as people would hope.   Therefore, I would like to discuss some key success factors that could assist others in their journey to achieve a positive ROI;

#1. Choose your battles carefully:   If you have technical skills and your customers have some money, then you can most likely work your entire life, because there is a never ending stream of projects.     Be very selective in the projects you initiate.  You must find what I call “Home Run” projects.    This is a baseball term for the non-American readers.   But it refers to a project that is technically easy to do, and will have a clear ROI.   You can recognize a home run project because they will have:

• Angry Users:   If no one is Angry, then there is no ROI. Business people only get angry when they have trouble making money when it should be easy.  As you meet the team members, see if anyone is truly upset.  If not, then the project is most likely a waste of time. Think of a marriage, when is your spouse the most unreasonable?  When your relatives visit.   This is normal; a spouse cannot behave any other way. It is the same with business people. If they are happy, then the project won’t help. It is only when you see steam coming out of their ears, do you know success is imminent. 
• Lots of Raw Data: Before you can embark on a project, you must have the raw data that shows the gap in business performance. Then your team must work with the business experts and demonstrate graphically where the gap in performance can be closed. If you lack data or cannot get your hands on it, then you probably have a questionable project. Remember the only true benefit of IT is to manage data, so if there isn’t a massive store of data related to the project, then it will not be a success story.
  

#2. Choose your team carefully:  As Boston has shown the world of sports, great teams are rare, but when they come together, nobody can beat them and they will win time and time again.    Here are some key things to look for in a great team:

• Can you make each other Laugh? I would like to point out that the greatest teams in history enjoyed each other’s company. Can you engage each other?  What if someone gets Angry, what if you get angry? Can they make you smile?   Look for some laughter.
• Have they done it before? The best teams have people with previous success stories. Make sure your team members show success in previous engagements.   
• No Quitters: The mission must be more important that all else. A loss of a key person in a project may make you wish it was never started. Look for perseverance in your team members.

Comments

[Bhavin Joshi]

Enlightening article.

[Ravi Kolluru]

Thought provoking article!! This applies to any situation in life.
"If ain't broke, don't fix it!!".

I specially liked spouse example used in "Angry Users".

[Mark Naudé]

In all my years of doing projects, I've never actually picked up on the one critical success factor: look for angry users.

That one pointer alone makes this article EXTREMELY useful. I'll be keeping my eyes open for that in the future.

Thanks for the tips!

[Smriti Karmarkar]

Interesting...Am moving to a Leadership role soon, so these tips should come handy...Thanks for sharing, John.

[Rajesh Rupani]

Thanks John, this was good. It comes to knowledge by sheer experience. And as it is always said "if you cannot mesaure, you cannot improve"

[Ravi Saxena]

The article was refreshingly honest! Thanks.

I have some counter points though:

On the Angry Users Tactic: I think we cannot classify all useful projects to have angry users. What about projects that happen as a result of rollout of a completely new functionality? What of projects that occur out of a business transformation?

I also feel that it is just a matter of mindset which is now changing from reactive to proactive with increasing maturity of IT Customers. A reactionary mindset is of fixing a system only if it is broke. With Customers getting matured in their IT effectiveness, the scope for systems still being broke is reducing. It is thus sometimes essential to go for projects which may not be a direct &/or immediate requirement of application users.

I hope there is an instalment two of this post coming in soon. We need a whole lot more advice on actual project execution after we have chosen our battles and our teams.