Making software for the A/E/C

Economic ups and downs, critical path scheduling and the essentialness of XML

Software Article August 31, 2001
Printer-friendly version





Primavera Systems Inc


Primavera Systems Inc. brought its massive exhibit booth to Chicago in June for the A/E/C Systems 2001 show at McCormick Place.


The number of exhibitors was down 10% from last year, and attendance was down more, but the weather was beautiful, and anyone who peaked outside toward the east was rewarded with the sight of the glimmering, blue waters of Lake Michigan.


Inside, visitors to the exhibit floor were rounding the bases (i.e., getting their tickets punched at Construction.com, Plan Express, e-Builder and Ironmax) trying to win the Sammy Sosa autographed baseball bat being given away by Construction.com.


After the show, Primavera’s CEO, Joel Koppelman, sat down for a telephone interview with ROADS & BRIDGES from his headquarters office in Bala Cynwyd, Pa., to give Primavera’s perspective on software for project management in the roadbuilding segment of the architecture/engineering/construction industry. What follows is a summary of that conversation.


How are current economic conditions affecting the market for project management software?


Project management software is an interesting phenomenon. When business is good, and there’s lots of work going on, the problem is you haven’t got enough people or equipment to do all the jobs at the delivery schedules that you have set out. So you need project management software to figure out what you’re going to do, to prioritize, to choose which projects move forward, which ones get delayed, or whether or not it makes sense to accelerate certain projects by buying additional labor or working additional shifts or whatever the case may be.


When things are bad you have a different problem, which is that you want to make sure that you don’t make any mistakes along the way. You want to make sure you do things right the first time. And you’re watching every penny like a hawk, and therefore you want to make sure that things are synchronized and coordinated and executed as crisply as possible, because you can’t afford to waste any money in that kind of environment.


What that means for us is that business is good. We’d prefer to be in an upbeat, expanding economic environment. That’s much more fun. But the truth is project management software gets sold no matter what happens.


What products do you have that road and bridge construction companies can use?


The basis of everything we do is critical path scheduling. Critical path scheduling is a way to do planning, figure out what work has to be done, the sequence of the work, who’s required to do it, what resources and materials and equipment are required to do it. It’s a sequential process: When this task is done then I can do the next three tasks. That’s what determines the longest time to get the job done.


If you’re doing a bridge that’s fine.


If you’re doing a road it’s a little different because you’re sort of rolling the road out, if you like, sequentially. You start at one end and go to the other end. What you really want to do there is figure out what number of crews you need and how much equipment you need in order to make that process flow smoothly. And it’s done a little differently. It’s not done on a critical path basis; it’s done much more like a production schedule. There’s a technique called linear scheduling. I don’t think there’s actually anybody who offers that commercially today, but it’s an interesting way to think about what your constraints are in roadbuilding. And it can be done as a subset, or a specialty, within critical path scheduling.


Our fundamental product is Primavera Project Planner [P3]. There’s another one called Primavera Enterprise and another one called SureTrak. These are the basic scheduling products.


The other thing that we offer is what we call Expedition. Expedition is about managing the contract and managing the change process and handling a lot of the documents, contracts, purchase orders, changes, RFIs, design reviews, things like that during the process. It’s a much more administrative and contract management-oriented kind of solution.


Recently, we created something in a third category of services, which is PrimeContract. The point of PrimeContract was to create, in a hosted environment, a place where companies can collaborate during the course of a project. This way they can exchange things like design drawings, exchange correspondence, negotiate specifications, handle bids and awards of contracts of the various suppliers.


And now there’s a new function, which we call master scheduling, which enables you to do overall scheduling for all the players who are involved in the project. They can input. They can update. They can create a master schedule and live within that.


Is such project management technology used by many contractors, or is it used more by designers and engineers? How far along is the roadbuilding industry in adopting such sophisticated project management software?


