Architects Integrating Industry (Ai2SA), specializing in “optimally managing and scoping industrial systems projects” was recently contracted by one of its mechanical partners (an OEM / machine builder) to assist with a project entailing “robotics”. The regular contractor had experienced challenges on another project in terms of over runs so was no longer available to complete works. We initially spoke to our client about same project in October 2017 and was only officially contracted end of January. The initial scope included reviewing design of drawings and panel built by others to determine status and next to write PLC and HMI software. Upon review it became evident that the design and panel construction was closer to 10% complete than 90% we were told and +/- 75% of our time went to clarify all the respective components depicted conceptionally below:
The project hence consisted out of two (2) robots, two (2) servo motors a SIL rated safety relay (given risks associated to process) along with PLC and HMI. All the equipment was mounted in control panel which we eventually took over both design and manufacturing. While within our skill set our partner’s problem (incomplete design and panel) became an opportunity for us to increase scope however detracted from equally important software engineering works so in hind sight we probably should have limited ourselves to a reduced scope.
On a technical level we had to familiarize ourselves with lots of aspects such as EthernetIP, working out Servo drive interface along with how to wire robots and how to communicate to it along with clarifying the actual signals in the field along with safety circuit.
Another challenge was that there was no user requirement specification (URS) from client and with system design taking 75% of our time it was not possible to verify all requirements / permutations pre-site. The issue with no URS from such a large company is worrying but understandable as not every client has a project division on site or even in the group and we were reliant on information from maintenance personal. While this is appreciated unfortunately insufficient time was available to document and discuss all scenarios which lead to interpretational issues on site and hence rework / changes impacting previously tested works. This may have still been OK was it not for overall poor project management. So not to point fingers but a lot of lessons were learnt on site which main ones impacting project the most were:
- Starting with project too late left insufficient time to follow normal methodology which came back to haunt project.
- On end client’s site the old equipment reached end of life some time ago and migration should have been planned sooner ideally. Again, allowing two (2) months for amount of works was also not ideal…
- Given amount of people working on project we were working with a constrained budget which resulted in further not following a working methodology. Present state calculations when writing the article indicate that we have lost close to R250K in terms of opportunity costs (i.e. time we should have spent on other works.)
- As per above not having an URS resulted in lots of misunderstanding and subsequent reworks as software was designed based on limited understanding and then had to cater for many more permutations i.e. in certain steps PLC had to check for faults however robots obstructed sensor triggering false alarms requiring additional interlocks.
- Also, as above while within our abilities we should not have taken on other entities problems as this resulted in impacting our own scope.
- It became evident that all role players had to be on site at all times while spending minimal time on own works given different components i.e. robots guys for robots, we for PLC / HMI, etc. This drove up costs and time was extended.
- At times the robot tried to be the master while ideally the PLC should have been “in charge” as a result of no central management / lead engineering structure.
- Lots of challenges were faced integrating the different equipment and to get timing right along with information passed between different components.
- Finally, a main issue was lack of strong project management specifically to align different parties as we as PLC team was doing one thing while equally competent robot team did another with no central alignment. Later-on we learned customer also expected this from us however was not communicated or quoted for…
So while project overran by a couple of days as a result of scope creep (due to URS) and failure to work against written plan client was fortunate to have made up stock levels before shut and also we have calculated that the loss caused by overrun will be nullified (in theory) by improvement to new robot speed within due course with net effect estimated to be a 0,64% loss in profit over a 15 year term however from a client point of view speeding up robot sequence increases clients profit in excess of R150M so it also begs the question does delaying projects delay future profits also? Note these are theoretical benefits due to the fact that downstream equipment may not cope with increase in output.
In doing postmortem two (2) models (helpful to determine level of complexity of a project) were identified: http://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm and https://harishsnotebook.wordpress.com/2015/09/07/its-complicated/. These are depicted below:
What the 1st model (Stacey) indicate is that the further parties are from agreement (of requirements) vs. certainty (i.e. using of technology to solve challenges) the more complex project may be. This implies one should always be sure about what is required and next to use technology we are certain can do the task required. Also, as per the Cynefin framework depicted on the right above if projects are complex answer may not be clear and a trial and error approach may have to be followed to move problem into complicated domain were experts, make use of good practices. Considering these two (2) models may keep one away from “edge of chaos”.
In terms of positives while it may have taken the OEMs months to design and build the machine in a factory environment it took us around three (3) to four (4) weeks to do the same. Another six (6) weeks however was lost resolving interfaces, etc. Obtaining input information was a key challenge.
Ai2SA: W: www.ai2sa.co.za, T: +27(0) 12-348 6124 / M: +27(0) 82-559 7437, Find us on Facebook, LinkedIn, Twitter and Google+FOLLOW US ON SOCIAL MEDIA