I’ve been racking my brain lately on the topic proposed by the title of this post. From my first job experiences to current ones I find that software companies don’t seem to follow the disciplined logic illustrated in the image above.
The Software Vendor
As the diagram illustrates, the Client usually has a pretty solid strategy of their needs before reaching out to the Vendor. It stands to reason that the client may also be “shopping” or researching limitation and integration effort cases against a relatively precise (albeit usually small) collection of metrics. In these scenarios there is usually only a single point of contact, and the level of communication is usually in the form of support tickets and support calls. Rarely does the client reach out requesting custom solutions to their needs. From the point of the Vendor it is really as simple as…
This is our software, this is how it works… if it doesn’t fit your needs submit a feature request and if enough clients feel the need for it or if it is simple enough to do we’ll get to it eventually.
There is no allusion to propriety nor a need to maintain a first-name relationship with a client that is more than likely quite capable of extending the Vendor’s software to fit their needs. You don’t see companies like Microsoft® or Google® going out of their way to make feature changes to their software for single client (or even a small group of clients). The other side of the product is the development life-cycle; the actual work put into features and bug fixes. For products released by Vendors the standard execution of the SDLC is usually as simple as “can this feature/fix make the next scheduled release?”. If the answer is no, it is usually pushed to the next release effort (usually known as the “back-log”).
Now… this isn’t an exact representation of the the software development efforts of those monolithic companies, but close enough to where anyone that has been part of an iterative software release schedule would agree that this model is more-or-less that foundation of the effort workflow.
The Software Consultancy
Now for the software Consultant (or consultancy)… this methodology is bit more complex due to the amount of moving pieces usually involved in this. In the ideal world, there a single point of contact at the consultancy that manages the client’s needs and liaises the needs to the larger team; CEO, Sales, VPs, developers, etc., since the bandwidth of the consultancy is usually estimated at this point. The reality is that there are multiple points of contact and virtually limitless information to lend to the creation of strategies.
In this workflow, the Client is usually in need of a strategy and is seeking professional, informed business decisions. A strategy is usually built from this need, in contrast to the Client seeking a Vendor; in which case the Client should already have a solid strategy is simply seeking the best possible tool to make the strategy work.
This is the part that confuses me… Consultancies, on average, are regrettably bias and will aim to strategize their own products and partners versus better-suited solutions that will get the Client further along in their project in a more desirable time-frame. For instance, you’ll often find Consultants pushing their own internal tools when there are 3 others on the market that work far better but simply cannot be supported by the consultancy for one reason or another.
Honestly this wouldn’t even matter, because the Client isn’t even aware of these solutions; because if they were aware they wouldn’t be seeking a consultancy to create their project’s strategy.
This business relationship is usually regarded as favorable in contrast to the Vendor’s since it usually creates a strong partnership between the Consultancy and the Client firm. This will open up other channels of business with partners of the Client, and create a plethora of opportunities for the Consultancy… if the relationship remains amicable. These relationships can be anthropomorphic in nature as they can have the same dynamics a human-to-human relationship have. As such, these relationships can turn sour quickly in lieu of all the effort a Consultancy has given.
Consultancies usually have a fair number of resources to throw at any given project, giving the entity the ability to split efforts across multiple projects or push all the resources over to one project for given deadlines.
That brings us to the next huge difference between a Vendor and a Consultancy… “deadlines”! While I won’t pretend there is no such thing as deadlines in the world of the Vendor, they are far more flexible than a Consultancy’s. Deadlines to a Vendor are as simple as fulfilling a promise to their clientele as a whole, a deadline to Consultancy can make or break the relationship between the Client and the Consultancy.
In a Consultancy deadlines are also laden with policies, politics, and perception; with a fair measure of presumption to match. A Consultancy’s deadline is based off of the effort-hours the project requires, which are estimated by the developer(s) involved which are rarely given the full spectrum of research they need and then other powers in the project will do a over-generalized comparison of the project to a previous one and estimate the project’s deadline. These effort hours are then converted into raw work days (~8 hours per resource for every workday) then converted even further into a date based off of those estimates.
For instance 1 resource (developer) estimated a project at 83 hours; that means [remember this is imaginary math…] that the resource will have completed the project in approximately 2 weeks from the start-date.
However, Consultancies pride themselves on having multifaceted employees and the chances of that resource having strictly ONE project on their plate for the next 2 weeks is almost laughable. Other facets of that resources such as support efforts, time-tracking, meetings, random questions from other resources, even life are rarely factored in.
Confusion & Conclusion
My confusion in all this when I witness firms jump the gap between Vendor and Consultant due to being comfortable in one side of this diagram more than the other.
This is an impossible-to-please “everyone” dynamic. Either your clients or your employees will suffer for it. My advice towards firms that may feel this is directed at them… pick one and work towards making it the best version of your firm; you can’t please everyone and it is up to you to figure that out.
There are flaws in both but the product is what defines which side of the diagram is more successful.