It’s really more a matter of size of firm than it is whether they are design firms or construction firms. What you’ll find is that large firms almost always use our software, and small firms tend not to use our software. If they do use it, they tend to use SureTrak. So for a contractor who’s doing $5-10 million a year, the odds are they’re not using our stuff. If you’ve got somebody who’s doing $25 million a year or up, they’re using our stuff. Somewhere in there is the tipping point where it’s clear that you ought to be running your business with these kinds of tools at your disposal.


I’ve heard some talk about established business people resisting adoption of new technology. They say, ‘This is how I’ve done it for 40 years; why do I need some newfangled gadget to help me do it?’ Have you seen such resistance?


Resistance to technology seems to be more age-related than size-related. If you’re dealing with a bunch of crusty old construction types, and they’re now in their late 50s or 60s, they think, ‘I’ve been doing it this way for so many years, I don’t want to change that.’ You can’t teach an old dog new tricks.


You see the younger people in the business, in their 30s or 40s or even 50s. They’re quite happy to take on new technology.


Would you say that the first component of a project management system to get implemented is often payment, because companies want to get paid faster?


Yes. Let’s say you’re a contractor. The ideal case is that you don’t have to borrow a dime to do the job. You are able to work on the owner’s money. So you try to set things up in such a way that you very quickly can start billing for work that’s been done, and that way you’re able to pay your people, rent the equipment and buy the materials.


If the owner says to you, ‘If you want to file your request for payment electronically and let’s negotiate this online, I can reduce that payment time [from 65 to 85 days] to 10 days or less,’ that’s a pretty compelling business proposition.


From the other side, if you’re the owner, the reason you want to do this is you want to know what the cost is at the earliest possible time, because you have liabilities. Second, you want to get out of this negotiating posture as quickly as possible, because it’s just not a pleasant place to be. It’s not getting the job done faster. And, in fact, if you stretch the contractors too thin you run the risk that they’ll go broke and default on payments.


The final thing is that if you can offer to pay somebody quickly, then you’re in a position to get the attention of good firms. As a result, you may get better quality. You may get better safety on the job.


What’s typically implemented next?


I think the next piece that somebody might go to would be Expedition. The reason for that is that once you’ve thought about progress payments, now you want to think about tracking the contracts, the purchases and the commitments that you’ve made, as well as all the changes to those purchases and commitments and budgets as you go forward. You really want to get a handle on the cost side of this thing.


I think probably the third piece for these people would be the collaborative elements, which is to be able to share drawings and requests for information and design reviews and do those electronically rather than doing those on paper, because it’s much faster. You get an answer right now.


Can you talk a little about how your project management software is scalable, so that a contractor—even a small contractor—can use what they think they need and not have to learn the whole package?


The nice thing about the software is that you can come in and do simple things and choose the pieces of it that you think provide the highest value. Then, if and when you choose to use more, it’s there and fully connected and integrated and available for you. You can grow into it.


One of the hurdles mentioned in the Primavera workshop at A/E/C Systems 2001 (Spring) was lack of standardization in communicating between software packages. How easily can you transfer information from your software to software from another company?


We send things through e-mail. So, I don’t care if you have Outlook or Notes or Yahoo or AOL as your e-mail facility, we can send messages to anybody on any e-mail system.


What we don’t do is, if you use Expedition and somebody else uses a different system for, let’s say, tracking RFIs, there’s no easy way at the moment to move an RFI from our system to Buzzsaw or vice versa. However, that’s changing, and the technology is sort of emerging as we speak using XML [extensible markup language] as an intermediary to exchange data between these independent systems. We actually do it with our own software, so in fact we exchange information between PrimeContract and Expedition using XML standards.


I think XML is really essential to the industry. It’s called aecXML. There’s a special variety of it, if you will, for the A/E/C business. The reason it’s essential is that you want to be able to allow software developers to make good software and use information in the way that makes the most sense within the context of those packages, but then permit those independent systems to exchange information without having to compromise how they behave internally. That’s what XML does.


XML simply puts that information in human-readable form in the hands of whoever the recipient is. And if their system is capable, like ours, then it can accept that data and use it. The good news is that it’s actually out in the marketplace.


About the author: 
Overlay Init