Working with External Integrators

When it comes time to actually start an implementation, who does it? The organization wanting the CMS can certainly do it themselves, but there also exists a vast network of professional integration firms. Some CMS vendors will also integrate their own CMSs for their customers. Which option is the right one?

Many organizations have no development staff, making the decision clear. Even if an organization does have internal development staff, they might still seek an integrator for several different reasons:

• Their development staff is too busy with other work, and they simply don’t have the capacity to do the work in-house.
• Their development staff is not focused on the Web; in many cases these resources are concentrated on internal, line-of-business applications, not what they view as a marketing exercise.
• Their development staff might do web development, but have no experience with this particular CMS.
• The reality of organizational politics and relationships often makes going outside the company more attractive. Marketing and IT have not normally been good bedfellows, and this often manifests itself as a search for an external integrator in an attempt to avoid IT restrictions or conflicts.

In these situations, contracting the CMS implementation can be a wise choice, through varying engagement models discussed in the following section.

Before considering a project, organizations should look at their internal resources and determine where they fit in. The result of that inventory will likely inform any decisions made about strategy, functionality, and system selection.

Engagement Models

There are a number of ways of working with an integrator, based on the distribution of work:

• Integrator develops: In this case, you simply write a check and get a website in return. In some cases, you might even contract with the integrator for hosting and support, which means you might not ever actually take possession of the implementation.
• Integrator and organization codevelop: In this situation, you and the integrator develop the website together, splitting the work through some agreed-on method.
• Organization develops, integrator consults: In situations where you want to do most of the work in-house, you might still engage with an integrator for expert consulting. During scheduled or ad hoc meetings, the integrator can review the current work, discuss upcoming challenges, and provide guidance for how to handle specific situations or challenges.
• Organization develops: Technically, there is no integrator in this situation, though occasionally the software will be sold through another party. Either you will purchase from the vendor, or the software will be resold through an integrator.

The range is single-party on the extremes – solely the integrator on one end, and solely your organization on the other – with varying shades of gray in between.

Of the two options in the middle, the codevelopment model is the most logistically challenging. Collaborating on the same codebase can often be difficult, especially between teams spread across two otherwise unrelated organizations. How do you split development? Along functional lines? Or does your organization want to be embedded in every decision?

Knowledge transfer incurs overhead. Some engagements quickly turn into long-term training relationships. Hopefully, this training is solely about the CMS, though in some cases integrators find themselves training on more fundamental questions of web development or development operations. Unfortunately, the need for this level of training is often not obvious until the project is underway.

Differences in experience between teams will quickly become apparent. An integrator might implement anywhere from 10 to 100 websites per year, whereas the average organization might reimplement their own website only once every three to five years.

These difficulties can be magnified when you consider deeper, subtler differences between a professional integrator and the typical organization:

• Motivations: The integrator might be paid by the hour, while salaries at an organization are sunk costs.
• Success metrics and time horizons: An organization has to live with the result, whereas the integrator typically disengages after the project is delivered.
• Competition for attention: The integrator’s clients have no affinity with each other – one client doesn’t care about the other clients’ projects, and is essentially competing with other clients for attention. By contrast, the employees at an organization are ostensibly working to advance a single mission and “client” – the organization itself.
• Project styles: Integrators are often more agile and iterative than larger organizations. Conversely, organization has the benefit of a more open-ended project – they can keep working to make an implementation better over time, while the integrator has to define a “hard” stopping point.
• Interpersonal skills and experience: An integrator works with many clients and organizational styles, while an organization might be more insular and more accustomed to vendors adapting to it.

CMS Vendor Professional Services

Many CMS vendors offer “professional services,” which are integration services for the CMSs they produce. For some vendors, this is simply a side business, meant to provide real-word exposure to their own products and to give customers an expert-services option to make a license purchase more attractive.

