So, you’re scheduling IT projects and you ‘know’ how long it should take. But you don’t want to get burned by making a too low estimate. Late projects are bad. I’ve developed a handy rule of thumb for large company development projects. I have found it to be surprisingly accurate over the past (mumble) years.
How long will it take for hard-core knowledgeable developers to get it done? (Say, 10 days).
Since you’re in a big company, double that estimate. You need have to have meetings about the project and get approvals. (Now you’re at 20 days)
Are you the developer? Nope? You have another org doing the development? Double your time estimate again. The IT org will have to have meetings amongst themselves and meetings with your business team. This is important – they need to know what you want developed. (40 days)
Is your development team handled by a third party / offshore contractors / not under your companies’ direct control? Double it again, because they’ll have to talk to your IT team and have meetings. (80 days) And then double it again, because they just aren’t best of class on your application. Most contract development models depend on rolling in resources as needed, then rolling them out as soon as code is complete. So, there’s some learning curve and training needed for the project. (Now you’re up to 160 days).
That’s the general rule of thumb for big companies with lots of layers and the typical outsource development model.
(Editorial comment removed – my boss reads my blog.)
No comments:
Post a Comment