Chapter 18

Select an Integration Partner

Summary

In many projects, you will engage with a services firm to install, configure, and customize a CMS to deliver the website you need.

Does This Apply?

If you’re developing your website completely in-house with workers who are employed by your organization, then you can skip this chapter. But if you’re contracting any part of the project out, then this absolutely applies to you.

Narrative

Both the authors of this book worked at a small boutique web development firm for years. One of the hardest things to do at a small firm is hiring.

First, when you only have twenty employees, one single hire isn’t just a desk and a computer – it’s a full five percent of your workforce. Any one person is a big chunk of capacity.

Second, working at a small firm is intimate. There are no departments. The organizational chart is flatter than you might find at a multinational corporation. If something doesn’t work out and you need to part ways with an employee, it’s hard. You feel that.

So hiring decisions were protracted. We would interview for months to find someone to hire. Our standards were high, and we didn’t want to make a mistake. During any hiring cycle, the stress was palpable. You need to make a good decision about someone’s capacity to work with a team for years into the future. You don’t take it lightly.

Your web steering team or marketing department might not be a small boutique web development firm, but unless you have the capacity to implement your CMS completely in-house, you’re going to feel that same capacity and intimacy of a new hire. You’re going to need to hire someone – an implementation firm – who will work closely with your team, and that hire will represent a shockingly important relationship over the next few years.

Wait … a few years?

No, it doesn’t take that long to launch a new website (usually …), but a web project doesn’t end at launch – and there’s a good chance your web relationship, if it’s a good one, won’t end at launch either. Professional services relationships like these tend to last a long time. They’re not really “project constrained.” Very rarely will a contractor come in, do the job, and then just walk away.

Your project will give birth to a new digital property that will require care and feeding. And the integrator who planned, designed, built, migrated, and launched it will end up knowing more about it than anyone else. Including you.

This means that these relationships will linger. You will likely be involved with this other firm for several years. If the relationship ends early, it’s usually a sign that something went wrong.

Therefore, just like hiring for a small services firm, you need to pick carefully.

Episode 18: Select an Implementation Partner (w/ Tony Byrne)

Corey and Deane discuss what clients should look for when selecting an implementation partner. Then, Tony Byrne, co-author of The Right Way to Select Technology and President of Real Story Group, joins to talk through the implementation partner selection process, including common mistakes, the value of domain knowledge, and how most projects should focus on technology first.

40:23 | Tony Byrne

Past Episodes

What Are You Looking For?

The first question you need to answer is what, specifically, you need an external firm to help you with. You’ve already got an idea as to what your team can handle, so what we’ll focus on here is what you need to hire out – and how to select that firm.

The standard full-stack project is essentially made up of dozens of different, overlapping sub-projects — like a big menu or buffet:

  • A planning project to define audiences, outcomes, goals, and content
  • A User Experience (UX) project to wireframe the basic user interface (UI) and plan the users’ interaction with it
  • A design project to incorporate your branding and marketing collateral and apply them to the UX
  • A technical consulting project to plan how the required functionality will be delivered by a technology stack
  • A development project to configure a CMS and programming framework to deliver the required functionality
  • A migration project to move your current content from your old CMS to your new one
  • A content creation project to generate new text and media for content that didn’t exist before
  • An infrastructure consulting project to plan and set up the hosting environment and required technology
  • An ongoing support project to respond to and repair website problems
  • And, finally, an overall project management … project, to make sure all these pieces are coordinated, delivered on schedule, and within

Understand that you absolutely can contract the “full scope” of your website project to other firms and go completely hands-off. Thousands of companies are standing by, available to run the entire project for you. The pro to this approach is all you need to do is stay relatively engaged, provide feedback, advocate for your vision, and reap the rewards when the site launches.

The cons are that this is a bit more expensive, and you are delegating a lot of responsibility, power, and accountability to another company.