However, for other vendors, professional services represent a significant portion of their revenue. For a small subset, the CMS might even be sold at break-even or a loss and exist solely to position the vendor to sell integration services. For these vendors, a license sale without a professional services component might be viewed as a failure by the sales team.

The benefit of this arrangement is ostensibly that the vendors know their own systems better than anyone else and have unparalleled access to the product and technical teams. While this is undeniably true, the use of vendor professional services is polarizing for many in the industry – it can be viewed positively for the aforementioned reasons, or negatively due to problems of insularity.

The issue here is that when the only CMS a vendor works with is their own, the vendor might become insulated to other developments in the industry. More than once, I’ve observed vendor professional services teams that were unaware of developments and techniques in use by the broader CMS community. In these cases, a vendor might fall into the “my way or the highway” trap – they’ve always done task X this way, and their product is designed to do task X this way, so clearly this is the correct way to do task X.

Additionally, a vendor might be loath to admit their product has a shortcoming, and will therefore be resistant to helpful workarounds or external integrations. Whereas a third-party integrator might be willing to say, “This CMS is bad at task X, so we’re going to use hack Y to fix that,” a vendor typically won’t do this because that might raise the awkward question of why they don’t fix the underlying problem.

In the end, there are just as many arguments to use vendor professional services as there are not to. Vendors will often push professional services just as hard as they push their products, sometimes to the point of competing with other integrators that work with their products for the services business.

Sales and Scoping

Without question, the hardest problem for an integrator is defining the scope of the project. You and the vendor have to come to some agreement about the work that has to be done. This is harder than you might think.

You know what you want. Your website is already built in your heads. You have a vision of what the final product looks like. The integrator doesn’t share this vision. They can’t read your mind.

Furthermore, if you haven’t integrated this particular CMS before, you are very likely making assumptions about how it works. You assume that feature X works in some particular way, or perhaps you don’t know how it works, but you assume that for the amount of money you paid for the system, you should certainly be able to achieve result X through some method.

In Content Modeling, we defined the term reification, which is Latin for “to make real.” Projects are a constant process of reification – taking a vague idea or goal and making it real through the application of information structures.

Consider these statements:

• “We’re really failing at digital. We need to do better.”
• “Our customers are uninformed. We need to keep them updated.”
• “We need a database of technical notes that customers can subscribe to.”

These statements are a progressive reification. They’re a movement down a continuum toward a goal. Knowing that your organization is not doing well digitally is one thing. Defining exactly where you think you’re failing is better. Defining a potential solution is even better yet. The problem is slowly being reified over time.

Unfortunately, all these statements have something in common: none of them can be bid by an implementation firm. The last one is the only one with an actionable plan, but it’s still missing key information:

• What does a technical note look like?
• How many will there be?
• Who is authoring them?
• In what system will they be authored?
• How do they need to look?
• How do they need to be delivered?
• How does access need to be controlled?
• What does it mean to “subscribe” to the database?

I could go on – there are at least 50 questions that need to be answered here, and the answers to those questions would likely spark 100 more.

In many cases, these questions are assumptively answered by a common understanding of similar use cases with which both the organization and the integrator have experience. If the organization wants an RSS feed, this is something that’s been done many times before, and both the organization and the integrator have a fairly common understanding of it and a common vision of where to start.

Other needs are far more variable: message boards, calendars, profile systems, commenting, etc. These things have also been done before, but the range of functionality from one example to another is so vast that the “common” understanding between organization and integrator might not be nearly as common as one or both of them think – the organization may think feature X is obvious and should be included, but only because it was present in the one example they’ve seen.

Websites are simply highly variable things. There are patterns, certainly, but two descriptions of a problem could result in wildly different websites, just as the phrase “single-family dwelling” could result in wildly different houses being built.

Pre-implementation Artifacts

A key factor in trying to get a scope from an implementer is what you are bringing to the relationship. The integrator has to start from somewhere. What are you providing them with to guide their scoping process?

Consider these starting points:

