Mark Bostleman
ProjectVillage

The first web-based applications for construction project management appeared in the mid-nineties. Soon after, the dot-com boom created a proliferation of software vendors in the category that, at one point, numbered over twenty. In the last three years, that number has decreased significantly. Today, given the varying design of the applications and their target markets, the viable offerings may only number two or three for any given contractor.

Despite their apparent value, the adoption of web-based project management applications has been slow in the construction industry. The often-heard explanation is that the industry, as a culture, is averse to change and not technically savvy. While this may be true to some extent, an explanation heard less often is that the applications do not return benefits that justify the investment. I feel that this explanation is far more likely than that of the construction industry being technologically backwards. The problem is, web-based project management applications carry a great deal of potential value, but they are deceivingly complex to implement in a manner that provides a compelling return.

In 1998 I built a web-based project management application as an in-house development project for a construction management firm. At the end of 2000, I formed a new company, ProjectVillageT (www.projectcvillage.com), to market that application to other organizations. During the last five years I have been involved in implementing the technology in many different projects and organizations. In the process, I learned a lot (often the hard way) about what makes the technology tick.and what doesn't. Below I have distilled what I've learned into ten myths about web-based project management that are often obstacles to its (financially) successful implementation.

For the sake of this article, I am defining a web-based application as one in which the user interface is delivered exclusively in a web-browser, a utility that is provided as a standard on any modern computer and is not proprietary to the web-based application of any particular vendor. Also, I am only considering applications in which the server software is hosted by a party other than the organization using it (typically referred to as Application Service Providers).

In contrast, I refer to a client-server application as one in which software specifically from the application's vendor must be installed on any computer that is going to use the application. Short of jumping through several technological hoops (and installing more software from other vendors), client-server applications are effectively not available outside of a wide or local area network. As such, the design (primarily the control over user access and workflow) of client-server applications usually only accommodates use by one organization.

It may also be worth noting that I am generally only considering solutions aimed at streamlining the activities of managing a project, in the construction phase, from the point of view of a construction manager, general contractor or, possibly, an owner or subcontractor. For the most part, though there can be overlap, I am not referring to solutions involved in the development of a design.

1. Web-based project management applications.are for collaboration

Collaboration tools typically include things like online meetings, drawing markup, white boarding and threaded comment or discussion forums.

Collaboration is a functionality. Web-based is a platform. For many in our industry, the two terms have become interchangeable but there is really no relationship between them. While collaboration (at least across the boundaries of organizations) is a functionality almost exclusive to the web-based platform, the platform is by no means limited to that functionality. That is, web-based applications, while uniquely capable of delivering collaborative tools, can (and do) provide any functionality that client-server applications do. Contract control and project financial tools, scheduling and document management are just a few of the functionalities of some web-based applications that go well beyond collaboration.

The point here is that to maximize your return, don't feel that you need to narrow your scope to accommodate limitations in the platform. I have yet to see collaboration alone justify the investment.

2. Web-based project management applications . won't be effective unless everyone involved with the project participates

One concern about workflow in web-based applications is that if just one person in the process is not online, the application will not work. If the primary function of the application is collaboration, and its functionality is not tolerant of offline players and processes, then this would be true. However, this is again a matter of function within the application, not a characteristic inherent to the platform. And that's good because at this point in the industry's adoption, everyone being a genuinely active and reliable online participant in a project is not an option.

Fortunately, good web-based project management applications have simple functional solutions to this problem that transparently accommodate offline people or portions of a process. As such, they can be easily justified by internal use only (especially when deployed enterprise-wide) without the participation of other organizations.

Of course, the value increases even further (I believe exponentially) as additional companies participate. But in the meantime, those companies who venture online are receiving significant value and have a distinct competitive advantage without everyone they work with being online with them.

3. Web-based project management applications . require only an Internet connection and a browser

Technically, this is true. The spirit of this statement is that web-based applications are, by several orders of magnitude, simpler and less expensive to deploy and maintain than client-server applications. In fact, the reduction (or elimination) of capital investment and IT maintenance costs is one of the compelling value propositions for this technology. However, rarely are the requirements as simple as only "having a browser and an Internet connection". Be sure to budget for these hidden costs:

• Current software. Upgrades to the latest versions of operating system and browser is often necessary to keep support costs in check.
  
• Current hardware. Mostly driven by the need for current software, the common practice of "sending the older computers out to the field" can be costly in this environment.
  
• Cookies, firewalls, proxy servers, virtual machines, plug-ins and ActiveX controls. All may require tweaking and, one way or another, despite the promises, desktops will often need to be "touched" and maintained by the IT staff.
  
• Bandwidth. Technically everything will work using a modem and phone line, but for a full implementation across many project management processes, there are few activities that are effective with dial-up bandwidth. This may mean more bandwidth for the office and field than you already have.

4. Web-based project management applications . are used to copy and post those things to the web that you want available to other companies or traveling employees

I have been asked a number of times, "This web application looks great, but who is going to put all of the information in it?"

The misconception here is that when you create a submittal log, for instance, you do it in the usual system and then, when you're done, you go back and do it again in the web application so that others can see a record of it. To get the maximum return, however, the web application should completely replace existing processes and systems, thus becoming the primary process, not a secondary process. When this happens, the system naturally "captures" the information in the regular process of doing business rather than adding a task that requires "someone to enter" the information. When building your strategy, keep an eye towards simplifying, reducing and replacing existing processes, not adding to them.

