Not too long ago I was reading a blog article on entrepreneurship, which I think really applies to software development projects as well. The article is titled, “7 Warning Signs Your “Big Idea” Is Going to Flop*”. I am not saying the article should be titled, “7 warning signs your “software development project” is going to flop”, but maybe it could be. Right now I just want to concentrate on the first warning sign – “You keep changing your mind”. Does this sound familiar to anyone who has defined a new project, or who has run a software development project? Probably it does!
I love this paragraph from Mr. Chartrand ‘s blog – “Business old schoolers call it “scope change,” and it can seriously hamper your progress. The more you push the boundaries and keep adding to your project, the more it becomes a time-consuming, cost-heavy monster that never ends. Risks go up, your schedule gets trashed, deadlines get blown and quality goes down.”
Wow, the same thing that happens during a software development project. You can change all you want, but realize it could affect your timeline and it could drive costs up!; if doing Agile development, i.e. you may need to add more iterations or you may be at risk of blowing an iteration deadline if you are not tightly controlling it. But adding more work tends to mean the cost goes up and the timeline extends!
I like the suggestions given as well for how to overcome this warning: “Give yourself a set amount of time to do research and plan the scope of your project before you start. Take a few days, weeks, or months to really think things through. It’s okay to waffle then because no one else is watching, and you haven’t done anything yet, so you don’t have to backtrack. But once your time has expired, stop, make whatever decisions you need to make, and move forward. Look at it like a deadline. You can change your mind up until a certain day on the calendar, and then after that, you stick with the plan until you’re finished.”
Applying this to a software development project, means it is ok to do a little planning, think and write out what you want. It doesn’t mean you are not “agile” or not “flexible” just because you think about something or write something down. It just means you have actually thought the idea through. I am not saying write a book, but writing down can help you think about aspects you have never even thought of and it can help orient others to the idea. Also great to have someone read those specs over besides yourself. Can they understand it? What questions do they have?
Another great suggestion is to give yourself a deadline. For software development deadlines can be imposed by government regulations, i.e. new banking regulations require you to track and report transactions over $10,000 as of the 1st of the year. Deadlines can also be imposed by your clients, i.e. they promised to their user base that this new feature will be available by this date. Well it had better be in by then. The harder situations are when you do not have a deadline imposed on you and you need to set one yourself, but set one you must, otherwise you will keep incurring costs and never finish your project. Even doing agile development, set a rule that the latest that changes will be accepted is 5 business days before the delivery date for each iteration (or whatever is appropriate for your organization). Making changes up until the day before the due date, or even the day of delivery just gets you this, (from Mr. Chartrand ‘s blog – “Risks go up, your schedule gets trashed, deadlines get blown and quality goes down. “ Good advice for software development projects!
* To read the original blog text: http://blog.kissmetrics.com/product-flop/#ixzz13QohVRzb