Six Things You Want from Your Technology Vendors

Comments

Our Best Practice Exchange members tell us what their favourite salespeople do right.

We can all speak volumes about what high-tech salespeople do wrong. But in the spirit of vendor relationship building, we asked members of the Best Practice Exchange to tell us what their favourite salespeople do right. Specifically, we asked them to name what they want from IT vendors. Tear out this page and show it to those vendors who could use a little improvement.

Don’t rush me. Salespeople who push too hard will lose out in the long run. “A good salesperson needs to respect my time,” says Jim Sloane, VP of IT at flooring company Mannington Mills. “They shouldn’t try to push for a contract prematurely. They need to respect the fact that I have to consider alternative solutions.” Sherry Rubin, CIO of Philadelphia Gas Works, puts it another way: “Don’t assume a relationship with me before we really have one.”
Tell it to me straight. “I expect a top salesperson to talk to me about what business problem their technology will help me solve, why their solution is the best alternative and what the downsides to their solution are,” says Randy Krotowski, CIO of ChevronTexaco Latin America Products. “I don’t want any surprises later. I want the same kind of dialogue I’ll be having with my CEO when I go to discuss why the investment makes sense.”
Be creative. The salesman who breaks the mould will win the business. “Our best salespeople get creative,” says Tama Olver, VP and CIO of life sciences company Applera. “They have the ability to construct ‘win-win’ options and to create offerings that we did not think to request.” Remember, one size does not fit all.
If you don’t have it, don’t sell it. While the phrase “I don’t think we have what you need” is anathema to most high-tech salespeople, it might be one worth learning, say CIOs. As Bill Haser, CIO of Tenneco Automotive, advises, “Understand my business well enough not to waste my time with new products or features that will not add value in my environments.”
Look past your quarterly numbers. A valuable salesman needs to pay more attention to the long-term relationship with an organization, not Wall Street’s quarterly projections. As Steven Steinbrecher, retired CIO of Contra County, puts it, “I hate it when a sales rep comes in on the 20th of December and tells me: ‘Hey, if you buy this product by the end of the year, I can shave X dollars off the price.’ That person gets ushered out my door as soon as possible, never to get past my executive assistant again!”
Stick around. Selling high-priced IT solutions is not a hit-and-run proposition. The best in the business stay to manage the details after a sale has been made. “Good salespeople follow up after the deal is signed to make sure the administrative details are managed properly,” says the vice president of IT at a major industrial manufacturing company who wished to remain anonymous.

“Especially with telecom services, getting the contract and pricing terms implemented so that the rates actually show up on the bill is a major undertaking. Too often the salesperson gets the order and disappears.”

Planning and Staffing a Project Management Office

By Geoff Scott

Editor’s note: Back in November, The Exchange ran a brief piece where Jack Ott, VP of IT and CIO at Allianz Canada, gave some tips for setting up a project management office. Geoff Scott, manager, project management office, IT Services at Bayside Health in Victoria, sent me this feedback: “In general I have read lots about: the trend for establishing PMOs; why an organization should set up a PMO, and what benefits to expect. However, I have not seen much information dealing with the importance of scoping a PMO, how to determine scope, and how to staff it accordingly. So, in the spirit of The Exchange, Scott puts his expertise to the test.

Project management offices (PMOs) deliver a wide range of services that may be specific, broad, complex or a mix thereof. How these objectives are defined and delivered is further complicated by variables that encompass assignments, frequency, culture, project type, project size and skill-sets. The resulting combination makes a PMO difficult to scope and a challenge to successfully implement.

Nevertheless, the argument for creating a PMO is highly compelling. This is particularly true where the CIO has a portfolio of high-profile projects, multiple project managers, budgets and a resource team to manage. But it’s unnecessary to reprise here the need for a PMO, why organizations are starting PMOs or list the benefits derived, when there have been any number of published papers addressing these points.

What has not been realistically covered is the implementation approach, the planning and staffing a PMO. The planning process in this article will incorporate the range of service functions and project to ensure implementation success.

Before Getting Started

It is imperative to establish scope definition, using a prescriptive/real-world model against which the PMO will operate. Overall the project approach must follow basic project management concepts.

Generic Models. A number of research papers propose that planning include the envisaged PMO model based on a list of generic high-level descriptions. The problem here is that generic models do not provide sufficient scope and detail to cover the majority of requirements. To demonstrate, a research paper from Gartner (The Project Office, 2000) documents three generic model types:

Project repository — in this model, the project office serves as a source of information on project methodology and standards. Project managers continue to report to, and are funded by, their respective business areas.

Mentoring model — an extension of the repository, this model assumes a willingness to share some project management practices across business functions and uses the project office to coordinate the communication. Best practices are documented and shared, and project performance is monitored actively.

Enterprise project office — the most permanent, consolidated organizational model concentrates project management within the project office. In some cases, all project managers are actually staffed within the shared service and consigned to projects as needed. This model also assumes a governance process that involves the project office in all projects regardless of size, allowing it to assess scope, allocate resources, and verify time, budget, risk, and impact assumptions before the project is undertaken.

Each description lacks detail, and is very high level. At a minimum, a real-world solution is more likely to comprise a mix of the generic models plus a host of permutations — it will be substantially more complex. Moreover, a given PMO is as diverse as organizational styles.

Therefore to meet expectations the scope and implementation model has to be unique.

Staffing. The skill-sets and the number of staff to deliver the range of PMO services is inextricably tied to expectations and requirements. This also has to be identified and included in the scoping exercise.

In some models a resource may take on singular or multiple roles; roles may be temporary or last for the life of an individual project.

At the small end of the scale a basic PMO model may include a subject matter expert and a project coordinator. But as scope becomes increasingly diverse, and size and complexity grows, it is likely that additional expert resources have to be added, for example a relationship manager, a contract manager or project managers.

Tying It All Together

The goal is to assess and align the wide range of service functions and assignments with organizational culture, skill-sets and frequency of function/assignments.

Phase One — Requirements. Requirements gathering is simplified by completing the Service Functions, Assignment and Skill-Set Matrix (to download this form, go to: https://secure.idg.com.au/cio.doc).

The matrix presents a list of service functions with assignment sub-categories. Where an assignment is deemed applicable, you need to decide and mark whether it falls into the tracking, advisory or manage category, next comes frequency, and finally a skill-set match for performing the assignment.

Align with culture simply means looking at the data collected and deciding what will and won’t work within the organization. Assess requirements will eventuate in the first draft of requirements to fall out of data gathering and culture alignment.

Phase Two — Scope and Plan. In this phase the scope is agreed with the relevant stakeholders and documented accordingly. Using the agreed scope, a high-level implementation plan is produced showing approximate tasks, durations and resources.

Phase Three — Business Case. Relevant data from phases one and two is used to write the business case document. The document has two major purposes: to obtain approval and be the reference document for implementation in phase four.

Phase Four — Implement.This final phase uses the business case as its reference document. However, it is still necessary to finalize the implementation plan and deployment schedule, devise a training schedule, run training sessions and oversee change management.