Solution Consultants : A Philosopher's Stone

Congratulations !!! If you are reading this blog, it means, you have already taken the decision to use software to solve your list of business issues. Most probably, by now, you must be inviting proposals or receiving them from prospective vendors for the same. If you are at this step or just before it, take a minute to read this blog. I assure you that you will start thinking more clearly after this. Or atleast, this blog will give you an argument to consider.

Some simple observations.

1. WHAT DRIVES THE DECISION

How does a business decide when to implement a software solution for its needs? 9 out of 10 times, it is the business users or the customers of a product/organization that drive it to take the decision to implement the software. This is, then, taken up with the CTO who drives the implementation. Sometimes the CTO becomes emphatic to the fact that the organization is doing too much of its work in the most favorite spreadsheet solution. The need for the software is born.

2. PROPOSALS FROM VENDORS

The CTOs, then, spread a word amongst their circle trying to look for vendors. They also contact re-engineering consultants who look for vendors in their circle. These vendors forward their proposals after understanding the detailed requirements and, if possible, arrange for a demo of the capabilities of their software tuned to the CTO's requirements. The word spreads around and more proposals start flowing in.

This is a traditional approach of getting software implemented. Pictorially, it can be depicted as below:

3. ISSUES AND INVOLVEMENT

The problem with this approach is that, the CTO and his team ends up spending a lot of time in this process. The pain doesn't end after finalizing the vendor. Once a vendor is selected, the CTO will now need a team on his end to follow up with the vendor from the requirement phase to the implementation and then onto support. You can see the involvement of the CTO's team's involvement from the picture shown below.

Enumerated, it will appear as:

1. Arrange and participate in the discussions to explain the requirements to the vendor (MOST IMPORTANT).
2. Initiate the development cycle and track the progress of the development (all the phases in the software development) eg. the Go-Design, Go-Develop, Go-Test, Go-UAT, etc.
3. Follow up with the vendor in case of any changes.
4. Raise software change requests, approve invoices, finalize effort estimates for changes and development, etc.
5. Create detailed test cases for the phase.
6. Test the software.
7. Post the software for the business users to test (UAT).
8. Production deployment.
9. Arrange for support vendor/team to manage support once the software goes live.

etc.

4. PHEW

Guys! The CTO does really work hard.

5. SOLUTION CONSULTANT

Here is where the Solution Consultant come in the picture. They are the people who do the chunk of the work for you. Think of them as the people who will do it for you or find someone who does it for you and then get it done. A CTO's true friend.

A solution consultant is the entity that gets hired the moment a CTO starts thinking of software implementation. The CTO is now, least bothered about who, how or what.

1. All that he/she knows is that a vendor has been finalized (of course, based on careful introspection only). The difference is that, now the CTO has access to a wider range of solution providers. Doing the market research and finding the best vendor is the job of the solution consultant. The CTO will now know that a vendor has been finalized and the grounds on which it was.
2. The solution consultant will then track the software development life cycle phases with the vendor. The responsibilities to finalizing the time estimates, approve the cost, technology decisions, etc. still lies with the CTO. But now the CTO doesn't have to sit and figure it out. The architect does that for him/her.
3. The change requests, bugs and their fixes, software licenses and agreements, etc. are kept track of, in detail.
4. The solution consultant worries about the implementation of the new software and its integration in the existing architecture after the implementation.
5. While the system is being deployed on the UAT, the solution consultant arranges for the test cases. The business users perform the UAT based on these test cases.
6. And much more...

6. WHO ARE THEY? WHERE DO I FIND THEM?

They can be absolutely anyone; either an organization that specializes in offering these services or individuals who do the same.

7. WHAT IS THE POINT, I AM TRYING TO MAKE?

All the CTOs out there, before you decide to implement a software solution yourself, explore this option. Whats the harm? What do you have to lose? You were going to work hard anyways ;). Get it done from someone else for a change.

[All the above view points are my perceptions based on a very fruitful career in software industry. I have seen Sales Directors, CTOs, CEOs, etc. actually throw money (not just out of choice but more out of compulsion as well) at anything that resembles what they need as a software implementation and the software companies actually milk them dry for this.

More often than not, the customer needs 'x' set of requirements. But in their search, the customer ends up with a vendor that has a product with 'x-y' set of features. The rest of the features are charged heavily as a customization

I, hence, decided to educate/warn the concerned about the ill effects of such an approach. This is my first (very first) blog on giving something back to the community. You can expect more.

Kindly provide me with your feedbacks.]