Instead, we often see a mix of partnerships. While there are companies that do all of the above, perhaps they’re not the company to hire for a particular aspect of it.

For example, let’s say you love the design work of a particular company, but they don’t work with the CMS you want. The CMS vendor has recommended a partner, but they don’t do migration work. And neither of them handle copywriting or content creation. Also, the integrator will host the site, but your internal IT policies require 24/7 network monitoring, and they don’t do that, but they know a company that specializes in this sort of thing … and so on.

If you can get everything in a single company and can afford the price tag, then good for you. But if you can’t, then you’ll need to find multiple companies, each providing a piece of the puzzle. And you’ll need to either ride herd over all of them as the general project manager, or structure the agreements so that smaller contractors work for some of the larger contractors who agree to be accountable for their performance.

A Key Question: What Does Your Post-Launch Staffing Look Like?

When considering the service provider landscape, it’s critical to think about your post-launch environment, meaning:

  • Who is going to host the website?
  • Who is going to respond to problems?
  • Who is going to work on continued development, strategy, and design?

We tend to look at launch day as the finish line, but it’s really the starting line. From this point forward, you need to care for and develop this thing you created.

Some questions to consider and get answered:

  • Will your organization control its own creative and development teams? How hard will it be to schedule updates?
  • Will you have a budget for an external development or creative team? Is this just an allocated sum of money (a “slush fund”), or will you require every piece of work individually scoped and approved?
  • Will you have a technical resource available to respond to website issues? What is their support coverage – 24/7, or only during business hours? If you can’t reach your primary contact, do you have an escalation path?
  • How many separate firms are going to be involved in support? Who is going to manage the interactions between them?
  • Are you technically competent enough to diagnose website issues and understand who is the correct provider to respond?

For further illustration, put yourself in these two somewhat opposite scenarios:

  • A large planned project: The company is branching out into a new service area. They need a new section of the website created in thirty days. It requires a unique design, specific new functionality, and ten to twenty new pages, totaling about 2,000 new words of content with associated media.
  • A critical emergency: The website is down. Every page is displaying an error about a “SQL timeout,” whatever that means. A developer you know says this is a server problem. But the hosting company says everything on their end is fine – that the website was programmed wrong. Your phone rings. It’s the CEO.

Can your team handle these situations? Or will you need external help with either one? Your answers will dictate your relationship with your providers after launch.

Does Industry Experience Matter?

This question comes up a lot. Everyone wants to hire someone who has worked in their industry before. You see the same questions on RFPs all the time: “What other projects have you completed in [insert industry here]?”

But is this relevant?

The answer – predictably, and probably frustratingly – is sometimes. It can help, but not as often as you think. In fact, demanding industry experience can be counterproductive and cause you to reject companies that might have done a lovely job for you.

The key question is: what aspects of a specific task would benefit from industry experience?

Let’s say we work for a regional bank, and we need to hire someone to do a full website rebuild. Let’s break down our project by the list of subprojects from above, examine each one, and consider if having completed similar projects in the banking industry would benefit this particular project.

  • Planning: Yes. A discovery project clearly benefits from a deep understanding of visitors and their needs. A strategist who has done this for your industry before has an existing reservoir of experience and data to work from.
  • UX: Maybe. A similar project might have some interaction patterns that are similar, and perhaps some functional elements that would appear often (financial calculators, for example).
  • Design: Probably not. Good design is good design. I suppose someone could claim to specialize in the colors and shapes that appeal to banking customers, but that seems pretty esoteric. And you’d probably end up with a website that looks like all your competitors’ websites. With design, fresh perspective often helps.
  • Technical Consulting: Maybe. There might be some technical aspects to a banking website that would appear again and again, but this seems like a small advantage. Any competent technical architect could probably adapt to this.
  • Development: Probably not. As above, there might be some technical challenges that cross over, but what’s far more important here is experience in the CMS platform. If there are specific industry angles to an aspect of the project, the issues would likely have been examined and translated into standard development tasks during technical consulting.
  • Migration: No. Content is basically content.
  • Content Creation: Yes. This is a core marketing function that is helped by industry and visitor experience.
  • Infrastructure Consulting: Not really. There are some industries that are more stringent about security, but “high security” is a general concept that any provider could be familiar with. Any differential benefit of experience would be limited.
  • Ongoing Support: No. Like development, it’s far more important that the provider understands the CMS and hosting environment.
  • Project Management: No. Web project management is basically the same across industries. Banks manage these projects the same way as everyone else.

