Of course, not all of them are bad, but there are plenty of reasons why some programmers fail to meet their web development project deadlines.
Top Reasons Programmers Have Issues Meeting Project Deadlines
The answer to a vague assignment is a vague deadline.
A specification may appear to be long and thorough – but it doesn’t prevent people to misinterpret even the slightest details.
Context and Environment
An estimate is given for the feature set described in the proposal in a “vacuum” environment. Third-party services or solutions, vendors, assets, any other dependencies could adjust the scope or postpone the project.
Lack of Experience
Inexperienced developers are more likely to vastly underestimate an assignment. Once you go through a few dozen insanely overtime/over budget projects, you develop a 7th sense for scope creep.
Limited Industry Or Business Experience
A software developer may build something that works – and yet, that piece may not satisfy a customer. The fact that a feature “solves a problem” doesn’t necessarily equate to solving the problem for the right target audience within another project, depending on their industry expectations and more.
The original assignment may actually evolve over time. My favorite client quotes are: “It was expected”, “It’s common sense”, “Of course this was a part of the assignment”. Obviously, it wasn’t quoted and agreed on.
Inefficient Estimation Process
There are dozens of approaches when estimating projects. Most of those evolve within organizations based on former experience with existing projects. Those techniques may include a series of steps, diagrams, office discussions in order to calculate the “best-case, realistic, worst-case” scenario.
I’ve tried the “estimation poker” with random estimates by several team members and comparing the edge cases. There’s also “top to bottom” and “bottom to top” – two popular techniques.
No Discovery Process
Regardless of the requirements, a lot of those caveats could be revealed during a proper discovery session. This should usually be billed within the contract and charged before sending the offer.
The discovery session may take a few weeks with regular meetings and internal discussions breaking everything down into semantic and actionable tasks that are easy to assess. This also includes the R&D phase for new features, services, tools to be evaluated before proceeding further.
Security, Performance, Scalability
A few of the common areas that require an overview before sending a proposal. We have worked with banks and telecoms requiring a completely different state of security, complex SLAs or certain requirements for concurrent users or a daily number of transactions.
Those are often requirements projecting some growth over the next months/years which should be discussed and estimated upfront.
Many of those areas can and must be covered in the contract. I’ve seen formal proposals with a lengthy section covering the things which would NOT be supported in the platform exclusively – protecting against the type of scope creep requiring a complete revamp of the system.
The same goes for the number of revisions for design iterations, expected manageable load (users, traffic, data), load times and any other KPIs that are to be expected upfront.
The Bottom Line
I generally do avoid estimates whenever I can and use a series of different strategies in order to assess scope, budget, time frames (on top of applying agile in-house).
And more things worth mentioning.
Web development is a form of craft. It’s a service – not a product. It can’t be manufactured when you ask for a custom build. The reason why electronic devices or books are priced with a fixed amount is due to a repeatable and predictable process.
Since there is “uniqueness” in each and every web development project, some buffer is to be scheduled upfront. It’s often not enough and this has to be discussed prior to signing a contract.
Development is generally a combination of science, art, and craft. There’s a certain amount of knowledge to be consumed. It has to be practiced similarly to every other job. And there is the “art” which is often overlooked.
A developer has to maintain a state of focus within a normalized environment for maximum productivity. Any professional (meetings, errands) or personal (lack of sleep, cold) deviations will inevitably lead to delays or mistakes which could expand the scope or miss the deadline of a project – unless managed professionally.