3 “Shortcuts” That Spell Doom for Your Product Development Schedule
Product development schedules are notoriously tight. After all, when trying to capitalize on a market opportunity, no one ever pushes a team to slow down. There is always a rush to get to market before a competitor or for a certain trade show.
Unfortunately, shortcuts often have the opposite impact; unintentionally resulting in getting to market slower than if the team had stuck with the original plan.
This article identifies three common shortcuts that often result in extending the schedule, offers solutions on how to avoid them, and provides guidance on how to identify the right strategy to tighten your project schedule.
Mistake #1 – Slashing the Schedule
Key Insight: Avoid the temptation to skip steps along the way and instead, take a risk-based approach when bringing in your schedule.
As soon as the product development team gets pressure from management to bring in the schedule, it is common to grab the project Gantt chart and start slashing what appears to be easily cut.
These three common methods of slashing the schedule almost always result in slowing down product development in the long-term and should be avoided:
“Let’s cut design reviews, we don’t really need those. Skipping will easily save us a few days!“
Getting rid of design reviews is one of the biggest and most frequent mistakes. This inevitably causes the team to miss something critical, resulting in extra time spent on unplanned activities that could have been avoided.
For example – a team misses a critical design flaw or interference forcing them to remake or fix parts that don’t fit to make them usable. By the time the team is finished fixing the problem(s), any “saved” time is added right back into the schedule and all of it was spent in crisis mode.
“We don’t need all of those design iterations, let’s cut one – we can just do a really good job on our first iteration and then move right into manufacturing!”
While in theory this seems like the perfect solution, in practice this almost never goes well. Typically, teams will take more time completing the first iteration to make sure they get it just right and then end up deciding to do another iteration anyway. So now, the team is behind the original schedule and takes longer on the project overall.
“We can just cut all the slop out of the schedule and assume everything will go perfectly!”
This approach uses smoke and mirrors to create a schedule the team can show to management that magically hits the desired launch date. But in reality, the team is now forced to use a schedule that no one believes in and significantly increases the chance of missing both the new and original schedules. With this tactic, the team is operating on wishful thinking, and it will eventually catch up with them in a big way.
Resist these temptations!
Instead, begin by performing a thorough risk analysis. During this exercise, the entire team brainstorms on what keeps them up at night, what could impact project success, and what factors could potentially push out the schedule. These are typically not line items in the schedule itself but rather, the things between the lines – anything and everything that could go wrong.
Once these are identified, the next step is to score which items will have the most detrimental effect and highest probability of happening. From there, plan how to prevent the highest risks from happening, or create contingency plans.
For example – an engineer is worried that a certain feature may require an extra iteration than is planned. The easy solution is to cut the feature from the product. If that is not an option, then form a tiger team (a dedicated team of experts, assembled quickly to solve a short-term problem) to speed along the design/test/revision cycles until this feature catches up with the rest of the product.
The team may also need to select a go/no-go date at which time it is decided if the feature will make it into the product, perhaps resulting in a delay of the desired schedule. The difference in this scenario is that the delay is now a carefully weighed decision.
Resist the temptation to start slashing the schedule without using a risk-based approach. Schedule slashing pushes the risk down the road and requires everything else to go smoothly. The one constant in product development is that the unexpected always occurs.
Mistake #2 – Skip the Planning and Jump into the Fun
Key Insight: Complete a thorough planning process – one that identifies all stakeholders - and make sure the plan is a living document that the team consistently revisits throughout the project.
It is not uncommon for a team in a hurry to have the “brilliant idea” of either skipping the planning phase or truncating it in favor of jumping into the fun part of the project.
Resist this temptation!
Instead make sure the team completes a thorough planning phase. The following three key activities should be included:
Define Product Requirements. It is critical that the team defines the product requirements prior to jumping into architecture and design. This activity aligns the team with stakeholder expectations and provides an opportunity to discuss the product as a system.
A system-wide review of the product encourages each discipline to examine the product interfaces. This is where miscommunication or misunderstanding often occurs. By discussing these at the beginning of the project, strategies can be created to minimize risk.
Also, make sure the team identifies the requirements that are the “nice to haves” and [JU4] the “must haves.” Facilitate a discussion with the key stakeholders to truly define and understand the priorities of a project. By separating the critical, “must have” requirements from the “nice to have” requirements, the team is given a tool to reduce scope and preserve the schedule as needed.
Build a thorough project schedule. Building a schedule should be a team activity that identifies all discipline interfaces and the true critical path.
Don’t let team members build their sections of the schedule in isolation. This often results in a fragmented schedule with each subsystem and discipline connecting inefficiently at the system interface points.
Instead, sit down as a team, and define milestones where the subsystems will come together – for example, prototype builds, system design reviews, and phase reviews – then, have the team go off and detail out their schedule.
Once the overall schedule is defined the team can discuss potential problems, identify high-risk areas, and launch contingency plans. Don’t wait until the team is stuck on a critical issue to think about how to proceed. Adjust as needed and be sure to allow for extra project management time to facilitate the active management of the schedule.
Identify all stakeholders and define roles and responsibilities upfront. As the schedule is being built, identify who is responsible for each task and deliverable. Ensure each team member understands their role and responsibilities and is given the opportunity to provide input and buy-in to the schedule.
Make sure to communicate these roles and responsibilities to the entire team to facilitate discussions across disciplines and interfaces.
Also, identify all stakeholders at the beginning of the project, keep them informed throughout, and invite them to design and project reviews. This prevents a stakeholder, that wasn’t previously identified, from surprising the team with a different perspective on project priorities or adding additional features that require extra design iterations.
Now that the team has completed a thorough planning process, make sure the plan is a living document that the team revisits throughout the project.
Mistake #3 - Confusing Technology Development with Product Development
Key Insight: Clearly define the criteria needed for your technology before it enters into the product development phase.
One of the biggest schedule killers occurs when technology enters into the product development phase before it is ready.
Technology development is a more circuitous and unpredictable stage (where most invention occurs) and should be completed prior to product development. It is also typically focused on features or subsystems whereas product development is focused on implementation of the technology and is more straightforward to define and plan.
For more information about the difference between technology development and product development, see this article by Don Baumgarten, Product Creation Studio’s Director of Mechanical Engineering.
When technology development is incomplete, there are too many unknowns. The team can’t predict how long it will take to solve a particular problem or even if that problem can be solved.
For example, a company wants to create a product that has a longer battery life than anything else on the market. In order to accomplish this, a new battery technology will need to be invented. Jumping into product development before defining the battery technology is a high risk to the project schedule since it is unpredictable how long it will take to invent a new technology.
Instead, complete the technology development for the battery prior to launching the product development effort. If waiting to move forward with the project is unacceptable then form a tiger team to run in parallel with the product development team.
Define criteria upon which development of the product can be launched. Set a go/no-go date for the team to decide whether to go on hold (to wait for the technology to finish being developed), move on with a lesser technology or kill the product altogether.
Minimize the Hits to Your Product Development Schedule
We all know when developing a new product that timing is everything. However, taking shortcuts is typically not the right way to get your product to market faster.
The key to keeping your project on track is to follow good process, involve all stakeholders from the beginning, and avoid the temptation to start product development too soon.
By avoiding the above schedule killers, you can minimize the hits to your project schedule and ultimately, get your product to market faster.