Do you have to write thick reports and plans and spend a lot of time on project management?
The answer is: no. This is certainly not necessary for developments of a limited size. However, a project-based approach is necessary. The easiest way is to write a simple project plan. This plan is then used to direct and coordinate the project with the parties involved. In the remainder of this article a possible content of such a plan with a short description.
- Introduction
Short introduction to the project and background
- Project goal, result and scope
The goals to be achieved with the product (for example, new market penetration). The result that should be there at the end of the project (prototype, zero series, user manual, technical documentation….) Finally, it is good to describe the scope. In this you describe what does not belong, you define the project!
- business case,
This is not always necessary if the goal and result are well defined, but it can be very useful as a frame of reference when making decisions in the project. And of course the business case is essential when obtaining external financing.
- Technical description
A short global description of what needs to be made and what the current state of the art is (how far is it already..). Also the most important specifications can be listed here.
- Product roadmap
Realizing all specifications in one go is often very difficult and certainly not always necessary. If you are already thinking about a first version and further additions, options or variants, you make the development much more manageable. In addition, you can also easily refer to the next version during the project, newly created requirements.
- phasing
Divide the project into phases and briefly describe for each phase the goal and the results that must be achieved in the phase before moving on to the next phase. A possible phasing is: Feasibility, concept, design, production preparation, however, some iterations may also be required.
- Work package layout (work breakdown structure)
A work package classification or 'work breakdown structure' breaks the total work into parts. For example, a division into modules: Lighting, engine, dashboard, etc. or by discipline: Mechanics, Electronics, Software. The parts can of course also be subdivided again. You then get a series of work packages that you can clearly define and for which you can make someone responsible. The work packages usually run through all phases.
- Risks
Write down every risk you can think of. As a result, you are at least aware of it and you can also think about possible fall back scenarios. This also gives a solid impression to the sponsor of the project and makes it possible to include budget in money and time for solving possible risks.
- Schedule
Make a schedule based on the phasing and work breakdown structure and do not forget to indicate dependencies between the activities.
- Organization
In this chapter you can explain the project organization and all roles of persons and companies. Make a clear table with persons and responsibilities!
- communication plan
write down which reports are made and with what frequency. If necessary, also make agreements about the storage of project information
- Quality plan
If there are quality procedures that need to be taken into account, they can be written down here.
- Cost
Make a sound estimate of all costs, taking into account setbacks
If the project is really small, make at least one A4 with: Goal, result, schedule and costs, this is really the minimum.
Having a plan should now also lead to using it. Do not adjust the plan every week, but try to adjust to stay within the plan. It is best to adjust the plan with a threshold (approval by management and/or client) so that this is not done lightly.
And then… let's get started!
