Plan your projects according to the IPD philosophy

Table of contents
IPD: history & development
Advantages and disadvantages of each method
IPD with Merlin Project: a step-by-step guide
Checklist: is your project IPD-compliant?

---

Integrated Product Development: history & development

The idea behind Integrated Product Development (IPD) did not come from a drawing board but from the daily business of large technology companies. In the early 1990s, IBM struggled with declining revenues, long development cycles and products that missed the market. When Lou Gerstner took over, he saw a pattern: teams worked side by side instead of together, decisions came too late and no one felt responsible for the economic success of a product.

IBM began to radically redesign its development process. Instead of separate departments working one after another, the company set up cross-functional teams. Marketing, development, quality, service and finance now planned together and shared responsibility for the same business success. This approach was later formalised under the name Integrated Product Development.

The method did not remain limited to IBM. In the early 2000s, Huawei faced a similar turning point. The company was growing fast, but the organisation was in danger of collapsing under the complexity. Huawei brought in a large IBM consulting team and introduced IPD in a systematic way. The impact became visible quickly. Decisions became clearer, development risks surfaced earlier and products matched market needs more precisely.

With this success, IPD became a known concept in China. Companies in the telecommunications and technology sectors in particular adopted the model. Many took over not only the tools but also the mindset: product development is not a purely technical project but a business investment that only works with integrated teams.

Today, companies in many industries use IPD because the approach translates a core insight into concrete practice: complex products work best when different functions bring their perspectives together early and accept joint responsibility.

---

Advantages and disadvantages compared to classic methods

What does IPD actually bring compared to traditional project management?

IPD offers clear advantages. Early alignment between stakeholders reduces planning errors and increases efficiency because teams can work in parallel. Close collaboration between different disciplines also drives innovation and increases motivation because everyone works towards shared goals. At the same time, IPD comes with challenges. The need for communication is high at the beginning and the approach requires trust and real willingness to cooperate. Some organisations struggle with this because their structures and culture are not designed for integrated work.

Aspect	IPD	Classic	Agile
Involvement	Everyone from the very beginning	By phase, often only late	Core team involved throughout, customer iteratively included
Responsibility	Shared responsibility and success	Everyone acts in isolation	Responsibility bundled in the cross-functional team
Risk & reward	Shared	Contract-based, often one-sided	Risk incremental, reward not shared
Communication	Open, transparent	Rather hierarchical	Frequent, iterative within the team, strong product focus
Goal alignment	Overall project	Sub-goals per company/department	Product vision and customer value at the centre

---

Implementing IPD with Merlin Project

Merlin Project provides the building blocks you need to implement IPD cleanly and transparently. The following steps follow typical IPD elements and show how to make them visible in your project plan. The focus is on bringing functions together early, structuring decisions in a traceable way and steering development as a joint process.

1. Map IPD phases and decision gates

The timeline is the backbone of every IPD process. Clear phases and decision gates ensure that teams from different disciplines follow the same roadmap and that risks become visible early. By visualising them in the project plan, everyone can see where the project stands and which approvals are required. Here is a typical sequence of phases according to IPD logic:

Concept and validation phase
The project team checks whether the product idea makes sense economically and is technically feasible.

Definition phase
The requirements are refined and a reliable project plan for scope, effort and approach is created.

Design phase
The product receives its system architecture and all technical designs and interfaces are aligned.

Implementation phase
The product is developed, integrated and tested internally.

Handover and validation phase
The product goes through external tests, certifications and pilot production to confirm its readiness for use.

Closure phase
The project is formally closed and the key learnings are documented for future projects.

How to set this up in Merlin Project:

• Create activities to represent the phases
• At the end of each phase, add a milestone for the related gate
• Link the corresponding phase as predecessor and the next phase as successor

2. Define resources and roles

Roles support the IPD idea because responsibilities are clearly assigned and the workload of individual areas becomes visible quickly. By focusing on roles instead of only people, capacity planning becomes more stable and flexible.

