figure 1: Doing nothing may be very costly
Managers
often think that there is no cost involved when people are not (yet)
working on a project. This is a misconception. Once the idea of the
project is born, the timer starts ticking (figure 1). Every day we start a project
later, it will be finished a day later, depriving us, or the customer
(it's upon sales and marketing to see that the benefit is shared appropriately) from the revenues
which by definition are much higher than the cost of the project, otherwise
we shouldn't even start the project. The only good reason why we don't run
this project is that we currently are spending our limited resources on more
profitable projects.
Initially, every day of the project adds potential value, but gradually
we arrive in the area of diminishing returns where every extra day adds less
than the return we should expect. This means that even delivery time should
be appropriately designed for optimum benefit, and this puts it directly into the
scope of Systems Engineering and design. After all, the Project Manager is
responsible for delivering the right result at the right time,
but the Systems Engineers and other developers determine the time it
takes to deliver the appropriate system or service.
Systems Engineers and other developers often think that before they have
delivered "all" requirements, the project isn't finished. Well, if delivery
time is also a requirement and even often the most important requirement,
why are all other requirements treated as being more important than the most
important one? See also "The Fallacy
of 'all' Requirements".
Time is money and we don't have the right to waste it, unless it's our own.
If the system we are realizing is part of a larger system, the system
integrator (our customer if we are a sub-contractor) prepares other
systems, people, and equipment to do the integration into his system at a
certain time. He also alerts the potential users of the system that they
can start reaping the benefits of the new system at a certain time. If
he doesn't get our sub-system on time, he's losing money, the other
systems, people and equipment staying idle, while the potential users of
the system also have to change their plans. The cost of one day of delay
to our customer and the deprived benefit to the ultimate users is a lot
more than we realize. Even doing nothing is a cost factor.
figure 2: The importance of Time
Are people in projects interested in Time? Many people working in
projects think that the delivery time of the project result is not their
responsibility, but rather the responsibility of project management.
They also seem to think that the system is ready only if "all"
requirements have been met. All people working in a project spend time,
and should spend their time wisely, taking into account the impact of
their decisions on the success of the project. Where "other" engineers
still may be accused of silo-thinking, the very reason of Systems
Engineering is to avoid silo-thinking, taking responsibility for a
multi-dimensional variety of issues: whole lifetime (cradle to cradle),
over all disciplines (including e.g. human behaviour,
see booklet #6),
balancing all systems requirements, including performances, and
optimizing the design decisions over all requirements, including
delivery time.
When I start coaching a project/team, I usually ask:
"What is the cost of one day of (unnecessary) delay? They don't know.
"What is the cost of one day of the project?" They don't know.
"What is your cost per day?" Most people don't even know that (note that
your cost per day is much more than you get per day!).
Now, how can we make design decisions if we don't know these things?
The exact figure isn't even important. Any reasonable figure will do to make better decisions.