figure 1: Doing nothing may be very costly

The importance of Time

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.

A product manager at a telecom company told me that 2 people had been analyzing a project to take 4 people 10 months to complete (figure 2). They said, however, that the development time could be shortened by 4 months if they would invest in a system costing €200k, but that the business was not prepared to invest this amount of money.

figure 2: The importance of Time

The analysts said: "Give us two more weeks to investigate further to explain better why we should invest this €200k." The product manager complained that the project should start, and that no more time should be wasted on additional analysis.
I asked him: "How much do these people cost per hour?" Like most people in and around projects, he didn't know. So I suggested: "How about €500 per day?" He nodded. "That means they spent some €20k (2 people, 20 days, €500) and they want to spend some €10k more to investigate more?" He said: "Yes, but I don't want them to waste more time!" Then I asked: "What will be the benefit once the project is finished?" The answer was: "The expected benefit will be €16M per year!" (Telecom must be like gold, but of course these companies don't tell us). "Aha! So the extra 2 weeks don't cost €10k but rather some half million euro, and the investment to save 4 months doesn't cost €200k, but would rather secure some €5M extra benefit!" The product manager ran to the business people: "Invest those €200k and start the project now!"

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.