During the execution of a project, team members use several different types of software. We have to deal with internally and externally developed software. We have to deal with customers’ and subcontractors’ software. We have to make sure that the soft- ware is compatible and at the same revision levels. I have come across several issues with software during my project management career. I will cover four such cases in this section.
We had an internally developed magnetic recording head fly- ing height calculator software. All of the design engineers on my team used this software. The developer of the software was a well- known scientist who worked in the company’s research and devel- opment group. He was good at what he developed, but he was not meticulous in document controlling his software’s revisions and updating his software’s user manual. My team’s design engi- neers were using different versions of the software and they were making errors. I had to take this sloppy situation under control. I went to the scientist’s office and politely explained several issues we had with his software. He accepted that his revision release process was not perfect. He told me that he was a sloppy, but good scientist and not a disciplined revision controller. It was going to be hard to change his sloppy behavior at his level. So I offered to release new versions of his software and user manual on docu- ment control myself and to inform all users. I wanted everyone to be on the same page when they used his flying height calculator software. He agreed with my proposal. I took over releasing new versions and user manual updates. All user errors diminished. My design engineers had no issues using our internally developed flying height calculator software.
I was heading a team in an oil platform subsystem design, man- ufacturing, and installation project for the Russian Federation. I used MS Project’s latest revision as my project management software. I presented our project’s schedule and critical tasks to my customer during the customer kickoff meeting. Everything was fine and dandy. My customer’s project manager asked me to send him by e- mail an updated project schedule with percentage completed task estimates every Monday. The problem was that they could not open my MS Project file and review my updated project schedule. My customer’s company used different proj- ect management software, which was not compatible with MS Project. I offered to send him my weekly updates in a PDF format. He accepted my solution. Every week after updating my project’s schedule, I had to convert it to the PDF format and e- mail to my customer that way.
In another project software case, a subcontractor was design- ing and manufacturing some trolleys for a transport system on an oil platform. My design engineers were using the most current release of AutoCad to design the transport system. My trolley subcontractor was using an old version of AutoCad. By the way,
AutoCad had 28 revisions from its first release in 1982 through 2014. The subcontractor sent us his AutoCad drawing files for trolleys so that my design engineer could interface them into the system drawings and verify that there were no issues. Several callouts and dimensions on the trolley drawings were transferred erroneously. My design engineer had to check each and every call- out and dimension for the trolleys and correct several of them so that our system drawings were intact. Backward compatibility of software releases should be checked very thoroughly at all costs. There can be some hidden surprises in different software releases.
In an integrated circuit design case, my team’s design engi- neers used Verilog, a hardware description language software. My engineers were trained at school and at work to use Verilog soft- ware to describe functionalities of the circuit. One of my German customers required us to use VHDL software for the integrated circuit design for them. They put this requirement into their tech- nical specifications. I discussed this design software choice issue with my customer’s project manager. He insisted that internally, his company only used VHDL software. That was the reason they put this requirement into their specifications. So as their subcon- tractor, my designers had to use the VHDL software. He did not budge at all in using the Verilog software. Our sales group missed this critical point when they signed the contract with our cus- tomer. Most experienced ASIC (application specific integrated circuit) designers could use both kinds of software, but my team’s design engineers were fresh out of school and they were only trained in using the Verilog software. I had to scramble and get a training program going for the VHDL software. I had my six design engineers trained in VHDL software in a crash course in two weeks. They designed all parts of the circuit for my German customer in VHDL language. They were slow at the beginning of the project, but they became more efficient as the project pro- gressed. At the end of the project, all my design engineers were very thankful to me for making them learn the VHDL software. They became efficient in both kinds of software, which was good for them and for my company.
The software used in a project has to be scrutinized very care- fully. There can be many unforeseen conflicts and issues between customers, subcontractors, and internal users. Errors generated by using different software and different software releases can sink a project’s schedule and cost performance.
LESSONS LEARNED FROM THIS PROJECT EVENT
• Software used during the execution of your project by your team members, by your customers, and by your subcontractors has to be compatible and has to be at the same revision levels.
• Internally developed software has to be released through your document control and the software’s revision levels have to be the same across your company.
7 7
3
Case studies
in
knowledge ManageMent
Knowledge management is the foundation of your project. Depth of knowledge in your team members to your subcontractors can sail smoothly or sink a project.
My subcontractor was designing and constructing trolleys with a 10-ton load capacity for one of my projects. Contract specifications called for a bronze coating over the trolley wheels for a nonspark operation with very tight tolerances. My subcontractor insisted that a bronze coating with such tight tolerances was not manufacturable. He had to educate me on bronze coating techniques. He had to show me what was doable and what the limits of the bronze coating process were. I was a bridge between my subcontractor and my customer in order to get tight specifications relaxed. Details of this case are pro- vided in Case 3.1.
My project management experience spanned several different technology- based companies. Leading-edge technical knowledge is the basis of an engineering project. I made sure that my engineers were trained and excelled in state of the art technological advances. When we bid for a project contract, we sold our technical knowledge and expertise in that particular field. I had to orchestrate to have an excellent collective technical knowledge internally and through our partners and consultants as depicted in Case 3.2.
As project managers, we have to make sure that all our team play- ers are ready and up to par for presentations in front of the customers, regulatory agencies, inspectors, and upper management. Many factors can spoil a presentation as shown in Case 3.3.
As project managers, we should always encourage our project team members to record their new ideas and findings in engineering books and have them signed and dated by a colleague so that their new ideas and findings can be verified and patented for the company’s
and their benefit. An interesting patent application is described in Case 3.4.
The “not invented here” syndrome can happen at an individual level or at a company level. Some company officers sometimes refuse to change company designs or procedures by better and proven ones available from the outside. This organizational level of not invented here syndrome can degrade a company’s performance and affect your project’s performance as shown in Case 3.5.
As project managers, we have to encourage our team members to attend technical conferences and shows as long as they are within our company’s guidelines. However, we have to establish with our team members as to who is going where at the beginning of the project. It is our responsibility to balance our project’s responsibilities with techni- cal conferences and shows as detailed in Case 3.6.
Methods of interpretation for a callout on a drawing can be quite different even from person to person in a global project as depicted in Case 3.7. Inviting the final user of the design drawings to the design review meeting is a must. As project managers, it is our responsibility to bridge the gap between the designer and the user.
Paying attention to details and checking out all possible conse- quences of a task is the first amendment in the laws of global engi- neering project management. In one of my global projects, I made a mistake in believing a departed project manager and my team’s engi- neers regarding the equivalence of U.S. and European certification standards as detailed in Case 3.8.
Some project managers are closed- minded. They are intolerant and unreceptive to others’ new ideas. Their actions discourage team mem- bers. Team members stop contributing for the good of the project. Even some out- of- line suggestions can have value. As project manag- ers, we should listen to and weigh all options before deciding on a course of action in a task as depicted in Case 3.9.
As a global team, your team members should be knowledgeable of all pertinent project specifications and requirements. They have to trickle down as required to all the people involved in your global proj- ect as depicted in Case 3.10. In a global project, a personalized trickle down project management is not possible. In such cases, you have to rely on your offshore managers.
Intellectual property guidelines have to be sorted out at the begin- ning of a project. Do’s and don’ts have to be advised to all team mem- bers. As project managers, we are totally responsible for honoring the intellectual property rules of a project. My several challenging encounters to protect intellectual property are given in Case 3.11.