Product Development & Management

5 Things Killing Your Product Development Process

By |

5 Things Killing Your Product Development Process

Product development involves a veritable ballet of deadlines, teams and goals, all of which must be harmoniously synchronized to ensure success.

There are a multitude of hurdles for developers to clear on the path to bringing a product to market the right way, and the collapse of any of the key elements can grind the process to a halt, or result in a finished product that fails to meet customer expectations or release at all. Such failures can be costly in both time and money, and in extreme cases, irreparably damage a company’s reputation.

However, many of these project-killing blunders are avoidable if teams approach each step of the development process judiciously and with an eye toward effective communication, realistic expectations and a rigorous dedication to fixing problems early. The following are five pitfalls to avoid in the development process.

1) Teams Not Working Together

In order for a project to stay on task, especially a complex hardware or software development project, disparate teams must be brought together under one umbrella. Siloed teams working on different facets of the same product risk, but with zero visibility into each other’s projects, escalates the probability for error.

These teams must also be fluent in the common parlance of the project, aware of their individual responsibilities, and have all expectations clearly communicated and regularly updated as changes arise. This collaboration is pinnacle to the development process, and failing to keep teams and contributors on the same page can spell disaster.

2) Testing Only at the end of the Process

You’ve gotten the team working together like a well-oiled machine, the goals have been established and met, and the finished product is ahead of schedule. One problem: it doesn’t work. Developers can’t afford to reinvent the wheel after countless hours have been spent wrangling the stakeholders and putting the pieces in place.

Revisiting completed projects to fix issues not addressed during the development process takes workers away from other projects and can be costly in both time and money. Problems have a nasty tendency to compound as subsequent work is done on top of it, which wastes effort, fosters frustration and can risk a product running afoul of regulatory requirements. Testing throughout the development process lets teams home in on problems early before they become calamities.

3) Employee Churn

Every company has turnover, and losing key team members during a development project can have a ripple effect up and down the stakeholder chain. That is, unless you plan for it by making sure project work is well documented in a shared tool.

Let’s face it, people have low incentive to spend time documenting their work on their way out. When documentation is stored in Word documents in a networked folder it might take weeks for the team to dig through the data to figure out what the missing teammate was working on. Project teams recover faster if you implement a solution that fully captures document work, reviews, requirements, etc., as part of the normal day-to-day workflow. That way you’re not scrambling to capture knowledge when someone finds a new job.

4) Not Assigning Responsibility

The more complex a project, the greater the onus on management to properly delegate responsibility among the teams involved. That includes tracking the progress along the way and keeping meticulous records of not only who is responsible for which task, but who is charged with overseeing the completion of each step.

This reduces or eliminates duplicated efforts and risk of misunderstanding. Each team member’s role should be clearly delineated and referenceable, which cuts down on finger pointing if something goes by the wayside. On each team, it should also be established who has decision-making responsibility to ensure the completion of deliverables, and who keeps the team on the same page.

5) Bad Requirements – Not Starting With the End in Mind

Poorly defining the requirements of a project can doom the process to budget-busting rework. In fact, according to Carnegie Mellon Software Engineering Institute, rework can eat up as much as 80% of a software development project budget, so it’s critical that all team members understand what exactly they’re building, how it should look and function, and what value it provides to the market.

Complex software or hardware development projects can have thousands of requirements, so managing them effectively is the only way to keep team members from ending up lost in the weeds. This involves keeping track of completed requirements, understanding all interdependencies and managing changes to better anticipate issues and ensure inter- and intra-team continuity. Good requirements are easily understood and followed by all team members, so all oars in the water are moving together towards the same, clearly articulated set of goals.

Latest posts by Tim Anderson (see all)