A tech project succeeds when it finishes on time, within budget and it works. These are the typical success metrics but there are more. There must be no security flaws, it should have as few bugs as possible, it should be easily supportable, new developers should be able to easily step into the project, installations and upgrades should be simple and it should have sufficient documentation. Everything has to come together to make a successful tech project. Failures in any of the above will contribute to project failure.
Time and costs are the typical measure of project success. Some approaches, like waterfall, work well with this and others, like agile, seem to contradict it. Agile focuses on a fast development cycle with rapid changes. It typically has no fixed deadline, the project continues until the client is satisfied. The intricacies of both methods are beyond this post. Typically, developers have a preference one way or the other and this affects their productivity. This is a simple concept; force someone to do things differently and they won’t work as quickly.
Other factors affect time and cost estimates. Some are external, such as scope creep. Scope creep is when the project manager makes changes to the project specification. Sometimes the impact is minimal, sometimes it means a complete rewrite.
Another time and cost factor is task switching. If developers are forced to switch between different projects, sometimes several times a day, it can destroy estimates. Developers tend to work ahead. Task switching interrupts that process so reduces efficiency. An equally disruptive factor is employee turnover. If new employees are brought into an ongoing project, it can take months before they are up to speed.
While there are many factors that impact estimates, skill is a large one. A project is typically divided into parts. A skilled analyst will organize those parts into complexity. Complex or highly technical sections require higher levels of programming skill to complete on time. Simple sections can be completed in roughly the same amount of time, regardless of skill. So you want the most skilled developers working on the most complex parts. A section with even moderate complexity could require two days of a senior developer while a junior developer would take two months. If a project requires skill that a company doesn’t have, any projects will take far longer than estimated.
Another large factor that impacts project estimates are the number of options. Salesmen and marketers always want more options because they believe it makes the project more marketable. There are good points in that line of thought but also bad points. For a project to work, it has to work with any combination of options. This leads to geometric project growth. A good analyst can reduce that by intrinsically handling many cases, but even design elegance has limits. Analysts typically resist new option requests while business folk try to add them. It’s one of the great arguments between business and tech guys.
Even the best estimates meet their match with unknowns. Unknowns are anything you don’t know going into a project. Libraries could be buggy or they could do something different than expected. If these bugs are unknown then they can’t be anticipated and time can’t be allocated to them. You could also find issues with the OS or drivers, and that means a new fundamental approach is required. That means a rewrite. Unknowns also impact the project requirements, such as features the client expects but didn’t properly communicate.
If a project is finished on time and within budget, it has cleared the first hurdle. It also has to work. To work it must do what it’s advertised to do and it can’t fail. To ensure it doesn’t fail, QA is required. Whether that QA is done by hand or through automated processes is irrelevant. There are cases where automated tests make sense and there are cases where human QA is more economical.
If time and cost are met then a project is typically considered a success. Unfortunately success isn’t binary. Factors beyond time and cost also impact how successful the project is. Complexity is a good example. If a project is very complex to use, people won’t want to use it. If people don’t use a project then it will fail.
A project can’t contain security flaws. If someone with malicious intent can access data or destroy systems then it doesn’t matter if a project is finished on time and within budget.
A project should be without bugs. Ideally that means no bugs, but realistically everyone is human. Mistakes are made regardless of how careful one is. Some bugs have more impact than others. Some projects allow small bugs so long as the major bugs are fixed. This depends on the company making the project.
A project must also be supportable. This means code has to be clean and well documented. Automated tests help make a project supportable, since changes can be fully tested before a patch is released. Many factors impact supportability, from code quality to custom features.
New developers joining a project, even for the support stage, will increase support costs. The cost depends on how easy it is to learn the code of a project. Code can be optimized for this, but it also requires documentation. Whether that documentation is in comments or a separate document depends on the context.
A project has to be installed and later upgraded. If this process is difficult or annoying then it detracts from the project’s success.
Finally a project sometimes requires documentation. If the project is a simple website then documentation won’t be needed. However complex projects definitely require documentation. Imagine CAD software with no documentation. Libraries are another example of a project that requires great documentation.
If all of the above factors come together then a project will succeed. There are a lot of things that can go wrong. Analysts try to account for this by padding the numbers but this is rarely accurate. Even if all factors come together and the project works as intended, it doesn’t mean the project will be a success. However that’s a business problem and not a tech problem.