Part of my job when I was in SharePoint Marketing at Microsoft, and most of my job when I was a competitive/technical subject matter expert for Microsoft’s field account teams, involved helping map product capabilities to customer requirements. Frequently, that meant supplementing the out-of-the-box product with either (a) some customization work or with (b) the aid of a third-party add-on product.
Guess which of those two was often more readily received by salespeople (although not necessarily customers)? Customization. This is, in fact, how IBM sells software; they front all customer interactions in a service agreement, part of which involves the cost of the software but then depends on extensive consultant work.
Why the reluctance (some of the time) to consider third-party add-ons? Sometimes there’s an irrational fear that the third-party will try to control the sale; I can’t really speak to that, other than to say that independent software vendors usually don’t want that at all. What happens more often, I suspect, is plain ol’ sticker shock.
What I find troubling, and not just because I now work for Nintex, a company that creates third-party solutions for SharePoint technology, is that it’s rare that off-the-shelf third-party add-ons don’t save money…
Consider my company’s workflow product (since I know the pricing, etc.): the Enterprise Edition of Nintex Workflow costs (in the United States) $17,500 per SharePoint web front-end server.
Let’s assume you can find a SharePoint technology consultant for $200 an hour. That would mean that he/she has just two weeks and one day (87.5 hours) to build the same functionality. For one thing, that’s an extremely short consulting engagement. For another thing, the odds of being able to build something like Nintex Workflow in that amount of time approach zero. Even doubling it (let’s say you have a two-server deployment) still leaves you with one man-month and an extremely unlikely chance of approaching even a fraction of the product’s functionality.
As for why consulting sometimes feels better than add-on products, I invite discussion in the comments section. Similarly, if you think there isn’t such a tendency, I’d welcome that, too. Heck, if you agree and just want to vent, I’m all for that as well.
–Fitz
MikeFitz's Blog 
Your argument is interesting. If the solution was turn key then your value proposition would be dead on. But with workflow products the real work does not begin until the workflow engine is installed and configured. That is when you create something of business value. I am sure you already know this.
What I find is that we spend about the same in terms of consulting $$$ and aggravation even if we use a third party product to make things simpler. For example early in our SharePoint implementation we decided to purchase the Rad controls from Telerik. Looking at those we felt that they would save us a ton of time because they had functionality to meet some of our business requirements for content editing. Well 8 months into the project we now know that Telerik controls ended up saving us nothing because we still had to do quite a bit of configuration to get the control to look and behave the way we wanted too.
So perhaps people are gun shy because they have been burned too many times.
BTW your reporting product looks really interesting. Our company sees reporting KPI’s as the next big thing from SharePoint. What I mean is we are looking to the KPI’s to tell the business what ROI has been received from the hugh SharePoint investment.
First, let me state I tooooooooooootally agree. I’m with you. Nintex Workflow specifically saves a lot of time.
Now. I’m sure these will not come as a surprise to you, but let me assume they are. Here are the main problems with buying third-party products:
1. Friction in the buying process. This means everything from budgeting to getting AP to add you as a vendor to getting the license key to install the product.
2. Hassle of installing. I recently worked through installing a small, specific-vertical-targeted third-party add-on, and had to follow a deployment process I’ve named “Call Chuck.” Because there is no installer, the documentation is wrong, and the only hope you have of making progress is to call Chuck, the vendor. As a sort of representative example, it took three tries to make sure I had all the files I needed to install the product. First try was missing files, second try was missing files, ahh, third try: we got em! It’s always great to have demos to assure me you’re not one of ‘those ‘call Chuck’ vendors, but…the fear is there.
3. Upgradeability/escape plans/long-term plans – Microsoft is a huge company. is much smaller and is at a higher risk of exiting the market and stranding their customers. I don’t know what you can do to combat these fears, if anything. Demo a Nintex Workflow upgrade to vNext as soon as possible?
All this is just my experience. I’ve worked with other “Enterprisey” applications and they follow these same patterns. I think the SharePoint ecosystem scores well, better on all three points, than the other systems I’ve seen.
Hi Mike,
I also a agree but what Jeff is saying is spot on as well.. I guess it also depends on what type of functionality you are bringing in. Maybe the comparison was better if you used Nintex Reporting instead of Nintex Workflow, since building workflows require consulting and Nintex Workflow ‘only’ makes life easier in building and maintaining workflows.
As in the Reporting product there is not much need to do consulting to get the business requirements because they just want reports about their environment 😉
Hi Jeff/Peter
I completely understand your predictment with third party products being sometimes more hassel than they are worth. With Nintex though and as Robin stated ‘only’ Nintex the process of installing and configuring a workflow is a process that takes minutes literally. I say the hat goes off to the Nintex Guys… what a fab product. To be able to install and to demonstrate the business value to my boss in minutes gave instant gratification to my job. Sure beats me configuring workflows all day long, this makes me look good.
The advantage of the third party component to a custom one in a nutshell is that it was developed typically as a product and is deployed to many customers. So the cost is always (seriously, always in my experience) far lower than that of customization (as noted in your comparison).
That said I think what most people miss is that the Deployment Process and Installation Process has seen an incredible change over the past few years. Now the issues with installation and configuration of new (especially well made ones) on new platforms is extremely easy.
Let’s take Nintex and SharePoint, because SharePoint has a model for extensibility and that allows relatively easy deployment of new features, and solutions one of the biggest worries for customization over a third party component is considerably decreased.
The only real issue I see with a third party component is that it is difficult to extend upon (typically) from a deep down code level. But again if the third party (in this case Nintex) is built on a platform like SharePoint the SharePoint API is still the same, so it’s easy to extend upon.
Just my personal opinion. 🙂
For my work, we tried for a long time to avoid customization due to fear of maintainability. While I personally could manage and redeploy/extend functionality no one else in the organization is trained in how to do so. Due to user requirements over time we have had to do this, and because of this fear I have spent a lot of time documenting and scripting a lot of the basic processes so someone else can come in if I’m gone/unavailable for whatever reason and get something that works in a fairly short period of time.