Why Custom Software Often Gets Delayed
43% of IT projects miss their budget estimate while 49% are delayed. This delay accounts for budget overruns.
This post explores the risks that can delay a software project and how you can avoid them.
Unclear Requirements
Requirements describe what a piece of software should be able to do.
Problem:
When requirements are unclear or underspecified, there are two things that a developer will do: ask for clarifications or guess.
If a developer asks for clarification, they will need to wait for a response. If a developer guesses an ambiguous or incomplete requirement, their output will likely need to be reworked.
Solution:
The time spent at the start of the project, to clarify scope and requirements, is time saved during the development of software.
To increase the chances of success, a project should start with a kickoff meeting. This is the first meeting between the client and the project team.
During the kickoff, the following are discussed:
- Scope of work
- Costs
- Timeline
The kickoff meeting aligns the client and project team so they understand the project mutually and what will make the project successful.
Scope creep
The scope of a project defines the:
- Project goals
- Tasks
- Deliverables
- Budget
- Deadlines
Problem
Requirements are bound to change, particularly as we learn more about how customers use a product or feature.
However, requirement changes that are uncontrolled and continuous are undesirable. The project goes on and on with no end in sight. This is when scope creep occurs.
Scope creep prevents a development team from delivering valuable progress within a defined amount of time.
Solution
Software companies that follow an agile methodology prevent scope creep by:
- Adding new features only at the start of a sprint (typically, a two-week period where a project is broken down to meaningful segments)
- Prioritizing: the features that are most important are completed first. Less important features can be pruned or delayed to meet the schedule. Remember the rule: it is better to have 100% of one feature than 50% of two.
Poorly structured communication
With so many communication tools in place, exchange of information in itself is rarely the problem.
The problem often lies in the assumptions developers and clients make.
Problem
Poor communication can happen in different ways:
- The client communicates requirements that are incomplete or vague.
- The software company or developer communicates progress that is too technical for a client to understand.
- The software company or developer is not able to update the client of the real progress of their project.
- A struggling developer is not able to communicate the progress of their work.
Solution
By nature, software is complex and difficult to describe. A software requirement template helps a client communicate their requirements in a way that is complete and easy to understand for the software partner.
To keep a client updated, a software developer works with different contact points for the client depending on the size and stage of the project. These are the business analyst, account manager, chief technology officer, and project manager.
A project manager will get daily updates from the project team so that they can identify blockers that can cause a project to miss its timeline.
Poor escalation process
Escalation happens when a developer gets assistance from a colleague or a senior developer.
It is beneficial under the right context because:
It highlights the problem, which can be a good reference for future issues.
It saves time and resources by involving people with the right skill sets for a given problem.
Problem
A project can be derailed by a bug that a developer is not able to fix on time. With no escalation process in place, custom software may spend more time in development than it should.
Solution
A software provider should implement a process to help a developer who has been working on an issue longer than expected. A peer, senior developer, or software architect can help in clearing up a blocking bug.
Unrealistic deadlines
Problem
Setting an unrealistic deadline happens for two reasons:
- The project team is too optimistic about the time needed to complete a project.
- The project team wants to impress a client.
Solution
To avoid unrealistic deadline promises, a software company should:
- Admit that there will be unforeseeable bottlenecks; and consequently,
- Make allowance for problems and risks that they cannot foresee.
- Require the development team to accomplish reasonable tasks at a reasonable time.
Hofstadter's Law
Problem
In 1979, when chess engines were still constantly beaten by human players, it was estimated that it will take ten years before a software team can build a chess engine that will be a world chess champion. This estimate fell 8 years short.
Any project that is complex enough is always delayed, as stated by Hofstadter's Law.
Solution
A software developer should anticipate delays and make allowances for them when agreeing a deadline with a client. Conversely, a client should set some flexibility for missed deadlines.
Procrastination by a team member
Problem
Too many "what if's" and "Let's think about it" can lead to inaction. Hours of inaction can easily pile up into days and into missed schedules.
Solution
Procrastination is a personal challenge that affects an entire organization. Company culture is still the best guard against procrastination.
A client should work with a company that rewards employees for their productivity while looking after their personal happiness. It's hard to talk software success without talking about the humans behind them. After all, software is written by humans.
Context switching
Context switching happens when a developer jumps between projects, programming languages, or tools. Task switching, which is another name for it, slows down a developer's ability to deliver meaningful work. This is because it takes time for the human brain to adapt to a new context.
Problem
A developer might be called on to work on another project that a software company is working on: to help with bug fixes or provide technical support.
Solution
Quality software requires focus. That is why a dedicated software development team is typically assigned to work on a complex project.
Poor workforce planning
Problem
Assigning the right number of people working on a project carries some complexity:
- Too few and everyone is overextended
- Too many and way too much time needs to be spent on communication; and deciding how and which things need to be done
The timing is also important. Adding more human resource to a late software project will only make it more late, as stated by Brook's Law. Adding more tools to an on-going project also tend to follow this arc.
Solution
Workforce planning should come after specific deliverables are defined.
A software company should assess each developers capabilities and measure it against the technologies needed to be used. The development team should be supported by a project manager, quality analysts, and other relevant non-developer roles.
Not explaining the motivation behind a deadline
Deadlines motivate a team to work towards a common goal. Completing a task within a specified timeline gives a sense of accomplishment.
Software teams, being the creative people they are, require more than just a set of tasks to do and the time to complete them. It helps with team motivation to know the reason why something is being done.
Problem
A client may set a challenging deadline for various reasons:
- An existing software needs to comply with a new state or federal law.
- An important event, like an upcoming holiday, may require the software to be updated or have new features.
- Security patches are urgently needed.
- A critical bug has been discovered.
Solution
Regardless of the reason, the business driver behind a deadline should be made clear to the project team. It helps them focus and gives them more motivation, knowing the context of why they put in effort.
Third-party technology
Modern software development is mostly about building new technologies on top of existing technologies. This makes the process faster. But it comes with downsides.
Problem
Developers may need to use third-party technology to build or upgrade a client's software. For example, the following scenario can happen:
- A customer wants a cloud-based custom enterprise resource planning (ERP) software.
- A software company uses a third-party cloud service
- The project goes smoothly at the beginning.
- A few weeks later, the third-party cloud service provider upgrades their system.
- This triggers a bug on a client's ERP.
Solution
A software company should map out all third-party technologies that will be used in their development. All the unknowns and risks should be highlighted.
There should be a dedicated person, a chief technology officer or a software architect, who understands the impact of a third-party technology on the whole software ecosystem.
Employee turnover
Problem
Tech is the industry with the highest rate of employee turnover. Most software companies have a churn rate of 13 to 21 percent.
A turnover of 13% can increase the required effort by 24%.
There is a possibility that a key personnel may be lost while software is being developed. Ask your software partner what their contingency plan is if a key personnel is lost.
Solution
A reliable software provider has internal systems in place to prevent employee turnover.
Before a project starts, a software house will also set in place a plan if a turnover happens while the project is on-going. Usually, they do this by reassigning a developer with the best fit skills for the project.