• You have a vague idea of a shortcoming: “We need a new website.”
• You have an existing website that has a problem: “We don’t like the design,” or “Our CMS is too hard to use.”
• You have some narrative explaining what you want: “Here are the different sections we want the new website to have.”
• You have detailed analysis by a qualified consultant: “Here is a functional specification, annotated wireframes, and a sitemap.”

Of those, the last one is the only one that could conceivably be scoped and bid without further elaboration. The documents described – a functional specification, annotated wireframes, and a sitemap – are collectively referred to as “pre-implementation artifacts.” This is the plan from which a website can be scoped.

Just as you wouldn’t walk into a contractor’s office and say, “How much for a house?” you can’t really ask an integrator, “How much for a website?” The integrator will want a plan.

As we discussed in The CMS Implementation, the documents that most integrators need are:

• Functional specification: This is a narrative document explaining how the website should work. It should describe all content types and aggregations, users and groups, workflows and permissions, etc.
• Annotated wireframes: These are line drawings of how each interface should look. There should be at least one wireframe for each content type and aggregation, and there should be wireframes showing those at different responsive breakpoints (tablet, phone, etc.). Callouts should explain how specific functionality should work.
• Sitemap or IA diagram: This is the classic “boxes and arrows” diagram showing all the content on the website (or content groups; news articles in aggregate, for example). It should show logical and geographical relationships between content, and it should seek to be as comprehensive as possible.

This is the generally accepted minimum for a comprehensive, firm bid. A smart integrator, when presented with less than this, will seek to get to this point before providing you with a number.

If you don’t bring this information with you to the integrator, expect to be referred to another firm to develop the information, or expect the integrator to do it for you and charge you for it.

Perhaps even consider treating the development of this set of documentation as a separate project with the integrator. If you’re having trouble coming to a well-defined scope, the integrator can help you develop and document that scope as a self-contained project (perhaps even at a flat fee), then bid the resulting plan. Do not consider this an “extra” expense, since it has to be done at some point (remember, architects design houses for a reason). Breaking it off into its own project gives you the benefit of both a defined cost for it and more realistic and firm pricing for the larger project, due to better documentation.

With any project of moderate scope or larger, there will likely always be some level of misunderstanding between you and the integrator about scope. Experienced integrators know this and have planned for a certain amount of leeway in this respect. A shared goal is to limit these misunderstandings to the point where none of them have a material effect on the project.

Costs

In years past, the rule of thumb was that a CMS implementation will cost three to four times what the CMS itself cost. Thus, a CMS that cost $50,000 to purchase will cost between $150,000 and $200,000 to implement, making the total cost of the project roughly four to five times the cost of the software (or estimated equivalent expense for an open source system).

This is a crude measure and not universally applicable, but it’s valuable to at least frame how expensive implementations can be. They are almost always the majority cost in the total budget. Exhausting most of your budget on the CMS license will limit your ability to have it implemented, whether you do it internally or hire a third party.

In practice, content management implementations run the gamut from simple blogs that might work out of the box to incredibly complex content aggregation platforms that require massive development efforts. Consequently, there’s no simple way to generalize about budget scope. Some of the factors that go into a budget include:

• The number of content types required
• The number of content aggregations required and their complexity
• The number of unique templates required and their selection rules and criteria
• The complexity of the design, and the number of pages that require advanced page composition
• The level of content migration and transformation required to bring existing content into the new CMS
• The amount of integration required with systems external to the CMS and the level of risk that brings with it
• The amount of editorial workflow and customizations required to support the editorial process
• The amount of project coordination and project documentation required
• The number of “one-off” page designs, not seemingly related to any other design

These factors can be combined in almost unlimited degrees for a wide range of budgets.

Perhaps surprisingly, aside from migration QA effort, total volume of content doesn’t play as big a part in the budget or level of effort as you might think.

Consider a website with 100,000 content objects, all having the same content type, structure, and aggregation requirements. The implementing developer is really working with that content at the content type level, not the content object level. Even though there are 100,000 objects, there’s still only one type. It’s only a slight exaggeration to say that the developer cares very little if there are 100 objects or 100,000 – the level of effort required to create the types, aggregations, and editorial tools is largely the same.