Approach in Merlin Project:

• Add new resources
• Assign specific roles to the resources (for example architect, site manager or engineer)

3. Enter budget and costs

Financial transparency is part of IPD because all stakeholders work towards the same business goals. A clear view of costs per phase or gate prevents unpleasant surprises later and makes approval decisions easier.

How to set this up in Merlin Project:

• Define the budget per phase or as a share of the total project budget
• Store costs per task and resource
• Assess your project with the planned/actual comparison

4. Define criteria for decision points

Decision gates mark the moments in an IPD process when a project is deliberately stopped, adjusted or approved. They help to identify risks early and to ensure that a project remains on track both technically and economically. The evaluation follows clear criteria:

• Fulfilment of the requirements of the current phase
• Viability of the business case
• Technical feasibility
• Risk analysis and resource situation

Many companies use defined guidelines that specify which evidence or results must be available at each gate so that a “go” is justified.

How to implement decision gates in Merlin Project:
In Merlin Project, you represent each decision point as its own milestone. You can attach the required evidence and assessment documents directly to the milestone, for example as attachments such as checklists for gate criteria, meeting minutes, presentations or documentation of the go/no-go decision. This makes it clear why a gate was passed and on which information the decision was based.

5. Represent interdisciplinary teams with custom fields

IPD depends on all relevant disciplines working together early. To keep responsibilities clear, teams, disciplines and accountabilities should be clearly visible in the project plan. This way you keep an overview even when several areas work in parallel.

Here is how:

• Create custom fields such as “Team” or “Discipline”
• Assign tasks to specific areas such as architecture, engineering or execution
• Group or filter by these fields

You can also group or filter by the roles already defined for each resource:

6. Work in parallel with concurrent engineering

Parallelisation shortens development time and is a core principle of IPD. The prerequisite is that real dependencies are clearly marked. This allows teams to move forward independently without increasing quality or schedule risks.

How to set this up in Merlin Project:

• Create parallel blocks of activities in the Gantt chart
• Only link mandatory dependencies
• Group your project so that, for example, you view activities per team separately

---

Checklist: 10 points for IPD compliance

1. Early involvement and joint project start
☐ All relevant stakeholders are involved from the beginning
☐ Risks, feasibility and goals are checked early

2. Common goals and shared KPIs
☐ Project goals are defined jointly
☐ Time, cost and quality are binding for everyone

3. Transparent communication and decisions
☐ Decision paths are clearly documented
☐ Everyone works with the same information

4. Interdisciplinary collaboration
☐ Teams work in parallel instead of sequentially
☐ Dependencies between disciplines are visible

5. IPD phase model and decision gates
☐ The six IPD phases are created in the project plan
☐ Each phase has a documented go/no-go gate

6. Roles and resources
☐ Roles are clearly assigned
☐ Workloads are visible across teams

7. Risks and opportunities
☐ A shared risk register exists
☐ Measures are aligned between teams

8. Budget transparency
☐ Costs and budgets are transparent for all stakeholders
☐ Gate approvals take economic criteria into account

9. Common data environment (CDE)
☐ Documents, drawings and models are stored centrally
☐ Versions remain consistent

10. Lessons learned and improvement
☐ Regular reviews take place
☐ Insights are demonstrably fed into later phases

---

Conclusion

IPD is more than a method; it is a mindset. Away from “me” and towards “we”. Merlin Project gives you the tools to shape this change in a concrete way. Whether phase model, decision gates, shared goals or interdisciplinary collaboration, Merlin Project provides a robust digital structure for your IPD implementation. It helps you get everyone on board and bring your project safely to the finish line.

You can go even deeper and add risks to individual activities, define reports based on the views in Merlin Project and use them as a basis for your next review.

To keep this article focused, we will leave it with the tips above. If you have questions or are interested in a second part, feel free to contact us.

---

If you have questions about this blog post or would like to discuss it, we look forward to your contribution in our forum.