5 Ways to Kill a Software Project
Dear Reader,
[UPDATE: Podcast version]
For the past three months, I’ve been watching a software project happening nearby slowly dissolve. While it’s not totally gone, currently, it is in such a state that I doubt it can be realistically salvaged. That’s not to say that the project won’t be delivered but the developer is now in ‘patch-n-go’ mode with major needs of the client being ignored simply to allow him to get “something†out the door. So as everyone is recovering from this year’s “Talk Like a Pirate Dayâ€, let’s take a look at some of the steps that the developer and the project owner took to effectively kill this project.
First, a little background; this project is a web based project. In hind-site the customer needed a CMS with a shopping cart. The customer sells a wide variety of items so any off-the-shelf shopping cart solution would have had to have been customized. I’m sure by now, you have selected your favorite open source CMS or shopping cart package as a good basis for this project. I know I did, but that’s too simple of an exercise. With the basics of the project in mind now, let’s take a look at 5 rules that were followed to a “T†to properly kill this project.
Avoid all design and documentation
To properly kill a software development project early on, you need to avoid all design meetings with the client. I’m not talking visual design meetings but any meeting where the client explains to you what the system really needs to do. If you are suckered into one of these meetings, make sure you take control of the conversation early on by listing all of the benefits of the system and side tracking the discussion on minutia like button colors or email addresses. It is imperative to the eventual failure of the project that you avoid, at all costs, the customer giving you any direct input as to what the system should do.
Hire a developer with no domain experience/expertise.
Make sure when searching for a developer that you find a gung-ho developer with no direct experience in the client’s industry. Domain expertise will simply get in the way and slow things down so it should be avoided at all costs. It’s best to find a developer who has a great idea for a system that he/she wants to build and shoe-horns the client’s needs into this system. The developer having an idea before you even approach them will work in your favor because he/she will concentrate on building out their system or framework and every feature request by the client will be squeezed into a slightly similar feature in their system.
For your project to fail properly, your developer needs to ignore the concept of Best Practices. Development environments, unit testing and source code control systems are all time sinks and should be avoided.
Write everything from scratch
Once you’ve hired your developer, make sure they do not cheat by using existing code as a basis for the project. Your project is unique enough so that no one else has thought of it yet and no existing project can help. Make sure he/she understands that this include the framework. Let them know that you expect him/her to write the framework for this project from scratch.
Make your Sales department start showing the project before your developers has finished it.
As soon as development begins, make sure the sales department is out there showing it to the client. Errors should not be considered a bad thing, they just shows the client you are making progress. Since you’ve done away with any controls in the process, expect features that have been requested and implemented to disappear the next day as the next request comes in. This gives you great fodder for jokes between you and the client. These times of bonding will only draw your client closer to you instead of making them wonder how you spent their deposit.
These meetings between your sales department and the client are excellent opportunities for your client to “remember†important features that have to be in the system. Be prepared, when the salesperson comes back they should have a napkin from the restaurant they met the client at, covered with new features that your developer needs to take into account.
Let your Sales department set your deadlines
Regardless of their lack of grounding in technology, make sure your Sales department knows that it is their job to set the deadlines for the project. Left to their own devices, developers will set deadlines based solely on the time it actually takes to build the system and refuse to take into account that the client has a trade show in a week and absolutely has to have the system in place before the show. The Sales department is the only organization that truly understands the clients needs and therefore should control the development schedule and all milestones.
If you goal is to kill a project, following these 5 simple rules will ensure your success. Software projects do not have to fail though. While software development is a complex and messy process, there are really only 3 things you have to get right in order to put your project on the road to success.
- Open and clear communication lines between you and your client.
- Clearly stated and immutable project goals and feature lists.
- An understanding of and an adherence to software development Best Practices, including source code control, unit testing and code reuse.
Get those right and you are well on your way to a successful software project.
