Mind Maps – A Love Story

It’s a tacky title I know, but what is really tacky is that it’s true. Over the last few months I have used Mind Maps for such a wide variety of situations, that I thought it deserved its own blog post.

I have found Mind Maps to be an extremely versatile visualization technique, helping me capture and clarify information.  Through the presentation of disparate information objects on one screen, connections between those objects present themselves naturally. I have personally found it also promotes creative thinking.  Because the maps removes the notion of a list or paragraph of text, it instead encourages your brain to not only make connections, but also to think ahead, imagining new and different threads growing from the connected or unconnected objects.

Here are some examples of the scenarios when I have used Mind Maps.

Requirements meetings

This is a BA blog so requirements are the most natural place to start. I have used the Mind Map tool to capture notes in a meeting on requirements and have found it to be very effective. By creating a node for each requirement stemming from a central node of a theme or screen, the notes and comments build around the requirements nodes very naturally and you start to quickly see questions and dependencies between requirements.   Using the relationship arrows, references to previous points can be quickly made, and those relationships jump out at you because of the presentation style of your notes. Also little features such as adding Priority and Star icons let you markup your notes effectively so they can be efficiently acted upon later.

Brainstorming

This is the classic application of this tool. The quick way that nodes can be created, manipulated and connected is perfect for a session where you need to come up with a new idea or creatively work your way out of a situation or dead end. There is a throw-away and casual nature to recording information on a Mind Map.  It feels flexible and malleable, and more of a marker for further discussion. Noting down something on a list creates a more static representation of the information, and, to me anyway, constricts my thinking on topic.

Brainstorm
Brainstorm

Workflows – States & Transitions

This was a surprising application of the tool, and I cannot take credit for it either. A colleague was trying to get his head around the workflow and accompanying states and transitions for a touch screen Silverlight application our team had developed.  There was a bug and it could not be nailed down and we needed some way of seeing the steps on the UI and the behind the scenes associations to methodically track down the problem.   Using the mind map tool, combining the structure templates provided to arrive at a fluid and effective visual representation of the workflow.  It was a more “folksy” or ad-hoc approach to a formal UML activity diagram in Visio, but was immediately understandable and allowed everyone on the team to contribute to solving the problem, whether they are tech minded or not. Since then I have used the same method for a Site Map that also showed a fields and associations. I plan to write another blog post on the discussion this raised for me about when to use formal diagramming techniques vs. whatever technique transmits the information most effectively to the average person.

States & Transitions Mind Map
States & Transitions

Problem Solving

Finally, I have used mind maps to flesh out ideas or to start solving problems that are rattling around inside my head. One of my idiosyncrasies is that I am a verbal problem solver, by saying something out loud I start to understand the problem better and so more often than not arrive a solution at that very point of verbalizing.  But for those times when talking out loud is not possible, I have used mind maps as a way to quickly right down the key ideas and connect and move them around, and the results have been very similar.  It gets those problems out of my head and allows easy manipulation which often allows the answer to present itself.

