Working with other agencies and consultants in the industry and attending business meetings, we keep hearing complaints by customers being ignored while asking for more changes to their fixed price projects.
There are several reasons for that scenario:
- The changes would break an existing functionality
- The agency is unable to apply the changes (for technical or business reasons)
- The change requests happened at the end of the development phase, or even after the delivery has been completed
- The change requests are out of the initial scope
While the first three happen occasionally, the main reasons for project delivery delays and failures are the initial miscommunication at first and the scope creep.
Project Delivery Statistics
Approximately two-thirds of the software projects are either delayed, lack features asked from the client during the process, or completely failed.
The Project Management Triangle
The Project Management Triangle (called also Triple Constraint or the Iron Triangle) is a chart that outlines the main problems leading to the large number of projects that don’t meet the requirements or the budget constraints. There are three dimensions to take into account for each project:
- Scope – as many features as possible
- Budget – most affordable cost
- Time – shortest delivery time
Given the complex equation, we have written a 5,000 words guide on 25 actionable project management tips for growing remote teams. The most challenging task while assessing a project is finding the balance between the three verticals. It is practically impossible to have the three verticals aligned to their best. A product owner should sacrifice one of the three components, which leads to the following combinations:
- Feature-rich project delivered quickly, at a high cost
- Featured-rich and affordable project, delayed with time
- Quick and cheap iteration for a small number of features
The reason the majority of the projects start and fail afterwards is related to misjudging those three dimensions. Let’s get back to the miscommunication and the scope creep problems of the project evaluation.
Miscommunication or lack of a detailed specification
The first major reason for failing projects (on each side of the business relationship) is the miscommunication, or the lack of understanding while discussing the scope of the process.
This happens constantly with smaller projects and lower budgets. The reason is that a detailed specification could take as much time (or more) than the software development process itself. Project managers and team leaders try to keep the costs to the minimum, which leads to poorly documented features, design requirements or constraint during the development process and the amount of iterations and changes allowed by the client.
At the end of the development process or right before the software delivery process, the client asks for features that are not available and haven’t been planned in the first place. Since this hasn’t been specified, the development agency did not provide those features. However, many requests are in the gray area and the client often responds with comments such as:
“This needs to look better since I paid for a beautiful design”
“We need these extra views and it is normal to have them available”
“Of course, we need the complete social integration with Facebook, including X, Y and Z”
The complicated situation needs to be resolved by compromises, but depending on the discussion prior to that this may lead to a lot of unpaid features.
Technopedia defines scope creep as:
Scope creep refers to a project that has seen its original goals expand while it’s in progress. As the term suggests, scope creep is a subtle process that starts with small adjustments and ends up resulting in projects that take far longer to complete or even fail before they are finished. Even if the project is completed, scope creep can result in final deliverables that look nothing like what was originally envisioned.
Scope creep can occur for a number of reasons, including:
- A poor understanding of the original project
- Changing market conditions
- Competing forces within a company
The scope creep process also starts at the end of the development process or during a delivery. The difference between both scenarios is that the change requests are obviously not a part of the discussion, have never been discussed before and cannot be expected by default. For example, adding a destination to a web link or an action to a button is definitely a valid expectation, but adding a CRM to a standard business site without discussing it before the project has started is a separate feature.
Still, smaller features can fall in both categories. Minor changes and customizations are easy to apply, and are usually not defined in details within the specification. Web development agencies tend to accept these as minor changes to the initial flow and take the extra time to add them, which usually leads to more and more changes and a level of scope creep that is handled too late during the software process.
How To Prevent Failing Projects
There are various ways to deal with failing projects. However, they lead to added pressure during the communication, drastic changes in the project management and development process or flexible budget terms, and clients are often afraid of taking the risk working under these terms.
Detailed Specification With Constraints
Building a very detailed specification defining in details every part of the process is a viable way to work on fixed fee projects. This would break the project in modules, and each module would have a definitive list of tasks leading to an overview of the final solution.
That model is safe for the project as it limits the miscommunication factor to the minimum, but the communication overhead and specification development is an expensive process and would lead to a surcharge for the total project cost. Also, since this is a time-consuming process for both parties, the software development agency can lose the project and waste a project manager’s time to an agency that takes the risk of falling in the trap of the majority of failing projects.
The hourly rate model is flexible since it allows for flexible work terms during the process development. The initial specification is estimated against a rough number of hours, which leaves a buffer for changes that haven’t been discussed at first. This model is more flexible than the fixed fee one, and new changes are billed hourly, but clients often can’t estimate how long would the final project take in practice. However, this reduces the cost of building a complete specification for every minor feature or design request by the client.
The Agile development process is a flexible model that doesn’t rely on a specification as the Waterfall model does (more on Waterfall model here), but starts with a general concept. Deliveries could be weekly or bi-weekly, and changes happen constantly, after each small iteration. Each phase is planned after the previous one, and the team should be flexible and responsible for changes. This also means that the platform should be carefully planned for flexibility since changes are expected to happen constantly.
In order to avoid a project failure, both parties should agree on clear and direct communication. All expectations should be defined as thoroughly as possible, and issues such as scope creep and the complications of a general development job should be outlined at first. A flexible model for adding extra iterations after the initial delivery should be proposed, or an agile model that allows for changing the project terms can be determined as the best solution for a project.
Check out our Services and contact us in case of any questions regarding our ongoing digital strategy for successful businesses.