This the same reason that “one-off” page designs can inflate the cost of an implementation. UX firms have been known to run wild, delivering detailed, individual designs for dozens and dozens of pages, each introducing a content management or templating idiosyncrasy for which the integrator will have to account. Remember that inconsistency is the bane of templating, and each unique page design comes with a price tag.

Even dynamic page composition has limits, because those systems work from a palette of available interface elements. Each of those elements has to be identified along with all of its variations, and then developed, templated, and managed in such a way that the page fits together the way the designer intended.

Finally, when budgeting, things that are unknown are what get an outsized allotment of time and funds. External integration is likely the best example. When your CMS has to work with Other System X, unless the implementation team has worked with both, the schedule and budget will suffer for it. Making two system work together can be difficult, or sometimes impossible. The effort required for even seemingly simple integrations can sometimes dwarf that expended on the remainder of the project.

Written Agreements

At some point, the agreement between you and the integrator will need to be codified and executed via some written instrument. This document is ostensibly the enforceable agreement for both parties.

Nomenclature is a problem here, because there’s no agreed-upon vocabulary for this industry, especially when it comes to project documentation. What one firm calls a “proposal” might be a “statement of work” or a “memorandum of understanding” to another .

In general, documentation falls into the following types. You’ll often see all three of these when working with an integrator:

• Marketing proposal: This is an attractive sales package meant to sell you on a firm’s capabilities. It might not speak to your project at all, or even your organization, but instead promotes the integrator’s capabilities in general terms. You might see this package one time, when your organization is initially being courted by the integrator. This is not an executable document (there is no signature line).
• General Services Agreement (GSA): This is a highly legal document spelling out things like warranties, required insurance coverage, intellectual property rules, etc. GSAs are usually drafted and reviewed by attorneys. There will likely not be a mention of a specific project, as these documents are usually meant to govern the life of the entire relationship between the integrator and the organization. These are executable documents, and often the subject of significant negotiation and revision. These documents are also known as “Master Services Agreements” or “Master Vendor Agreements.”
• Statement of Work (SOW): This is the project-specific document that explains exactly what the integrator is doing for this specific project. If you do more than one project with an integrator, you will likely have one SOW for each project. As the title implies, a Statement of Work is an explanation of the details around a specific unit of work. This is an executable document. The SOW is sometimes referred as a “proposal” or a “project proposal.”

When it comes to the General Services Agreement, a key question is: which side generates it? The integrator no doubt has one of their own, but there’s a good chance your organization has one as well. Do you execute both? What if they conflict? Do you need to review both and come to a third, resolved version? For many compliance departments in larger organizations, this isn’t acceptable as they want their GSA executed, specifically.

Many times, the side with the most lawyers wins. The integrator will submit their GSA for execution, and the client will return it with so many changes that the integrator decides it’s easier to review the organization’s GSA and just ensure nothing in it is objectionable.

When negotiating a project, there’s often an unspoken vibe as to which organization is going to require the more stringent documentation. That organization usually gets their document executed, even if it doesn’t differ remarkably from the other side’s version. So long as both parties agree to the contents, who “owned” the document in the beginning is of little import.

The Statement of Work is important enough to require its own section for discussion.

The Statement of Work

The Statement of Work is the guiding document for any particular project. If there is a disagreement about some aspect of a project, the SOW is usually the arbitrating document. If something isn’t in the SOW, then it doesn’t legally exist.

At a minimum, the SOW needs to explain:

1. What is being done
2. When it is being done
3. How much will it cost

What, when, and how much. Those are the critical questions in any implementation.

What is being done?

The SOW has to clearly state the scope of the project. In many cases, the preimplementation artifacts discussed previously will be attached to this document and referenced as exhibits.

