Monday, June 30, 2008

The Naked Truth About Construction Technology: A Conversation with Renowned Construction IT Consultant Larry True.

Fred Ode, CEO & Chairman of Foundation Software Inc., shares the following interview he held recently with Laurence C. (Larry) True, Managing Director of DR Construction Consultants LLC. With a background that spans more than 40 years in construction, True explains how he came to become one of the industry's leading experts on software selection, implementation and process management. He describes the slow but steady evolution of technology adaptation among contractors, as well as the kind of advice he gives companies that are looking to increase efficiency and streamline their operations.

FRED: Can you tell me Larry, what led you into the field of construction?

LARRY: Well, first of all, I got into construction kind of by accident. I had gone to The University of Nebraska for a year and a half and had no idea what I wanted to do. I moved to Colorado at age 20, got a job with a survey crew for the Bureau of Reclamation. I ended up on project that was constructing a dam and got hired by one of the contractors as a foreman when I was 23 years old. I was pretty green then.

FRED: You mentioned you went back to school part time. What is your education?

LARRY: I have a Bachelor's of Science in Civil Engineering. I did it going to school part-time. I was actually almost 30 by the time I finished. This contractor I was working for had moved me around for a few years so I could learn the basics, out in the field. Then they brought me into the office and started me as cost engineer and I became an estimator and scheduler. So while I was in the office, I took advantage of the opportunity and went back to school. I received an Associates Degree in math and science and then applied to University of Colorado.

FRED: So you had the best of both worlds. You had the practical experience – what every college grad tells you they don’t get in school – while studying the principles of construction. I would think the combination of the two was extremely helpful.

LARRY: I like to say that my career did more to help my education than the other way around. By the time I went back to school I really knew what I wanted to do. The practical knowledge that I had from working in the field, and from estimating and surveying, so much of my experience was directly applicable to civil engineering courses. It really made school have meaning for me.

FRED: What made you leave working within a construction company and move into the technology area?

LARRY: Well, construction technology consulting is kind of my 3rd career move. While I was working for this contractor, the company changed ownership several times and, after a while, I decided it was time to move on. A friend of mine had gone to work for a consulting firm doing construction claims work. It was a new company, and I felt it offered a good opportunity for growth. It turned out to be really interesting and challenging work.

FRED: What did you find most interesting about it?

LARRY: I think finding out that most contractors had horrible computer systems in those days. I became interested in learning about contractors' accounting systems and why they were so terrible. I had come from a construction company that had pretty good cost control systems in place and knew everything about all their jobs, their equipment costs and so on.

FRED: How did they do that? You must be talking about the mid 1960s through the 1970s, correct? Were they computerized?

LARRY: To an extent it was computerized. One of my first jobs was to take the ledgers off the job cost posting machine and transfer them to paper so I could get a concise report to field superintendents about how their jobs were doing. That was part of my work as a cost engineer. And then when they sold to another company that had a big IBM mainframe out in California, they began using something called the Monitor system. Later, our division was sold to another company headquartered in Des Moines, Iowa, and they went about writing their own system, also on a mainframe. It was sort of a copy of the Monitor system with their own little tweaks.

FRED: Sounds like your company had all the processes in place to be able to leverage whatever technology was available.

LARRY: Yes. For example, we had central purchasing, and an equipment management shop that knew what their equipment costs were. We knew what revenue had to be charged to the jobs to cover the equipment owning and operating costs. We had a budget for each piece of equipment. We knew how many hours a year it should run and how many hours it should bring back in revenue. Basically, all the things we preach to contractors today that they should do, but many of them don’t.

FRED: This consulting firm you joined in 1975. What happened there?

LARRY: They were working all over U.S. helping contractors prepare claims against owners for extras on job that they weren't being paid for, etc. And as I got into that, I realized that contractors had very poor accounting systems. Many of them were doing job cost with their general ledger. They would sometimes use a manufacturing software package or a general ledger system and were doing job costing but not much more. They were so poor compared with what I was used to. So I started saying, well if you're not going to build your own, is there anything out on there you can buy. So I started looking and found a few I liked.

