Working with fixed-scope and fixed-budget projects is perhaps one of the biggest product management challenges I have encountered.
In this article, I will describe my experience in applying different technical and management practices that, when carried out at different stages, prove to help with these challenges:
The process I will describe is a guideline based on several assumptions and practices that I will list, as we go through the steps of the project life cycle.
Before starting, let’s look at the problem that needs to be solved and the real limitations of the client.
Contracts, RFPs and scope documents rarely reflect the purpose of the product or the client’s main limitations.
It is important to devote the necessary time to understand the problem the product will solve and the strongest limitations of the project either before or after the sale. Frequently, we get acquainted with the project after the sale was made and the conditions were fixed. We need to distinguish whether it is more important to resolve something specific for a fixed date, validate some hypothesis, make the most of a very limited budget, or go to market as soon as possible.
In any of these cases, it is very important to get as close as possible to the reality of our client; this inception activity can be very useful at this stage!
It’s impossible to estimate the size of a software project.
This has basically been proven, and it implies that there can be no estimation errors. Accepting this is forcing oneself to develop better skills in scope management, planning, task breakdown, negotiation, and quality assurance. In general, it is not a good idea to push a developer to “comply” with an estimate or “commitment”; this will only result in more defects and low morale.
Always try to solve an estimation problem by managing the scope, that is, doing less. The fastest way to end something is when you discover that it is not necessary. This video of #noestimates does a very good job explaining it.
The result of the initial estimation is actually a budget.
Although it’s not possible to estimate accurately, the initial estimate is a useful tool to determine the budget and to discover other limits. Somehow we try to establish the size of the project to know if we will have sufficient resources (time and money) to generate the desired impact. Normally, this is achieved with an initial estimate. Proposal software tools can help streamline the estimation process so you can focus on the scope of work and budget.
If, for example, the estimated size is 1,000 hours of work, my recommendation is that once the project starts, that number should be treated more like a budget constraint than as a number of activities on which the deviation will have to be controlled. In this case, we have 1,000 hours (or its equivalent in money) to solve the problem.
Prioritize work on an ongoing basis. Keep in mind, 80% of the value of a product is delivered by 20% of its functions.
Once we have at least a basic understanding of the project’s limits, it’s necessary to prioritize based on the estimated cost-benefit ratio. This means to work first on those functionalities that will deliver the greatest value and at the same time, work on mitigating the identified risks (either technical or not) as soon as possible.
Whatever the chosen prioritization model (Kano, Cost of Delay, ROI, ad hoc, etc.) it’s also important to keep in mind that the initial prioritization is a snapshot of our initial understanding of the problem/solution and will lose relevance with time, therefore it will be necessary to perform this exercise continuously.
Build in an iterative and incremental way. Working software is the only real measure of progress.
One of the most effective things I discovered in software development was when we changed from layered development to vertical development in short iterations: splitting the work into small increments so that in one week they can be developed, tested and installed in at least one QA environment that’s accessible to users. Use a definition of done so that there is no unfinished work that accumulates and generates problems in the future.
Dividing work into even smaller increments also helps to remove many low-value items from the scope that would otherwise have been developed as they were considered part of a whole.
Quality is not negotiable; the faster the work, the more defects.
Unless we are building a disposable prototype, each increment delivered must have the highest possible level of quality both internally and externally. And every detected error must be resolved immediately if possible. To increase internal quality, it’s wise to do unit testing and code reviews. These practices together with the necessary refactoring are the minimum that a team should apply.
To increase external quality, each functionality developed shouldn’t be considered as done until the corresponding testing has been performed. The whole team should participate in this activity; not only those who have the role of QA, and it shouldn’t be done in a separate team nor a post-development phase.
Read how high-performing teams ‘shift left’ with continuous testing.
The lack of internal quality generates technical debt and maintenance problems; the lack of external quality generates defects. Both end up being very expensive in terms of time and your relationship with the client, especially towards the end of the project.
By utilizing APM tools in development and QA, many performance issues and bugs can be identified before they make it to production. Read why APM usage is shifting left to development & QA.
It’s much easier to negotiate with a client who has already been able to use their product.
When we work in an iterative and incremental way, in a few weeks we should be able to install a first version of the product in an environment accessible by the client and – if desired – by their users.
The level of anxiety experienced by the client will decrease with each consecutive delivery as they can see a quality product growing after each iteration and even more if it’s possible to use it before the end of the project.
You can always divide a product vertically.
Breaking the work down in a way that is compatible with the continuous delivery of small increments poses many challenges for those who are not used to it. In general, all the teams are quickly faced with the impossibility of dividing something that – in less than a week – delivers value and can be validated by a user. However, if you devote enough time to research and practice the many existing ways to divide the work, it is always possible to achieve.
So far we have seen the foundations to generate a helpful framework for project scope management and ROI maximization. These practices in themselves have the ability to radically change the way we experience software development. In the next section, we will see how to use the benefits of this way of working and achieve a complete transformation of the framework to successfully finish our project.
In this second half, we’ll see how to use scope management to evolve a product and its framework with the ultimate goal of transforming what initially began as a project with a fixed scope and budget into a project with a variable scope and equal budget.
Show the evolution of the product.
If there are no limits, there’s no real prioritization.
Usually, at the beginning of a project, there is a low level of awareness as to the little amount of time we actually have to develop our product. This perception may result in statements such as “everything is important”, making it very difficult to generate a prioritized list. It is good then to always work on visualizing the limits of time or money that exist; only then will you work consciously on really prioritizing.
Revealing the limits helps to focus on effectively prioritizing, and can be achieved by showing, for example, the number of estimated sprints left to complete the budget or reach the required date.
Work and effort tend to expand.
I practically have never seen a project finish before the estimated date or before the budget is used up. That is why it is so important to set the limits; any software is potentially infinite in size and the limits are what will determine when it’s done. In my opinion, it’s a combination of the Parkinson’s Law and the existence of predefined budgets that “compel” you to spend whatever is available.
The continuous delivery of functional increments generates more changes.
One of the reasons why some people argue that Scrum does not work with fixed-budget contracts is a large number of change requests that it generates. Allowing the scope to change is not the same as letting it grow.
It is important to understand that the initial specification is nothing more than a set of hypotheses about how to provide value to users. The increments serve to validate these hypotheses and usually, the feedback tends to be very different from what’s expected; at this point, the greatest contradiction and the greatest opportunity for change become evident. We as providers of the solution are probably tied to the predefined initial scope, but the user responds according to their needs and the client, according to the needs of their business.
It is very important to clarify and record what is NOT going to be built.
Prioritizing well is a constant exercise in scope reduction and simplification. In the many talks that we can have with the stakeholders, new ideas will always come about that will affect the size of the project, generally inflating it. To avoid misunderstandings, it is important to know that you can acknowledge everyone’s ideas, but that doesn’t mean that they will be included in the project. It is important to explain that adding new things means removing others. For this, I have found it very helpful to use tools such as the one below, in which, together with the client, we write what will not be included in the next release in a collaborative way.
Source: https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/
The continuous exercise of deciding what is within the specified scope and what is not should result in a list of those things that although valuable, cannot be included by contractual issues (or other limits), generating some sort of backlog for elements out scope.
Changing the rules of the game. The value of the required changes that are out of scope will exceed the value of what is on the “to do” list.
As the project moves forward, there will come a time when:
At this particular moment (in my experience, around the middle of the project), we should reveal that the value of things that are out of scope have greater value for the business than things that are in the initial scope and that are still pending. This is because the users/clients have been able to test the product and validate/refute their hypotheses, identifying future, more valuable improvement opportunities. In the best case scenario, a reduced version of the product was already put into production and exposed to the greatest change generator that exists: the use of the product in its context.
The client will prefer to change to a flexible scope in order to maximize the value of the product
If we have reached this step and we are working with a fixed scope and budget, then we can offer our client the possibility of including and prioritizing elements of the backlog that contains the elements out of the project scope. Given the expectation of maximizing the ROI of the solution and the investment, it’s unlikely they won’t want to talk about it. In return, we will need to negotiate the commitment of not exceeding the initial budget or the limits we used as a reference in the beginning.
We can do this by prioritizing elements that were out of scope and discarding those that were in the initial scope, but have a very low value.
The advantages of this change are:
In some cases, it’s even possible to deliver such a high amount of value at the outset that you can end the project early, saving time and resources for both parties.
There will always be low-value items in the backlog that won’t be developed.
At the end of the project when the allotted time or money are exhausted, it’s very likely that there are many things left that will never be implemented and that is fine. As we previously discussed, software is potentially infinite in size, so there will always be more items to add. However, since we have constantly prioritized and delivered valuable software, the value of what is left out will be marginal.
The software reflected in the initial specification may be very different from the one that is delivered.
Since the initial definition was no more than a set of hypotheses to solve a problem, it’s normal and expected that the result has little to do with that initial scope, yet is a lot closer to a real solution. How different could it be? It depends on many things, but what would be odder is if the two weren’t different at all.
What I have shared here is nothing more than a series of guidelines that I use in my professional practice. Each project is different, and as with any complex problem (see model Cynefin), different results are obtained from the same practices. We should not think that there are best practices; there are (at most) principles or guidelines which is what I have presented here. Yet, I don’t believe they are static, but they will continue to evolve and change with their day-to-day use.
The Cynefin model of complexity https://en.wikipedia.org/wiki/Cynefin_framework.
Stackify’s Application Peformance Management tool, Retrace keeps applications running smoothly with APM, server health metrics, and error log integration. Download your free two week trial today!
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to stackify@stackify.com