The scope in the SOW often says something to the effect of, “Integrator will develop a website to fulfill the functionality and requirements described in Exhibit A.” In other cases, the functionality will be described in the document itself, though this is more rare since the requirements can be lengthy.

The SOW should also state what form the deliverables should take. Is the integrator delivering the website as a set of files and a database backup for the organization to deploy? Or is the integrator actually deploying the website to a server somewhere? Are they hosting it?

In practice, there is a constant debate on the required depth of this documentation. To what level of detail does the website need to be described?

This is hard to quantify, for the simple reason that a website can always be described in more detail. No matter how specific you are, you can always be more specific, and what level of description is “good enough”?

The desire to describe every last aspect of a website can turn into a black hole of time lost, and it often drifts past simple scoping and into deeper consulting as technical questions get more detailed and are answered with more and more specificity. There’s only so much analysis an integrator will do without being paid, and there’s only so much time either side will wait before they need to get started.

Where to draw this line varies for every organization and integrator, and it’s often simply a level of comfort and trust. When both sides agree that the level of description is enough and they feel comfortable moving forward, they do. There are no hard and fast rules here.

When is it being done?

The Statement of Work needs to address dates in the following two ways:

• Start date: If an integrator can get started on a huge project instantly, it might be a good idea to ask why. Sometimes the integrator just happens to have a convenient hole in their schedule. In other cases, they may be overstaffed or not have enough business to sustain themselves.

• Project duration: Regardless of when it starts, how long will the project take? This shouldn’t be discussed in hours, because that’s generally a function of project cost (projects are almost always priced against some nominal hourly rate). Rather, you want to know actual calendar duration. From the start date, how many weeks will there be until launch?

It’s wise to be clear with the integrator whether your project is date-driven or quality and feature-driven. Do you have a desired launch date, and is this date set in stone? Should the integrator plan their development to hit a specific date no matter what, or should they plan on delivering the best final product possible, even if that means investing more time?

How much will it cost?

Clearly, you need to have some idea of your final cost, but determining this is rarely simple. Projects can be priced in several ways:

• Flat fee: You will get website X for $Y, full stop. Expect this on projects where you’ve defined your requirements clearly. If your requirements are vague and exploratory, the only way you’ll get a flat fee is with significant padding (or foolishness on the part of the integrator).

• Time and materials: The integrator will perform work for $X per hour or per day. The integrator should give you an estimate of total hours. If they don’t, then you’re simply agreeing to pay a certain hourly rate, open-ended.

• Fee capped: You will spend $X, and the integrator will get as much functionality done for that amount as possible.

Clearly, the first option is the most rigid and therefore the safest for both sides. With that option, both scope and cost are defined in the SOW. However, because this is so rigid, it leads to two other phenomena that we’ve discussed previously: a tendency for cost padding, and a need to excessively define the scope of work, often leading to delays.

The other two options are both more flexible. A time-and-materials project has the scope defined, but the cost is open-ended. The integrator will simply keep working by the hour until the job is done. This can be risky for the organization. A fee-capped project has a hard limit on expense, but no expectation of delivered functionality. The integrator could theoretically hit the cap with only 50% of the project finished.

In the end, deals are fundamentally negotiated around the assignment of risk. Both sides – the organization and the integrator – are trying to minimize their risk. Rigid deals are risky for the integrator, so they’re often padded to compensate (which implies a type of risk for the organization – the risk of overpayment). On the other hand, flexible deals are risky for the organization in that there’s no clear correlation between functionality and expense.

It’s entirely possible to pursue a hybrid approach. If 90% of your project is straightforward, consider a fixed fee for that portion of work. The 10% that’s exploratory and risky might be handled under different terms – time and materials or fee-capped. This method allows work to start quickly on the mainstream part of the project, instead of the entire project being delayed while details of the more complicated sections are labored over.

Regardless of deal structure, the payment terms and schedule need to be defined:

