Take a look at how we have planetary system.  Sun at the middle, planets revolving around it.  Like that there are many solar systems.

Now, in the microscopic world, lets look at the collection of smallest (well not actually the smallest, but really basic elements) components; the atoms.  Atoms have nucleus, and a collection of electrons that revolves around it.

Free electrons move between atoms, and if there is a current, electrons move in a particular direction; if we heat the material or send microwaves through it, the electrons vibrate and can dislodge other electrons.

Comets are free moving bodies in space.  there are many such free moving bodies in space.

Are we part of a bigger composite?

How does one influence customer loyalty through Solution Design? What does one need to keep in mind when designing solutions?

I have often wondered about limits to thinking on “solutions”, more so after having read, “The Glass Bead Game” by Herman Hesse.  Solutions to problems can be defined or derived from subjects that are diverse – not necessarily from the same domain.  When one observes adaptation of concepts from unrelated fields into designing of solutions, one calls it “Innovation”.   In that context, one may ask, where does the concept of Loyalty raise its head when we engage in active Innovation? (Active Innovation, amongst other things includes, the act of reserching trends and progress in varied fields to nail down anything that can be adapted to problems at hand).

When we talk about Loyalty, whom are we being loyal to?  How does it influence our chances if winning business?  Most importantly, how does this subject influence loyalty demonstrated by existing customers?

When we design innovative solutions, we are being loyal to our customers – we are delivering innovative ideas to solve their problems.  By delivering innovative ideas our customers remain loyal to our capabilities (that is what they need, that is what we need), and thus, the concept of loyalty plays a role across different dimensions.

One needs to keep this in mind when designing solutions.  Our loyalty is rewarded by Customer trust, and in the grand scheme of things, everyone gains.

Its no good saying that new systems have been designed to process XX trillion transactions over a calendar year or support peak load of YY zillion concurrent users; One has to take cognizance of the environmental impact of deploying such IT systems in a data centre, or within operating IT landscape.

We have gone through the phases where RFP requirements for vendors included a need to provide:

1. functionally compliant solutions
2. technically compliant solutions + 1.
3. operationally compliant solutions + 2.
4. …meeting certain cost pressures +3.
5. …demonstrate value adds (over and above specified requirements) +4
6. vendors to demonstrate cultural match (CSR etc.) + 5.
7. … what next?

…so…

1. What are the things that one should keep in mind?
2. Should there be a mandate from government to include “environmental impact” clauses in RFPs?
3. What would be the benchmark for such solutions?

…hmm.   food for thought.

…hmm.  I haven’t defined what I mean by a “blue bird” opportunity.  By the metaphor “Blue Bird”, I mean any opportunity that is deemed easy to sell, one that is usually very profitable, and something big.  Though colloquial usage of the term “Blue Bird” would connote something that is easy/achieved without significant effort, I refer to it with the following in mind – “something rare and something big”.

…so what is it that would help run and successfully conclude a pursuit that is rare and big?

This is probably a good juncture to link up concepts mentioned in my page on “What is Solution Design about?”.

How to spot a “Blue Bird” opportunity?

This question usually does not fall into the zone of concern for presales consultants – traditionally it relates more to a sales person.  However, in today’s climes (financial squeeze and matters relevant to today’s business/opportunities) drive a need for holistic understanding of the sales process not only by a sales person but also by supporting sub-organisations, such as technical teams and solution architects.

Solution Architects/ Presales Consultants, having responded to few RFPs, fall easily into the trap of omniscience – “I have all the answers, I only need to associate them with appropriate questions”.   This is the biggest hurdle for success.  This trap can derail any pursuit, even the most simple ones.

Since that is the case, the question remains, what should a presales consultant – responsible for solution design - look for to understand about hunting or spotting ”blue bird” opportunities?

If one goes to hunt for “blue birds”, what should one take? what are the top 5 things that should be available at hand to catch a “blue bird” opportunity?

Answers to the above will help prepare an answer to the second question:  How do we create “fertile grounds” for Innovation?

Have you heard about the “pike syndrome”?  (I will google it later to get an appropriate/suitable url to be linked here, for the moment, here’s a story)…

Pike is a freshwater / brackish water carnivorous fish.  In one experiment, a pike was placed in a glass aquarium, which had a glass partition dividing it.  The pike was kept on one side of the partition and small fish/minnows were kept on the other.  The pike subject itself to lot of pain from consistent bumping into the glass partition that was blocking its attempts to get to other fish before giving up.  When the partition was removed, the pike still did not make any attempt to capture the fish, it had given up completely.  This is called the ‘pike syndrome’.

What is its relevence here? Well, when we design solutions, we approach a problem with our accumulated experience, assumptions, and biases.  Sometimes we don’t realise the existence of biases latent in our solutions.  Scienctific principles are available to help us address challenges posed by this syndrome.  Challenging assumptions, adopting a structured approach to move away from the shackles of preconceived notions and enable creative thinking are some of the methods that have worked for me in the past.

As a corollary, on numerous occassions, I found that a solution, however unique it may appear in first instance, would have a lateral / parallel solution already existing for some other problem (similar and in the same field or in a completely disassociated field).

Building upon the learning structure for engineers as proposed by Boeing (J.H. McMasters and B.J. White) presented during a Boeing-University workshop that was focussed on discussing the role of industry in enhancing engineering education, one clearly sees the presence of science behind structured thinking and developing solution design skills.

The bottom line is, designing solutions requires combination of various skills, creativity, observation, social skills (team work), visual thinking, numeracy, literacy, craftmanship, basic sciences, etc.  Knowledge or ideas can come from anywhere, but only a disciplined approach backed by scientific rationale can help create a structure than enables implmentation of good ideas.

In IT, and specifically in the Application Solutions space, ‘Solutions’ are designed based on “Requirements”, or information detailed in an “RFP”.  In this blog, I will try to put together some of my thoughts on Solution Design.

While designing solutions, we often come across following thoughts/messages,

• “Why does this solution appear to be a mechanical ‘Copy and Paste’ from previous submissions?”
• “Why do we have a generic response?”
• “Why does this solution not appear to be customised for the prospect?”
• “It seems all that this solution team has is a hammer hence all problems look like to be a nail”
• “Lets see how we can change the requirement to fit our capability”
• “Can we influence the prospect’s thinking and get the cards set to our strengths?”

Questions that exist, and are often felt lurking in the recesses of peoples minds, but never asked are:

• Is Solution Design an Art? Or is it a Science?
• What are the types of skills required to become a Solution Architect?