5. Web-based project management applications . are a job-cost and would only be used on larger projects that justify them

Sometimes, this "project specific" strategy is extended even further such that use of a web-application is offered by a GC, CM or architect to the owner as an optional service for an extra fee. Personally, if I were the owner, I would wonder why, if this is a better way of doing business, is it not an inherent part of your organization?

With this technology, the return is significantly enhanced by enterprise-wide use: standardization of processes, information format and location, not to mention high-level roll-up, analysis and aggregation of data from multiple projects. All of this is lost if it is only used on a few projects.

Could you imagine using your phone system only on big projects? Given that you still have the investment in training and support and the learning curve of the participants, it's hard to imagine that you can recoup that investment on one project here and there, even if they are big projects. The more projects in which the technology is utilized, the more the cost is divided and the benefits are multiplied. The bottom line is this: if your fee must be raised to cover extra cost, there is something wrong in the way you are implementing the application.

6. Web-based project management applications . are technology, therefore IT should lead the evaluation

Obviously, your company's project management processes are not a technical issue. While these applications are clearly built from cutting edge technology, the overriding objective in selecting one should be its ability to solve business problems, not technical ones. Of course, if an application can't solve technical problems first, it won't have much chance of solving business problems. For this reason, a technical review should not be eliminated. But it should not be the primary focus and probably not even be a pre-requisite.

In many respects, web-based applications are actually anti-technology in that they move a great deal of the deployment and maintenance of the technology out-of-house. This means reducing the administration and complexity of existing systems so, if anything, they require less input from IT compared to the deployment of conventional systems.

7. Web-based project management applications . are easy to implement because you don't install any software. Just buy a subscription for six months, give the project managers a password and see if it takes off

Despite the hype, web-based project management applications are not "killer apps" like email or Napster that just take off by themselves. To the contrary, for many users, the thought of moving their familiar paperwork online is painful and unattractive.

Buy-in from upper management is important, but enforcement will probably be essential. Of course, like any strategic endeavor, clearly defining your goal and constantly communicating it is also important. Are you going to decrease expenses? Compress schedules? Increase quality? Reduce risk? Market the fact that you are more technologically progressive than your competitors?

Once you get started, the personalities may vary widely. On one end, may be the extremists that are so against the new process they will go out of their way to sabotage the deployment. Somewhere in the middle may be the moderately uninterested who simply resist. This group will eventually get with the program and succeed, but it will cost more in training and support to get them there. On the other end, hopefully, will be the enthusiasts and early adopters. This group should serve as test pilots in the first project and the champions and mentors in the later projects.

There will be a direct correlation between the collective attitude of the users and the cost of deployment. All else being equal, there will also be a relationship between the age of the users and the cost of deployment. As you develop your plan, make a list of your users and budget training and support costs you feel will be necessary for each one to bring them, and keep them, up to a point that they are pulling maximum benefit from the application.

Because of the mix of personalities and the willingness to adopt, it is best to keep most if not all of the initial efforts within your own organization. Attempting to implement ten processes across five companies on the first project is a recipe for disaster (and a waste of a lot of training time). Start off with a couple of simple internal processes and maybe one, like RFIs, with the architect or a subcontractor. After you have developed a couple of experts in-house, they will be in a much better position to encourage and support people from other organizations when you begin to pioneer processes across companies.

8. Web-based project management applications . hold information until the project is over and then you burn it to a CD and take it off the web

An important, but often unanticipated, benefit of this technology is the ability to develop a historical archive and an organizational "memory". However, to get this benefit, you can't look at the application as a temporary location for data that must be quickly removed when the project is over.

Instead, the application, wherever it runs from, should be considered a location for storage that is just as valid and long-term as your own hard drive, network, or file drawers. Taking this attitude means putting a lot of trust in your vendor's fiscal and systems stability. It goes without saying that having regular CD or tape backups in your own possession is a good practice. But having data from all of your projects over several years in one database always online and accessible can provide some powerful insight as well as quick answers to issues that arise long after a project is complete. One more benefit that you don't want to overlook.

9. The point of web-based project management applications . is to save money on faxes, shipping, travel, and personnel

This is not so much a myth as a gross understatement. These applications can be justified by overhead cost reductions alone, but the real return lies in other areas:

• Standardization of project management processes. Best practices can be refined, re-used and enforced in online workflow across multiple teams.
  
• Reduced risk. What is the value of mistakes that can be avoided on projects by having pictures and other information immediately available to the project manager instead of arriving days later?
  
• Less disputes and the time involved in litigating them. Because business processes are captured as they happen, documentation is automatic including who saw what, when and what actions were taken.
  
• Competitive advantage in marketing and proposals. A successful use of technology that hits the bottom line is a powerful and, for some time to come, distinctive selling point.
  
• Attracting new employees. The next generation of project managers will appreciate and seek out technologically progressive employers.
  
• Senior management oversight. Executive roll-ups provide analysis across projects that summarize the operational health of the organization.

As with any software implementation you are going to spend valuable time and money deploying a web-based project management application. As you can see, there are a number of not-so-obvious areas in which you can mine value as well as several hidden traps that can derail your effort. Your success will depend largely on a clear understanding of what the software does (and what it doesn't do) and where the value lies.