It has been almost 9 years since I started developing solutions in Microsoft technologies and it has been always a challenge when you have to suggest the right solution to the customer. A right & apt solution given to the customer is more than a business. On the contrast a wrong solution can ruin your career and so as your organization’s.
Today I am going to discuss very briefly on the important aspects that one has to consider before proposing the solution.
Presales
This is where everything starts and from now onwards its all the first impression set up takes all the way through the business between you and your organization. Remember that the guy who sits behind the telephone talking to a consumer on the other end of the world is not a low profile guy, neither you can afford to have a low profile guy sitting on that place. A sales guy can be categorized in to three.
There is somebody who can talk anything and pursue the customer with a little knowledge about technology. Well, he is definitely good for your business as he will ensure that the customer goes nowhere but you. But, on the longer run its not! Imagine a low tech profile has set the expectation of a solution development for $1 million which would actually cost $1.5 million. Well as per the sales person, he has done his job but when the solution gets into the build phase it will be a scary world of surprises for developers and the customer. I am sure that nobody likes too many of surprises.
The other version is a guy who has a better technology skills but less marketing. Since he is your front face and the first impression for the customer, he is little likely to attract and impress the customer who has lesser or void technical knowledge.
A balanced sales executive is hard to find but will definitely yield his / her share to the organization. It’s the old saying you should always keep in mind that “Know what you are selling before you try to sell that”.
Analyze
For some reason most service organizations and customers don’t love this step; both try to skip / reduce the amount of effort involved on this. Before you are even thinking of proposing the solution, you should analyze the business of the customer, what is the problem the customer trying to resolve and how much the does the solution mean to the customer. Get as much as information you can from the customer and never leave a place of assumptions being obvious when they can be filled with facts.
Revalidate the customer’s business against the problem he has mentioned and your analysis. You might feel that this is a unnecessary overhead when you are not doing a business analysis but just a solution building but, believe me this exercise is going to reduce the risks during the development process and also will avoid unwelcomed surprises. After all, consulting is all about putting the customer on the right track so that he can use his full potential.
As I always say “Put the right person in the right place”, always have the best team / person in the organization to analyze. If you ask me, I will have a team where I have a combination of best solution architect and the best domain expertise; thereby you always ensure that you are not missing anything from the solution and also the customer is not missing something from his end.
And yeah these are the investment as an organization you have to do before you even know that the customer will even hear to your solution, leave alone the contract signing. Yeah you have to do this if you want a hallmark quality on your brand.
High Level Design
This job is neither for a over confident newbie nor for a expired technical architect. It has always been the hardest part in finding an technical architect or solution architect who is on the top of technologies but you must be knowing that you can never run an organization without one.
A overconfident newbie who doesn’t have an experience of developing multi-domain and multi-technology applications, is tend to give solutions with a narrow vision on what he knows. And over confidence on the design phase is the biggest risk you would want to take. I love the architects / designers who are more pessimistic which allows them to turn 360? around the design and think for a while what might go wrong. If brakes are invented by a pessimist, then I would love to have more brakes in my design phase which will allow my developers to go on a highway with full throttle during the build phase.
On the other hand, technically yester year technical architect is tend to design a solution based on the technologies of his juvenile times. As we all know that if you are in a coma for single day, you are not up to date in the software business. Everyday, there is new solution / API / Framework / technique introduced which allows to make more sophisticated solutions in a much better way.
People say “Even the best wood cutter is useless if he doesn’t sharpen the axe.” but I would say “I need a wood cutter who knows the best axe or tool out in the market and if there isn’t any, better he makes one”. At the same time I don’t want anybody to reinvent the wheel.
For every architects there are few advice I would love to give.
- Never over engineer. Keep your solution simple.
- Try to make your solution more agile. Prepare your design for the worst change request you could think of.
- Experiment at your warehouse not on the customer. Remember that your customer is not a lab rat.
- Don’t use a technology / product for the heck of using it. This saves a lot of money and also allows you to concentrate on building the solution instead overcoming the technology / product overheads.
- Fit products to the requirements and not the vice versa. e.g.) because the customer is ready to pay, don’t sell him a SharePoint Server and try to fit the requirement into it. Its going to cause you more overhead and budget in the build phase and it will be your worst nightmare.
- Plan to reuse the frameworks available in the market. Don’t hesitate to consider frameworks like Enterprise Library, Entity Framework, etc. before planning to have your own.
Estimate
Phew, finally we are here! Leave your estimation task to a person who has designed to the solution along with the person who can sit and write code (if your solution architect is too old to write code anymore).
Few things you should always remember to include in the estimation.
- Accommodate the environment you work to the estimation. e.g.) if your team works on a remote / virtual machines, then your development estimate goes up by at least 10% due to slow response the machines are expected to give.
- Always count not more than 75% of productivity; no human being can put 100% productivity.
- Account the project management, meetings and few leisure times to the estimation.
- Remember estimation is not only on budget but also on time. If a bridge can be built by 100 workers in 100 days, then it doesn’t mean that it can be built on a single day by 10,000 workers.
“Buffer”; I know few hate this and most love it. Its always good to accommodate the buffer time without being explicitly mentioned. But always remember over estimation on the buffer is allowing your competitor to have a better chance and reducing it will reduce the insurance time / money you have for the project. Make it a good balance and always remember that “buffer” is also your customer’s money and his profit is yours!
Remember that the estimation you make at this phase is always a ball park and not the real estimate and ensure that you pass the same information to the customer. You will never know the best estimate unless you have the low level design done.
Now if you are proposing for a fixed bid, then do the last two steps (Analyze and High Level Design) again and again for at least 3 times, preferably by different connected teams. If your customer is not interested in the estimation at this phase (which will be very rare) then proceed with the solution proposal but, my advice is always to have a draft estimation which will give a heads up to both you and the customer on what you are getting into.
Propose Solutions
Yeah I know what you think “Hey dude, we give solutions the next minute my customer says the problem”. Believe me I would rather hear to my customer and get the maximum information I can, and then do my homework and get back to him with solutions. Unless you are a good listener, you could never run a business.
As I have mentioned its “solutions” and not solution; I am a strong believer that there is always more than one way out for any problem and so does your customer believe. Don’t decide the solution for the customer instead give him the choice to pick his. Every solution has its own pros and cons and its your duty that you draft them side by side and propose in the jargon what he understands; eliminate the technical terms to the most possible. This will advocate for you when your customer has solutions drafted from your competitors. Don’t urge the customer to pick his choice immediately, let him do his homework and come back to you on what he wants.
Over the course of job, I have seen lot of customers who say “Hey, I think you are the best to choose the right solution for us.”. Always remember that he has said that not because he doesn’t want to do it but it’s the trust he has on you. Now its your duty not to be a greedy farmer and choose the apt solution for him which will have a lesser overhead, longer run and cost effective.
Final Word
If your customer thinks that your solution is the best, there is no need for any affidavit to convince your customer that you can build the solution for him. But always remember that when you are in service industry you cannot afford being dishonest to your customer. There is always someone who can serve your customer better. When you have the right solution in hand, you have already won the bid.
Finally in service industry, its not what you can get for the customer, its what the customer needs.
I will continue to talk much about designing the solutions in the further articles.