The Right Practices In Place Can Minimize Unexpected Changes in Project Breadth
Anybody that takes pride in their work loathes not getting it right the first time. Anyone that strives to run a profitable operation also hates having to do things over again. Arguably, the biggest threat to a systems integrator’s profitability and pride is scope creep. The question is, is it something that integrators just learn to live with, or can it be prevented?
Maybe not entirely, but it can definitely be minimized with the right practices in place. The challenge for systems integrators is getting in front of the client early enough, so they can identify potential areas where scope creep could…well, creep up on them.
“What I see most often is that either we didn’t get all the requirements completely defined up front because the customer wasn’t sure of what they wanted, or wasn’t aware of all the requirements, or maybe all of the stakeholders weren’t included in the discovery process,” said John Bailey, vice president of systems integration at Whitlock, an AV and unified communications provider headquartered in Richmond, VA. The danger in this is that it’s difficult to clearly define an accurate use case, and thus the right solution for the job. “Sometimes you have to educate customers because they think they want one thing, and it’s not the best solution to their problem. When we can get directly in front of that customer in the design phase and employ our system of doing discovery and needs analysis and really understanding what the experience is that they’re going for, we definitely do a better job of delivering [the project] with fewer surprises.”
For systems integrators working on bid projects, one of the issues is that while the bid documents may be highly detailed when it comes to technological specifications, they aren’t always as clear as to how that technology should be installed, noted Chuck Wilson, executive director of NSCA. This leaves things open to interpretation: for example, the integrator may install a system leaving the wires exposed while the owner assumed that everything would be flush-mounted. “One might say that scope creep is having to reinstall [the system] in a different manner than you originally planned for,” he said.
Dale Bottcher, vice president of sales at AVI-SPL in Tampa, FL, acknowledges that scope creep isn’t always avoidable; the key is empowering field technicians to alert the powers that be when it’s clear that a change order is necessary. “They need to be the first responders, so to speak, when this is something that is outside our statement of work, and outside of our scheduling, and they need to be able to push that through to our project managers so that we can have those discussions with the client and generate change orders when appropriate,” he said.
Bailey prescribes “over-communication” as crucial in scope creep prevention, not only during the discovery process, but every step along the way. This is where a good project manager is invaluable: in weekly meetings with the client and the integration team, they can identify upcoming risks and mitigate them before they actually happen. “Project managers are really on the frontline of understanding what the scope is and communicating the risks based on that scope, and trying to get out in front, so we can head issues off before we crash into them,” he said. Solid internal processes are also paramount to preventing scope creep; without them, it can be difficult to recognize when the scope is creeping beyond what you originally planned for. “If you don’t have processes in place to monitor that scope and make sure that it’s not getting out of control, it’s easy to wake up on a Monday morning and have one of those realization moments where you say to yourself, ‘we’ve got a serious leak, and it’s been leaking for a couple of weeks now and we just didn’t realize it.’”
Carolyn Heinze is a freelance writer/editor.
Get With the Program
One of the trickiest parts of managing scope these days is at the tail end of projects when it’s time to program the systems. The sheer flexibility these technologies offer often lead to costly back-and-forth with the client when they fully understand how robust the programming functionality can be. “It’s very difficult to define it to the point that you fully related the capabilities to the customer, so they understand ahead of time what’s possible, so you don’t get into a situation where they say, ‘It can do this? Can you add that?’” said John Bailey, vice president of systems integration at Whitlock.
While Whitlock attempts to curb this by building in enough meeting time prior to programming to identify things like the look and feel of the GUI, “there’s some aspect of the last mile that you can’t really define until you go through the process of doing the design and collaboration with your customer. There’s got to be a little bit of flexibility left in there, but you don’t want it to be completely open-ended.”
At AVI-SPL, in addition to the programmers it has on site in all its offices, the firm has created a centralized programming group in an effort to streamline programming and thus, avoid scope creep. “They’ve been very influential in helping us generate templated scopes of work,” explained Dale Bottcher, senior vice president of sales. “We’ll lead with one of our recommended templates and graphical user interfaces and try to move the client down that path whenever possible.” Before this happens, however, the integrator asks the client a series of questions based on how automated or manual the client wishes the system to be. Bottcher likens it to aviation: do you want to be the pilot, the co-pilot, or do you want this system to run on auto-pilot?
While controlling scope creep in programming is important, Bottcher believes that spending the time to define the system up front is crucial in pulling off a successful project. “It’s one thing to talk about functionality, but you really need to have discussions around how they want the flow to work to be and how they want the user interface to function,” he said. “Honestly, when control systems are involved, they are probably one of the most important parts of the system because they really make or break the client experience, and really define whether your project is a success or not.”
––C.H.