• When is payment due?
• Are payments tied to milestones?
• If it’s a time-and-materials project, how are hours recorded? Can they be audited?
• What are the terms of acceptance in order for the integrator to request payment?
• Is there a deposit required before work can begin?

Beware of large deposit requirements. On smaller, shorter projects and consulting engagements where there is no functioning deliverable, 50% is common. But on longer projects, a requirement to pay half up front may be indicative of an integrator who needs the money to fund current payroll and liabilities. Some professional services firms can be extended to the point where they need deposits in order to stay in business. This is clearly dangerous.

When discussing deal structure and payment terms, remind yourself that at some point, your Accounts Payable department will need to write a check to pay an invoice from the integrator. What information will they need to be able to do that?

Production

There’s a temptation to think that since you’re paying the integrator specifically for production, once the project is started, you’re hands-off. Resist this thought process. You have several critical things to keep track of during production.

Team Proximity and Dedication

What will your relationship with the project team be? While it’s common to work with a remote team, other firms might work on a staff augmentation model, where the developers come to your site and work in-house.

This is getting rarer, and is almost always unnecessary, but some organizations require it. Some organizations have such stringent security requirements that access is controlled down to geographic locations (this is quite common in banking and finance). In other cases, the code might have to interact closely with other parts of the organization’s infrastructure that are only available on their network.

Define your proximity to the team. If they are coming on-site, do you have the physical accommodations for them? More than one project has gotten off to an awkward start because no one thought to ask where the project team would sit while they’re in the building.

Additionally, to what extent is the production team dedicated to your project specifically? Are you employing them full time, or are you sharing them with other clients? Can you expect that they will always be working on your project?

Unless specifically stated, assume that the production team is working on more than just your project. As such, you usually can’t micromanage their work schedule or their process.

Development and Testing Infrastructure

Where will the work in progress be located, and what will your access be to it? Developers commonly work on their local workstations and deploy code at regular intervals to an integration environment. Who controls this environment? Will it be on your infrastructure, or on a server controlled by the integrator?

Where will the source code be stored? It’s quite common for an integrator to store source code in their own environment, but at what times are they required to turn it over to you? Additionally, what level of visibility do you have into the source code management system? Can you inspect it at any time?

How do you record issues? During development, you might bring up a concern, only to be told it will be addressed later. How does this issue get tracked? Is there a ticket management system or a wiki where these items can be tracked so they don’t fall through the cracks? Unless your concerns are recorded somewhere, the likelihood of a production team remembering each of them and circling back proactively are quite small.

Project Communication and Check-in

You need to establish what level of communication you will have with the integrator’s production team, and what level of visibility you will have into the project.

It’s very common to have a scheduled project call with the project team to discuss the work in progress. Define the schedule for this call in advance. Weekly is common. If you have an extremely intensive project with a larger, dedicated team, perhaps a subset of the team might have a daily “standup” meeting to discuss progress. However, daily meetings are often unnecessary.

Remember that your project often won’t be the only project the developers are working on. Additionally, they might not work on your project every day. If they’re waiting on something, or had to fight a fire on another project, there’s a good chance that they simply won’t have done anything on your project that day. For this reason, daily meetings are usually too much. They’ll often be canceled because no one has anything to report, and when they’re canceled multiple days in a row is usually the time it becomes obvious that they were overkill to start with.

As with any meeting, be careful of inviting people who don’t need to be there. In some cases, having the development team in a design meeting is helpful, but only if you need their specific input. Having them on the phone “just in case” wastes their time, and you should expect to be charged for this.

You need to define your point of communication at the integrator. Will you have a dedicated project manager? If you have a concern, who do you contact, and how will this concern be escalated if you’re not satisfied with the result? What will be your level of ad hoc, unscheduled contact with the development team? Can you call a developer out of the blue? Will you have access to developers directly via email or instant message?

It’s common for integrators to limit direct access to developers. This isn’t to make things difficult, but just to limit interruptions, which can be deadly to productivity. You might think “Well, it’s just a quick question,” but when this happens with multiple clients, multiple times per day, it becomes a serious drain on progress .

