When developing a product, the given constraints and boundaries aren't always easy to handle. But as long as they are realistic and used wisely it shouldn't interfere with building a great product. The most common constraints are set on scope, budget, schedule or quality.
In traditional plan-driven projects, the features are described and estimated upfront. The time and cost necessary to deliver these features should be clear at the beginning of the project. After the requirement analyses phase the scope, schedule and budget get frozen and the phases of design, implementation and testing start. Everything with the big-bang deadline in mind at which everything must come together magically.
Scrum projects are value-driven. Given the complexity and unpredictability of software development an upfront fixed scope isn't possible. Therefore the budget and schedule are often fixed, but the scope isn't. Because Scrum always focuses on the features with the highest value, the features that aren't done at the end date are the ones with the lowest priority.
Another variety is one that can occur in both traditional and Scrum projects but for sure is a recipe for disaster. And I know, it may sound like a Product Owners dream, but in my experience, it's a nightmare for a project:
A customer with an apparently unlimited budget
Now you might wonder, how often does this happen? Well, I've encountered quite a few projects in which budget really wasn't an issue. Having all the features was more important than the budget. And sure, sometimes there was a set completion date, but when the budget is unlimited, quite often the deadline also isn't set in stone.
Having unlimited budget is a problem because:
- It causes a fundamental problem. Setting the right priorities is extremely hard when you have something abundantly available. Therefore the real difficult choices aren't made. You can compare this with having the eternal life. This seems very attractive, but an eternal life is a meaningless. Because in such a life it doesn't matter if you do something today or tomorrow. You might do it next week or month; it doesn't matter. A restricted life however, creates a sense of urgency and the need to make the right choices. "You only live once, but if you do it right, once is enough". This example can also be used for products and projects. A funny movie that empathizes my point is: "Pentagon Wars - Bradley Fighting Vehicle Evolution"
- It causes a planning problem. The value of a deadline is insignificant with projects that have an unlimited budget. Because surely, with money you can always buy more time to build more functionality. The pitfall is having a customer that demands new features continuously. When you don't have a decent continuous delivery process; chances are high the product won't ever see the daylight.
- It causes a motivation problem. Without a restricted budget (and consequently without a product vision and scheduling constraints), the development team doesn't know what they can expect; when is the product done, when does it add any value? Sooner or later this will become a problem. And this is quite remarkable: you would think a team with an unlimited budget should be able to create the most brilliant products. But this isn't the case: when the "pain" starts (the death march), the team will fall apart due demotivation, not because of the lack of money. The opposite is also true: a team with a restricted budget will be highly motivated to build the right product within the limited amount of time. This might also be the reason why small startups (with limited budgets) are nowadays outpacing large companies.
How to deal with an unrestricted budget?
- Create a product vision. Describe and visualize your product vision and strategy. Capture and validate the ideas about the target group, key product features and the value you want to achieve with the product. Share this vision with everyone involved with the product development. Knowing the 'why' behind the product is necessary for making the right choices during the project.
- Set a schedule and budget. Determine the minimal viable product and estimate the number of sprints needed to build it. Based on the number of sprints, calculate the necessary amount of budget. Be transparent about the progress and continuously inspect the quality of the product. Order the Product Backlog taking into account the priority, risk, and dependencies. This increases the chance of building the right product and build the product right.
- Release early and often. Moving your ideas into production as fast and efficiently as possible is necessary to validate the products quality and value. Using a software delivery strategy like Continuous Delivery supports a smooth and frequent release to production. This gives the customer the opportunity to really use the product, give important feedback and trim the tail whenever he/she feels the product is complete. An important side effect of frequently releasing the product is the highly motivating effect it has on the development team. Nothing beats a satisfied customer using the product you've build.
So, although having unlimited project budget might seem the ideal scenario, I have some doubts about it... What's your opinion on this topic?