“We want these deliverables, in this many hours. Can you give us a time and materials estimate?”
Have you ever heard something like that from your clients? In my time as a project manager, I have been asked several times by different clients to deliver something within a pre-determined amount of hours, before estimating the time and materials it will require. If the deliverables cannot be developed in the amount of time requested, a difficult negotiation must begin: “Why do you need it within that time frame? What if we avoid the tests? Is that analysis really necessary?”
If you work for a system integrator, you know what I'm talking about. In the past, a time and material contract simply meant that billing was determined based on time and materials. Essentially, one company would buy expertise from another company, which would be measured in terms of labor-hours billed at regular intervals. Sometimes, a more flexible type of time and materials contract was agreed on, wherein clients could request changes, which would subsequently be estimated by the contractor. If the client approved of those estimates, the contractor would begin work. Because this was mutually accepted as a rough approximation, moderate deviation from the original forecast was considered acceptable. This model lasted for years, and in some cases replaced more traditional time and materials contracts.
Since then, new models have grown in popularity. With it becoming more common for companies to undertake projects with a high level of uncertainty, the Agile method was created. This method is tailored for situations where clients do not have a clear idea of the final product. Throughout several iterations, the product is shaped in accordance with up-to-date needs and requirements. In a series of short, repeatable phases known as sprints, items are picked from a product backlog that specifies what changes a team needs to complete in order to achieve a specific result, until value can be delivered. Each piece of value is like a Lego brick, and once the process is complete, a full Lego model has been constructed. It may be a castle or a dolphin, and in both cases the initial idea may have been to build a car. Whatever the case, this is fine, because the Agile model exists to discover the real requirements of a project during the process of development.
And what contract model is behind Agile? Time and material. This makes sense because uncertainty is high, and fixed pricing is not an option.
But what happens if an Agile approach is too cool not to be adopted? What happens if the Agile culture becomes a trend?
The answer was stated at the beginning of this article: ““We want these deliverables, in this many hours.” It's a sort of sad marriage between a fixed price and time and materials model, a hybrid Frankenstein where the product shape is clear from the beginning, but people want to talk about sprints instead of milestones, story items instead of requirements, and product backlogs instead of work breakdown structures. As a result, the focus is no longer on the expertise delivered, but on the deliverable itself—the value.
But is this a bad thing? Yes, and no. In my opinion, speaking about value is never wrong, but if we try to mix different approaches so that we can squeeze the supplier and get one deliverable at a time at a cheaper price instead of having a full-turn key project delivered all at once, I suggest adding a risk register, because something will be lost in the process.
Endless Martinenghi is a Project Manager at Autoware, certified members of the Control System Integrators Association (CSIA). For more information about Autoware, visit its profile on the Industrial Automation Exchange.