Work Acceptance and QA

At some point, the integrator will invoice for the project, which is contingent (explicitly or implicitly) on the organization accepting the work product. What does this process look like? This can get closely intertwined with the methodology and development style the integration firm uses.

To describe what they do, many development teams throw around the term “agile.” This term only makes sense when looking at how software used to be built.

In years past, software development used what was informally known as a “waterfall” methodology. The development process proceeded down a serial line of tasks. Just like water can’t go back up and fall down a waterfall a second time, each task built on the first, moving slowly and steadily forward. The result was that the software product tended to not come together until the very end of the process. There might have been nothing to see until the project was almost complete.

The problem here should be obvious: with nothing to see, how do you know if the product is coming together well? A huge problem might be only identified upon testing the final product, and by then it’s too late to change anything.

In 2001, a group of software engineers released what they called http://agilemanifesto.org/principles.html["The Agile Manifesto,”] which was a declaration that the old methodology wasn’t working well. The manifesto has 12 principles, but the first one is key:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This is the key to agile software development: deliver early and often. Get something into the hands of the client as soon as possible, no matter how rough or stripped down, then collect feedback and iterate back through the process. Refine the product over time with the client’s feedback an integral part of the process.

The term “agile” is overused (and is often thrown around by developers too young to have even been exposed to a “non-agile” process), but it should be accepted as a standard practice. The key is for the integrator to avoid the “crawl into a cave” syndrome of building the website without you seeing it until immediately before launch.

In practical terms, you need to know how often you will be given the opportunity to inspect and pass judgment on the work product. There should be scheduled times during the project where parts of the final product are released for your inspection. These will usually coincide with invoicing. You will often be asked to inspect, approve, and officially accept the work product at these points.

Related to this, at what point do you officially “take possession” of the work product? This is likely related to the final disposition of the code. If it’s meant to be deployed to your environment, the integrator might state that this happens upon deployment, but it gets murkier when the code is to be hosted by the integrator themselves, or by a third party. At what moment do you state that the work product is acceptable and fulfills the agreement? This should be clearly defined in advance.

Define the level of QA you require in advance. Will you require the integrator to develop formal test scripts and provide you with results for each iteration, including regressions of prior tests? Or will you just take the integrator’s word that everything works fine? Do you want to see the code? Do you want line-level input on coding decisions? Different organizations require different levels of QA and documentation, and don’t let this be a surprise when it comes time to accept the work. If you have high expectations of formal QA, the integrator needs to know this so they can build that into their scope.

Content Development

It’s very likely that the implementation project will change your website in such a way that content changes will be required. Content will have to be reorganized, or new content will have to be created. And this doesn’t take into account all the content that will have to be migrated.

Who will make these changes or create this content? Are you paying the integrator for these changes? Are you paying another firm? Or do you need to make these changes yourself?

The scope of content development is often underestimated by the organization, and is consequently delayed. Many websites have been completed and have sat for months waiting for necessary content changes to happen. “We’ll launch as soon as we get the content in shape” is a common refrain.

Define what needs to be done on your side prior to launch, and dedicate staff and resources to this. Make sure the timing is clear. When does your content have to be complete, and what disposition should it be in? Can you input it directly into the developing website, or will you need to stage it in some neutral location such as Google Docs or a service specifically designed for this, such as http://gathercontent.com/[Gather Content]? More than one integrator has gotten an unexpected ZIP file of hundreds of Word documents right before launch with the note, “Here’s all our content. Let us know when it’s in the system!”

There’s a joke in this industry (and many others, I’m sure) that “this job would be great if not for the clients.” While clearly dark humor, understand that the biggest threat to your project might actually be you. Make sure you have your own bases covered during the implementation process.

Training and Support

As we discussed in The CMS Implementation, training and support can be tricky because the website is often a combination of a vendor’s software and an integrator’s implementation.

