The Mythical WoMan-Month in Automation Projects
Published on : Friday 07-05-2021
PV Sivaram dwells upon the Mythical (Wo)Man-month in automation projects or why it always takes longer than estimated.
A project is budgeted with estimation of cost and benefits. Presentation is made, and the budget gets sanctioned. Vendors are invited for the different packages of supply and work. They all prepare estimates for their portion, and submit bids. Evaluation is done, and contracts awarded. After sometime, appeals are made by vendors for revision of cost and time. Eventually, when the project becomes functional, the actual consumed amount of time and money is even higher than the revised estimate!
Sounds familiar? Why does this come about?
How are estimates of effort made? There are a few philosophies and practices. First is that the boss knows best, so (s)he makes the estimate in isolation which may somehow become binding on the team. Another way is to co-opt the most experienced veteran to provide an estimate. A democratic approach has been to collect a range of estimates from various senior people, then use a formula – (highest estimate + lowest estimate + 4x(median estimate)) the whole divided by six. Does any one of these methods work better than others?
Why work estimates are not always accurate
Estimation of the amount of effort involved in a project is often quoted in man-months. This is a convenient metric; it suits both the project owner and the vendor who makes the quotation. The service company usually collects estimates from their engineers and converts these estimates, by adding some safety factor, into a quotation. All is well, if the work is performed within the quoted period. In case of an overshoot, all parties become unhappy. The vendor, because he is delivering extra hours. The commissioning engineer, because he spends extra hours, and gets a bad remark. The project owner, because his project startup is getting delayed. Is this a rare phenomenon? Unfortunately, No! I have experienced and observed many times timelines getting extended. The reasons are not always obvious, and can even not be identified. There are many accusations and counter-accusations flying around.
The amount of result which can be achieved by one man-month of effort is always less than the estimate. This is the mythical (Wo)Man-month.
More work for same output
What are some commonplace causes for delay in projects? Since they are commonplace and therefore in the experience of most people, we need not dwell on such topics here.
Many delays have origins in scope and specification of work itself. Either scope or specs could be incompletely laid out at start, or could be incomplete and erroneous. It can also frequently happen that the actual site conditions and data at site are at variance to that assumed at time of design and development. So, all of this results in rework.
It is not that the work takes longer, but rather the amount of work done has increased, but without an increase in output.
Another aspect is introduced by the testing, validation and acceptance team. Site Acceptance Team might read the specs differently, compared to the design team. Since the Site Acceptance Team is usually close to, or composed of end users, their interpretation carries weight. So, what does this result in? It results in a hasty development at site. Note the stress on ‘hasty’ and the unfavourable location ‘at site’. We will come back to this below.
Automation projects are largely programming projects
Automation per se has become more software-centric. As such therefore the amount of programming effort is a large part of the scope of work. Programming work has a different nature from point of view of supervision. It is unlike work involved in civil construction or instrumentation wiring and cabling. Progress of work does not lend itself to estimation by the eye. But such are not the crucial topic. The state of completion of software is very difficult to estimate. It is not the number of lines of code that have been composed. It is the correctness of the code. Even code generated which is 90% complete and correct does not give a confident indication about the amount of work yet to be done. At times, to bring in the remaining 10%, it was required to scrap the 90% already done. Because, by continuing on the same track, it would not be possible to obtain the remaining 10% of correctness. Therefore, we had to go back to the drawing board, and recast the solution scheme, and start programming afresh.
So, the trajectory of the project towards completion was not uniformly progressive, but involved some degree of backtracking, once in a while.
The final testing for accuracy, etc., could only be done at a late stage of the project, only at the actual site. This once again brings us to a hasty development at site.
What is our problem with hasty development at site? Hasty development is error-prone, and once again increases the need for rework. The project site is not the ideal place for development work, which is more efficiently done at the laboratory. In addition, there is the factor of expense.
Remedy lies in using technology from IT
The problem of time lost due to rework and redesign is real and present. It is going to be with us for some time to come. It is not specific to any one project or team. So what could be a remedy? What did we do?
We invested in developing general purpose function blocks and macros, so that frequently used code was not getting written and tested repeatedly. This eliminated the need for testing each time, it generated good quality code independent of project and team.
Unit testing is a good philosophy – the project is divided into smaller pieces, and each unit is tested before incorporating in the main body. This gives quick debugging and more confidence in the product.
For some projects, we used the ‘agile’ methods rather than earlier ‘cascade’ methods. Trying out a solution scheme to check the feasibility gives confidence that we are on the right path.
Our programming platform came up with many system aids to error proof the code, and we did use all the mechanisms. Some of these aids go by the name of expert systems. There was a price to be paid in terms of code with somewhat reduced efficiency, but it was well worth it.
In most cases the performance issue was not noticed by the client, but the on-time delivery was noticed!
Enter IR4.0 and AI
So much about the past. With technology, learning from experience can also mean discarding old methods. In the era of Industrial Revolution 4.0, a new assistant has come up in shape of AI which is Artificial Intelligence. New design platforms and programming systems come together with a helpful AI bot. This bot is pervasive and ‘always on’. She keeps watching over each development step, and raises a flag when there are any errors. Not just flagging inconsistency, but also offering better alternatives.
In the new, fiercely technological workplace, youngsters are often more knowledgeable than the senior colleagues. The advisory and mentoring role played by seniors in the organisation can be supplemented by AI. This technology is still learning. We will be doing ourselves a favour by putting it to use very early.
More it is used, more perfect will the bot become, and for us it means accurate error free software well in time!
PV Sivaram was the Managing Director of B&R Industrial Automation and had founded and built the organisation in India since 1996. He is also the Past President of Automation India Association (AIA), and a Mentor at C4i4, Pune which is a part of Samarth Udyog Initiative by Department of Heavy Industries. Sivaram began his career in Bhabha Atomic Research Centre (BARC) where he has worked on Reactor Controls. He later shifted to the electrical engineering major Siemens before joining B&R Industrial Automation.
Subsequently he founded the Indian Subsidiary of B&R Industrial Automation – now part of ABB. He grew the company over twenty years making it one of prominent Machine and Factory Automation companies in India. Sivaram has worked in various fields like Power Transmission and Distribution, Communications, and Power Plant Automation.
At B&R he has led projects on Machine and Factory Automation in all verticals like Plastic, Pharma, Textiles, etc. He has considerable experience in Distributed Systems, SCADA, DCS, and microcontroller applications. He has worked on software for redundancy systems and managed large projects both in the public sector and private fields. He has nearly forty five years of work experience. After retirement from B&R he is actively engaged with C4i4 primarily as a Mentor and as an evangelist for Digitalisation.
Sivaram strongly believes that digitisation and adoption of the technology and practices of Industry 4.0 are essential for MSMEs of India. He works to bring these concepts clearer to the people for whom it is more important.
