How can a software company that makes and sells a development tool ensure that their early success, when they did their own consulting, can be reproduced as they grow and have third party consultants and internal IT people at their customers doing the implementations? This is something I've faced where I've worked before and I was wondering what to do when it comes up again.
Joel Spolsky has talked about a similar issue, why are small consulting firms often capable of doing better work than larger ones. The answer being, as I read it, that at large firms methodologies replace or constrict talent while small firms allow talented people to do good work. Unfortunately for a software firm that's going to want to rely on large consulting firms for implementation this answer is cold comfort.
What is it that makes early customer support efforts successful? I suppose I can identify a few obvious things.
Early on the close contact between the developers and the inhouse consultants means that the developers know how the package is being used and the consultants know which developer to go to for help. Also, at this stage the barriers preventing the consultants talking directly with the developers are likely to be lower so contact is easier. Aside from the practical help this provides I think the feeling of "community" between the developers and consultants provides the support that can be very useful when you're facing the customer trying to get stuff working that just isn't there.
Early on there are fewer consultants so each is likely to have seen a larger fraction of the total problem and solution space and they will know how to solve a larger fraction of the total problems. Inter consultant communication should also be better at this stage so that knowledge sharing is more effective.
As outside consultants are brought in how can the same success be continued, reproduced and extended? A couple of suggestions.
Some way to reduce consultant/implementor isolation and provide/encourage a sense of community among the consultants and between the consultants and developers. The use of internal newsgroups where implementors and developers can post and answer questions would help I think. It's been used fairly successfully by some companies. Perhaps even blogging could play a part by providing some regular update and "contact" between the people in the field and the developers.
For improved knowledge sharing I think that a patten approach to describing problems and solutions would work. These are loose enough to allow you to enter the information you have yet provide structure to help you think about the problem. The issue of coming up with a domain related or specific pattern language to make writing and reading the pattes/s easier and more fruitful is the topic of another post.Posted by Alex at February 24, 2002 09:40 PM