ensuring project failure in 4 easy steps
1. defining the problem and scope
- Start with an ill-defined problem or hope. Don’t bother spending time clearly outlining the issues you are trying to address. Surely it’s enough to say we have a problem.
Better yet, let your vendor define the problem for you in terms that fit their solution.
- Next, make assumptions based on what you hear from those closest to you, or that you talked to last. Don’t discuss the details of the problem with the stakeholders or those closest to the problem. Their understanding of the issues will only complicate the situation.
2. selecting a solution
- Goals? Well, they’re obvious aren’t they? “We need to fix our (inventory|security|llama|management|data) problem.” That should be good enough for anyone. Defining the requirements in any kind of detailed way is just going to eat up time. We want a solution now.
- Don’t waste time looking at your local environment or talking to the staff. Who cares if the solution you choose is completely incompatible with your existing infrastructure? You want “best in class,” right? Just ask your vendor. Besides, they said the system requirements are pretty basic.
3. implementing the solution
- Implementation planning. Whatever. The vendor says it’s a “turn key” solution. What, maybe a week to implement?
- There’s no need to talk to the people who will have to support and maintain the solution either. They’re just a bunch of whiners.
- Buy it. Tell the support team you want to start using it next week–they should get busy.
- Congratulations! Your work here is done. If it doesn’t fail, it’s not because you haven’t tried. It will certainly at least be over budget and significantly over time. If you like, you can berate and blame your staff/consultants for the failure.
- You have plenty of company. But, sometimes, you can learn something.
Or don’t. Maybe take a different path–on your own or with the help of someone who’s been there.