As a consultant, it is important to take notes and record as much information as possible. You are the new guy to the company/project and usually, do not have the benefit of tribal knowledge. So it is critical you record and retain as much information as possible.

The challenge is to record the information in a manner that is conducive to fast access. Simply writing notes in your notebook (physical or electronic) is not enough.

There are many different ways to take notes. Many of these methods begin to fail when you enter the world of multiple clients and projects; your meetings are never linear. You meet with engineers one day, users the next, leadership another and the information is a mix of details and concepts. Regardless of your note-taking style, you probably have asked your self "What meeting did we discuss <topic>?" to help you find some bit of information.

Over the years, I have found that when I work multiple projects at once, it is helpful to create an electronic document for each of the projects on which I am working. I have used OneNote, Notability, Evernote and even created Word documents and this process works with all of them.

In the Meeting

Let me start off by saying I try not to attend meetings with my laptop unless I'm presenting. First, clicking away during a meeting is distracting. Secondly, the screen is a barrier between you and the others in the meeting; a wall which blocks you from personal interaction. Thirdly, far too many people are focused on their laptops doing other tasks and not actively participating in the meeting. Fourthly, (is fourthly a word?) I like to diagram the concepts I hear regardless of what is drawn on the whiteboard. My diagrams serve to solidify what I am hearing. I don't use the sketchnotes method per se, but I do get the benefits of visual note-taking.

The Moleskine classic softcover (7.5x10) plain notebooks work great for me because they have 190 pages, a pocket, are black (professional appearance), have great paper quality and a handy elastic band to keep it closed regardless of the papers crammed into it. This is my personal preference, but I highly recommend them for taking to meetings. Plain paper works for me because I like to draw and those lines on ruled paper are distracting. When I need lines to help me keep things neat, I have printed a grid on a separate sheet of paper I slip behind the page on which I am writing to give me guides.

Take notes however you wish. Whatever works for you is fine.

Daily Routine

Depending on the number of meetings I have that day, I will block off fifteen to thirty minutes out of that day to review my notes. This is where I take the notes from the notebook, review things in my head and type them into a project document. This daily review helps solidify the information in my memory and provides an opportunity to update my To-Do list.

During this review, I look for notes which do not make sense or generate other questions. I try to send off a quick email to get a clarification. This has saved my bacon more than once when a subject matter expert is hard to contact later. Asking a follow-up question the same day of the meeting is more likely to elicit a response.

While the meeting is still relatively fresh in my head, I can elaborate in my document in more detail than my notes might provide. If there was a discussion, my notes may be brief but my notes might trigger my memory to record more details than what is in my notes. This would be difficult to do days later.

Each project will have its own document. If you use OneNote, each client will have a notebook and each project will be its own section (Tab). If you use Word, then you will have a document per project and all the projects for a client in the same directory. Other note-taking programs will have their analogs. You can now zero-in on any project notes for any client.

Don't forget that any whiteboard sessions can be captured with your phone, and those images pasted into the document. Don't worry about cleaning up the photos or re-drawing them in an application. Only do that if it is necessary.

Some may skip this step and enter their notes directly into a document. While the choice is yours, I find reviewing the notes to be a valuable step in remembering the details, making sure action items are addressed and generating follow-up questions.

Formatting

It is important that the information from your hand-written notes be categorized so like information is grouped together for easy reference. I have found that when dealing with systems design, it helps me to create six basic sections. These start with high-level concepts and progress into more detailed sections. The top-level section is Contextual and deals with the lowest level of granularity. The following five sections I use progress in level of detail and granularity:

• Scope (Contextual) - This section is the big picture, the landscape for the organization. This is the lowest level of granularity.
• Business Model (Conceptual) - This is where many of the business concepts are recorded. These are course-grained details.
• System Model (Logical) - This is where you record different parts of the organization and how they interact with each other. This contains medium-grained details.
• Technology Model (Physical) - This is where implementation details are recorded. This contains fine-grained details.
• Detailed Specifications - This is where you will record detailed requirements and configuration specifications. This is usually the highest level of granularity.
• Operational Details - This is where details of how the system actually operates are recorded. This contains high-grained details of the operational system.

You can name the sections what you want, but I use industry standard labeling to ensure others understand the level of granularity of the information. It should be obvious to most in technology that Scope has less detail than the System Model and that Technical Details has more fine-grained information than the Busines Model.

Most of your notes will fall into one of the first four sections. The last two tend to catch the details of the system as it is implemented /used and normally have links to documentation artifacts created by the development teams training, operations, and users. When I hear of a document which might be of interest, I try to get the links to that document and place them in my notes. I then do not have to record all the information but have a link to the system of record. I try to validate the link when I review my notes and transfer them to the document.

