Chapter 18

Select an Integration Partner


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.


If you’re not going to integrate your CMS in-house, then you’re going to need to hire someone to do it. This will be a shockingly important relationship for you over the next few years.

Wait… a few years?

No, it doesn’t take that long to launch a new website (usually…), but an important point is that 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, you need to pick carefully.

What Are You Looking For?

The first question you need to answer is what, specifically, you need an external firm to do. A wide array of services are available – it’s like a big menu or buffet. You need to narrow in on the set of services you need so you can figure out what the goal of an external relationship is going to be. In other words, what is your scope?

A website is like a three-legged stool. The biggest three components of it are:

  • Content: these are the words, images, and other media contained within the website. It includes both the content itself, and how it’s organized. It also includes functional aspects that provide value to the user (a mortgage calculator, for example).

  • Design: this is how the content is visually or experientially presented to the user, including the interface elements, layout, color palette, and user flow – how the user navigates through the content or otherwise interacts with it.

  • Technology: this is underlying technical details of the website – the content management system (CMS) or other technical platform which powers it.

Every website will have those three things, whether you like it or not.

There has to be some content or you don’t have a website. It has to have a design, even if it has none – call it a “austere aesthetic,” but even no design is a design. And it has to have some technical hosting platform (as we’ve discussed in the last few chapters), or it’s not getting delivered to anyone.

By this point, you should have some plan for what those three things need to be. The effort to execute that plan is your scope, meaning that is the total breadth of what needs to be done to deliver your website to the world.

The good news is that all of this stuff can be done for hire.

If we pull apart the tasks of a website project from start to finish, we find a lot of little subprojects that weave around each other.

  • 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 budget.

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. All you need to do is stayed relatively engaged, provide feedback, advocate for your vision, and reap the rewards when the site launches.

But this can get expensive. And like we mentioned above, you are delegating a lot of responsibility, power, and accountability to another company. You will have a deep, long-term working relationship with them.

Additionally, while there are companies that do all of the above, perhaps they’re not the company you want to hire for a particular aspect of it. Very often your situation can play out like this:

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 your service provider landscape, an absolutely critical question is: what does your post-launch environment look like?


  • Who is going to host the website?

  • Who is going to respond to problems?

  • Who is going to work on continued development and strategy?

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 you have your own development and creative teams? Are they under your organizational control? How hard will it be to get them to do something for you?

  • Will you have a budget to hire an external development or creative team? Is this just an allocated sum of money (a “slush fund”), or will you have to have 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 scenarios:

  • The company is branching out into a new service area. They need a new section of the website created in 30 days. It needs to have a unique design, and will have some specific functionality that will require programming. Also, there will be 10-20 new pages, totaling about 2,000 new words of content with associated media.

  • 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. They say the website was programmed wrong. Your phone rings, and caller ID says it’s the CEO…

What would you do in those two situations? Will you need external help with either one of them? Or can you marshal the talents of your internal marketing and development teams or call your own internal IT help desk?

Your answers to the questions above will very much 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 – is sometimes. But not as often as you think. And demanding industry experience can be counter-productive 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 for us. 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 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 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. But here are some points to investigate.

Note that no single point below (except maybe the very last one, as noted) is an absolute deal-breaker. Every company might have a couple bad answers to these. You need to take them all into consideration together.

General Fit

  • What is the normal type of project they work on? How closely does this match yours? There are lots of types of content management projects – 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.

  • How big are you and your project compared to them and their average project? Are you at the top range of what they do? Or are you far smaller than their average 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? What’s their total headcount? What’s their annual staff 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 will the project get invoiced? Is there a set payment schedule based on milestones, or do you just pay for accrued hours? Know that what the partner wants more than anything here is predictability. They’re looking for a way to know how much they can expect from you every month.


  • What is their development methodology? Dozens of different methodologies exist, and we defy you to accurately evaluate them. But you want to make sure they have some process. You don’t want Step 2 in their methodology to be “...and then a miracle occurs.” Listen to what they tell you and ask yourself if it sounds clear, reasonable, and repeatable, or if it sounds like they just made it up on the spot.

  • How will your project be staffed? 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.

  • What do they expect from you? 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.

  • How will communication be managed? Who is your point-of-contact on the partner side? 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.

  • Who will do the production work? Is the partner going to keep the work in-house, or are they sending it off-shore? I’m not indicting the off-shore approach, but investigate the model behind that. Is the off-shore team employed by the partner, or subcontracted? If the latter, is the partner taking absolute responsibility for their work?


  • How do you signal acceptance of a deliverable or milestone? Are you expected to formally sign-off on 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? What do they expect from you in terms of QA? 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? Who sits above your partner’s project manager? 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.


  • What is their normal scope of customer relationship? What happens after launch? Do they continue working with the customer, or do they hand them off? Neither option is wrong, but make sure that your expectation matches theirs.

  • How does follow-on work get handled? Do they want a retainer, or will they scope each project? Will you get some set amount of hours? How does that get scheduled among all their other clients? 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? If something breaks at 3 a.m., are they available to assist? 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? If something breaks one week after launch, will they fix it? What about one year after launch? 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? Do you have access to all the code they write for your project? Will you own everything if you part ways? 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.

Tougher Questions: Staffing and Schedule

The following questions are common, but understand that they’re often difficult for providers to answer with absolutely 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 start. 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 ironclad 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 get done? The only answer here can be given in relative terms, because this necessarily depends on when it starts. The provider might answer, “This is an 8-10 week project.” So, it’s done 8-10 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 change its course and cause the date to slip. This makes exact commitments tough and inadvisable.

We’re not saying you shouldn’t ask these things, but just be realistic about responses. You might not get the specificity that you’re looking for.


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 absolutely never 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.


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

  • “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.”

  • “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:

  1. Defining your requirements is a process in itself. It takes time, which you may not want to wait for. Additionally, whomever 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.

  2. 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 follow variables:

  1. How efficient are they? How long does it take to get something done?

  2. How good is the result of what they do? Do they have to fix stuff every time?

  3. Are they even doing the right things? Many times you’ll depend on your partner for advice. 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.

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. The outcome is a selected implementation partner, with a 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 say with certainty what you’re hiring someone to do.


The evaluation of a partner needs to be done by the entire 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.