Projects fail for many different reasons, but there are two key stages that can virtually guarantee a project failure if you do not get them right:
- Requirements
- Testing
- Don’t allocate too much time to getting and documenting requirements. Your management wants this to get done really quick, and when they talk about it is seems pretty easy, right?
- Methodology smology. Just get ‘er done!
- Assume everything – or at least everything you “know” is correct and complete.
- Don’t evaluate what business processes may be impacted – you’re just working with the application anyway.
- Don’t worry about all the requirement details, just put down the highlights - you don’t have the time to write it all down anyway, right?
- Don’t spend a lot of time reviewing the documented requirements with the users – they already know them anyway, and they are too busy (they’ve told you that over and over, so just accept it and move on!).
- Don’t walk-thru the requirements with the developers – they can read, and you can answer any questions they have. You need to keep moving on the next set of requirements.
- Don’t worry about sample screens or any of that kind of stuff. That takes a lot of time. Get any forms you are automating, and provide them as examples to the developers. That’s what they get paid for anyway.
- If “stuff” comes up during development that wasn’t written down you can just include it in the project, or do it later.
- Detail requirement specs can’t be put together until you get the final product, so don’t worry about it. You already know what’s in the requirements, just test that!
- Wait until everything is done before you begin testing. Otherwise you’ll just have to test stuff over again.
- The best test is to just do a parallel with production, and you can’t really plan ahead too much for that. Production data is always different so you need to do it right then anyway.
- If there is a problem, stop. Give it back to the programmers to fix, and wait for them to fix the problem before you go on. You’re probably too busy to waste your time when you know there is a problem anyway. Besides, the data downstream is going to be wrong now. You can’t work with bad data!!
- Don’t bother to record what tests failed, there is probably too much detail and you won’t have the time anyway. Just record that the main test passed so you know later that you tested it successfully.
- Don’t bother the users with testing too much themselves. They’ll just get frustrated with you. Wait until you’re ready to install it, give them training, and they’ll be fine.
- When you go live, it will be great. Take some time off. You’ll need it.
Ok, I know. That’s all a bit ridiculous. But, I’ll bet you’ve encountered one or more of the above attitudes on one or more of your projects. I know I have, and I’ll likely encounter it again.
Survey’s indicate that approximately 30% of all companies utilize project methodology to fully drive project process and timelines that achieve success. Most project failures are attributed to poor requirements, indicating they don’t have a good process in place for requirement definition, don’t follow their process, or just don’t have the people or culture developed to carry out the process.
Nearly every project has a time constraint that requires the project team to find the balance of what I phrase as the “need for speed, and the need to do it right.” Doing it right in my mind is the combination of following sound methodology, and achieving the right results. The faster you need to go, the harder it is to do both.
The reality in most companies then, is that you may well need to add risk to your project, take shortcuts, and adapt to your company culture.
Adapt is the keyword.
One of my favorite project stories is from a book; The Mars Pathfinder Approach to “Faster-Better-Cheaper” by Price Pritchett and Brian Muirhead (see side bar to order from Amazon – it’s an entertaining and quick read). Chapter 6 is called “Plan . . . and improvise.” The following paragraph sums up the typical project challenge:
“In your own pursuit of spectacular results, start out by doing some ‘deep planning.’ Anticipate as best you can. Consider different scenarios, and run your calculations. Make your very best guess about how the situation will unfold. But then be willing to bob and weave.”Adapt to your circumstances. Find the right balance on your project between the need for speed, and the need to do it right. Minimize the ways you guarantee failure, and you’ll certainly improve your chances for success.
About the Author
Paul currently is Practice Lead with Collective HR Solutions, and General Partner with Global ProManagement.
He is also passionate about family, soccer, and American football, and is an investor in the amateur soccer organization, the San Francisco Seals.
No comments:
Post a Comment