The Run Away Project of Doom

The first step to taking control of a run-away project is to evaluate your goals. What are the stated goals of the project? Now you need to figure out why these goals are not being met. Is it caused by poor planning? Poor performance? Inadequate resources? What?

Poor planning means you are in a world of misery. If you are just woefully unprepared for the job then you need to get to work and design a plan that will get the job done. The US Army teaches the 5 P's: Proper Planning and Preparation Prevents Problems. Get a plan together ASAP and get to work. Once you have your deployment plan you have to reset everything and start fresh. Good luck, but chances are you will catch endless flak for this error.

If you are plagued by poor performance from your team or suppliers then you need to look into replacing them. With the current job market in most parts of the world you can make very valid threats about firings. You don't need to be a bully but some people just don't fit into every work environment. Don't let personal relationships hinder you in this process either. I have had to fire some of my closest friends because of poor job performance. Needless to say, we aren't friends anymore, but I blame them for that.

Whatever you do, don't be too quick to blame resources! In many cases you are asked to perform the impossible and are only offered limited tools. It happens. But this is when you need to get creative! If MacGyver could escape from anything with a paperclip then you should be able to develop an escape plan for your current predicament. First, you need to know what why you are implementing this project. What purpose does it serve? Who are you trying to please? What goals are there for this new system? Once you have that data, you need to narrow your focus to the absolute core requirements and ignore the "pie in the sky" features/requests that always seem to get included in every project. Once you know the real purpose you can start getting creative.

For example, one of our clients needed a computer server at a remote warehouse facility. We were told explicitly that we could not spend any money at all. We examined the real functions that the server would perform and we divided them into core requirements and requested capabilities. Then we narrowed down the core requirements into basic functionality statements. So, for example, the server needed to capture data from the shipping terminals which translates into the functionality statement: "retrieve and store data." Once we burrowed down to the real functional requirements, we realized all we needed was something that could store files for a short time then transmit them somewhere else. So, we simply configured an external hard drive to run Linux, connected it to the network and created our very own $150 micro-server. We solved the problem by focusing on the heart of the requirements and ignored all the ancilliary functions that our client could live without.

Is this the ideal way to work? No. But that doesn't mean that it won't work. Just get your team together and have a serious discussion to identify the real core requirements of the project. Then focus on getting those requirements implemented in a logical sequence. Additional features and gizmos can be added in later on, as needed.

No one ever wants to hear about why you failed. Don't waste time on useless behavior, such as assigning blame. Instead spend your energy and resources on solving the problem. Then no one gets blamed.