Project Management Solutions and Field Automation: A Less-Than-Elegant Convergence

In the construction industry, today’s software automation landscape is a minefield. For the uninitiated, considering direction and evaluating options can be a complex and mind-numbing exercise consisting of bold promises, shiny product demonstrations, and considerable tech-jargon, none of which bring the situation into focus. Those trying to make a decision about a solution or platform end up frustrated and hurried to fix a near-term problem without adequate consideration for the larger systems’ vision or company direction.

This issue has become more complex over the last 10 years, as project management solutions and technologies being applied in the field have proliferated considerably. Now, instead of companies having to make one broad decision (e.g., ERP solution, estimating application, etc.), they must make numerous smaller decisions around solutions for RFIs, foreman daily reports, safety, QA/QC, and drawings among others. So how does one approach the longer-term needs of the company and the direction of technology in general, while still being responsive to the immediate needs of a large project or demanding owner?

It helps to start with a better understanding of the overall platforms (not products) available in the market. These are the technical foundations vendors and developers use to create and deliver their products. Unlike years ago, today’s solution platforms are not one-size-fits-all. There are cloud-based applications, Web-based applications for collaboration around functions, others still for file sharing, and finally mobile platforms meant for tablets and limited amounts of data entry. Each of these platform types has inherent advantages for the functions for which they are intended, but may contain limitations when trying to perform unrelated tasks. In the extreme, imagine typing a letter using a smartphone ... possible, yes. Desirable, no.

This article’s objective is to provide executives and senior IT professionals with a framework to ponder the various solutions and platforms currently offered for project management functions, collaboration, field solutions, and document storage. Ultimately, by using this framework as a guide, it will better position the organization to make improved long-term solution architecture decisions.

Within the scope of project management solutions, there are at least five different solution types being used. This amounts to dozens of products which specialize in one, several, or many of the standard PM/PE functions. The classifications are:

• Stand-alone PM solutions 
• PM applications within ERP
• EFSS solutions (e.g., Box, Dropbox), 
• Owner-driven programs 
• Collaborative platforms 

This does not include the fallback favorite of office productivity tools like Microsoft Excel and email. Each solution type has certain advantages and challenges depending on vendor and product.

PM applications that are part of the ERP solution typically are well-integrated and highly functional for financial transactions but may not offer an easy way to collaborate with the outside project community. However, some ERP-integrated PM applications that were once state-of-the-art now are struggling to keep pace in a rapidly changing environment that includes a demanding, tech-savvy workforce. Those are considerations of that platform, without regard for the products. Yet, to understand the complexity of this problem one needs only to consider the various functions being automated.

The table below is a partial list of the field/project functions being automated, and also provides an idea of the scale of the issue: 

Field data capture	Safety	Site layout
Equipment	Camera/site-cam	Compliance
Drawings management	3D printing	RFI/Submittal
Change orders	Laser scanning	Meeting minutes
Small-tool tracking	Punchlist	Scheduling
Check-in/check out	Fabrication/delivery	Material coordination

In theory, each of these processes would benefit from having a solution and/or platform uniquely designed for its requirements. Then project data, cost codes, and personnel or contacts all would have to be reentered any number of times, just to keep the systems current and synchronized. There is a practical limit to the number of applications, though, since increasing the number of solutions in the field becomes increasingly hard to maintain, and fundamentally inefficient and expensive. 

Another complicating factor is that data or documents rarely are handled by just a single solution. Take insurance certificates or lien waivers, for example. They both are part of the contracting process initially, become part of the payables process, and finally are part of the project closeout process whereby the documents get turned over to the owner or general contractor. Therefore, one must think about not only the best platform to process the documents on initially, but conclusively where the information resides and how it gets there. 

