This article describes project-typical risks in development and construction projects. It focuses on the project phases concept, design and construction/engineering design. Risks and possible countermeasures are described. The target audience are people who are involved in order initiation and project preparation or who are responsible for such projects. The main purpose of the article is to provide suggestions for risk management in a product development project.
The risks are listed first according to their characteristic allocation and then briefly explained. There are risks here that can be assigned to several areas, for example it is possible for an employee to be unplanned absent in any project phase.
The risks will be identified based on an example project process. The individual risks are highlighted as follows:
This is an individual risk.
Initial situation
A company wants to bring a new product onto the market. There are results from a competitive analysis that show that the current product portfolio does not yet cover a certain market segment. Therefore, a development project for a new product is initiated. At the time of the project initiation there is only a "vision" that there will be a product that is supposed to fulfill functions in a certain application area.
A concept study is commissioned to sound out the technical possibilities for a new product. In further steps, the development of a new product is derived from the concept. That brings us to the
Project phases
Concept
The concept phase should begin with presenting the vision of the project in order to then collect ideas for possible implementations. These ideas can either already be extensive product ideas or only cover partial aspects. After completion of this creative phase, the ideas found are grouped and summarized into concept proposals. A final evaluation and selection of the most suitable concept takes place. There can be more than one.
The following aspects must be taken into account in this phase:
Are the requirements for the desired product sufficiently described?
The amount of possible solutions can become too large and miss the topic.
In practice, the description of requirements ranges from verbal descriptions to detailed specifications. At the start of the concept phase, the vision of the new product should be described in at least the following aspects:
- In which environment is the product located?
- What problem is the product supposed to solve?
- In what period of time should the product be developed?
- If known: What have been the biggest problems with previous similar products?
Are the requirements too narrow?
The ideas found are not sufficiently different from existing solutions.
At this point in time, requirements should only describe functions and not a specific form. The more specifically the requirements are described, the more the solution will look like what already exists or what the person who formulated the requirements had in mind. Exceptions can be, for example, that certain dimensions are absolutely necessary, or that only certain energy sources are available or permitted in the planned environment; these should be specifically described.
Are the solutions found technically and economically feasible?
The solutions found are beyond the scope of the development budget.
In the course of the brainstorming process, a wide range of technological requirements can be expected. In order to compile these ideas into a concept, they must be evaluated both in terms of their technical feasibility (does this already exist or does it have to be developed?) And in terms of their profitability.
Are patents infringed?
The solution has already been patented.
Many solutions already exist, and the more specific an application, the higher the likelihood that someone has already patented a particular process. A patent search is therefore useful here. In the best case scenario, this research can also lead to new solutions that come from completely different areas of application.
The patent research should be carried out independently or only after the creative phase of brainstorming, otherwise creativity will be inhibited.
Do you have to register your own property rights?
The competition copies the product or parts of it.
A product launch is associated with a lot of effort and costs. It must therefore be ensured that the product can also be marketed over a longer period of time without it being immediately copied.
Are enough new ideas found?
The brilliant idea is missing.
In order to develop a new idea for a product, one has to look at the problem to be solved as impartially as possible. In an idea generation team, there should be a mix of employees with experience in this field and employees who are completely unrelated to the topic. This also means that an external view of the project can be useful at this point.
In addition, time plays a decisive role in generating ideas.
Practical tip: It is better to have several small workshops than a few large ones.
If the problem is presented in a small workshop and the desired orientation of the product is described, food for thought is set which can then be taken up in a later follow-up event. That works better than coming to a programmatic result in a single workshop.
Draft (Design)
In the best case scenario, it was determined in the design draft phase which concept or concepts should be pursued. The product elements and functions described in abstract in the concept are specified here. It is to be expected that there is a large variety of variants that could be pursued.
What should you commit to?
The number of possible solutions is extremely high.
In the abstract, a product consists of a large number of function carriers. These functions can be solved technically in different ways. There are different approaches as to how this set of solutions can be narrowed down: either through willingness to make decisions (but rather unlikely in complex projects) or through evaluation of the solutions. In order to evaluate the solutions, however, criteria must be established, which can then be used to measure the achievement of objectives. An absolute assessment is not required here. It is sufficient to compare the solutions with one another and, for example, to determine a ranking using the pairwise comparison.
Are you breaking new technological ground?
It cannot be said with certainty that a new process or assembly will work.
Especially when developing innovative projects, it is likely that you will be heading towards solutions that were previously not common in the company. It is therefore necessary to assess which measures are required in order to safely convert a solution into a functioning product or product component. This can be done by scheduling preliminary examinations and prototypes.
When is the first cost estimate available?
The return on investment is unknown.
The product costs and the product development costs should be estimated as early as possible in the design phase and included in the evaluation criteria. Usually there are sales specifications for the achievable price of the product, from which the budget can then be determined.
How fast should it be developed?
Components are not available in time.
Important components can have long delivery times. As soon as such critical components can be determined, procurement should also be initiated.
Design (Construction)
Construction begins when the product has been largely defined in the design draft. This means that there are already clear guidelines as to which assembly should be located where, which main components are used and which functions have to be fulfilled. In practice there are very different qualities of drafts, so that corresponding efforts have to be made in the construction. The later it is recognized that either the concept or the draft has a defect, the more time-consuming it becomes.
Is there a change in plan?
A design component cannot be integrated as planned.
"The devil is in the details" is a well-known saying among design engineers. Depending on the scope of the design component that cannot be implemented, it must either be improved or completely changed. This is an argument against "decisive design" and in favor of "systematic design", since with the latter you have other solutions up your sleeve that you can fall back on.
Are the costs monitored?
The product will be more expensive than planned.
As the level of detail of the product increases, so does the number of components and the resolution of the cost estimate increases. Typically, the original cost estimate has to be revised upwards for development projects. This means that at the time of the first cost estimate, i.e. in the draft, appropriate buffers should be planned (and defended).
The construction is more complex than expected.
The effort required to design a product or process with a novel character cannot be determined with certainty. But qualified estimates can be worked out in which the steps to be expected are resolved and evaluated over time.
Cross-phase risks
Many risks exist across all project phases. Depending on the character, these can be classified in further groups.
Contracts
The cooperation with external service providers within the scope of product development takes place either on a work package contract or a service contract basis.
The outsourcing can take place due to a lack of capacity or due to a lack of skills. Both cases differ in terms of risk.
Is the task clearly formulated?
The development results are not within the desired range.
At this point, a scope of work document including a specification sheet clearly helps. At the same time, the supplier must take a very clear position on this through his state of work sheet. But that's not all, because in the course of a project there are usually so many changes that they have to be communicated permanently. Ensuring functioning and regular communication is at least as important as the initial requirement specification.
Will it be delivered on time?
My supplier does not receive the required information from me on time.
Depending on the complexity and organizational structure, appropriate runtimes must be planned for decisions that have to be made in the context of product development. If this does not happen, this is an "open" gate for postponements and additional demands (claims).
My supplier does not deliver on time.
Extending the turnaround time for a work package is not exceptional. A contractually agreed penalty payment may appear to be an effective means of pressure, but it cannot save a project that has got into trouble. If the supplier is involved in a critical deadline chain, the project status must be followed closely. Ideally, an escalation scheme for various deviation scenarios should be worked out in advance.
Is the quality right?
The supplier's work results do not meet expectations.
When the order is placed, a "scope of work" must be agreed, i.e. what is being processed. In addition, it must be defined what the criteria for a finished work result are, i.e. what you want to measure the quality by.
Who will rate the results?
Nobody knows about the subject.
If parts of a development project that are critical to the success of a development project are disclosed to the outside world without being able to check the results yourself, either a second opinion can be obtained or tests can be planned that confirm the results of the development.
Team
A team is typically always put together individually for a project, as the requirements in a project are always individual.
Who does it?
Nobody has time.
Product developments on behalf of customers are rarely planned in advance; they usually come as a surprise and in a hurry and thus discard the previous resource planning.
Not everyone knows what to do.
The preparation and assignment of work packages is an elementary part of project management. The work packages should contain task descriptions as well as information on the expected processing times and, if applicable, dependent predecessor and successor work packages.
A task or work package should not be "unloaded" to an employee, but handed over to him and a common understanding of the expectations associated with it should be developed.
What if someone is not available?
An employee falls ill / takes parental leave / leaves the company.
In practice, key functions and skills are often assigned to individual employees, so that a project comes to a standstill if this employee is absent. This cannot always be avoided, as the costs for a "backup" usually exceed the planned framework.
Is the subject mastered?
The qualifications of the employees are not enough.
Missing qualifications can either be compensated for through appropriate further training or through the use of external staff. The costs for this must be taken into account accordingly.
Is it right between people?
There are personal differences between teammates.
The composition of the team is of fundamental importance. Both the technically correct mix and a mix of different types of work have to be found. The phases of team building must be planned in (see Forming, Storming, Norming, Performing; unfortunately there are constellations that "get stuck" in one of the first phases).
The motivation is deranged.
In addition to many other points, both excessive and insufficient demands can lead to a deranged motivation. What is important is the "commitment" of the employees to their respective project assignment, at least at the beginning but also from time to time.
Infrastructure
Where is the data?
Data is transferred to the product landscape too early or too late.
Product development usually begins "on the green field", outside of the other IT landscape and structures that are used in the company to manage the existing product data. This ensures more flexibility and efficiency, as the development results are only entered into the product landscape when the appropriate maturity has been reached. However, this point should be defined so that there is no subsequent increased effort. For the time before the transition to the product landscape, it is important to consider which functions are required for data management in this phase.
What is the data like?
There is no specification of what is documented and how.
The information that arises in the product development process is extensive and of various types. There is information from suppliers, drafts, design reports, CAD models (here, for example, an exemplary definition of a numbering system for drawings and assemblies) and other data whose storage must be defined .
What information channels are there?
There is conflicting / outdated / duplicate information.
It must be defined where what information is created, how it is documented and how it is to be processed further. It is imperative to avoid the double maintenance of information stands.
Are special applications required?
A tool / software / license is missing.
CAD applications for product development vary in complexity and are sold with different licensing models. Functions that are required but not available can lead to considerable additional costs.
Communication
Communication is listed last here, but it has a significant influence on the projects.
Is there a common understanding of terms?
Different names are used for the same things.
The use of different terms for the same things is only not critical if there is still a common understanding. However, since it is to be expected that employees will leave the team and new employees join the project during the course of the project, clarity should be ensured here with regard to a quick familiarization.
Terms are interpreted differently.
A common understanding must be created for all project elements and related actions. This is particularly relevant when concluding contracts.
Are they all talking to each other?
It is not communicated enough or not in a targeted manner.
It is better to briefly exchange information at short intervals than to exchange information at long intervals. People usually like to meet expectations, they just need to be communicated.
Is communication being carried out quickly enough?
The response times are too long.
This risk exists both in terms of communication with suppliers and in internal communication between teammates. An employee who is generally badly motivated to contribute his or her share to a project will not complain if he cannot take action due to a lack of an answer.
The open questions and obstacles in the project must at least be bundled by the project manager; even better, there should be an overview of the open points for all project participants.
Is the mood positive?
The mood is bad.
A good atmosphere in the project team is the "lubricant" of the project. Therefore, no opportunity for positive, but also always individual feedback should be missed.
Conclusion
The risks in product development and construction that have been taken up so far are very much on the surface of an abstract project flow. In concrete individual cases, there are also many specific risks, although not all fully compensating countermeasures can be found: these then remain as residual risks. However, a risk assessment for a project is quickly drafted and even the first consideration makes it possible to identify essential risks and counteract them with simple means.
