Based in Sydney, Australia, Foundry is a blog by Rebecca Thao. Her posts explore modern architecture through photos and quotes by influential architects, engineers, and artists.

Only Make Promises You Can Keep

Only Make Promises You Can Keep

Why your product development team should be in charge of your proposal process

 

Remember when Healthcare.gov was launched and nobody could access it? What about when the U.S. Air Force spent over $1 billion on the Expeditionary Combat Support System that never came to fruition? It’s not just a U.S. problem - the U.K. is still $12.8 billion into its Universal Credit welfare payment system consolidation that was supposed to be available in 2013 and is now expected to finally be delivered in 2021.  These aren’t isolated cases. A recent Standish report found that 31.1% of software projects will be canceled before they’re ever completed. Over half of projects that do get completed end up costing 189% of their original estimates.

One of the things that drives this failure rate is the organizational structure of most businesses. Account managers and salespeople work with clients on estimating a project. They may provide largely over-optimistic scopes, either because they’re incentivized to promise the world to pick up a new client or out of a genuine misunderstanding of the work necessary to solve a customer’s business problem with software.

When a product team is tasked with delivering on these estimates, they struggle to provide a functional product both on time and on budget. They end up with a glitchy product that’s only a fraction of what was initially promised. Why are we making things so difficult on ourselves in the first place?

glenn-carstens-peters-203007.jpg

 

Stop Derailing Software Development

Making promises based on the ultra-rare, best-case scenario may be a great tactic for acquiring new clients, but those clients will inevitably have a bad customer experience. Your reputation will suffer, and both the estimators and development team will point fingers at each other for being the reason why.

Having the product team provide the initial estimates helps focus this accountability and remove finger pointing.  It also makes for more accurate estimating and a lower likelihood of failure in the first place. If there are any changes during development, the team can update the plan, shift priorities, and work with the client to ensure the most important deliverables are met.

No matter what you’re developing, there are always going to be changes and pivots mid-flight. Bug fixes and unexpected design changes add extra time to projects.  New features are added to respond to business opportunities not present at the outset. Experienced product teams like those at Buoy know this and are able to bake buffer time into their estimates to account for these possibilities.

Delivering Working Products On Time and Budget

What defines a successful project is a vague concept. Facebook, Paypal, and Amazon’s mobile apps, for example, don’t have the full functionality of their web apps. Does this mean they’re not successful?

Of course not – those are three of the most popular mobile apps on the planet. What matters more than a full transfer of features is meeting the business requirements. Prioritizing features is necessary to develop a functional project in the allotted time. When product teams (designers, product managers, engineers) are in charge of scoping, they’re incentivized to estimate with accuracy because they understand this.

Here at Buoy, we loop our product teams into the sales process so that our would-be customers are provided with plans and estimates that we can deliver on. From their experience and expertise, our teams have a deep understanding of what they’re capable of delivering and what’s liable to go wrong. This method ensures we’re providing accurate estimates, setting realistic expectations, and, most importantly, delivering functional projects both on time and on budget.

Don’t Skimp on QA

Don’t Skimp on QA