Some large-scale vendors are trying to bring all of these functions together into a single platform, either through development or through acquisition of complementary products. Nonetheless, their base platform, Web, client/server, or mobile, may be ideal for one function or set of functions, but less than optimal for others. The lack of functionality eventually will force larger developers to open up their platform architecture so that best-in-class applications or point solutions can be integrated. A company’s decision to incorporate point solutions is dictated largely by company size, as smaller companies tend to prefer the single vendor solution for ease of licensing and deployment, while larger companies appear willing to integrate point solutions to accommodate their diverse users, and typically have the resources available to handle more complex deployments.

If the PM application were the only consideration, it would be a fairly simple decision process of aligning key benefits of the platform with the requirements and priorities of the company. Yet, there still is increasing pressure from other processes/functional areas inside and outside the company, which makes the choice in application all the more difficult.

Without a good framework for making these IT decisions, it is easy to be confused on how to automate these solutions. The choices then will be made on a number of less-than-optimal criteria, such as a well-marketed product, an owner requirement, or a demonstration based on features, and not the core functionality required by the organization or a tech-savvy, persuasive PM. Limiting the decision to these criteria, and not aligning them with the larger strategic IT vision and business objectives of the organization often results in a high investment with little long-term value.

To avoid a short-term solution or worse, an ill-fitting one, planning the organization’s IT solution strategy and deployment model is essential. The many competing solutions, underlying technologies, and confusing marketplace messaging prevents companies from effectively moving ahead with significant purchases. One way to develop this plan is through an IT Steering Committee comprised of a few senior managers, functional area leaders, and IT professionals who understand the current IT footprint, and assess how additional solutions will affect it. They also should be able to prioritize IT spend, as solutions are discussed for varying functional areas. 

Another way to approach the planning is to analyze all of the required functions that need to be automated, determine the best underlying technology for the majority of those functions, and then select broad-based solutions from strong vendors who provide services, as well as ongoing support. Review the vendors’ product roadmap to ensure the direction in which they are taking the product or product(s) is consistent with where the organization is heading with IT requirements.

As mentioned previously, including the IT manager in the purchase of the software solution is critical, since they can provide their expertise, as it relates to the underlying platform, tools, and technologies, ensuring a solution is a supportable one that will meet today’s expectations, and that it also remains a viable platform in the context of other platforms within the IT ecosystem. However, since IT does not process RFIs and submittals, no one solely relies on them to make the decision.

 

Operations, including field personnel, must be involved as well, as they are the subject-matter experts with regard to the day-to-day functions that will drive value from the solutions. Additionally, senior management should be included to provide guidance on the organization’s strategic plan and business objectives. They will be able to offer insight into financial considerations, changing markets, and customers that others may not. They also are the group that will or will not push for adoption of technology, depending largely on the extent to which they feel it is important. Finally, they are the ones best positioned to evaluate the company’s risk tolerance.

One last suggestion when considering alternative platforms or products is to not allow old processes and thinking to dictate future direction. If status quo guides the selection, you will end up with older technology that merely mimics legacy processes instead of inspiring innovative process change. This may be more comfortable and less disruptive, but it does not move the organization forward. Conversely, the opposite thinking can be equally dangerous, "Anything is better than what we have now." Bottom line, be deliberate. Think about your future, what you are trying to accomplish, and how you are trying to work. That will drive you to a better platform, and ... a better result.

With the above framework in mind, if you are in the middle of a product and process evaluation, it is wise to step back from the morass and hit pause. Take a broader look at all of the functions needing to be automated, consider the platform type that is the best fit for the organization, and evaluate solutions meeting that criteria. Also, contemplate a middleware solution that acts as a data broker, moving data from one program to another when appropriate. While middleware is more expensive and meant for larger-scale operations, smaller companies can take advantage of routines vendors include in their application exclusively for moving data in and out.

Select the right tool for the job. Yes, a pair of pliers can be used to secure a nut and bolt ... once or twice. But you know the value in the field of having the best possible tool for a job that is critical, done frequently, and efficiently. The same applies to technology.