Just as a journey of a thousand miles begins with a single step, achieving the best resolution to business problems often begins with identifying the right software solution and the vendor that can provide that product.
Resolving the issue means placing a project under the direction of a project manager or, in some cases, a project management office (PMO). But does project management embrace that first step of finding the right vendor/partner? 
Vendor management to be part of the project management focus for businesses, asserts Frank Schettini, vice president of IT for the Project Management Institute. PMI’s Project Management Book of Knowledge discusses two primary points: actively managing vendor relationships, and imbedding project management throughout the whole vendor life cycle.
“It should be tied into how you do your vendor management,” he says. “Companies follow a formal process when they go through vendor selection. They get a cross-functional group, they come up with a weighted scoring system, they evaluate different vendors, and they select a vendor. Some of the challenges occur because the upfront project management hasn’t been defined when the contract is actually [awarded].”
Are insurance carriers better at doing project management for implementation than they are at doing project management for software selection?
George Grieve, CEO for CastleBay Consulting believes they are, and his reasoning is companies don’t take the software selection as seriously as they should.
(For more on George Grieve's views on vendor selection, click here and here.)
“They may have methodology and people who are good at running legacy replacement or implementation projects, but they don’t tend to apply that level of focus to the actual software selection process itself,” he says.
Software selection as part of the overall project plan is emphasized by Grieve to his insurance clients. “This is a project, and it needs a project plan, a project charter, and a project team,” he says. “It needs all of the structure a regular IT project has, but oftentimes carriers don’t give it the attention it should receive.”
This is one reason there has been a high level of failure in large replacement projects in the past, contends Grieve. “It’s often because the client has crippled the project by choosing an inappropriate vendor in the first place,” he says. “You can’t win at that point. It’s too late.”
So, why don’t insurance carriers identify this problem? Grieve maintains carriers don’t always recognize the complexity of working with legacy systems that are two- or three-decades-old.
“If legacy systems are 20- to 30-years-old, it means the carrier hasn’t gone to look for software or tried to replace software for 20 or 30 years,” he says. “What the company has done is work in maintenance mode on its software. So, now it is about to do something it has no practice at doing.”
Carriers need to think about the approach they are taking and how to organize it, Grieve advises, adding this is something carriers tend not to do.
ACUITY does not have a formal PMO, but much of the project management is done by those in the business consulting area run by vice president Laura Conklin. ACUITY prefers to build most of its own solutions, but Conklin points out there are situations where the carrier needs external suppliers to find the best resource and knowledge. “That’s when we look at how we can partner with a vendor,” she says.
ACUITY looks at vendors as another team member on its projects, indicates Conklin. “On project management teams, communication and accountability are vital,” she says. “We want to be sure we have a vendor that assigns to us its best resource—someone with the authority to make decisions and someone who has some accountability. We also work hard to have them understand us and what our criteria are.” 
Conklin feels it is important to explain to the vendor/partner what the expectations are as well as ACUITY’s timetable for deliverables the carrier is looking for. “Communication always is a key as is accountability on both sides,” she says. “We have to be clear about our expectations with the vendor, and it needs to be upfront with what is going on with us.”
ACUITY uses a timebox methodology as a means to offer deliverables every six to nine months during a project’s lifecycle. “When you get into large projects—sometimes multiyear—we are not going to disappear for three years and say then say, ‘ta-da,’ and here it is,” she says. “It’s more of how we can chunk up the project with interim deliverables to ensure success and ensure we are heading down the right path.”
Conklin doesn’t believe the approach is any different when ACUITY decides to build its own solution. “There needs to be more communication, and you have to lay out the expectations clearly,” she says. “That’s where communication becomes key as we constantly talk about what is going on.”
THE RIGHT STUFF
Software selection is just like any other project, notes Grieve. It starts with defining requirements. “What do you want the system to do?” he asks. “What kind of a vendor/partner do you want? Are you more interested in the software or the functionality? Are you more interested in a vendor/partner that offers other services, or do you just want software?”
After gathering its requirements, a carrier then has to go through the process of assessing vendors against a set of criteria the carrier has defined, and come up with a way of scoring them to determine which is most appropriate.
“Without that kind of project management discipline—defining the requirements and then finding the vendor to set the requirements—carriers tend to buy the shiniest toy or they buy something from the vendor that can sell the best,” says Grieve. “If they don’t have the discipline of defining what they want and how they are going to recognize it when they get it, they are in trouble. They may end up buying something that might be right, but if they are right, it is more by accident than by design.”
If a carrier is purchasing a product or a service that is either tangential to the organization or not directly tied into the enterprise architectures—and thus doesn’t require much integration—such formal processes may not be as important.
For example, Schettini reports PMI purchased a spam filter solution using a SaaS model that is supposed to be tied into e-mail. “From a project management perspective, all we do is make sure the installation happens properly and it is properly integrated with e-mail,” he says.
The other end of the spectrum occurs when a company builds solutions that have to be tied into other systems. “When you have those types of vendor relationships, you need a more integrated project management approach,” says Schettini.
Before negotiating a contract, Schettini suggests it is imperative that the parameters of which project management approach the company intends to take is factored in and is part of the evaluation, negotiation, and the signing-off process of vendor selection.
“If you are implementing [something such as] an ERP solution, the vendor may have a project management process it followed that has been successful,” says Schettini. “You may want to look at its project management processes and either leverage them or figure out how to tailor them and apply them to how you currently do business.”
Either way, Schettini insists those conversations need to happen upfront before the contract is signed. “You want a product that works but integrates with the rest of your enterprise and meets the cost and scheduling objectives you set for it,” he says.
Adopting a vendor’s project management skills depends on the maturity level of the vendor as well as your own organization, continues Schettini. Often, a simple conversation between company and vendor during the evaluation process can tell the company a great deal about the vendor it is about to do business with.
“The more mature the vendor’s processes, the more likely its project management processes will be followed,” says Schettini. “If it is a new vendor, you probably are going to want to adhere to your organization’s project management methodologies. In either case, you have to follow project management to make sure the vendor solution is effective.”
PART OF THE TEAM
Vendors have to be members of the project team, according to Conklin. Project leaders don’t necessarily come from the business units, though.
“The business units always are involved and always are champions of whatever project we are doing,” she says. “Without that, why would you even be doing the project, since ultimately you should be looking to fill a business need.”
The bottom line is ownership lies with the business unit, but Conklin views the project team as the conduit that makes sure success happens. “Politics shouldn’t play into this at all,” she says. “We are trying to fill a business need in the best way possible as an objective third party.”
In most of the implementations Grieve has dealt with, the carrier wants the vendor to be its partner. Typically, carriers organize the projects in such a way the carrier has a project director and the vendor has an equivalent person—what Grieve calls “two in a box.”
He maintains most companies have received the message that the best way to succeed with a vendor is to have a genuine partnership and share what both are trying to do. The good news is the two sides “tend to work more collegially with projects than they did 10 years ago,” he says.
One way to ensure the two sides work well together is by selecting a vendor that is focused on the vertical market. “It’s much easier to build a meaningful partnership than if you are dealing with a vendor that tends to be a horizontal market player that just happens to be in insurance,” says Grieve. “Insurance vendors seem to be easier to partner with than horizontal vendors. They live and die in the space, so they are more committed. It’s where they make their living just as it’s where the carrier makes its living. They are interested in knowing the problem they are trying to solve and being experts in that marketplace. The horizontal players usually tend to be bigger vendors. You are just another customer to them.”
Bringing the vendor into the carrier’s project management team depends on how much the carrier has to integrate solutions from an enterprise perspective and whether the transition points are documented and agreed to upfront as part of the initial contract.
“Many organizations have a project management methodology they have adopted based on our PMI standards, and that is how they have been successful in meeting their objectives,” says Schettini. “The vendor has to comply with that to make sure its solution is going to be successful. All those things should be spelled out upfront. If a vendor is going to sell a specific product, you have to make sure it integrates. If you are buying software that integrates with your core system, then you apply a more rigorous project management approach to it.”
The project structure Grieve feels is most appropriate is with the PMO as an administrative and service unit, not a leadership unit. “PMOs tend to be a support function,” he says. “They update the plans and do reports but in support of the project director who is making the decisions. The project director usually is responsible directly to the sponsors of the project—the key stakeholders. The project director can be an IT person or a business person. We’ve seen both work quite well. It depends on the caliber of the person.”
With ACUITY, projects involve true teamwork. If there’s a problem that’s identified, resources are brought in from the line of business to explain what’s going on. The business consulting people under Conklin do workflow and reengineering as well as specifications and testing for systems. Lastly, there are the IT people. 
“Sometimes you also have to bring in vendors—maybe for information that’s lacking or state-mandated requirements,” she says. “We might want to go to a vendor for that because we have to be sure we are compliant with all state mandates.”
GETTING BETTER AT PROJECTS
Project failure is becoming less common than it used to be, according to Grieve, although he admits his knowledge in that regard is strictly anecdotal. “It’s hard to get data on [failures],” he says. “Carriers aren’t about to say they screwed up.”
In the past, Grieve felt the failure rate on major legacy-type projects was somewhat higher than 50 percent. Although there are different degrees of failure, basically failure means the project stopped.
Today, though, Grieve estimates the number of failures is closer to 25 percent. One reason failure rates are lower is because carriers are better at selecting software and performing implementations.
But the biggest reason, adds Grieve, is the vendor community is better than it used to be. “The options for carriers are much more viable than they were 10 years ago and maybe even five years ago,” he says. “The new generation of vendors coming into the market is much better at building and implementing software than the legacy vendors.”
This also has forced the legacy vendors to keep up with the competition, he observes. “[Legacy vendors] had to get a lot better in order to stay relevant and continue to compete,” says Grieve. “The bar has been raised the last few years in our market space. So, if the vendors in general are better, the chances of choosing the wrong vendor are lower.”
TAKING THE PULSE
PMI conducts surveys regularly on the pulse of the industry, and its membership has indicated an organization that standardizes on project management and applies those standards is more likely to be successful in terms of being on time, on budget, and on schedule.
PMI also has learned that project management offices, which Schettini reports have been proliferating the last three or four years, play a significant role in ensuring standards are applied and the business objectives actually are being met.
A PMO may have different variations, adds Schettini. Some may include portfolio management, some may include management of the project managers, and some have a combination thereof.
“From a general perspective, the business units are responsible for meeting business objectives, and part of that includes projects,” says Schettini. “Some of us would argue pretty much everything you do is a project, and that’s something we’re seeing a lot of growth in as companies look at everything they do as being associated with some kind of a project.”
Schettini believes it’s important the PMO’s role is to make sure the project is delivered successfully, and that happens by applying the same standards and being consistent from one project to the next. “The business unit is the recipient of that [success],” he says. “It is the one that holds the PMO accountable for those successes.”
“We don’t work in silos,” says Conklin. “We are all working together as a team and trying to come up with a solution. We find we can be more responsive to changes that are needed. Sometimes with vendors, [the question is] where do you fit in their pecking order? Here we know we can do it well. We try to look for the same high standards we hold ourselves accountable to.” TD