Purolator Courier's CIO: Why We Shuffled Execs
- 10 October, 2008 13:22
As investment plans go, the one embarked on by Purolator Courier in 2005 was a doozey. In essence, the five-year plan was one of those 'bet the company' initiatives, entailing the building of the firm's first two automated hubs (in Montreal and Vancouver), the overhauling of its data warehousing strategy, and the jettisoning of much of its technology infrastructure, including its time-management system and its Web-based and customer shipping systems.
As Senior Vice President and CIO Jim McDade modestly put it, "It's been a busy three years." The need for the big overhaul was indisputable. Hampered by legacy systems that in some cases were nearly a couple of decades old, Purolator found that it couldn't bring new products into the marketplace. The company was being outmaneuvered by its competitors, who had the ability to price services fairly precisely between two points, while Purolator was saddled with zone pricing.."
Strategy and the CIORead what five Canadian IT executives had to say about their changing role in strategic planning.The objective of the five-year plan was to build a new Purolator for the company's customers -- one quite different from the original and one that would give customers a new way of doing business with the firm.
"We changed how we bill for our services, we changed the definition of our services, and we changed what services are available at what postal codes. Fundamentally, we rethought all that," said McDade. "And one of the guidelines throughout the initiative was that we couldn't lose a single customer because of this new system." That meant coming up with equitable pricing between the old and the new Purolator, and getting customers to sign off on the new pricing.
Putting the Right Team in Place
A great deal of thought was put into the initiative from the outset.
"I'm a firm believer that eighty per cent of the value of a project comes within the first twenty per cent of its time-frame," said McDade. "And so we did a lot of hard slogging to envision how we wanted to run our company and get the business onside as to what that change would be, and how they would change to support it."
Once this future had been envisioned, executives from the business as well as a cross-functional team of employees were invited to join the project and help build that future. Though the building of a new ERP system was a heavily IT-based project, the company handed the reins of the design phase to VP of Marketing John Cooper. Along with three of his direct reports, Cooper worked hand in glove with the IT specialists to come up with an appropriate solution.
"There were two big challenges we faced," said Cooper. "The first was ensuring that we had thought big enough in the design phase so as to enable us to deliver flexible solutions to our customers, while at the same time focusing enough to provide clear direction to the build teams to execute against.
The second was to gain endorsement from a representation of key internal and external stakeholders, creating an opportunity for them to review the design principles and framework, endorse the direction, and prepare themselves for the deployment activities to come." At its peak there were over 300 people on the project, including staff from Innovapost, CGI, Microsoft, Kewill, SAP, Accenture and Avanade. There wasn't a pre-built solution for the things Purolator was doing, so the team had to work through and think through how to make the changes effectively.
About 40 of Purolator's core business staff, including Cooper and key members of the Marketing department, were assigned to the project and relocated to a floor of one of CGI's development centers, about ten minutes from Purolator's head office.
This, of course, created some anxiety for the affected staff, who naturally voiced many of the concerns heard frequently on such projects: Why me? What if this doesn't go well? What if someone comes in and does a great job in my role?
"We knew that this was an issue and we worked hard with everyone to make things very transparent. We didn't want people worrying about their future here, so we spent a lot of time with them, explaining that they had been hand-picked because they're among our leaders and we want to invest in them," said McDade.
"Just because someone started on the project didn't mean that they ended on it," he added. "And if they left it, it didn't mean that there was any kind of a problem with that person. It just meant that we were entering a different phase and we needed different skills."
The CIO as Prime Contractor
While Cooper led the design phase out of the off-site facility, McDade worked with his peers at head office, ensuring that the company got the design right, tackling such issues as how best to do point-to-point pricing, what should the shipping channels look like, and how should the business intelligence layer be done. In essence, he became the prime contractor for the project.
When he joined the company in September 2005, most of the project work at Purolator was done on a fixed-price basis. But McDade wasn't a believer in fixed-price contracts, so he took a different approach, opting to avoid customization and go the time-and-materials route.
"My thought was if we go fixed price and we get into a problem, it's probably going to be because I didn't make a decision on time or I did something that took the IS folks in the wrong direction," he said. "So why should I pay a premium to have them cover themselves when it's my fault anyway?"
McDade said that his biggest challenge in the prime contractor role was working with the tough timeline and budget on the project.
"There are some very nervous and exciting times when you're burning through probably a half a million dollars in expenses every couple of days at peak," he said. "You're really trying to ferret out where you are and whether or not you're making the progress you expected to make. Are we moving the ball down the road? Are the numbers in line with the budgets, and are they correct? Because in projects like these, there are always surprises. So how do you handle those surprises?"
More Changes at the Top
When the build phase kicked in, McDade assumed responsibility for the project. He now spent two days a week at the CGI location, while Cooper returned to head office to help prepare the business for the incipient changes.
Though McDade's duties didn't change a great deal, there was an important symbolic significance to the leadership change.
"We wanted to make sure people knew we weren't going to be in continuous scope creep. So my taking that lead role was, as much as anything, to close the door on scope changes," said McDade. "We're living with what we've got. Yes, there's probably three or four per cent that we didn't get.
But the 96 per cent we got is a heck of a lot better than what we had, and where we're going in the future will be where we want to get to." During the build phase, McDade's project leadership position touched on many levels of the organization.
"What I tried to do is take the 'managing up' role myself and get the people with me to handle the 'managing down' roles," he said. "I had a co-lead from Accenture and she managed down quite a bit, making sure our issues were resolved. I would take the outcomes of that -- the good news, the bad news, the decisions we needed to make -- and manage those up. I'd explain, for example, why we're in a particular situation, what we're doing about it, why it's not a big deal, and how we're planning to get back on track."
But McDade shrugged off the notion that he was the man in the hot seat. "There are a lot of people in critical positions in a project like this," he said. "Everyone's the meat in the sandwich. It just depends on where you're looking from."
Another executive stepping into a critical role during the build phase was Mike Coté, VP Corporate and Regulatory Affairs, who took the lead in preparing the company to take the new business model to market. Five salespeople were pulled from each of the company's divisions and worked as a dedicated team under Coté's direction.
"Perhaps the toughest job faced by the take-to-company team members was digesting the shear magnitude of the change before them," said Coté. "We worked with the leaders of the change management teams to ensure that their team members maintained a day-to-day focus on 'the next step' in the change process that we had laid out. By adopting this approach, our change management team leaders were able to safeguard against the temptation their team members may have had to singularly focus on the end goal, a view that risked being overwhelming."
The take-to-market team created a playbook that acted as a how-to guide for moving customers from the old world to the new world.
"We focused on all the positive aspects such a change would bring to our customers," said Coté. "We also emphasized the fact that over the years we had earned the trust of our customers by delivering on our promises time and time again, and in so doing we had earned the right to deliver the sort of positive change that our initiative represented."
As the project had a big team with many companies involved, proper oversight was critical, so a series of regular meetings were held to help things stay on track. On Monday, the project team would meet to go over what happened the previous week, get a fix on where things now stood, and plan for the following week.
Tuesday mornings were set aside for a project review, which would run from ten till noon or however long was needed.
"We had people in our PMO who were just phenomenal. They managed our checkbook, time-reporting where we were, and they also managed what the issues were," said McDade. "In about three hours they would walk us through a 50-page deck. We'd have thirty or forty people in the room and different people would talk about their parts of the project -- what they had achieved, what their issues were, what was outstanding, what they needed help on. We did that every week and we did it relentlessly. Early on it was a little uneven but then people found out that these meetings were there to help them get their issues on the table and get them solved."
At the end of the Tuesday meeting, McDade tried to get an informal measure of how things were progressing, asking questions like, 'Are you a little more nervous or a little less nervous?' 'Are we making progress?' 'What are your gut feelings on it?'
"On a job with that many people, there are four or five layers until you get down to that coder at the bottom, so you need to maintain some sort of communication with everyone," he said. On Wednesday afternoons the project leaders would go in front of the executive committee and report on the past week. "Visiting your CEO every week keeps you sharp," said McDade. "I would talk about what the development teams were doing, but the people making the presentation were the folks like John Cooper and Mike Coté. So it was an opportunity for them to shine and for them to be on the spot too, which was a good way to keep the whole thing on track."
Tackling the Challenges
Purolator has about 300,000 customers, the vast majority of which are small or medium enterprises that do not have contracts with the firm. The greater challenge for the company in migrating to the new system was its 5,000 or so large customers, the biggest of which were making thousands of shipments a day.
"When it came to those 5,000 large customers, we were still operating our old billing system at the same time as our new billing system," said McDade. "On the one hand we were saying, 'Hey, we have to get rid of all of this stuff, it's 20 years old,' and on the other hand we were saying, 'Well, we're going to have to talk to those things until we convert the last customer.' So our legacy systems were a big issue for us in terms of a risk to be controlled." But with the help of a good project manager from CGI, the legacy piece was well managed and ended up not being as big a risk as anticipated.
"Someone would say, 'It's going to take this many days to do this,' and we'd say 'I don't think so -- explain why. Let's take a closer look at this -- why, why, why -- and we'd just keep going through it. We'd just keep managing the risks away as we evolved through the project," said McDade.
As the project moved to the back end of the build, another hurdle was faced: will the business accept this? The question was an important one, as the roles of a few hundred people were about to change.
Again, Purolator responded by putting the right person in a key role. The Director of Customer Administration, Sandra MacLennan, was a very detail-oriented person who knew the company's systems intimately from end to end. "As part of the 'getting the company ready to accept the changes', the customer administration team had a head start from the beginning as the project team members came directly out of the Customer Administration department," said MacLennan.
"We made the decision at the beginning of the project to use as many subject matter experts as we could justify. This included management as well as front line employees," she added. "This made the ongoing day-to-day running a bit more difficult, however we believe it was the right decision.
We required a bit more overtime for the project duration, as we did not replace the individuals we assigned and management had to take on added responsibilities. But we were more than adequately represented from a front line and management complement on the project, and who better to represent the business than the people that do the job every day?"
Changing the Game
There are many roll-outs associated with the new systems and McDade is happy with the way they have been going, although he admits to the belief that there is more value inherent in the new system than has so far been realized.
There have also been a couple of glitches in the proceedings. Unluckily, the company's Montreal data center had a fire on go-live weekend last September -- an extremely rare occurrence -- and rather than risk a breach in service capabilities, the rollout was put back a week. As well, with a fragile economy and fluctuating fuel prices, it's not the best of times to be talking to customers about new pricing.
But on the plus side of the ledger, the technology's working fine and the sales force is happy with the new things that can now be brought to market.
The new system has also enabled the company to enter into new agreements to better serve the needs of customers and partners.
"When I talk about the business case for what we've done, I point to these agreements. We can make the changes needed to enter these agreements in a couple of months because we have this new platform. We couldn't even envision doing that in the past," said McDade. "Now that we've got all these new capabilities, we need to spend more time thinking about how we're going to exploit them and plans are underway to do just that this fall."
The Role of 'Trust' in Systems Projects
According to Jim McDade, building systems is all about trust. You've got to get the people around you to trust you, and you've got to trust them.
There's nothing worse than a surprise," he said. "And if you want to avoid surprises you've got to get people comfortable that they're not going to get beaten up if they have a problem."
If an error is found before you start coding it, then it takes a day to fix; if it is found when you code it, it takes fifty days to fix; and if it is found at integration testing it takes a thousand days to fix, he noted. Therefore you must create an environment where errors are corrected early.
"You need to know where the hidden problems are. What aren't we doing?" said McDade. "So you must create an environment where people want to make it clear where they see the risks." In order to create that level of trust, McDade spent a lot of time with the team during the build phase. And he had a couple of people on the project -- Mike Scotten from Innovapost and Dave Miller from Accenture -- who didn't have a defined role on the project, but were trusted people who "knew the real insides" of how to build big systems.
Scotten and Miller were an important piece of the puzzle because there was a lot of simultaneous design and build that had to be kept track of, especially when the team was working on a big piece of custom code in SAP, which formed the basis of Purolator's service directory.
"They moved around and made sure things were going smoothly," said McDade. "Everyone was comfortable with them because of the environment that had been created. No project lead was affronted by the fact that one of them was in their area."
Because of the trust factor, Scotten and Miller were able to do their jobs effectively.