FRED: So that's how you started researching accounting systems for construction?

LARRY: Well, around 1979 or 1980, I met a guy named Paul Levin, who had started a computer application newsletter called CCAN. I met him through another guy who was doing software research like me, only for engineering companies. Paul said, "Why don’t you come and write about it. I’ll identify systems out there and you can review them and write reviews about them for my newsletter." So that led me to start cataloging all this information, and first thing I knew people started becoming interested in learning what I knew about computer systems. That led into consulting and got me away from construction claims and into doing more IT related work.

FRED: Have you been pretty involved in the technology area since 1975?

LARRY: Yes, I still do a little bit of construction claims work and I do some other kinds of construction related consulting work. But probably 80% of my time is in technology and the business processes that surround it.

FRED: So in your opinion, how have you seen the software industry change over the past 20 years?

LARRY: I guess it's been more of an evolution than any revolution certainly. There are a lot more standardized software applications out there and a lot less custom work is being done. In other words, vendors have moved more toward software that is flexible and offers some leverage with set up options, and relates more to what the contractors will get out of it. There is definitely a lot less custom work going into setting up the systems.

FRED: So standardization is what you have seen in products, or customizable?

LARRY: Tailorable I would say rather than customized. In fact, you used to see almost every installation had some custom work. Nowadays I would say its probably one out of 50 that involves some custom. Typically, on the high end, maybe you will you see the possibility of some custom work. But very few mid-range products, and certainly none of the lower-end products, do you see any custom work.

FRED: How do you recognize software companies that are here to stay? Obviously over the past several years, some companies have struggled, some have gone out of business, some are just milking their maintenance revenues. Any way to recognize the successful ones?

LARRY: There are a few things that I look for. One, do they have ongoing stream of new business? That tends to indicated companies that are going to be around. They should have a pattern of growth and a pattern of new business. Why? Because you can't live on old business forever. Secondly, do they have a structure that is sustainable, both in company and in a product? If the product is not sustainable, i.e. it's an antiquated data structure and they can't adapt to the tools that everyone wants today, the price of getting there, as you well know, Fred, is horrendous. And the companies that did not start that 10 years ago are so far behind the eight ball now, they are probably never going to catch up. That would be a red flag for me. Finally, as far as the company structure is concerned, they have to have an active sales force and a good support staff and be able to give out good references, or nobody will want to do business with them. Altogether, those are the things I look at when evaluating a company.

FRED: Can I assume strong financials would be part of that too?

LARRY: Yes, I think it kind of goes along with all the others, although many software companies don’t have a lot of net worth other than their software. If they are consistently producing a profit and they've got sufficient cash flow coming from new sales and ongoing revenue to follow the growth and keep up the development work then they are doing fine. But they may never return a huge return to their investors as say a construction company. Software companies, as you know, are a lot like consulting firms in that your chief expense is the people. That's why ongoing new sales and ongoing development are so critical in looking at benchmarks of success.

FRED: And that is exactly why we continue to spend a tremendous amount on future development. Our cash flow is also extremely high.

LARRY: That's commendable. Taking a look at your return on revenues, I would say you are definitely in a minority.

FRED: Unfortunately, most contractors wouldn't think to ask these types of questions from software vendors. I assume this is where you would come into play as a consultant?

LARRY: One of the things people always ask me is: "What system do you recommend?" And I say, well, "I recommend the best system for you." The way I approach it is, I make the client make the decision but I make sure they don't make a bad decision. In other words, I lead him down a path to a decision so that they look at the right things and ask the right questions and focuses on the things that really matter to the bottom line. But in the end, the decision has to be the contractor's, not mine. The reason for that is if they make the decision, they have bought into it. If I make the decision, they can always throw it aside if things aren't working well and say, "Oh well the consultant told us this is the one to buy and it’s no good." I’m very careful about that and the only time I've ever been bitten by a systems selection is when the customers didn't buy into it themselves.

FRED: What kind of contracting companies does your consulting firm serve? What's your typical customer profile?

