Everyone is building stuff these days on the web. Grab some design templates, and an open-source CMS, and pay some freelancers from a foreign country $500 to bring it together. You seemingly mitigate risk by looking at their feedback ratio, client reference list, or even sample code (if you are technical enough).
But your project fails for some simple reasons:
No daily checkpoints: You might have an 8-week schedule, and let’s just assume your estimates are reasonable for now. The programmer tells you that everything is fine and you’ll have something to see soon. But soon doesn’t seem to happen and now it’s one week before the deadline. You’ve burned most of the clock and can only pray what’s there reflect your requirements.
Solution- daily checkpoints. They must show your progress, not hide beyond the tomorrow that never comes or that they are working on the backend, doing invisible stuff that is necessary, but which you won’t understand. Force daily releases.
Some people adopt agile, or scrum-based methods, which are particular versions of the iterative approach I’m describing here. The key is to review progress regularly versus allowing things to drift way off track. Easily said, but you might be surprised how hard it is to get programmers to commit and show the project. Don’t be fooled by the “almost done” or “I’ll have it tomorrow” ploy.
No prototype: if your requirements are not rock-solid and have no risk of ever-changing (only possible in military projects or large construction), you must and will build a prototype. The reason I say will is that whether you call it a prototype or not, you will probably throw away the first version of what you do. So you might as well accept that and be as efficient as possible. Allocate about 20% of your budget for the prototype and perhaps 40% of the time.
Multiple stakeholders: have one project decision-maker if you can. Sure, many people can provide input on what to build. But only one person can sign off. It’s hard enough coordinating between different pigs at the trough. If your project serves multiple users or departments, find one person among them who is trusted and is a neutral party. You won’t have time to referee. Bad budgeting/planning: this is the #1 reason projects don’t meet their deadlines. You simply set too low a budget or do not have enough time. Likewise, when you hear that someone’s project came in x% under budget or ahead of schedule, overestimation is usually the culprit.
Overestimation is also called sandbagging, to use a derogative term. In a more positive light, you should take your engineer’s estimate and multiply it by three. Not 30%, but a factor of three. The best engineers are often the worst at estimating. So don’t mistake a truly incompetent engineer for one who just is terrible at estimating time. Not the same thing as time management, which is another story,
Scope creep: this is probably the #1 project killer. The camel is carrying so many straws that its back is broken. Some project leads “fix” this by rigidly enforcing no changes. But that’s like forcing an airplane to land in dangerous weather, just because the original plan said so. The answer is to allow adjustment, but under the rule that anything added means we have to subtract at least twice as many other things. That’s also called prioritization.
