The (Mis) Understandings of Product Delivery

Ana Maria Masoud gives her take on what most don’t understand in product delivery

Many project managers struggle to keep projects on time and within budget while often complaining that they do not have enough resources to get the job done within the agreed schedule. Therefore, they push their teams to minimize waste, to work harder and to plan carefully all deliverables. Sometimes this approach may work, but there have been many projects where this continuous pressure actually produces more damage than gains often because they’ve underestimated the full understanding of what it means to deliver a product. 

Product delivery is no easy skill – it requires a certain skill set, a certain bravada that can keep the end goal in sight and within reality. There are a lot of misunderstandings or myths about product delivery, but let’s focus on the top five. 

  • The more resources we add to our projects, the more scope we’ll deliver

Without a proper analysis of delays, management sometimes will consider adding more resources to a project means it will increase speed in delivery.

In reality, adding resources to a project already started can lead to bigger delays, as new resources need to be introduced, trained and onboarded properly. For the majority of projects, an undersized team doesn’t represent the cause of the delay. From personal experience, delays are caused by:

  • Dependencies not properly managed (e.g. – waiting  on other teams to deliver their piece of code)
  • Improper planning (e.g. – executing front-end tasks before back-end then rewriting front-end to match back-end development)
  • Bottlenecks in development (e.g.- code stuck in development environment because no one approved it)
  • High bureaucracy (there have been some projects where receiving an access to a specific tool took almost a month or longer)
  • Improper split of teams (e.g. – instead of having a team with more competencies, split people in dedicated teams which deliver only a piece of code => increase dependencies and waiting time)

With 19 years of a career in the software development industry, I’ve only seen undersized teams turn into oversized teams just because management believed that adding more people to a team will increase speed of delivery.

  • Cost-cutting approach

One objective of management is to optimize costs. While it is very important for a business to have a healthy profit margin, cutting costs can have opposite effects if it isn’t done properly.

With software development, cutting costs can be done in two ways: outsource teams, roles, departments, or buy less expensive equipment/licenses and so on. Outsourcing can be a good way to increase profits, but this should be done with careful planning. Managers should focus more on the quality they get with the same money, and less about moving one role from a country just because it’s cheaper. 

With this in mind, a good balance costs-benefits should prevail. If not done properly, outsourcing can jeopardize your relationship with customers, may reduce quality of deliverables, can lead to additional costs on training, retention and sometimes,  instead of reducing your costs, you actually end up increasing them. The other option is to buy less expensive equipment/licenses, which long term, can harm your business/project, producing low-level quality deliverables and de-motivating your team. 

  • High utilization of resources will improve performance

The biggest concern of some managers is that their team is not utilized enough. Many companies have targets for utilization, and management is constantly scrutinizing  this KPI. Many surveys state that the vast majority of companies consider that if resources are not billable 100% on  projects, they will have delays in delivery and will waste money paying employees to do nothing. However, the situation is opposite and high utilization leads to delays:

Some companies, like Google, implemented a system that allows employees to spend 20% of their time studying or working on other topics outside their current work related projects. This led to major innovations, as the majority of creative solutions came from those extra-activities. 

  • The sooner the project is started, the sooner it will be finished

Another myth is that the sooner a project starts, the sooner it’s finished. Unfortunately, if a project is not started properly, it will lead to delays. It is very important to spend some time in a discovery phase where you try to understand the particularities of the development, the concerns, risks and scope before jumping into a project. It is also very important to spend some time digesting information that you received before starting a project, thinking about a solution and to figuring out what is missing.

There have been  many project managers that I’ve personally witnessed that have jumped into the development phase without a minimal assessment, or consideration of the different aspects of the proposed solution, without a bird’s eye view on the deliverables and targets. It’s important that before starting a project, a reflection period on the whole solution, with different perspectives and outside the box thinking is considered. 

  • The more features we put into a product, the more customers will like it

One fan of minimalistic design was Steve Jobs, which differentiated Apple products from the ones designed by others. When the iPhone was released, Steve fought with the engineering team because he wanted a mobile phone without any buttons and they believed that it was  impossible, however no one imagined a phone without a keyboard before it became a reality. What happened is history though, iPhone revolutionized the whole industry and led to the collapse of Nokia’s mobile division – who didn’t see the disruption coming.

Google, the simplest search engine is another great example. Prior to its introduction, Yahoo! was the leader of the industry and displayed lots of content – everything from Yahoo! Finanace, Romance, Lifestyle and the in-between – crowded into one single portal. It was hard to believe that Google, a white page with only one search box, would end up destroying the Yahoo! supremacy, but it happened with much owed to the minimalistic nature of Google’s offerings.

Therefore, a lot of times the less concept works for our customers, don’t try to impress them with fancy products with tons of functionalities – keeping your software simple and easy to use. If a 3-year old child can play with your software and understands the flow, then your product is a good one and your delivery team hasn’t fallen victim to the many misunderstandings of product delivery.

This isn’t an exhaustive list, of course, but there are a lot of biases and myths that lead to failure of projects. But, let me be clear,  failing isn’t a bad thing. What’s important is to learn from failures and to keep trying until your product will become a success.