Software development projects frequently overpromise and underdeliver. This is frustrating for everyone involved – customers, leadership, and the team. To deal with this, I use a very simple approach that I call the “70/70 Model”. This model helps to ensure that software projects not only deliver to their commitments but have the flexibility to respond to the inevitable challenges and opportunities along the way.
The Need for Roadmaps
As software development or IT managers, we are expected to deliver features and capabilities that meet the needs of our customers. Whether we have responsibility for the full product or work on components, we are expected to provide visibility into what we will deliver and when. This visibility, often in the form of a roadmap, is critical to our delivering what is expected of us.
If you are developing a software product (or component of a product), the roadmap is important for two reasons. The first is internal. Your management will want to review the capabilities that you plan to deliver in order to make your product successful. This roadmap will need to include key features or capabilities most likely aligned to calendar or fiscal quarters, even if the delivery model is more frequent. The second is for customers to know what is coming. This roadmap may be the same as that used internally or may be a simplified higher-level version.
This concept still applies if you are delivering internal / IT software. The only difference is that the delivery will be to internal rather than external customers. You still need approval from management and your customers will need the roadmap in order to plan for adoption.
Whether or not you explicitly say it, the features and capabilities that you include in your roadmap are seen as commitments by your stakeholders. This is the case even if you communicate them as not committed. The expectation is that you will deliver these as described and on time. That sounds simple enough, but most software projects underdeliver.
Why Software Projects Under-deliver
Software development projects almost always miss their dates. Ok, that was a slight exaggeration, they don’t always miss their dates but in order to hit them features typically get cut. Even when features don’t get cut, there are often other problems such as poor quality, or burned-out engineers
There are a few key reasons why this happens.
- Management pushed hard for a date that is just not reasonable.
- Something comes up that is unexpected, oftentimes related to a difficult technical problem, taking more time than was planned.
- The scope of the project changes.
- There are some resource issues during the project.
These problems are not new. We have been working to address them through different processes and methodologies for quite some time. We started with the Waterfall model by focusing on the accuracy of our plan. We decomposed every aspect of the plan into tasks, estimated each, and rolled up the results. We determined the critical path and documented dependencies. We even had strategies for areas with a lot of unknowns, leveraging prototyping to ensure we understood enough to fully scope the tasks.
As you can imagine, all of this took a lot of time. We did end up with far more accurate plans. But there was added pressure from management to be aggressive with our completion date given how much time had already gone into the planning process. Additionally, the plans that we created were not very flexible in adapting to changes in the market and feedback from customers.
This gradually lead to the broad adoption of a new methodology – Agile.
Why Agile Does Not Solve the Problem
Agile addresses the estimation problem directly, and in a way that delivers a better solution for the customer. Rather than planning everything out in detail and then working to execute to the plan, Agile takes a very different approach. Agile breaks work into small pieces that are well aligned to delivering value to the customer. These small pieces, commonly called user stories, are prioritized frequently based on previous work completed and feedback from customers. The team or teams then work on these stories in the order provided, ensuring that the final result that is delivered meets the needs of the customers.
Where Agile struggles is in defining the features and capabilities up front, in the form of a roadmap. Approaches such as Scaled Agile are designed to help with this. But they do not fully address the risk that you will overcommit on your roadmaps.
The 70/70 Model
Never commit to a roadmap of features and capabilities that require more than 70% of 70% of your resources.
This sounds like sandbagging – adding in a bunch of buffer so that you can handle all of the risks that exist. Nothing could be further from the point. Here are the components of the model.
- You should only allocate at most 70% of your team’s time. You need to take into account vacation, sick time, classes, all-hands meetings, company events, etc.
- Of what is left, you should only allocate 70% to roadmap items. There are two reasons for this. The first is that software engineering is hard to estimate and full of surprises. Therefore we need to have some flexibility to deal with the unexpected. The second is that customer needs change. We need to adapt. If we were to fully allocate our resources to items on the roadmap, we would have no flexibility to adjust.
Closing Thoughts
We have made great progress in the way we plan, develop, and deliver software to our customers. The 70/70 model is the key ingredient that is missing.
You will run into some challenges with management and the commitments that you make on your roadmap. They will want to see more. They will want to understand how long you think things will take and how that compares to the resources that you have. Initially, they are unlikely to support the 70/70 model based on the number of features that you will deliver. It will be up to you to work through this. You will have to decide if you show them the details of your calculations or not. Ultimately you need to show that this model allows you to deliver what you committed and more and that the results are well accepted by your customers.
When the scope of your releases change, you still need to make it very visible that this has happened and why – and then you need to show that your model allows you to deliver on the committed roadmap along with dealing with some level of scope change.
A word of caution – be very careful in estimating the key features that you need on your roadmap. Make sure that you are allocating only 70/70 or roughly 50% of your resources to these. Then use Agile to execute keeping a careful eye on the committed roadmap items. You will have sufficient resources to deliver on these and can leverage Agile to overachieve – delivering additional capabilities that are driven by customers and the market.
See Also
Get Stuff Done!
Spend Time on the Right Things – A Super Effective Tool
How to Manage Your Manager
0 Comments