As you look through that list, note that there are a few absolutes – some planning and content creation – and lots of waffling. When we waffle, we’re basically saying this: “Industry experience might be helpful here, but it shouldn’t be the only consideration and can be easily outweighed by other factors.”

In those situations, if you’re a little more comfortable with Company A than Company B, but Company B is claiming “industry experience!” then ask yourself if the benefit of their experience for the specific task they are doing for you matters enough to overcome your preference. For some disciplines, maybe it does. For others, it won’t, and you shouldn’t let industry experience act as a mirage that pulls you forward into a bad decision.

So … What Does Matter?

What you’re looking for with an implementation partner is broad-based, long-term compatibility. This means it’s hard to generalize since the right partner is specific to your project and your implementation.

While we can’t generalize, we can present the following Q&A of various vendor questions. Note that no single point (except maybe the very last one, as noted) should be an absolute deal-breaker. Each company will have a couple of less-than-ideal answers. You need to take them all into consideration.

General Fit

  • How closely does their typical project match yours? Content management projects come in all shapes and sizes – a body of technical documentation is not the same as a campaign microsite. Make sure they have at least some experience in the general type of content management you’re planning.
  • Where does your project fit in terms of size – are you at the top range of what they do, or are you far smaller than the typical project? Neither situation is great. You don’t want to be so big that you overwhelm them, but you also don’t want to be their smallest client, fighting for attention. You’re looking for somewhere in the upper-middle range – big enough to be important to them, but not so big they can’t handle you.
  • How much experience do they have with the specific CMS and technology stack you’re considering? There’s some chance you’re only talking to them because they know your CMS, which is great. But if this isn’t the case, you need to nail them down on their level of experience. A modern, enterprise CMS is complicated enough that you don’t want to be their first project with it.
  • How long have they been in business, and what’s their total headcount and turnover? You’re trying to gauge general stability, to make sure they’re going to stick around. You can also ask for financial statements, but don’t do this unless you actually intend to examine them. Would you even know which numbers signify what’s healthy or unhealthy?
  • How are projects invoiced, and is payment based on milestones or accrued hours? Know that, more than anything, this helps illustrate predictability — a way to know what to expect every month.

Production

  • What is their development methodology? Dozens of different methodologies exist. Simply put, make sure they have some process. You don’t want step two in their methodology to be “… and then a miracle occurs.” Ask yourself if it sounds clear, reasonable, and repeatable, or if it sounds like they just made it up on the spot.
  • Will you get a dedicated resource or team, or will you have a partial resource who is working on other things? The latter option isn’t necessarily wrong. At times your project won’t be in active development, or specific team members won’t have anything to do for you, so they’re obviously going to work on something else. But know where you stack up in someone’s daily responsibilities.
  • At what points in the project are you expected to do something? You need to figure this out in advance to manage your own staffing. You don’t want to be caught flat-footed, because having the project grind to a stop can be devastating, especially if it drags on so long that your partner re-tasks some of your production team.
  • Who is your point of contact on the partner side, and how much access do you have to the production team? Ideally, you want a single point of contact. But at the same time, you don’t want to be forcibly prevented from contacting the people doing the work. A direct conversation goes a long way sometimes.
  • Will the partner keep the work in-house, or are they sending it off-shore? We're not indicting the off-shore approach, but investigate the model behind that. Is the off-shore team employed by the partner or subcontracted, and will the partner take absolute responsibility for their work?

