I think I've just figured out why software projects are almost never delivered on time or on budget. I started thinking about this today, as two pieces of our site were supposed to be delivered over the weekend, but, as usual, didn't show up. I'm not upset - because, well, I'm accustomed to it. I realized it's something I was guilty of too when I gave project estimates. I just need to better plan around it.
Engineers (meaning software or hardware engineers/programmers) are definitely a specific breed of person. We tend to over-promise or at the very least, overestimate our skills and ability to meet business requirements. It's not that we can't complete the project, it's that we think we can complete it in a much shorter period of time. We tend not to think about the details - or the issues we'll encounter, because, we think we won't have them. We know the end goal and we know we can get there. But there are so many variables - does the software have the libraries I need to complete the task? Does this Javascript query work on IE and Firefox? Is the database properly configured? Does the database design make sense/work? Have the images been properly sliced? Engineering projects run into roadblocks that projects in other fields often just don't encounter - the intangibles. Painting a house for example is a repeatable task. You generally know how long it's going to take to paint a specific square footage. Sure it may rain, but everyone understands that you can't paint in the rain. Even other non-repeatable tasks don't suffer the same issues. If you're investing money for someone, you pick an investment and invest. As a lawyer or any other field which requires research, you do your research and are done with it. But with software, it's rare that you've programmed, to a tee, whatever your current assignment is. You'll undoubtedly uncover a variety of unexpected issues along the way. And it's nearly impossible to evaluate every issue. Hosting issues. Network connectivity issues. Database issues. There are so many moving parts that aren't entirely within your control or domain of experience. We also like to think we won't face those issues or that we can overcome them much more easily than we can. So next time you have a software project due, take the time estimate and double it. Then add a few months. That will be much more realistic.
2 comments:
Hey Mark - I actually disagree with you assessment on why projects are late. I think the inability to give accurate estimates is a piece of it but a small one. I agree that they are always late but it is due to the fact that the only way you get people to focus on the details is with time pressure. I can have a project that is 6 months and we will look fine right up until people start freaking out about go-live and thinking through all of the little things that need to be fixed. For this reason, I manage projects with a "pump fake" approach. I always pick a date ahead of when I really need it to go-live and force it to be ready by then. Call it a pilot, beta, etc but it will drive people (both biz and tech) to get serious about requirements, design, construction, and testing before you have to truly deliver to a customer.
Software projects always take the time you give them... so give them less time.
@Scott - I'll concede a bit to your point, because I think you're partly right. And I guess the degree to which each component plays a part in the delay of a project is project specific. But what you suggest is something people face with any project in any domain. As someone who writes code myself, I'm always over-promising, because I don't take into account these unexpected issues. I like to think I can deliver in a set amount of time because I think I'm that good. And I don't think these problems will happen to me. Maybe I'm delusional in thinking that this only applies to me, but I can't tell you how many times I'll stop by a fellow developers desk only to find him stuck on a problem he thought was incredibly simple. For days. Procrastination is at fault in many cases...but in software I find it's often more than that. It's ego too.
Post a Comment