It is not necessary to have all the sections filled out. What is important is the ability to find meeting information later when needed. Placing them in the above sections allows you to pull the jumble of information received in a meeting and record it in an "indexed" location.

The amount of information in each section depends on my role in the project. If I am working in the role of a developer, I will have far more in the Technology and Detailed Specifications sections than I would in the others. If I am working in the architect role, I will have loads more in the System Model. Here is a list of the six main sections and who generates or is interested in that level of information:

• Scope (Contextual) - Planners and Strategists
• Business Model (Conceptual) - Owners, Leadership
• System Model (Logical) - Designers, Architects
• Technology Model (Physical) - Engineering
• Detailed Specifications - Development Teams, Subcontractors
• Operational Details - Users, Operators.

Planners tend to have general details; the scope of the enterprise. The leadership of an organization tends to deal more with the conceptual aspects of the organization and its systems. The logical view of the systems tends to be maintained by the designers and architects. The technical leads and engineers have most of the information for the Technology Model section. The development team has the details in the Detailed Specification section and the operations staff has the operational details.

I try to complete as much of the layers above my layer of interest. If I am on the development team, I want as much information as possible in the Technology, System and Business models. It helps me make more informed decisions. This brings us to another benefit of this note-taking approach: knowing where to get information.

Taking It To The Next Level

Depending on my role in the project, I often come to a point where one section in the document is too large to find things easily. The sections themselves need to be categorized one level further. This is where we bring in the  5 Ws (Who, What, When, Where, Why) and their trusty side-kick "How" (a.k.a. 5W1H):

• People (who) – who are the people that run the business, what are the business units and their hierarchy?
• Data (what) – what is the business data, information or objects?
• Time (when) – when are the business processes performed, i.e., what are the business schedules and workflows?
• Network (where)– where are the businesses operations?
• Motivation (why) – why are the processes,  people or locations important to the business, i.e., what are the business drivers or business objectives?
• Function (how) – how does the business work, i.e., what are the business’ processes?

This gives me thirty-six (36) sections where my data can be located. It is now much easier to find any notes from any meeting because I can easily determine the level of granularity to give me the section and then the category of information.

By this time, some of you may recognize the Levels of Granularity combined with the 5W1H concept aligns with the Zachman Enterprise Framework. This framework is an ontology for creating, operating, and changing any object, in this case, the enterprise. All systems can be described by using this ontology and therefore all information about the system exists within the ontology. Simply, all information about an object (e.g. system) can be classified into any of the thirty-six cells of this ontology.

Each day, I go through my notes and record the details of the meeting in one of the six major sections, then, if there are too many details in a section, categorize the notes into six subsections. I now have very logically structured notes of the project and client which I can use to generate very detailed reports with only a little editing.

Too Much Work?

You will not have thirty-six sections in your document unless you are an enterprise architect responsible for all the systems in your organization. You are more likely to have a dozen or so sections with links to other, more official documents.

You may also not need anything quite this structured for your note-taking. I often have to work with many projects and many clients at one time and all my notes are scattered across many different pages. Having easy to retrieve information saves me far more work than reviewing and structuring my notes.

Even when I am dedicated to one project, I am often in many meetings with people at various levels and my notes tend to be categorized to the level of the attendees. When I meet with architects, the notes tend to be related to the logical (System Model) level. Transferring notes is relatively easy and involves little categorization.

There are times when having a structure allows me to take notes more efficiently. When I am in an inception meeting with leadership, users and engineers, the levels of granularity span all six sections. Having a plan for where to place the notes makes my notes easier to read later and therefore easier to review and transfer.

Even if you do not use manual notebooks and use an application like Notability or Evernote, having a plan makes recording notes easier; just go to that section and record your notes. Now your notes are easy to find, easy to read and be read by others. This is especially true in multi-day meetings, workshops, and discovery sessions.

You will have to judge for yourself if you need anything this structured and perform your own trade-off analysis.

Summary

When working with multiple projects, taking notes manually and later entering them into an electronic document is a good way to collect information from various sources at various levels of granularity and format and filter the information for later retrieval. Going over the notes helps with memory retention and making sure action items are recorded for follow-up.

Because this can create voluminous documents, it is a good idea to format the document into levels of granularity and to sub-categorize those levels into Who, What, When, Where, Why, and How (5W1H) when too much information is recorded in a single level.

The result is a collection of notes in which it is easy to find any bit of information. No searching through pages of hand-written notes is necessary to locate meeting information. Further, structuring the information makes ctrl-f more effective.

There is another benefit of having a document which is easy to transfer to other parties as it is logically formatted and easier to understand and use.

Too Long; Didn't Read

I take notes manually and enter them into an electronic document using the Zachman Framework as a formatting guide to make everything easier to find and report.