Quality

  • How do you signal acceptance of a deliverable or milestone? Will you agree in a meeting, or will you formally certify a deliverable? If you’re certifying a deliverable, know that you might be sacrificing your rights to complain about something later. If this is the case, then make sure you have some process to make absolutely sure that deliverable is ready to go.
  • What is the partner’s QA process, and what do they expect from you? Many different processes exist, so it’s hard to say one is better than another. Just evaluate their answer to make sure they have some process. If they look like a deer in headlights when you ask this, then plan on doing your own QA.
  • If you’re not happy, what is your escalation path? Ideally, you would rate at least a short conversation with someone at the C-level before you sign on. If something goes wrong, you need to know how you climb that tree and talk to someone who can take action.

Support

  • What is their normal scope of customer relationship, and what happens after launch? They may hand you off. They may continue working with you. Neither option is wrong, but make sure that your expectation matches theirs.
  • How does follow-on work get handled? They may want a retainer worth a set of hours, or they may scope each feature or project. What’s right here depends on how much work you expect to continue to do with them over time. If you’re going to have an active, ongoing relationship, seek some kind of standing retainer – you can often get a better deal on hours and priority scheduling.
  • To what extent are they available for support? Not a lot of shops offer 24/7 support. This usually comes from a hosting provider, but your hosting company might tell you that your implementation partner did something wrong. What happens then?
  • Do they offer a warranty, and how long is it? A warranty might be one week, or one month, or one year. Don’t expect the latter, because partners have to put some boundary around support, but just find out what that is.
  • What’s the intellectual property (IP) status of what they do for you? At Blend, we’re sticklers for making sure you can walk away when you want to. We absolutely will not advise you to engage with a company that would maintain any IP control over your project. Make sure that if you cut ties, you get everything you need to restart with someone else.

Staffing and Schedule

The following questions are common, but understand that they’re often difficult for providers to answer with absolute certainty.

  • Who is going to work on my project? Who the provider assigns to your project depends highly on schedule. They can’t just have a stable of people sitting around doing nothing waiting for your project to And aspects of your project that get defined midstream might change who staffs it. Clearly, you want to make sure you’re not getting “the B team,” but asking for iron-clad staffing commitments for a project that doesn’t even exist on their production calendar is only possible if you will be the largest project they have going and they’re willing to clear the calendar for you.
  • When will my project be finished? The only answer here can be given in relative terms, because this necessarily depends on when it starts and what the final scope of work looks like. The provider might answer, “This is an eight- to ten-week project.” So, it’s done eight to ten weeks after it starts, whenever that is. If they give you a date, and then you delay on making a decision, expect that date to slip. Additionally, like staffing, things might come up during the project that changes its course and cause the date to slip. This makes exact commitments tough and inadvisable.

References

Asking for references is a common thing, but the value is highly questionable. We find it hard to recommend it as a research method.

Here’s the thing: no one is going to refer you to someone who will give them a bad reference.

All the names you get will know in advance they’re being used as references. You’re not going to catch anyone off-guard or unprepared. The company might even kick them back something to the reference in exchange for the favor. Any reference given to you is probably not the first time they’ve done this.

The company you’re considering might have this down to a science. Every experienced company has a “stable” of references they can use when they need to. Larger companies might have someone in marketing who is formally responsible for cultivating, maintaining, and even coaching references.

We’re not saying to ignore references completely, but keep them in perspective. You’re not going to get a reference that tells you to run away. Most references will be overwhelmingly positive. If you’re lucky, you’ll get someone who gives you some honest candor and cracks the door on something south of perfection. Listen to those people.

Take everyone else with a grain of salt.

Pricing

The most important thing to understand with pricing is that it varies greatly in degrees of “firm-ness.” Consider these two extremes:

  1. “We will charge you $150/hour. We’ll just keep working on your cool idea until it’s done or until you run out of money.”
  2. “We will charge you $73,742.13 for exactly your requirements listed in this 183-page Word document that has 87 footnotes.”

