Last month I wrote about how an unconventional, agile approach can be crucial to the success of a manufacturing execution system (MES) or manufacturing operations management (MOM) project. I did not expect all of the interest that has been expressed on the subject. Many people commented on LinkedIn, where the blog was reposted, requesting explanations and insights, in particular: "How it is possible to estimate a project with this approach?" and "How can one manage the changes of scope that may occur during the various sprints?"
In this month's coumn I will address the first of these questions; next month I'll tackle the other question. Obviously, I do not presume to know all of the answers, but I offer food for thought and discussion from my experience with Autoware.
Estimating a software project is always a complex task. Much theory has been developed in an attempt to bring the estimating activity to a quantitative algorithmic approach. However, since the software development process is fundamentally creative, no approach has, in my opinion, actually been shown to produce an estimate sufficiently correct to be more effective than experience. This is especially true in the case of development projects, where the variation occurring among projects can be extremely high.
Choosing to manage a project with the agile methodology adds a further element of complexity because the high flexibility offered by the agile methodology corresponds to an uncertainty of the final result to be obtained. How can I then make an estimate of the resources required to achieve something that is not well defined and specified?
When we need to define the commitment necessary to develop a new project, we address the problem by following these steps:
- Define with the client the approximate boundaries of its desires and map the macro requests to as many macro areas of our experience as possible. This helps us to identify, at least crudely, the problems and to understand from which set of experience draw information to try to bring the requests back to something already known.
- Develop a macro architecture of the technological solution to be used as a reference, taking into account the project complexity. This architecture provides a defined common element to refer to in any later interaction with the client.
- Identify how much of the requirements set is comparable to standard features or to components already developed for other projects and how much is different or outside the sphere of experience available in the company.
This activity takes into account the documentation provided by the client’s user requirement specifications, if available. Above all, this process works through a direct interaction with the client, helping us to better understand the client's aims and expectations beyond what can be described in any document. Also crucial is the understanding of the medium- and long-term vision of the client so that is possible to immediately approach the project from the direction that will be needed to reach the ultimate goal—at least as it can be defined at the time of this analysis.
Relating the macro requirements to the macro functionality allows you to fragment the problem into smaller problems, or modules, through which you can better leverage the experience gained both in the estimate and in the realization. This significantly reduces the risk of the process of defining the necessary resources and allows you to define more clearly the risk coefficients of each module to be used to correct the estimate.
After defining the modules, the experiences from which to draw, and the risk factors, you get two things:
- The definition of a budgetary value of the project that has the sole purpose of allowing the client to determine whether it is consistent or not with their expectations, estimates or budget.
- An accurate estimate of the value of the commitment necessary to explore the themes exposed, refining the analysis so as to bring each document, possibly produced unilaterally by the client, into a document worked out and shared by the client-integrator team.
If the client decides to proceed with the project, a phase of in-depth analysis of the project scope starts, leading to the drafting of a document of general specifications or to the revision and sharing of what was worked out by the client.
This step is crucial to creating a common base that can provide support and security to all the actors involved. This document of general specifications aligns the expectations of the team, clarifies the purpose, and defines the contours of the official project as far as possible at this stage. This document is intended to be edited and revised during the course of the project, but is used in each case as guidelines to direct future activities.
Only after this activity is complete is it possible to rework the budgetary estimate and provide an estimate of effort involved. The value obtained will be subject to only one category of changes—the variants of scope discussed and agreed to during the project—which will be discussed in detail next month.
Luigi De Bernardini is chief executive officer at Autoware, a Certified Control System Integrators Association member based in Vicenza, Italy. For more information about Autoware, visit the Autoware website or see the company’s profile on the Industrial Automation Exchange.