LARRY: It's all over the map, Fred. I’ve worked with GCs, heavy highway, mechanical, electrical, drywall, general building, big industrial contractors, steel erectors… you name it. Right now we seem to have a pretty big following in heavy highway, but I really don't know why that is. Seems like they are all upgrading their systems.

FRED: What size company?

LARRY: Typically the low end is around $20 million and the high end is up to $100-200 million range.

FRED: Your assignments generally have to do with technology, but not with business consulting, processes or people?

LARRY: A lot of time we do get into the process area when we get into system implementation work. Obviously we are trying to refine their processes to help them leverage the software they bought. And that's actually the more challenging part of it. And its one of the reasons I got into this area. You can take someone into system selection but if they don't implement it correctly, then they might as well have saved their money. I really like doing implementation work because we have a little better chance of getting the outcome we want from the selection process. Many times I see contractors go through the whole system selection process and then their users get involved who want to warp it all back to the way they have always done things. And that doesn't always work. In fact it very rarely works. So most of the implementation work we do is more about process, than it is about which button to push.

FRED: So how do you assess a client's need for technology? Do you do a needs-analysis? How do you go about helping them choose their technology?

LARRY: We take clients through the selection process using sort of a rating system. It's basically a check list that has evolved over the years and deals with all of the common differentiators among software: the things that make one software package different from another system. Having refined the check list over time, we look for specific things. For example, we have a contractor who is doing work in California where they have pre-lien requirements. So those are the kind of things you look for. Do they have a unique need that’s not going to be met in a variety of systems? Or do they have some special need which is going to focus them toward one set of software applications rather than another? We help them articulate that and put together a kind of a narrative about their company to take to the vendor. The checklist serves as kind of a reminder: Here are all the things the contractor says are really important to them. And then we have the vendors respond.

FRED: Who do you have involved in this selection process? Who is answering these questions?

LARRY: It's the users.

FRED: So that sort of ties of goes back to implementation. You're getting them involved pre-implementation.

LARRY: Exactly. You get them involved in the decision to buy the system in the first place. And then you get them involved in the implementation to have them rethink the processes that they are using. It often comes down to, "You said that you wanted this feature, now in order to get this feature, we need to work on this process over here in order to get it to do it that way."

FRED: Do you ever question why a contractor might do you do it this way, or why they might need that report?

LARRY: Absolutely. They may ask for some 'blue sky' things that you know they are never going to find in a system so then you ask, "Why do you need that?" Because usually we can come back with, "What if we did it this way?" You reframe their thinking so that they can actually achieve those results.

FRED: Can you give me an example of a 'blue sky' request a contractor might make?

LARRY: The VP of Operations says he wants to come into the office and push a button and find out how his jobs are doing. Well, I'll ask, "What does that mean to you? What pieces of information do you need that will tell you that?" Try to train their thinking into the way I know systems work in general, and then figure out a way to get this guy back down to earth so he makes a selection and finds something that will actually work for them.

FRED: So once you have an idea of which products might be appropriate you send the information out to vendors asking for quotes?

LARRY: We like to send the company narrative out to vendors so they know what they are getting into, and whether or not they want to quote. I also tell them how many users there are going to be and give them a classification of users, or generally what the experience level is like at this company. That way, the vendor can do some preliminary budgeting for the implementation process. Then the proposals come in so that the contractor has an idea of what he’s going to be paying to get what he thinks he wants.

FRED: As a software developer, I appreciate the fact that you classify experience levels. Many contractors don't consider whether their people are willing or able to learn new software. And that can mean the difference between success and failure.

LARRY: Exactly. We emphasize to our clients that they keep in mind the ability of their people to adapt to new systems. Because regardless of what some of them think they want, or what upper management thinks they want, they often don't have the skills sets in house to get there. In other words, they might be able to buy a well-structured system that operates in a certain way and if it's set up to operate to a point where their people would be able to use it. But their people won't ever be able to get them to the point where they could use it if it is too complex for them to develop a basic understanding.

