If you want your digitalization project to fail, do one or more of the following:
- Don’t use a specific methodology (because coding is all that’s really important).
- Life cycle, life cycle, life cycle! There are lots of over-hyped methodologies, like Agile, but there are life cycle development methods that work.
- Using a methodology is not a cult, it is a systematic development framework that allows you to address the spectrum from requirements to acceptance testing.
- We have done instrumented studies of system development and the idea of coding takes up 10% of the overall process. Why do “coding” projects take so long? Because you have to do requirements gathering, design and testing anyway. Without a methodology you do it in an ad hoc and chaotic fashion.
- Create the project plan by working backwards from a drop-dead system completion date.
- How can you set a date when you don’t know what you are going to build? Don’t memorialize the date that your project can be declared a failure.
- Always remember the old software adage, “There is never enough time to do it right, but always enough time to do it over.”
- Don’t bother with a data model.
- “We’re using programmable logic computers, not database machines. Data models are a waste of time.”
- Really? Do you have any sensors? They provide you with large amounts of situational data. How are you going to keep that data and manage it?
- Do you have an alarm system? How are you going to manage the data going from and to it? How do you manage the creation, reading, updating and deletion of alarms? Sounds like a data model to us.
- Use a Technical Lead that has never built a similar system.
- Without a client on your team, the technical lead becomes the “voice of the client”. If they have never built a similar system, how do they know what the system is supposed to do?
- If the Technical Lead has worked on, managed, is familiar with the system from the user’s point of view, that gives them an idea of what the system is intended to do. But, if they do not understand how the system is to be built – the tools, techniques and processes of systems/software engineering – they have no idea what is possible or impossible with the tool set.
- Hire new developers to make the coding go faster.
- A “sister ship” of several others already in production was contracted right out of the yard for a new drilling campaign. Six developers were put on board during the one-month tow to complete customization of the drilling control system. It was a sister ship, just like the others — but, it wasn’t. Months after arriving on site it was still not turning to the right.
- Build the system in Java, even though most of the development team still thinks that Java is coffee and you have no intention of ever deploying to the Web.
- Java and JavaScript are excellent languages for web development, mobile applications and office programs. They are not appropriate for time critical, machine control systems. Picking the wrong development language and environment can be a disaster for a drilling rig.
- Three months before the system goes live, assign one junior developer to handle the data migration.
- Data? This is a machine control application. How about alarm management? Data migration included alarm rationalization, normalization and management. Thousands of alarms are generated — and, hopefully, responded to — per hour on a drilling rig. Putting a junior engineer in charge of data migration is a disaster if they are making decisions in an unknown subject area.
- Skip the testing phase because the project is way behind schedule.
- “We can test in production!” “Our coders don’t make mistakes!” See the examples in the “Why do you care?” section of this blog.
- Change the system to support critical new requirements discovered during final development.
- In your lifecycle, final system development is usually verification, validation and acceptance testing – possibly commissioning. All the code is completed and you are doing minor fixes and regression testing.
- Once new requirements are introduced, the process is to go back to the design phase and work forward with modified designs, code and retesting. Based on the magnitude of the changes, this can add months to the project.
- This is the point in a project where the development team needs to declare victory and deliver the currently defined project. The new requirements need to go into a new, major release that is treated as a new project. Anything else is a disaster.
- Buy a commercial, off-the-shelf package and customize it … a lot.
- An operator needed a sensor system to manage the mechanical integrity of a steel catenary riser. They selected an off the shelf package based on a laboratory management system.
- They hired a contractor to modify the package to calculate mechanical life using a different set of algorithms. On installation, the modified package worked.
- 90 days after the installation the provider of the commercial package made an update to fix a set of data transfer protocols. The update could not be installed because of the extensive changes made by the contractor. The contractor was no longer available to fix the custom code.
- 60 days later the data transfer buffer overflowed shutting down the mechanical life data transfers to the regulatory agency. 60 days after that the regulatory agency shut down the production platform for failing to provide the required data.
What do you care?
Building software that has one or more of the attributes above is going to cause problems like these once it is attempted to place it into production:
Recently the elevators and bails of an older-model top drive reacted erratically to a rapid and erroneous user command. They swung around and injured two of the rig hands resulting in reportable LTIs. One finding of the investigation showed that a vendor had released a software patch to that model to prevent this erratic behavior, but somehow it had not been communicated or installed on that drilling unit. This example shows two things. First, poor initial design and testing of the control software: the software interlock issue should have been discovered during its initial design and testing. Proper requirements gathering in addition to an FMECA would probably have identified the issue. Secondly, it demonstrated poor management of software as an asset on the MODU between the supplying vendor and the operator.
Graphic
Does this look anything like the area where your software is being built? If it is, do you have a list of all the software tools in use? Know what’s running on each computer? We didn’t think so.
What can you do about it?
Read the blog entries on our website – www.athensgroupservices.com, join our LinkedIn Group, and subscribe to our newsletter.