So what mind map tool(s) are you using I hear you cry? Well just one has been enough, and the good news is it is free!  Check out XMind (http://www.xmind.net/).

You can also try these options listed in the Wikipedia entry on Mind Map Software.

Advertisements
Mind Maps – A Love Story

The Business Analyst and Knowledge Management

Rodin
Knowledge is valuable

I have read a few articles recently that have talked about the promotion potential of Business Analyst’s, particularly at Laura Brandenburg’s excellent http://www.bridging-the-gap.com.  What jobs are open to a BA? What skills do you have that can open new avenues?  I think this is a very valid discussion as the BA role can seem pretty flat in terms of long-term potential.  What is the career path? Senior Business Analyst? Super Senior Business Analyst?

There are typical answers to this, the most common being Project Manager, but that is one that I find distinctly unappealing.  I think being an Analyst means you are the type of person who likes to get in to the weeds of a project a little too much for you to transfer nicely to a PM role.  In a previous post I spoke about the cross-over between a BA and an Information Architect, and I still believe this is an open avenue, but this may be too “webby” or design focused a step for some people, as well as being a rare field, still growing and maturing and hence difficult to access.

As part of my Masters in Business & Information Technology at DePaul, I am taking a course in Knowledge Management, and it is fascinating.  It is such a fuzzy area and almost a non-subject according to some, however I see a lot of value in it.  It centers around not only how do we collate what we know in to knowledge bases but also how do we identify, stimulate and capture this information from experts within the organization.

Something that seems very clear to me is how a Business Analyst can significantly help in this area, if they have worked within an organization for a period of time.  Over the course of various projects, many interviews have been conducted, problem domains examined and modeled, and a sense of the organizations knowledge centers would have been subconsciously formed.  As the BA who is observing and objectively analyzing how information, data and processes flow within a company, they are essentially tracking the knowledge flow through a company, how it is formed and who are the creators, experts, team players etc. who contribute to it’s formation.

So when you are next creating an Activity Model, or interviewing key stakeholders for a new system, keep in mind that you are also tapping in to a key knowledge resource, that has a broader importance.  If there is a knowledge management initiative at your company you may then be able to leverage this information outside of the main project focus.  But if there isn’t a knowledge management initiative, then maybe this is a good way to propose one and perhaps land yourself with a Knowledge Management project.

Related posts on the Business Analyst career path:

http://www.bridging-the-gap.com/can-i-be-promoted-as-a-business-analyst/

http://www.bridging-the-gap.com/whats-next-what-do-i-do-after-im-done-being-a-business-analyst/

http://www.businessanalyst.com/advance-from-business-analyst-to-business-architect/

The Business Analyst and Knowledge Management

Case Study Part 2: Process Flow Diagram Analysis

The diagram was a challenge but I will persevere!

 Well it took me longer than a week to post the results of my process flow diagram experiment and for that I apologize. I will not bore you with excuses. 

A quick recap for those who did not read Part 1 of this Case Study.  I submitted a proposal to my boss to add a process walk through conversation with the customer during the project kick-off, 2-day discovery meeting.  This meeting is currently driven almost exclusively by a question and answer tool and resulted in a very stale and stunted meeting.  My aim was to engage the customer by asking them to tell the story of their current process, which I would capture using a swim lane type model I had developed, for delivery with the Business Requirements Document. 

The pilot overall went well, however it was a challenging meeting as the customer was not engaged in the process and had provided little documentation beforehand to help me lead the discussion.  But it did achieve some of the goals I had set for the experiment, which were: 

  • Provide a framework for a free-flowing discussion.
  • Elicit requirements that are missed by the basic question & answer format.
  • Allow the diagram to be constructed as the discussion took place.

The challenges I experienced were: 

  • The customer was small and the process being described, although with many parts, was all conducted by one person.  Therefore the customer found it difficult to talk through the process in a more abstract way, linking one section to another.  This highlighted that I had designed the process with a larger customer in mind and would need to tailor it to a small company setting.
  • Creating the diagram neatly, on the fly, was difficult.  The meeting was conducted in a restaurant and I had to do the diagram just with a pad and pen.  I had not prepared for this correctly, not knowing the setting of the meeting until we arrived, and needed a portable whiteboard, or just plain paper and a pencil would have been better.  I will certainly be more prepared next time. 

I will persevere with this method however and continue to work on refining it.  My boss is still certainly on board with the idea. 

Once again it demonstrates the power of iteration, and learning from your experiences.  I will do this again at the next meeting and I will now have these lessons learnt and will start from a stronger position.  I am striving to make sure I personally review my work  and learn from my mistakes.  An internal heuristic walk-through of my work output if you will.  I must embrace my mistakes and challenging experiences and see them as a valuable part of learning. 

Thanks again for reading!

Case Study Part 2: Process Flow Diagram Analysis

Case Study Part 1: Adding a process flow diagram to a Q & A driven requirements process

I recently suggested to my boss a way to incorporate a process flow diagram technique in to our requirements gathering process. She liked the idea and allowed me to run a pilot at my last requirements gathering meetings. This is Part one of two articles documenting my experience.

As an Implementation Consultant for a SaaS product, the big kick-off for each project is a 2-day meeting at the customer site. This is a requirements gathering session driven entirely by an online tool that ensures I ask all the critical questions so I can generate the Business Requirements Documents and have the product configured. This question & answer, tool driven process is part of a broader Six Sigma, repeatable and reliable implementation path that the company has invested heavily in over the recent past. This in turn generates lots of data points, measurable and reportable milestones which the QA team use as a stick to beat us lowly Implementation Consultants with when we don’t meet them 🙂

However I felt as though this drive towards fully quantifiable actions and processes had resulted in a very stale and un-engaging requirements meeting. The tool forced the meeting away from a qualitative semi-structured discussion, in to a repetitive question and answer session…for two days!!

  • Where was the consultative approach our implementation procedure and job title highlights?
  • Where was the business process analysis?
  • Where was the free-flowing discussion and use of more traditional BA methods of enquiry and elicitation?

My concerns at this particular issue possibly taps in to a broader problem of operational efficiency programs, such as Six Sigma, throttling fuzzy, qualitative procedures, but that was not my problem to address.  However I saw a great opportunity to include a visualization technique to capture the customers existing workflow that would be directly affected by the new software I am implementing. What I proposed was a business process diagram method, but what that would look like I had no idea at the time.

The key objectives were:

  1. It must be quick and simple to draw / develop in real-time in front of the customer.
  2. It must generate discussion and allow the customer to walk through the process, as it exists today, with no consideration for how it will change with the new software, or more in-depth technical considerations.
Process Flow Diagram Example
Process Flow Diagram Example

This is the example I developed after some online research (thanks to David Morris @GreySkinnedBoy on Twitter for pointing me to the BPMN) and showed to my boss. It builds on a swim lane type method although it will not conform to the linear timeline aspect normally the case with swim lane diagrams.

My hope is that this high level overview and story telling on the customer’s part will elicit requirements that would normally go undiscovered until later in the process. I also want to create a then and now document so the customer will know how the process will look at the end of the implementation, as well as a proposed process flow diagram if efficiency saving options are open following analysis after the meeting.

Overall I hope the introduction of a visual artifact will offer both value to the customer, improve the requirements gathering process and offer more opportunity for real value add consultative work.

Look out for Part 2 next week to see how the pilot went.

Case Study Part 1: Adding a process flow diagram to a Q & A driven requirements process