Everyone is going to want the latter, because everyone loves specific numbers that are set in stone. But what they don’t understand is that when someone is trading you $X for Y result, then you need to be in absolute agreement on what Y is.

If you’ve nailed your requirements down clearly, so you can say with certainty that you have described exactly what you want, then you can expect a firm number in exchange. But there are two problems here:

  • Defining your requirements is a process in itself. It takes time, which you may not want to wait for. Additionally, whoever is doing it for you will probably want to get paid for it. They might do a simple statement of work for no charge to speed the project along, but they’re not going to deliver exact technical specifications unless someone pays them.
  • Even if you think you’ve nailed down your requirements, edge cases exist, and interpretations and misunderstandings come up, where one side genuinely believed one thing and the other side genuinely believed another thing. The only unassailable requirement is a running, implemented system that everyone can use and say, “Yes, this is what we want.” Sadly, you’re attempting to get a price to build this system, so it isn’t helpful.

The only practical advice here is to understand that the number you get will be roughly as firm as your requirements. If you’re vague on what you want, then they’ll be vague on how much it will cost. Expect either a wide cost range, lots of rigid assumptions on their side that you’re expected to agree with, or “escape” clauses that allow them to re-scope if things get complicated.

In reality, this is never perfect. You’ll come up with some firm-ish idea of what you want, and they’ll come up with some firm-ish number. For any large project, you’ll have a few disagreements about requirement scope, which is to be expected.

The ability for you to work through disagreements is directly proportional to the long-term relational upside for the partner. If they think they can have a long-term, profitable relationship with you, and you think you can work with them for an equally long time, then you’ll both usually meet in the middle or otherwise figure it out.

The Myth of the Hourly Rate

Lots of people will fixate on hourly rates, thinking that a lower hourly rate is better. This is a myth.

If someone consistently takes twice as long to do something as they should, then their hourly rate is effectively twice as much as they quoted.

To accurately gauge hourly rate, you need to account for the following variables:

  • How efficient are they? How long does it take to get something done?
  • How good is the result of what they do? Do they have to fix stuff every time?
  • Are they even doing the right things? Many times you’ll depend on your implementation partner for advise. Are they giving you good advice or wasting time on bad ideas?

These three variables can swing so widely between two contractors that it’s basically impossible to consider hourly rates in isolation. The best you can do is look back at a period of time, evaluate what was accomplished compared to what you paid, and ask yourself if you thought it was worth it.

A Team to Make Things Real

Finding a service provider is a tricky thing. You need to walk a line between competence, affordability, and culture fit. But for some projects, this is unquestionably the most important decision. It’s a foundation on which everything else will be built.

Your partner will directly impact your projects in countless ways. They’ll guide you on how to communicate to your audience, they might help you select technology platforms, they’ll have a large impact on the schedule of when things get done, and they’ll advise you on the most foundational of questions: what is possible, and what isn’t.

More than anything, the key is trust and rapport. Before making any decisions, ask yourself if you trust this firm with your project, and if they’re a group of people you want to work with for a long period of time.

There will absolutely be moments when problems come up and the relationship strains. If you have a basis of trust and connection with the other side, you have a much better chance of working through the issues and moving forward.

Inputs and Outputs

The input to this process is a site plan, much like the one you used when evaluating CMS vendors, that helps you understand the team you need to supplement. The outcome is a selected implementation partner, with an executed agreement.

The Big Picture

Clearly, you need this before the site development can start. But to get this, you need to know quite a few things about project scope – you can’t expect a price unless you know what you want done. So you need to be far enough along that you can confidently provide a scope of work.

Staffing

The evaluation of a partner needs to be done by the entire core project team, perhaps assisted by someone in legal or finance. There’s going to be a contract involved at some point, and that will need to be evaluated.

Resources

Articles