The start of a €100,000 project

Scope

“Yeah sure, we can fly to the moon too!”, answered a colleague once to an unreasonable customer question. Not the most diplomatic answer but – up to a certain point – he was right: sometimes you have to stop dreaming and reconsider the scope of the project. For a new product in a new domain – such as our energy harvester – defining the scope is an iterative process because domain knowledge is lacking: you don’t know anything so how to limit the scope?

For the moment the scope of the project is to build a prototype of a small renewable energy facility (a “box”) which can

• harvest energy from a (small) wind turbine,
• harvest solar energy from a (collection of) solar panels,
• charge batteries,
• divert energy to a dump load (or maybe the electricity grid),
• deliver the energy from the (rechargeable) batteries.

The additional business goals are to outperform the competition by making the box:

• highly configurable,
• power-optimal (whatever this means…).

Finally, because our box delivers green energy, sales really wants an elegant, green housing with rounded corners (this is reality).

That’s it. No more specifications. There are lots of open questions: which sizes of wind turbines are supported? How many solar panels can be connected? And so on… but we can’t expect from our managers to exactly define what we, the engineers, have to build. That’s our job (or at least the job of the system architects).

Focus of this iteration

Given the high-level, informal project scope, the focus and goal of iteration 0 is to

• improve the specifications and thus the scope of the project by achieving domain knowledge and exploring technologies, and
• create an initial set of requirements in order to formalize the project scope. This set of requirements can later on be used to agree on features with management, to set baselines, to do traceability, to make estimations…

The team

So far , the aforementioned authors are the only members of the team. We take up several roles:

• project management,
• system architect
• software architect and engineer.

In addition, as we are embedded software engineers and architects, we do have some basic hardware and electronics knowledge. This might be enough to do some basic hardware prototyping (proof-of-concept, proof-of-technology).

Nonetheless, we will outsource the (final) hardware design as well as the mechanical design, although the latter is still uncertain (since that depends on whether we are going to industrialize the prototype or not).

Planning

An unclear project scope can only result in a rough planning. We hope to have decent prototype over one year. If the prototype is going to be industrialized we take another year (mechanics design, production chain). Note that we work full-time as freelancers (and have other projects) so we anticipate to only work one day per week on this project. However, to get this development on the move, we will invest some more time in the beginning.

Budget for building the prototype