FRED: So, what do you do when it comes to the tough choices? For example, Joe doesn't have the skills, and he is really hurting the company. Do you ever get involved in that side when there is obvious user resistance or incompetence?

LARRY: Well, you have to handle it very carefully, obviously. There could be some reason why that person is still there despite the fact that the person may appear incompetent. Usually there is a discussion with the powers that be. We might say, "You know, I think we are having some challenges here with this person and we either need to bolster them with more training or reassign their duties." Perhaps with more training, or putting them in a position that is a little more structured, the person can more handle the tasks competently. Or if we can move them to a new role that is little more structured that they can be trained to handle, then they can be successful and we reduce the risk of their failing or causing problems elsewhere.

FRED: I'm assuming that's one of the biggest challenges in your job: the people issues.

LARRY: Technology has gotten so good, that with the right people, anything is possible. A lot of

times, you get down to the last two or three systems in a selection and you know that any one of them could do the job. And that's why implementation is so important. Because if you could take any two or three and make it work, then you have to be influential in the process of making it work.

FRED: So if technology has gotten so good, why aren't more contractors using it, or using it effectively?

LARRY: Even though the software today looks easier to use than it did twenty years ago, it's actually a lot harder to learn because it can do so much more. And the biggest problem I find is that the software, in most companies, is much more integrated than the people. So as they go from a bunch of stand alone, unconnected systems, to a fully integrated system, the people have to work together a lot more than they used to. And that's a big challenge for organizations. It's a whole sea change in the way they do things.

FRED: Yes, I call that, in this order. People, then processes, then technology. In other words, you have to have the right people in the right places, and the processes in place, and then the technology can work for them.

LARRY: Exactly. Take a company that has been hand writing their purchase orders, for example. Well it didn't matter if they didn’t put their cost codes on them because they were going to do that when the invoice comes in. And it didn't matter if the quantities or the dollars were not right, because they were going to do that when the invoice comes in. But now when the invoice comes in it has to tie-out to the purchase order and if it doesn’t and the coding isn't on there then they can't even process the invoice. So the process involves everybody, from front to back, and its a whole different way of approaching their business than the way they used to do it.

FRED: So Mary Jo who handles purchase orders might say, "Oh this is so much more work." And in a sense, for her, it is.

LARRY: That's precisely it. One of the biggest challenges you have is convincing people that they have to change job assignments of certain individuals. For example, this person may be an AP clerk, but they are no longer going to be approving purchase orders. They are going to be handling the payable end of the purchase cycle where somebody that used to be writing POs (and then handed them off to someone else to worry about), now has to worry about all the cost coding. So now when they create a purchase order, they have to know which job it is for, what the cost code is, what the purchase price is and a whole bunch of information. Although it may be 10 minutes more work at the front end, what they don't realize is that they are saving about an hour of work at the other end of this process. Plus it puts safeguards in place, provides more accurate and timely information, and so on.

FRED: In other words, you need to convince people that changing their job tasks will ultimately benefit the company as a whole.

LARRY: Yes. And that’s the kind of thinking that's really hard to change.

About the Author/Interviewee
Fred Ode is CEO and Chairman of Foundation Software, Inc. of Brunswick, OH. As the founder of the company in 1985, he has spent 23 years developing job cost accounting systems for construction. He has managed the growth and development of the company and was integral in the design of Foundation's flagship product, FOUNDATION for Windows, which is today used by more than 2000 labor and equipment-intensive contractors throughout the U.S.

Larry True is Managing Director of DR Construction Consultants LLC, of Albany, NY. Since 1975, Larry has been involved in providing construction services to contractors throughout the United States and in all disciplines. With an area of expertise in system selection, implementation management and process management, Larry has hands-on software experience with more than a dozen integrated construction accounting, estimating and project management systems. He is an active member in many professional associations, has had numerous articles published in construction industry publications, and has been a frequent speaker for contractor organizations.


Post a Comment

Links to this post:

Create a Link


Email Me

Enter your email address to subscribe to an email version of this feed:

Delivered by FeedBurner