My team recently started working on a product rebuild from the ground up. All software development projects have some inherent risks. In my opinion, the main risks of this project are:
- Not delivering on time
- Delivering on time, but with lots of critical bugs.
To manage these kinds of risks, teams often turn to frameworks like the Project Triangle, as I explained in this article.
However, that doesn’t really work on a rebuild. If the team was late and the remaining features were too critical to remove them from scope, the team would be left without any room to negotiate scope. Let’s see why.
The MVP Approach
Let’s pretend my team is working on rebuilding a blog service, where authors can write some text, and visitors can read it.
My team has a set of requirements, and our goal is to release an MVP by an agreed date. This MVP includes some core logic plus some critical features for the success of the new application.
One approach for a project like this would be to complete each component of the new service to the last detail, and then move to the next component, until the whole service is done.
However, this is risky.
Completing one component after the other may leave us with no time to complete the last component, or to ensure that all components integrate correctly. Instead, we’ll build a house.
Building A House
A house is not built one room at a time. Instead, foundations are built first, then the structure, and lastly the end details.
In this project, we’ll be following a similar approach. Rather than completing every MVP feature one after the other, we’ll build the foundations and structure of our application first.
This means we’ll ensure that articles can be written and saved, that visitors can read those articles, and that all of this works for any registered user of the blog.
By having the core features ready earlier, we gain more time to test them and fix any critical bugs we may find. We can also validate some decisions and even run early demos with key stakeholders.
It’s like visiting a house that’s still under construction: we know it’s not finished, but seeing the structure in place helps us confirm we’re building the right thing. The finer details, like wall colours, tiling, and other features, can be left to our imagination for now.
In essence, we could say that by completing these core features we have completed the rebuild, and that we can treat the rest of the project as a regular new-features project.
This is really powerful, as it takes a lot of pressure off the team, as the risk of not delivering is heavily mitigated. There’s still a chance that we don’t deliver every feature planned at the start of the project, but this is bread and butter and we can use standard project management techniques for this part.
Identify What’s Important
Every Software project is different, and although we can’t always apply the same techniques to reduce the risk, there’s always something we can do to mitigate it one way or another.
I find that the best way to mitigate any project is to work on the key features first, but it’s not always clear what this means. In most projects I’ve worked, this is as simple as to sort a list of features by some kind of priority.
In this case, however, sorting by priority would not have helped us mitigate the risk. We needed to break down the features to identify what are the really important features are.
Happy coding!
José Miguel
Share if you find this content useful, and Follow me on LinkedIn to be notified of new articles.