When I was in the UK last week, I availed myself of the opportunity to catch-up with some friends in the industry. There were both product and delivery people in the crowd and we had a good time.
At some point, we hit the topic of Partners delivering software and how organizations should go about the process. We agreed on the right ways to use Partners and promptly celebrated with another round. As a rule of thumb, when that crowd agrees as a group, it is usually accepted knowledge. Even so, we all could readily recall multiple stories of people doing it poorly.
Software is Secondary
Working at Alfresco, this may seem like crazy talk, but bear with me a moment. The software you choose has to clear a certain hurdle in functionality to meet your requirements. There are many times Alfresco wins a deal where another product could also have met the requirements and vice versa. There are also situations where Alfresco isn’t a fit.
This is true with every software vendor.
For the first project, assuming you pick a vendor that doesn’t significantly mislead you, success isn’t going to be defined by the product you select. Success is going to be defined by the Partner you pick when you start that first project.
Implementation Partner is Critical
Picking the right Partner is critical. You can have the best software in the world but if the implementation is done poorly, the project will fail. What should you look for in a Partner?
- Domain Expertise: Do they understand the business problem that I am trying to solve? You don’t buy Alfresco simply to address Content Management. You buy it to store your Insurance content or manage your Correspondence process. Make sure that the needed domain expertise will be on the team.
Project Managers: A good project manager is mission critical. They don’t need experience with the specific technology or industry, but the product domain is critical. If I need a project manager for an Alfresco product, someone who has successfully managed Documentum or SharePoint projects will likely do well.- Product Expertise: There has to be strong technical expertise in the product. New people are okay, but depending on the size of the effort, there needs to be at least one full-time expert directing all technical efforts. This one is obvious but I’ve seen it overlooked.
- Meet the Team: If you can’t meet the individuals that will make-up the delivery team before signing, don’t do it. Bait-and-Switch is common in the industry. The partners that I routinely work with don’t do this.
- References: Check them. This is even more important for the Partner than the software company. The most important question is this: Will you use them again? Learn the details behind the answer, but the answer is critical.
Now that we know what to look for, when do you pick your Partner?
Choose Everything Together
The best piece of advice is this, pick the vendor and the Partner together. If you have a vendor coming to you saying that their product is the best, don’t spend a dime until you have a Partner to do the work. I’ve seen too much software gathering dust while a Partner was being selected.
In fact, ask the vendor to recommend a good Partner. It will help you gain a better understanding of the vendor’s Partner ecosystem. If they have trouble finding a good Partner, then that may be a sign of a weak ecosystem which could bode ill for the long-term.
Finally, I don’t care how “GOOD” your internal IT team is. For the first project, get experienced experts to do the work. You can, and should, hire someone, but you are better off with a Partner on that first project. You can hold them accountable for the result and there is a greater chance that a core mistake won’t be made that will haunt you for the life of the installation.
Word of Pie 
From what I see happening I widely agree with you about projects and how to chose software and partners. But that does not mean it is the best approach. This is especially true when partners are chosen offshore because they have low rates. If you have a 10.000 staff outsourcer claim that they have done projects with a particular software and they have references, how likely is it that the people you get actually have that expertize? With most outsourcers the ratio skilled to unskilled is 1:25. Thats why they are so cheap. It is not the cheap head that counts but what is INSIDE the head.
But am I missing something or is it totally impossible that the software vendor does the project? And how about the software being so simple that there isn’t a huge project necessary? And how about not using software that needs huge projects? And how about if you use the right software and still need to do a big project, could the project scope be wrong? And how about IT architects demanding technical compliance to some internal structures and that makes the project complex and not the software chosen? How about the vendor not needing domain expertize because the business should have the domain knowledge and not the IT people? How about the software installation being really easy and the business can be very strongly involved in actualy creating the solution they need and it does not need a huge project?
The worst projects are the ones where IT people have control and the business people are not spoken with and even intentionally kept out. When there are large projects with partners that is often the case because of the scope and cost issue. The price is fixed to the scope and therefore it is prohibited for anyone to talk to the business that would demand changes or actually define what they really need.
The success of the project does not lie in the completion of a project at time and cost, but purely in the actual adoption by the business and how much it enables them to do things better than they were before. Most IT driven projects and especially BPM and ECM ones usually really suck in that respect.
LikeLike
Truth: The success of the project does not lie in the completion of a project at time and cost, but purely in the actual adoption by the business
Max, in general, not hitting all those points in a single post as I want the thing simple and digestible. Yes, sometimes a vendor is the right choice. No, if it is a large scale deployment, you need outside guidance, even if it is one person. Scope can ALWAYS be wrong, in both directions.
Each answer could be its own blog post. If anyone wants to hear my thoughts on key points, the comments is the best place to let me know. 🙂
LikeLike
I wouldn’t rely on the vendor for a partner reference. Vendors may refer partners based on the partner’s sales not on their quality of development. I’m not denying they might be able to send in you in the right direction with a shortlist of partners. I am pointing out the risk of relying on the vendor who may need their partner to grow. Here’s a real example UNRELATED to a vendor I have worked for. Two different CMS vendors in Europe told me that if a partner sold a license they would refer X number of customers. Then there were also promises of preferential treatment. Now, I’m not sure all vendors do this and I’m sure it could boil down to who exactly you are talking to at vendor, what their growth strategy is for the partner network and how far they are from meeting their personal targets.
LikeLike
That is always a risk…but evaluating the Partner for the necessary business domain expertise and other areas still applies. I’d never take anyone vendor’s recommendation for a partner strictly at face value. It may be the right choice but people have to validate that Partner also has to be right for them.
LikeLike
What Max described as a cause for “worst projects” is one side of the story. When IT guys leave out business guys and assume requirements – sounds like a path to failure. However, I have seen (and unfortunately was part of) some projects where the business people tried to play roles of architects and drove the technical solution. I understand that for a business guy it is fairly easy to be carried away with “add this button here, add that control there” game, especially when his/her colleagues are present (e.g. workshops) and everyone tries to outsmart others by proposing “great” ideas and solutions. That’s why I could not agree more what Pie mentioned in his second point, a strong Project Management expertise in the team is one of the critical success factors for any IT project. Unfortunately, it is being neglected so often and is usually among the first things to go out of scope in the cost reduction process.
LikeLike
Zoran, being user and business focused must not mean to neglect good project management. And even if the project approach is Scrum or Agile, then there must always be for each milestone a clear target agreed with the stakeholders, so that there won’t be scope creep. Yes, business people decide by GUI only and they think that can’t be so hard. But if they are well informed and good agreements and compromises are made they will be much more willing to accept the result.
It should be the architecural skill of the IT department, the product skill of the vendor and the business skill of the business. That in collaboration produces the best result as long as the partners do not demand that their counterparts forgo some of their knowledge to be right. I therefore see little need for a partner unless the product(s) require substantial integration work.
Unfortuately too often there is no IT department left and there are different outsourcers running networks, HW, SW, PCs and operations. Add the interests of the project partner and the vendor and why should anyone be surprised that such a huge percentage of projects fail.
LikeLike