For example, Malone suggests, many companies reward their sales departments based on projected gross profit rather than net profit. That, he says, removes incentive on the part of sales to do anything that would retroactively reduce that number. Change orders might dribble through periodically and in some cases be simply woven into the already agreed-upon contract.
That might not make a huge difference in product or component costs to the integration company, but it has a cumulative and negative impact on the operational members of the company, who might already have been scheduled at 100 percent based on the original projections by sales. That’s the crack in the dam that undermines a company’s ability to manage multiple projects simultaneously successfully, because the sales silos cannot (or will not) see the effect that change orders are having on scheduling.
“This is really a matter of resource management,” says Malone. “A fundamental question you have to ask yourself when evaluating how a company works is, does sales view the resource pool as necessary for success or a necessary evil? Often, the sales force is product-focused and quarterly driven, and they promise dates and create client expectations that can’t be fulfilled. That’s a systemic problem, a problem of culture, and one that will make managing multiple projects at the same time much, much harder.”
Worse, says Malone, overlaying a good software management tool over such a culture subverts the usefulness of the tool. He suggests more communication between sales and service and working toward a culture in which sales instinctively refers back to installation before creating schedules for clients. He also encourages companies to book their installs at less than 100 percent all the time.
“A fully scheduled integration department looks good on paper, but the reality is that a change order comes along and the technicians say we can’t fit that in for another month because we’re booked so tightly,” Malone says. “Those kinds of situations – and they happen all the time – create ripple effects throughout the scheduling system. I
t’s amazing how many projects there are out there that are sitting at the 99-percent completion level, but because of that one percent, you can’t bill.”
Malone advises that a scheduling resource rate of between 85 and 90 percent leaves enough flexibility to accommodate last-minute variances in projects and allow for resources to be shared across multiple projects when one needs a late injection of manpower to keep it on course. “And having that kind of flexibility routinely built into your scheduling system also means that when you do have to move crews from one project to another, you’re not creating an ‘exception,’ which eventually reaches the point where the ‘exception’ becomes the rule,” he adds.
Going To Extremes
As projects become more complex, and as integrators take on more at once, something called “extreme project management” occurs. That concept embodies the first Project Management X-Treme course, held in April under the auspices of Professional Systems Network International (PSNI, an alliance of A/V systems integrators) and NSCA. The course, part of a larger series of seminars, focused on project management. Nineteen participants from nine of PSNI’s affiliates attended the daylong symposium, which was held in Indianapolis and led by Nadim Sawaya, CPP, a principal of Enterprise Performance Consulting in the Bay Area.
“Project managers are being asked to do more and more, and it’s impacting their performance and the quality of work,” says Sawaya.
In his analysis, Sawaya says that the typical project manager working on the low-voltage systems side of integration should be able to manage projects worth $2 million of revenue annually, based on large projects; a workload composed of smaller projects, of $25,0000 or less each, would lower that annual figure to closer to $1.5 million. Sawaya says while that underscores the notion that multiple smaller jobs reduce overall productivity, the real killer is that project managers are being asked to do tasks outside the immediate realm of responsibility for their job title, such as engineering, programming and starting up projects – tasks that should be done by others or at least delegated to others by the PM before the project begins.
“Most project managers come to the position promoted from the field, so they not only have these skills but are used to applying them,” Sawaya says. “They often have to be told or reminded that someone else has to do them now. This is especially true in smaller companies where almost everyone comes up through the ranks. You have to learn how to be the manager, and manage what others do.”