Hit your Deadlines
Comments
Sometime it feels that for a lot of companies working in software development, deadlines are something that should be kept a bit vague, a bit ‘could be this week, or could be next week’. I would like to propose an immediate end to this!
Deadlines should be stuck to, as rigorously as end-of-term papers in college. In college, missing your deadline means losing marks or possible even a fail. People try it once or twice in their first year in college, get badly stung and then learn how to hit deadlines. We in the software development industry should behave in the same way.
The excuse is often, ‘oh the client changed their minds halfway through’. Obviously, this can mean a lot of different things but here’s how I propose it should affect the deadline… Whatever was agreed upon in the original delivery schedule and remains unchanged, should be delivered according to the original deadline.
Whatever has been affect by changes should be isolated and a new delivery schedule and deadline should be agreed upon. This new deadline may even be on the same day as the original deadline. However by isolating the areas affected by the client’s change request, everyone can quickly see how much work is involved in the changes, which of the original tasks are now eliminated, which new tasks are added and what the dependencies are in terms of the original tasks.
Based on this information the new schedule can be agreed upon and the deadline can be set. No deadline should be missed. Simple! 🙂
Any questions? Feel free to contact us.
Check out iStockist, our wholesale eCommerce.
It is amazing how universal this problem is and how even the most advanced companies get it so badly wrong. We are all sick of the resulting blame game where developers blame product for feature creep and product blame developers for agreeing to what now seems to be impossible deadlines and then the developers blame the business folks for having unrealistic expectations.
In my experience one major cause of missed deadlines is that the development team provide a deadline for building a feature but do not factor in the time to get the feature polished and don’t factor in other complexities caused by the new feature. Basically this runs like
“we need a commenting feature – how long with that take”
“About 2 days”
And it does take 2 days to build “a” commenting feature, but the second the client sees it they want it tweaked here and tweaked there. This final 20% can end up doubling or tripling the time lines even though each small change is effectively trivial. The second part of this that is normally overlooked is maybe the commenting feature breaks something else in the product or introduced unforeseen latency. These unforeseen problem mean that if you want a deadline to be hit you have to include a LOT of contingency into any deadline.
Another major problem with deadlines that I have seen is that the business person is blind to reality. This goes something like this.
“I want this feature”
“That will take 3 months”
“We don’t have 3 months, can you do it in 3 days”
“No”
Big argument follows which ultimately end with the developer being informed that the business guy pays the developers salary and a impossible deadline is agreed to.
Hiya Caelen! Yes, I was laughing out loud in a ‘it’s so true’ way reading this!!!
I guess there’s always going to be some underestimation in terms of giving a time-to-complete certain tasks… it’s human nature to think we are faster than we are (well it’s my nature anyways 🙂 )
But I think that by separating the unknown-more-complex tasks from the known-‘done this a thousand times’ tasks in the delivery schedule, the development team can hit more deadlines.
Our aim: Keep the delivery milestones short and achievable. Lots of quick wins. Most importantly, isolate the complex (‘how am I going to do this?’) tasks with unknown time estimates from the delivery schedule and work on refining them into bite-sized, fully defined (‘oh, now I know how I can do this!’) tasks.
In terms of unforeseen dependencies in the software… for sure there’s going to be unexpected surprises and hidden dependancies, especially in larger systems… All the more reason to keep delivery milestones short! And for sure, included in every new features delivery deadline, there’s got to be a contingency period for testing and quality assurance.