In an agency’s model of software development, a limited budget is not a project’s death sentence. It's more of a reality check determining if a project is affordable for the client.
The first project assessment is very important for the project as it’s the first attempt at breaking down a broad idea into smaller achievable chunks of work. But as software development is involved, it’s hard to ever perceive them as final or fixed.
Because of all the risks & changes involved, the initial project estimation is more of a pointer driving the development team and the client towards a determined goal.
How to make it all work in a setting with a limited budget?
Every Agile project requires features prioritization
Typically, there are three variables in software development projects: budget, scope - Time. Changing one affects the other directly. It’s self-explanatory that when we change the project’s scope, we affect both the project’s budget and the development timeline.
Every software development project is different and should be treated individually based on the team’s prior experience in the relevant industry. What’s important is that the client and the development team are on the same page when estimating and determining what the project’s deliverables are. In practice, it means that they agree on exact elements that will be designed and developed for the project.
With a limited budget, features prioritization plays a vital role. The famous Pareto rule can also be applied to software development: every idea, project, or an app has 20 percent of features that are indispensable to their functioning. The other 80 percent is extra. The key is to determine those 20 percent before the project’s kick-off. Transparency is crucial: the client and the team have to agree on the division.
Feature prioritization is considered one of the best practices for software development projects. Splitting the project’s growth into actionable stages is not only cost-effective, but allows you to gain users’ feedback in real-time after release. Plus, you can’t really escape the bugs. (link do case study, albo common mistakes in app development).
Mitigate the project’s risk from the project’s kick off
Change and risk management are crucial in creating the estimation for a software development project. The team has to consider the possibility of potential problems that can influence the speed of development; from day-to-day technical issues to potential programming obstacles that can appear along the way.
The kick-off is the most important part of the project, especially for the development team. As a project manager, I need to make the team aware of the project’s high-level goals.
To make sure we all understand them better, I use the Inception Deck tool I found in the Agile Samurai (How Agile Masters Deliver Great Software) by Jonathan Rasmusson. Basically, this is a set of ten questions and exercises that allow us to double-check if everyone understands the project’s constraints and goals. This is a great tool that can mitigate risks and misunderstandings that can happen later in the project.
For more on change and risk management, read the article on how the pandemic made us rescope a project and improve our product development process (How Agile Can Facilitate Design and Development Cooperation).
Taking ownership of the project
We all learn mostly based on our own experiences, so let me give you an example. Quite a while ago, I was an Agile Project Manager for a software project for an airline company. Throughout the estimation process, we made the mistake of not prioritizing the app features that would be crucial for the project's initial success.
Throughout the development, some features were added to the already existing backlog. After six months of development, which marked the initial release date, the product was not yet ready to be deployed. All because we did not prioritize the core features - we did not choose the crucial 20 percent. Lesson's learned.
In an agency’s model of delivering software, we’re the software experts, and the client is usually an expert in the relevant industry.
We should be acting as consultants, and take ownership of the project, not limiting our role only to being the project vendor. There are some tech constraints and limitations only we are aware of. To make the most of the cooperation and to deliver the best software, sometimes we should challenge our clients on their priorities, explain the consequences of certain choices, and propose other solutions.
It is on us: agile project managers, developers, and designers, to support clients so they fully understand the Agile way of delivering software, and are able to navigate consciously through these circumstances.
Check out also