When planning training, determine who in your organization needs to get trained at what level. How many people need to know basic, foundational principles about the CMS software? On the other extreme, how many people need to know nothing more than what it takes to get the job done?

Most integrators won’t do the basic, fundamental training, for the reason that the vendors use training as a revenue stream. Vendors make money from training and would frown on integrators offering formalized training courses on their software as competition.

Most vendors offer training in one or more of several models:

• On-site: A trainer from the vendor travels to your organization, which is appropriate for training larger groups.
• Hosted: Your employees fly to the vendor’s location (either their actual location, or a remote location from which they’re offering training at a particular time); this is appropriate to train a smaller number of people than would justify flying a trainer in.
• Remote: The vendor runs a training class online, usually in real time, for a group of participants.

Unlike the basic training, implementation training is something only the integrator can provide. The most effective training is likely a mixture of both, though participants might have to be prepared to unlearn some vendor training principles when undergoing the implementation training (“I know they told you it worked like that, but this is how we actually implemented it…”).

Much like training, support becomes a jurisdictional issue between vendor and integrator. If problems arise, are they related to the software (vendor) or the implementation (integrator)?

A running website being actively managed also brings in the variables of the hosting environment and the editors themselves. There are dozens of combinations of variables that might be the source of any given problem.

There are four major types of support that an integrator may provide to an organization:

• Downtime support: In these situations, the site is significantly and obviously impaired for some reason that an editor cannot fix. Thankfully, critical software errors in mainstream CMS products are relatively rare. Most products are tested to such an extent that glaring, show-stopping bugs aren’t common. When such a problem does happen, it’s often infrastructure-related (the hard drive is full, DNS is broken, the database server stopped working, etc.).
• Error support: In these situations, a user has encountered an error that may or may not be public (it might only be visible to editors). The user is doing the task correctly, but something in the software has clearly failed. The editor cannot fix this problem and needs external assistance.
• User support: Sometimes there is no error, but the editor does not know how to accomplish a specific, defined task that she feels she should be able to complete. This is often due to a training deficiency.
• Consulting support: Again, there is no error in these cases, but the editor wants to accomplish a larger, more systemic goal, and doesn’t know the best way to do this. This is less support, and more advice. The editor needs to know the most optimal route to bring about some larger goal.

The last two types – user and consulting support – can get tricky because the lines between support, training, and consulting can be blurry. At what point is this less of a support issue and more of an consulting issue, where the integrator is being asked to explain foundational concepts of content management and web development, and assist the organization in planning out new functionality? By the same token, at what point is it obvious that some people just didn’t pay attention during training and the integrator is explaining the same thing for the tenth time? These conversations can get awkward.

Much like with the scoping process, there’s only so much an integrator will do without being paid. The line between what’s considered support and what’s considered consulting or additional, unscoped training can be tricky to navigate.

It’s becoming quite common in professional services to pursue retainer-style agreements where organizations pay a monthly fee for access to a development and consulting team as necessary. These are generally “use or lose” hours that allow ad hoc access to expert services but do not carry over between periods. Even if such support is not needed long-term, it’s still quite beneficial to have such access in the months immediately following launch, when most questions and issues are bound to arise.

A Final Word

While it would be ideal if the relationship between organization and integrator was perfectly business-like and free from interpersonal issues, this is never the case. The organization and the integrator (and, to a lesser extent, the vendor) will work together closely, usually for an extended period time. This relationship can stretch for years after launch in some cases.

In a relationship like this, human factors will come into play over time. Organizational politics can and will have an influence on the project. Development teams at the organization might be resentful of an external vendor coming in, marketing teams might have had bad experiences in the past, or an integrator might not be able to look past their perception of the organization’s unsophisticated thinking.

It’s crucial to establish a relationship of trust and communication between both parties. If you don’t feel like this exists, keep looking. A poor relationship at the beginning of the project often doesn’t improve, and barriers between teams can fester over years and have a devastating negative effect on the project over time.