[Guest Blogger] 40 Years in the Field (Part 9)

Graham Jones (Surrey, British Columbia, IT Pro)

Having chipped away a little of the “outer shell” of getting the first real opportunity to use PDMS, it was “put up or shut up time”. One of our regular clients (from Tasmania) wanted us to use PDMS. That was the official line as far as the client was concerned. However, the assigned PM would only do it if it was done in parallel with the manual system. Sigh! Oh, well better than nothing. The problem was that the 2 approaches are not even remotely compatible. In effect we had a 3 cornered fight; (1) the people – as always, (2) the application of new computer technology and (3) the methods/procedures of working – linking the people to the technology. To get the full benefit from “computerization” very often it is necessary to completely revamp the order and nature of working processes and data flow. Making headway is often frustrated by people who may have a vested interest in the status quo and figuring out exactly where you are “starting from”! My objective for this first project was to use it to identify “the starting point” for our “journey” and to demonstrate that the “crude” facilities simply wouldn’t cut it, ie. some “real” money had to be spent.

Like most attempts at trying to determine “where are we starting from?”, you discover that there is no single answer. It depends upon who you ask. The company was very unstructured and few written procedures, practices or guide lines existed; the VP of Engineering believed that they “stifled creativity”. All that philosophy actually did was give people enough scope to waste money. Over procedurization isn’t the answer either since that can be too prescriptive and can stop people “thinking”. You need to find a sensible middle ground. Before I proceed further I should explain that I was working for a Process Technology Company (PTC) that bid fixed price contracts. This is a totally different business from most Engineering Companies (EC) who simply provide engineering services, ie. hours of labour.  PTC’s typically do engineering to sell Process Technology (that’s where the profit is), often the fruits of their own research and development work. Typically EC’s want to maximize hours (more hours = more $’s coming in) whereas  PTC’s doing fixed price contracts want to minimize hours (hours wasted = less $’s made).  The premise behind justifying PDMS from the original study was that it would assist in reducing office hours. Whilst that was ultimately true to some extent the real payoff was somewhere else entirely. The largest labour and material cost is in construction and not in the office. With the manual system construction re-work was expected and to some extent that had bred a “we’ll fix it in the field” attitude. Studies had shown a 5:1 cost advantage by getting it correct in the office!

Building a “model” afforded 2 major advantages over the manual system: (1) improved visualization and (2) interference checking. The biggest reason for field re-work was 2 or more “objects” wanted to occupy the same space, eg. the electrical engineer would route the trays that carried power and instrument cables and the piping designer would route a pipe that interfered with them, or the steelwork, etc.. Designing a process plant is deceptive in that there appears to be lots of “space” but you have many people involved simultaneously and you have to work to fairly close tolerances. I will talk a little about “Concurrent Engineering” later. That first project clearly demonstrated that “if we are serious” then we had better “get serious” and spend some money. That meant the purchase of a Prime mini (9650), the PDMS software and some Tektronix graphics terminals. I put together a proposal and literally sat outside the President’s office for 3 days just prior to Xmas trying to persuade him to sign it. I wore him down in the end. I caught him in a weak moment when he was leaving and excited about going skiing at Whistler! I had been told that would be a good psychological ploy!!

Now the work really began. When you are using a bureau service you tend to take for granted the operational side of things. I was getting my new “toys” but who was going to run it all? I looked around and there was me and my assistant. The rest is obvious. A “crash” (literally) course in PRIMOS ensued. A lot has happened in the OS world since then but I have to say that PRIMOS was one of the best OS’s that I have “played” with. It had an outstanding command language which would be the envy of most today. The command language had most of the features of a high level procedural programming language with easy access to system functions and services. For example, you could send data/commands to and retrieve data from running apps very easily. Since PDMS early on only had a very crude macro language to extend the product functionality (eventually it did have a very good language) the PRIMOS command language proved immensely valuable in adding the efficiency extensions needed to make the product economically viable.

For example, drawings are produced from the model. All of the dimensional data is there. The program had features for annotating drawings (names and dimensions) but why have someone waste time sitting at a terminal doing it. Besides it was boring, time consuming and made the users (the designers) feel that their drawing skills were being devalued. So automatic drawing production had great appeal. However, the annotation part is akin to drawing “with your eyes closed” and requires a very complex algorithm to even come close. So it wasn’t possible to produce perfect drawings right out of the computer. However, eventually it was possible to get 85 – 90 % of the way there only leaving some cleanup work to be done. Great kudos to my assistant. He did a brilliant job and we presented a paper together at one of the annual PDMS conferences (more about those later). Eventually features like this, and many others developed by the user community, found their way into the product.

So far we were making some of the necessary “technology” progress (improved and new software tools) but what about the people and the procedures? We weren’t really going to be able to find out “how to do it” and then educate the users as long as we continued to do things in parallel. I needed my next piece of luck and that came in the form of a PM who had just joined the company. He was not only willing to “bite the bullet” but actually came to me and volunteered. Even though he and I knew that it was going to be a rocky road, it was the only way to prove things one way or another. That first “real” project cost about 40% more in office hours (which caused a bit of a stir) but the field experience was much better. Eventually we would get better in the office ultimately matching, and sometimes beating, the manual process but with a far superior experience in construction. The construction people were used to, and expected, “screw ups”. I visited a number of the NA construction sites to get first hand feedback. The typical reaction was “it actually fits and the 3D drawings are a fantastic visualization aid”.

As the kids say every 30 seconds on a road trip, “are we there yet?”. Not even close after one “real” project because we had to have everybody on the same. But now we had some “practical” procedural info which we could use as a base for writing procedures and training people. That was the next big push and things were refined over the next several projects. If you can’t find that champion to help you “conquer from within” it probably isn’t going to happen. Certainly any amount of “management edict” isn’t going to do it. In part 10 I will touch upon how PDMS evolved as a product, the development of the international PDMS user community and my exploits with the Commodore 64.

Cheers

Graham J.