An ounce of prevention: Planning IT projects
Software / Hardware
Mechasys Announces Collaboration With Fujita Corporation, a Member of Daiwa House Group, to Adapt the FramR, Its Laser Layout Projector, to Construction Methods in Japan
No contractor would show up on a job site with no plan or schedules, yet many embark on information technology projects with a very vague set of goals
It is often said that a problem well defined is a problem half solved, yet we humans have a tendency to skip the planning part and jump right into a solution. How companies handle software projects is a case in point – and contractors are no exception.
“I see many companies implementing without a clear roll out plan,” says Dennis Stejskal, customer experience director for Sage Construction and Real Estate. “One of the components of the implementation that often is missed is setting a company standard on the use of the technology, and then training to that standard.”
The results are all too familiar. Projects get delayed by unexpected complications. Costs run through the roof. Solutions arrive in the field with gaps that require manual intervention or workarounds from IT. Field personnel see a solution as “something corporate has forced on us” and the system gathers dust.
As Yogi Berra quipped, “If you don’t know where you’re going, you might wind up someplace else.”
The trouble begins with the faulty assumption that business owners don’t need to be involved in software decisions. “I think there’s an expectation that if you install software on a server, you’re automatically going to solve a lot of business problems,” says Rick Deans, executive vice-president of Industry Engagement with Scottsdale, Ariz.-based construction software vendor InEight Inc. “That’s something I try to get out ahead of.”
The first step is to bring all stakeholders to the table – not just IT people and tech-savvy users. “We need to get business process owners involved,” says Gerry Salm, senior manager at Edmonton-based PCL Construction. “We have power users who have some great ideas, but we really need to involve people who have a bigger vision of where the business is headed.”
The initial conversation is not on software features and functions, but on the business processes that the software will be supporting. “My starting point with clients is that software is an enabling tool and works best when there are established business processes,” Deans says. “What I try to do with my clients is build a map for how the solution is going to support those business processes. And part of that exercise might be challenging some of those business processes.”
Deans points out that he often brings people into the room – perhaps an estimating team and an execution team – that have never talked to each other before. “It’s really interesting to see those walls break down where you get them sitting around the same table,” he says. “I often hear things like, ‘Wow, you folks think of everything!’”
The dialogue with vendors is also critical. “Both groups bring something to the table that can help the other out,” Salm says. “We know we’re not a software development company, so they have some practices that we can take advantage of. We also have alignments with our business that software vendors don’t understand. So it’s a meeting of the minds and determining what works best for both groups.”
Facilitating these meetings properly is a must. “These conversations can run off the rails,” Deans says, “so we need to keep people focused on what the inputs are, but more importantly, on what the outputs and benefits are going to be.”
A software development framework known as Agile provides a formal roadmap for maintaining this focus throughout the process. Many vendors and some contractors are now employing it, particularly on large, complex projects. Agile provides both the structure and the tools that ensure a highly collaborative approach.
“What the Agile framework does for us is get projects done quickly,” Salm says. “Because you’re always coming back to the business with ‘did I get this right?’ whether that’s at the stage of requirements, design, or development. Our solution framework is about keeping a focus on that.”
The Agile approach will be familiar to contractors who practice Lean construction, where the general contractor works collaboratively with all stakeholders throughout the project (see On-Site’s December 2019 issue for a more in-depth look at Lean).
“Some people have pointed out to me that they’re seeing this collaboration on the business side as well as the software side,” Salm says.
All this demands business owners make IT an ongoing part of their strategic conversations.
“As companies grow, they need systems that can expand with them,” Stejskal says. “We advise companies to align their corporate objectives with IT strategies and objectives. There are a lot of companies that don’t do that.”
This column first appeared in the June 2019 issue of On-Site. To read through the full issue, click here.
Jacob Stoller is principal of StollerStrategies. Send comments to firstname.lastname@example.org