The Analyst's Attitude
Before starting an analysis assignment, the following checkpoints are usually quite useful. Most of them deal with the situation the analyst is being asked to analyze, and the attitude of the analyst.
3 Encourage your stakeholders to start with an open mind
4 "If everyone just did what I told them to do, it would be so much simpler."
5 Mentally disassociate yourself from your ideas.
6 "We have always done it this way. Why should we do it differently?"
7 "It all ends up in the database anyway."
8 "I think they need a CRM system"
9 "You should use that vendor anyway. Everybody uses them."
10 "I am happy to argue, but remember, then I am being paid to argue."
11 "I can't explain it. It's a gut feeling. Just trust me on this."
12 Avoid idioms, jargon, acronyms, and ambigious words
1 Understand your charter
What kind of problem are you being asked to solve? Who has asked you to solve it? Have they given you a formal charter? Has the charter been explicitly phrased? Analysis through subterfuge rarely works in most organizations. If you are trying to start the analysis of a problem by packaging it as something else to your stakeholders, you will probably fail in the long run anyway.
Seeking an extensive charter that gives you carte blanche is usually quite difficult as well. The middle ground is that you obtain a charter to solve a specific problem from stakeholders who can actually implement your solution if required. If your stakeholders do not have the charter to implement solutions, try and involve individuals in the process who can as additional stakeholders. When starting a new initiative, it's also important to keep the number of stakeholders as low as possible.
2 Start with an open mind
Easier said than done. As an analyst, you may feel that you are approaching the situation with an open mind, but scrutinize your approach. A lot of analysts that work in hectic environments tend to perceive the ability to rapidly categorize a problem with very little input as their key skill-set. This approach is very suitable for trouble-shooting and support, but definitely very restrictive if you are tasked with designing a new system, or re-thinking an existing system. If you've already done one of the following, try and purge your mind of the preconception, and start again.
3 Encourage your stakeholders to start with an open mind
This is also easier said than done. In course of understanding the problem you are trying to solve, you will end up speaking to stakeholders and people working with or around the issue. It's human nature to want to solve things, and you can usually count on a lot of people having solutions or recommendations. The analyst's challenge in these circumstances is to first understand the problem independent of the solutions, and to be able to sift through solutions once the problem is clearly understood. Your stakeholders and people working with the issue have the advantage of possessing a good understanding of a business domain. Your challenge is to take on ideas for solutions as input, and pass them through the same framework of rationalization and scrutiny that you would apply to your own ideas. Usually the best ideas form as a synthesis of your own ideas and the ideas of the people working in the domain. At the same time, if the ideas were truly mature, they would probably have been adopted already, so make sure they pass through your structure of rationalization.
4 "If everyone just did what I told them to do, it would be so much simpler."
The best ideas are rarely realized by an individual, but by a group of people working together. An idea conceived in isolation rarely has the kind of scrutiny that a team can provide. At the same time, avoid "design by committee", popularized by the maxim "a camel is a horse designed by committee". Start off with a strong idea or proposal, and then take on the feedback and criticism you need to make it a fully working implementation of the idea. Above all, it is important to respect your stakeholders, the problem, and the people that explain the problem.
5 Mentally disassociate yourself from your ideas.
Once you've come up with what you think is a good idea, the need to see it working follows. Others may not share your perspective, and it will be a challenge to get your ideas implemented if they diverge from the existing ways of working. An important step to making sure a good idea is adopted is to make sure it isn't perceived as your own idea. A good way to do this is to put your idea on the table, and position your idea as a seed of thought rather than a complete idea. Encourage people to tear the idea apart, see what's missing, add to the idea, take things away from the idea, etc.
This is often easier said than done. If you've thought things through, and you've come up with a good idea, it is often difficult to disassociate the idea with your own ego. It is possible to become emotionally defensive about an idea or concept just because you have come up with it. A good practice is to pretend in your mind that someone else came up with the idea. This makes it easier to view your own ideas with a critical eye.
6 "We have always done it this way. Why should we do it differently?"
Manage resilience through rationale, and be prepared for concessions. There will probably be some form of resilience towards any new idea, but the fastest way to adoption is through making your stakeholders and audience feel that they also own the idea. Make it clear that you are interested in the optimal solution being adopted, and not having your own ideas being adopted. Your stakeholders and audience probably have lot of domain and organizational knowledge, and you can add a lot of value by using parallels from other domains and organizations, solutions from other industries, and existing solutions elsewhere that mirror the problem at hand.
7 "It all ends up in the database anyway."
Don't make any technical assumptions about the implementation of your solution. This is extremely restrictive, and severely limits the value of your analysis. Leave assumptions about systems design until you have completely understood the problem you are analyzing. All this is even more challenging if you have a technical background, and the primary analysis you do is of a technical nature. And for the record, no, not all things end up in the database.
8 "I think they need a CRM system"
If you have already decided what kind of system would solve the situation, why bother with the analysis? Labeling a situation without due analysis is unfair to the business and restrictive towards yourself. Typically, vendors that engage with analysis projects introduce a strong bias for their own systems. If you work for a software vendor, and you have asked to analyze a problem, try and do it with as much objectiveness as possible.
9 "You should use that vendor anyway. Everybody uses them."
That would make every business the same, with the same products, objectives, strategy, and business models. Try and be completely vendor neutral, and create analysis models that are do not make any vendor assumptions.
10 "I am happy to argue, but remember, then I am being paid to argue."
This is the worst form of disrespect to your audience. It's a line I've heard used quite often by analysts who have been hired as consultants. Interpreted, the analyst that uses this line is saying, "I can't defend my ideas. But as I am more expensive than you are as a resource, I know better." If you are unable to create a rationale for your ideas, and explain them to your audience without resorting to scare tactics, perhaps you shouldn't be an analyst.
Other variations:
"I've implemented the same solution in bigger companies that this. They didn't have a problem with it."
11 "I can't explain it. It's a gut feeling. Just trust me on this."
If you can't rationalize why a solution should be adopted, why certain feature is required, or why something is really necessary, the first thing you should do is to resist making the decision. Try and understand your personal motivations for the decision. Are you making the decision because of your personal value system or the organization' requirements? Does your gut feeling reflect what is best for the organization, or best for yourself? If you don't do this analysis, others will do it for you.
Before starting any analysis work, start by creating a rationalization structure. Try and understand the organization's value systems, and created a model for it that you and others can reference. Before making a decision, try and identify all of the options. If you select an option for a specific case, avoid making it the standard. As a simple example, let's say you are designing a user interface element for users to select multiple options. You can use a List, a Table , a Tree , or a drop-down. If you happen to select a Tree as it gives you the most options for the problem you are trying to solve, don't declare it as a standard, and start using it all over your application. Consider the alternatives, and select the best option.
To quote from Christopher Alexander's excellent book, "Notes on the synthesis of form" :
"The modern designer relies more and more on his position as an 'artist', on catchwords, personal idiom, and intuition - for all these relieve him of some of the burden of decision, and make his cognitive problems manageable. Driven on his own resources, unable to cope with the complicated information he is supposed to organize, he hides his incompetence in a frenzy of artistic individuality."
These were wise words when they were written in 1964. In an age where it is easier to introduce faddish behaviour into systems, where web agencies seem to have more "creative directors" than ever before, and where gaps between technology practioners and organizational leaders can grow very quickly, these words become even more important.
Other variations:
"I've implemented the same solution in bigger companies that this. They didn't have a problem with it."
12 Avoid idioms, jargon, acronyms, and ambigious words
Try and use terminology that is universally understood, or is used regularly within the business. Avoid using words that create ambiguity, such as "set", which has 46 possible definitions, or "context", which could, in context, be interpreted in any way. When specifying, use an active voice, using phrases that contain "will", "will not", "under these conditions, the system will ..." rather than "it may be possible", "it should not be possible", or "sometimes". Avoid the use of "weasel words". Avoid the use of acronyms that aren't universally understood. For instance, defining a request by a business stakeholder for a change in the system can be called a change request, request for change, RFC, ROC, or CR. Calling it a change request uses the least amount of words, but doesn't add ambiguity. Only use an acronym if everyone in the organization has a clear understanding of what it means.
