I was struck by a recent Baseline.com article that described the top 6 reasons IT projects fail in "What Dooms IT Projects." Primarily because the reasons have nothing to do inherently with information technology, and thus are identical to why all projects fail – including new product launches, new market expansions, new manufacturing technology adoption, new financing forms and any other new projects companies start. AND because these are the same reasons I've been reading for 20 years!
- Insufficient user (or customer) involvement. Inevitably someone says that if the team had just spent more time talking to users/customers everything would have worked out OK. As if for some reason the team had no interest in the customers, and were so arrogant as to simply not care! We all know that lots of time is spent capturing user/customer input. The problem is that users/customers don't really know what they want! Therefore, their recommendations are insufficient to describe what it would take to really make them happy with any change.
- Unrealistic Timetable. Why do people say they'll do a project in 3 months that everyone knows will take 9? Simply, the team has no choice. In today's world we have to achieve results quickly. Long projects are never completed, because conditions keep changing (more on this in #4 below). So the team is forced into very rapid deadlines. Only, the deliverables are usually kept the same, making it impossible for the project to complete on time!
- Poor Requirements. As if there was no target? There are plenty of requirements, it's just that (back to #1 above) the customer doesn't really know what they want, so the requirements which look great at the beginning look insufficient (poor) after people are a lot more educated from the completed work! The requirements look great until you get into the effort and start seeing how much more could be done, and how much of the value lies in going the next step (often in multiple places.)
- Scope Creep. During the project users/customers see early examples or interim deliverables. Once that happens they say "Oh, now I have a LOT better idea what I really want. So can't you just make this small change? It will make all the difference imaginable in how I'll use this – or even whether I'll use this." Given this interim input, there's almost no way to NOT add on to the project.
- Lack Executive Support. Of course no executive is going to say "I am four-square behind this project" once user/customer feedback starts coming back less than enthusiastic, timetables start slipping, the deliverable starts looking a lot bigger (and the work a lot more expensive) and finger-pointing has started about "why didn't we figure this all out before we started!" Even when the entire management team yells "go" at the beginning, once a project is deemed problematic support evaporates faster than ethyl alcohol rubbed on hot stainless steel!
- Poor Testing. Sure, blame the testers. Given how many variables have shifted and turned since the project started, who remembers, or knows, what to test any longer? Exactly what performance requirements will be the triggers that determine acceptability? Which variables are most important? And, if the project is now struggling with changed requirements, the timetable is blown, scope has been redefined more than once, users/customers have started griping about delays and the executives are saying "will this nightmare project ever end" exactly what tester is going to stand in front of the train and say "hey, let's stop this thing"?
Bad projects are expensive. According to Baseline.com, just in American IT projects $63B is lost every year to failed IT projects. About 25% of the time – really, 1 in 4 times – projects are considered complete failures. Less than 1/3 of the time are projects considered successful. Yet, there is nothing new in this list. It's been the same list for at least 20 years! Even though "project management" has now become an academic discipline – results are not improving.
The approach to project management since the 1960s has been the same. Write down requirements, use some sort of "scientific management" effort – some kind of time/motion study – to estimate the time to complete, freeze the project, get agreement on project outcomes and funding, then "execute." And project management has been all about how to improve this process by adding more, and more, and more, and more steps. There are now checklists that are book after book of things to do in order to "nail down" each step. And there are hundreds of articles written about the "discipline" of keeping to the plan, not changing things, and keeping "everyone on board to the original project" until it is complete.
But all of this simply adds up to do more of what we've always done, try to do it better, via automation try to do it faster and consider using consultants or offshore resources to do all of this extra work cheaper. There's been no change to how we do project management, no change to the underlying premise. Even though results are no better now – in fact they may well be worse – than 40 years ago!
So why don't we change the approach?
The problem is that shifts happen. Customer needs change every day, based upon what happens not only in their work but in what their customers want and in what competitors do. As the world shifts, requirements change. Customers that don't really know what they want, because they only know what they've done, are asked to do the impossible to define their requirements – and then asked to do the even more impossible task of not wanting more as things shift. As demands on customers change, and as competitors change the environment, shifts demand changes in expectations. And testing is all about "does the hurdler jump the bar" without any consideration, by design, as to whether he finishes the race (much less how fast he finishes.) And the incentives are for judges to lower the bar, so the darn race can just end.
The old approach was designed for a nice, slow-paced, static world. Where everything is known, and that's impossible with market needs. It can work if you're trying to build a bridge maybe, but when trying to design some solution for a complex system (like the modern market, or IT community, or logistics design, etc.) that has infinite moving parts? And where the speed with which parts change can be amazingly fast? Let's get real, traditional project management simply won't work in today's complex IT, marketing, finance, HR, operations, production, logistics, manufacturing, sales world!
So, instead, try a new approach. We've used this for 10 years with all kinds of projects, and it works a whole lot better. Undertake your project realizing that if it aligns with future needs it will add value – and that is what really matters.
- Don't ask users what they want. Don't ask them for requirements. They don't know.
- Develop your scenario of what would be the PERFECT, ideal solution in 2 or 5 years. Really. Not just an improvement over today, what would be perfect! Even if you have no idea how you would ever do it. Write that down. Then, say what those requirements are. Design to those specs – which are probably 10 to 100 times beyond the current state. Don't settle for some fractional design. Don't start if you can't deliver what the market will want in the future when customers aren't bridled by what they don't know today. Build for a future scenario that is way better than today – not just some initial requirements your Locked-in customer thought about.
- If you don't know how to design it, study your competitors – including fringe competitors. Look at everyone imaginable that is solving a similar problem and see how those you may never before considered are doing it. See how people in China, Bangladesh, Hyderabad, San Paulo, Moscow, Taipei or Bangkok are doing it. See how some 20 year old college kid and her buddies are trying to do it. Look at how the upcoming competitor with .1% market share is doing it. Don't just go for the well known solution approach. Don't settle for "best practice" which is a 6 year old innovation that has little competitive value left. Don't be afraid to do what can provide huge value improvement.
- Write a long story, with detail, about how completing this project is going to really screw with your existing competitors. Describe the huge pain they will feel. How they will be in shock and awe of your performance once you are able to blow them away with this new capability. Destroying the traditional competition is a great motivator. Make them into the villain – after all, they are! (By the way, if you don't think the project will have a positive competitive impact – why are you doing it?)
- Focus really, really, really hard on defining important early valuable deliverables. Fast wins. Don't just figure out what the end state will look like, it's critical to know what you can deliver successfully in 90 or 120 days! We can't wait forever for results, so throw out complex ROI analysis. Instead ask the team to simply say how quickly they can start producing, rather than spending, money – and how quickly their project will pay back the investment. Force them to prove that there are measurable wins in the first year, and payback in less than 3 — on something!! Don't worry about "scale." Just the opposite, worry about how to demonstrate value quickly! Keep all timelines under a year, most under 4 months.
- Tell everyone you are going to do something new. You are prepared to be the innovator. You can, and will, Disrupt the things you've done in order to give spectacular results. You don't just want a 5% improvement, you want to win. It's not about how much better you were than before – it's about being competitively better than everyone else. You simply want to win in the marketplace – and you'll do new things to accomplish this. You care about results more than process.
- Give the team permission to do whatever they have to do to succeed. Don't give them a list of "rules" within which the project has to operate. Give them the permission to really focus on success – that they can do what's needed to accomplish their goal. Don't set up barriers. Instead, tell them there are no barriers and you don't want them to talk about there being any barriers.
- Make sure the team does not report to the Status Quo management. Structure the project so that the team reports to someone who can focus on project success first, rather than abiding by old rules, or fears cannibalization, or has a vested interest in the success of the Status Quo.
- Commit enough resources so the project can succeed. Don't give it piecemeal funding that will require the team constantly battle to keep the project moving forward. Don't expect success from part-time resources borrowed from other full-time work, or from a team assembled only to do this project then return to their old jobs. Everyone has to be committed to the project, and its success, and the money should be there if they reach their goals (regardless of the route they took.)
This may not sound like a typical project management approach. But hey, given how well the old approach has worked out don't you think it's time to give something new a chance? Would medicine have ever advanced if we just kept on blood-letting? When will we try something new if not now?
PS – Don't miss my newest column in CIOMagazine. "IT Strategy, Use Scenario Planning to Get Beyond Legacy Systems." As IT has become one of our highest costs, it's more important than ever we change how we do IT planning and project management.