I've been in several situations in which students would stop me in class and ask with stern faces: "How do you avoid analysis paralysis?" First time I heard that I sincerely replied: "How do you get to be paralyzed?" Indeed, there are many ways to avoid analysis paralysis-at least 5. The rest of this article assumes you're in the shoes of an analyst, with the mission to model some new topics that experts are explaining to you.

Perhaps a manually run business operation is to be automated. The analyst must first understand what the system has to do (analysis) before deciding how to automate it (design). Muscular paralysis comes from blocking the connection between the brain and muscles. Mental paralysis, the analogy used here, comes from either having no idea what to do or having too many options to choose. The following advice cures the no-idea case and gives priorities to help you determine where to start and how to continue.

Picture the subject matter experts throwing all kinds of elaborated concepts at you. They're the experts, yet you may see them stumble over fundamental definitions, use terms you can't relate to, contradict another expert, call-up a colleague to check on key concepts and so on. That would slow down and even freeze your analysis process, wouldn't it?

1.Deal with the best-known topics first

Identify a topic your experts seem to know best and model it right away. It doesn't have to be an easy one (half of the time it won't be). You know how to model and the experts know the topic. Here is your opportunity to make quick progress. Once you're done, go on with the next best-known topic, and so on.

Your tactic at that early stage is to channel everyone's energy to come to closure quickly on existing knowledge, knowledge that is readily available. This will bring you two immediate benefits: a) everyone will feel satisfied with the rapid progress; b) future discussions won't be cluttered with these topics.

While dealing with the best-known topics and concepts first, you might end up building a good chunk of your model. This will definitely prepare the ground for further modeling. Later on, additional and more-complex concepts might easily "plug-in" with the already modeled ones.

2.Locate the most knowledgeable person(s)

We've all been there: you work hard with a very well intentioned fellow trying to understand some deep topic, but somehow the more you analyze it the less you feel you can grasp it. After some considerable labor, he or she tells you: "I don't really know--after all, I'm not the expert! You can avoid this problem by looking for the experts prior to starting anything. Always ask: "Who's the top expert in this matter?" Spend time with the experts first. If they can't really afford to spend hours with you, invite them to join some of your short analysis sessions. Involve them by all means.

You'll find that real subject matter experts will make your project progress with giant leaps.

3.Use the marvels of natural language

The UML may be a great modeling language and you might be a champion at using it, yet you could experience a very slow start. Have the expert write one or a few paragraphs on the subject matter. For example, Paul is the man who truly understands retirement plans. It's a hairy subject. Don't start to model it straight from a first encounter with him. Have Paul write a few paragraphs ahead of time to summarize retirement plans. Then Paul and you can meet and model. In so many years of consulting and mentoring in the industry, I've almost never seen a true expert fail in writing his/her knowledge in plain English. Natural language has its unquestionable power.

Ask also that key words used in that text be defined in the glossary-still in plain English. With these two documents, the expert's knowledge will be clarified, you'll get a powerful start and you'll have a reference that you and the expert can use while modeling. I've tried it both ways: with or without a narrative to start with. I feel that modeling sessions are much faster if you start with a short narrative (I also call it a "problem statement" or "business synopsis"). They will enjoy seeing their terms appear in your UML diagrams and use case narratives. Remember, with UML you are structuring their expertise, not encrypting it.

Some people object that plain English is not that useful and certainly not as high-tech as the UML. They argue that tools like UML sequence diagrams could "get you there" much faster. It's a myth. Narratives expose the meaning; they build up fundamental understanding in the analyst's mind. That's the best place to start and it's quickly obtained. Note: In a future tech letter I'll write about object interactions, activity diagrams and business process modeling. I'll also write about the power of relationships as modeled in various UML diagrams.

4.Slice up concepts

Now, assuming you've got the right expert(s) to speak with and a narrative to start with, what's your next step? That's where your analysis activity really begins. Stick to the business concepts: what they mean, how they differ from each other, what type they belong to, what characteristics they exhibit, what they are made of and so on. Very importantly: how they relate with other concepts.

That part is like "dissection": slicing up the concepts. All the above angles, as you know, lead you to using fundamental UML constructs. Examples are: classes (or objects), attributes, inheritance, composition, associations and association classes.

In very little time your UML picture is built of various diagrams and you feel at home. Don't think you're done. You need to present the outcome of your analysis back to the experts, as advised in the next paragraph.

5.Assemble concepts back together

As you probably remember from our course, a model is only as good as its effectiveness in reflecting the reality. Experts took the time to work with you; they hope for more than a cryptic picture that you seem to be the only one to appreciate. You need to close the feedback loop.

Read the whole diagram back to them "in plain English", using their business terms. Examples would be: "Purchase orders refer to goods that are requested by manufacturing departments?" Do not say things like: "Here is the PO class that is associated with the Goods class, and it's a 1 to many association?"

Do not use any UML terms while describing your model back to the domain experts. They need to "hear" your model. Based on that, they'll tell you whether your understanding is right. They'll help you fix details and refine your model, based on your own reading of the model. After a few iterations your understanding will be raised to the expert's level.

Now, your model is ready. It's the blueprint for the whole project. It's a bridge between the expert's mind and the actual system that will be built to automate the business needs.

Before modeling, we always make sure that enough knowledge about the subject matter is available. If it's not, then we go get the experts. We model what is known. We postpone what's not known. We use natural languages to start with and also to conclude. What was said at the beginning of the analysis period will also be expressed at the end. In the process the model is built.

It's a very simple, systematic strategy based on common sense, based on human understanding. This very dynamic process moves you towards the goal. How could you possibly get stuck? There is no excuse for paralysis while doing analysis; that is nothing more than an old catch phrase.