Launching a new product seems easy; it is a combination of demand, talent, and technology. However, some estimates show that well over half big projects fail. Mavenlink published this blog in 2017 covering “21 Shocking Project Management Statistics That Cost Business Owners Millions Each Year”. This chapter covers some of the reasons projects fail.
Before we start, let’s describe briefly the phases of product development. We won’t dive deeply into details; in future blogs, we will draw a table describing the differences in product development stages in different sectors such as aerospace and consumer electronics. Product development stages, in a nutshell, include:
Planning- assessing the opportunity.
Build up- developing the plan and requirements.
Implementation- monitor and control per plan.
Closeout- production, sustaining and postmortem.
Flaw #1: Lack of communication between the business team and the technical team
In product development the business team identifies the market needs, the product high-level functionalities, the price customers are willing to pay, the time to market and the desired quality (sometimes measured in annual failure rate).
The technical team develops the technical requirements, the product cost, the low-level functionalities including the system requirements, designs, verifies and validates the project.
One of the major flaws in product development is assumptions. The business team assumes that the technical team understands what the customers want and the technical team assumes they understand what the business team requests.
Starting the early stage of the product development there must be a mechanism placing a dialog between the two teams.
The business team must be clear what the business requirements are and the technical team must be able to develop a product based on those very specific business needs. While it seems that communication exists and both parties understand each other, there must be a method to establish the handshake between the two parties.
We usually use a requirements management tool as a method. The method should allow the business requirements to be reviewed and approved by the technical team and the product and system requirements to be reviewed and approved by the business team. These requirements should be agreed upon before the implementation phase. Any change of the requirements during the implementation phase required approval by the business team.
Flaw #2: Not having a proper project plan
A project needs a proper plan agreed by the business team, the technical team, and any other stakeholders. A proper project plan includes tasks, subtasks, dates, who responsible for every task, major gates, and the critical path. The plan is often established by the project manager and it’s developed by the team. The project manager consults with the technical teams’ leads (functional manager) to develop the project plan. This project plan should be approved by the technical leads and other stakeholders before the implementing stage starts.
Flaw #3: Scope creep
There are a few reasons scope creep occurs:
The lack of clear project requirements.
Not having a good method in place to review and approve the requirements.
Change board and change requests are not part of the process.
The project plan doesn’t take into consideration inputs from the technical teams.
Not specifying gates to review progress (monitoring the projects).
The technical team keeps polishing and adding features.
Flaw #4: Missing the Go to Market strategy
The go-to-market strategy is the plan for how to bring the product to market. I will have a chapter that covers what the go-to-market includes, but in general, the go-to-market includes a business plan frameworks who the target customers are, the channels to use, the marketing plan and the sales strategy.
Flaw #5: Not specifying clear approval gates
A good project plan includes major approval gates performing go-no-go decisions. Some companies perform the go-no-go decision once at the beginning of a project. Others require having four to six approval gates during the project life cycle. I favor the second approach. It improves the sense of urgency, it allows stakeholders to be informed on the progress, it is a good opportunity to cover requirements’ changes and an opportunity to assess if we should continue.
Flaw #6: Not specifying roles and responsibilities
The purpose of specifying roles and responsibilities at the beginning of a project is to clarify who is doing what. A project must have a project manager; The project manager is responsible for the overall project’s execution. The project manager is responsible for moving the project forward on time, margin and quality. It is also important to specify what other team members on the team responsible for. When developing the project plan it is recommended to specify the role of the person in charge of executing the task.
In the incoming blogs, we will cover the best practices such as requirement management, product lifecycle management, project planning, the role of the project manager and more.
コメント