5 Things Mega Project Teams Should Know Before They Select and Implement Technology

There is a pattern that plays out on nearly every large capital program that brings in new technology. Leadership identifies a problem - cost overruns, schedule slippage, fragmented data, too many claims - and the instinct is to go find a system that fixes it.

But too often, teams move straight to the solution before they have fully diagnosed the problem. They buy technology for the symptom they can see, not the underlying issue driving it. And that is where things go wrong.  
 
The result is usually a mismatch: the organization invests time, money, and change management effort into a platform that looks promising on paper but does not actually solve the real operational breakdown. The pain is not just wasted spend, it is that the program still carries the same core risk, just with a new tool layered on top of it.

I recently spoke with three practitioners who have lived this challenge from the inside: Cari Stieglitz, President of Kvolve, who has worked on programs ranging from a 95-building campus in Dubai to Sound Transit's enterprise systems overhaul; Mike Marcel, President of the Integrated Solutions Group at K2, whose work with WMATA became a case study in what it takes to bring order to 25 years of organizational chaos; and Rich Miesemer of Parsons, currently serving as PMIS Director on the Hudson Tunnel Project,  a $16 billion program connecting New Jersey and New York that carries Amtrak, NJ Transit, and effectively the entire Northeast Corridor on its shoulders.  
 
Here is what they taught me.  

Most organizations try to jump to technology to solve a problem, Marcel says. It rarely works. When K2 arrived at WMATA, leadership was facing 25% contract overruns and serious pressure from federal funders.   

The temptation was to implement a system. But a more disciplined approach was to start by getting people aligned: understanding roles, responsibilities, and accountability before a single workflow was configured.  

Technology creates accountability, drives efficiency, and locks data into a single place. But it can only do those things if the people using it understand why it exists and what they are responsible for within it. Get the people right first. Then move to process. Then bring the system in to reinforce both.

This is one of the most important and least-discussed distinctions in mega project delivery. Processes will (and should) vary across project types within a large program. What cannot vary is how cost and schedule data are structured and reported.

Miesemer described this tension from the Hudson Tunnel Project. Each delivery package operates differently, with its own stakeholders, its own team, and its own reporting requirements. But the Gateway Development Commission still has to report consistently to federal funders and that requires standardized data underneath all of that project-level variation.

Work breakdown structure (WBS) is where this plays out most critically. Individual projects within a program may legitimately need different WBS structures. That is acceptable. What is not acceptable is failing to agree upfront on how those structures correspond to each other at the program level.  
 
If you do not make that decision early, your cost reporting will be unreliable, your schedule rollups will be meaningless, and your federal reporting will consume far more time than it should.  
 
People consistently underestimate the work involved in getting this right, Stieglitz says. It is not glamorous work. It is the backbone of everything.

Every implementation runs into the same human obstacle: people love their spreadsheets. Moving them off a system that has "worked well for them" (even when it hasn't worked well for the enterprise) requires more than good training.  
 
It requires clear communication before go-live so nobody is blindsided. It requires genuine presence and support after go-live, because when something goes wrong and nobody is there to help, adoption collapses.  
 
Change management is not a checkbox at the end of an implementation plan. It is a sustained commitment from day one through stabilization.  

First and most important, says Miesemer, is asset lifecycle management. If a project management information system (PMIS) cannot handle asset management in addition to capital projects, it is solving only half the problem. The time and money spent managing an asset over its operational life dwarfs the cost of the capital project that created it. Selecting a system that stops at project closeout means you will be solving this problem again in five years.

Second: real configurability. Every vendor will tell you they are highly configurable. The way to find out if that is true is simple: give them a bespoke process, including the form and the workflow, and ask them to build it out in the room. Time them. The results will tell you more than any sales presentation ever could.

Third: user interface. It still matters. A system that nobody wants to open is a system that will not get used. But User Interface (UI) is increasingly table stakes. If you have selected for asset lifecycle depth and genuine configurability, the UI conversation is a refinement, not a decision.

They are not just buying software. They are building a system of people, process, and technology that has to outlast the project itself. On a mega program, the decisions made in the first six months of implementation will shape how data is collected, reported, and trusted for the life of the program. 

That is why the most important software decision is not which platform looks strongest in a demo. It is whether the organization has done the work to define the process, clarify accountability, and understand the problem it is actually trying to solve. 

Get the foundation right, and the technology can deliver on what it promised. 

Get it wrong, and no amount of configuration will save you. 

For teams evaluating construction management software, the real question is not just what the system can do. It is whether it can support the way your program actually needs to operate.  
 
Read more on how to evaluate the best construction management software: 10 Best Construction Management Software Platforms In 2026