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.