Visual Hierarchy - Order

Visual Hierarchy - Order

In my experience, good visual hierarchy is most important and most often missing element of project and business documents and plans. It could be because analytical people sometimes don’t have the design mentality to do it well, It could be because it takes a little extra time and effort to pull off, but I think a major reason it’s done so poorly so often is because it isn’t discussed, broken down, and practiced in team settings. To do my part in changing this trend, I’m compiling examples of good visual hierarchy.

Some elements of visual hierarchy that we will explore are:

  • Order
  • Impact
  • Arrangement
  • Grouping
  • Conditional Formatting

The ‘Fuzzy Eyes’ or ‘At a Glance’ test

If you were to look at the information without out of focus eyes or just glance at it for a moment, would you have the basic idea? Would you be able to explain what’s happening by that short view?


First Example - Order

Can you tell, at a glance, what number between 1-100 is missing?

My guess is no. In this example you have to start counting numbers and crossing them out before you find the one that's missing. 

How about this example. Can you tell what number between 1-100 is missing? 

My guess is you can in less than a second. In this example, we can see the gap visually first without having to identify or assess any numbers. Then, we can see that rigorous order has been applied so we know what number is missing after looking at any surrounding number.

Perspectives in Action

Perspectives in Action

Everything available to everyone is just as bad as nothing available to anyone. The power of an integrated system comes from serving individuals what they need to see & do, when they need to see & do it.

Every Individual

  • Daily task list.
  • Weekly/upcoming task list.
  • Owned risk triggers, issues, and decisions.
  • Link through to all assigned projects and reference material.

+ Project Manager - Owner of all assigned project documents. Visibility to individual task lists.

+ Program Manager - Visibility to all project and program documents, reports, roll ups, and dashboards.

+ Executive - Visibility to all roll ups and dashboards.

Vendors

  • Interactive report of all assigned tasks.
  • List of owned risk triggers, issues, and decisions.
  • Visibility to detailed project schedule.
  • Not able to link through to unrelated documentation.

Clients

  • Feedback Requests.
  • High Level Project Schedule.
  • Budget and resource burn down charts.
  • Not able to link through to other documents.

System Elements

System Elements

After researching who will be using the system and what they need to see, it’s time to review the ‘what’. That is, what are all the types of things that will be included?

Project Stuff

Strategy - At the highest level, everyone involved should be able to see the chief aim and the plan of action put in place to achieve it.

Programs - Programs are a series of projects that, together, advance strategy. Program level information should be viewable as a road map that shows current and planned projects, their status, and how they interact.

Projects - Project information shows stages and progress against the plan. The project level is where all documentation and resources are linked.

Work Packages - The efforts required to achieve a project deliverable are viewable as a work package. This is the lowest level of detail in most project plans.

Action Items - Individual steps required that, when complete, will complete a work package. A well defined action item should be completable by the assigned individual in one sitting.

Other Stuff

Reference Material - Any and all related reference material are be attached to the work packages in the project level. Ideally, the material is saved in an easily accessible collaborative platform (eg. Dropbox) so all documentation is searchable in one place.

Research Projects - The inputs, tasks, and results of research can be kept in their own workspace or as a work package in a project. Relevant data attached as background information to the relevant projects.

Issue & Decision Logs - Rolling list of issues and decisions about issues can be kept with owners and next actions assigned.

Risk Plans - The plan for managing risk is generally a piece of reference material while the actual risk register can be kept as an active list with trigger and next step owners assigned.

Meeting Agendas - The best way to run meetings are with a team-compiled list of action items and discussion points, curated by the project owner. If not done in system, an attached document also works.

Meeting Notes - As with agendas, meeting notes are best captured in system. Actively collaborative capture (eg. Google Doc) also works well.

Start with User Perspectives

Start with User Perspectives

Before getting into the mechanics and elements of an in-system strategic plan, we need to break out who this system is for and how everyone will be using it. Too often systems are set up with one user in mind without considering others. This can slow adoption and, in the end, wastes resources.

Here are some examples of who should be considered users, what they might be looking for, and how they might interact with the system. Make sure to make your own list and ask your own people what they need before starting a project.

Internal Users

  • Individual - What does each team member need to know and do each day to complete their assigned work.
  • Core Team Member - What project documentation is relevant to me. How do I know what to do next and if I am on track with my work.
  • Extended Team Member - How are all the projects going. What is my part in each project and do I know when to get involved.
  • Steering Committee - What is my role in keeping this project moving forward? What input do I need to have and where should it go?
  • Project Manager - Are we tracking to the plan? What does the risk landscape look like right now?
  • Program Manager - How are these projects working together? How do risks and delays in one project affect the others?

External Users

  • Vendors - What do I need to know about the projects elements that I own? What do I have to do to keep the project on track?
  • Clients - How is my project going? What does the team need from me to keep the project on track?

This may seem like too much information for one system to handle, but think about you collected and distribute this information today? It is likely contained in power point decks, project schedules, spreadsheets, or a variety of independent systems that don’t talk to each other. How people know what to do is probably communicated in meetings, phone calls, messages, and emails. Replacing these tools with a collaborative system will not replace those meetings, communications, and project data, but it can combine them all in one place and provide context for them so that all users can see the projects from any angle and figure out what they need to do next.

Personal Email Rules - Advanced Class

Personal Email Rules - Advanced Class

4. Advanced Class

  • Common Response Templates - When I reply to an email that I know I’ll have to reply similarly again, I save it as a draft so I can copy/paste next time.
  • Bookkeeping Tag - I tag emails that include receipts, bills, or other financial data for review when bookkeeping. I do bookkeeping one morning month and clear the bookkeeping tags to zero.
  • Google Inbox - If you're using gmail and can switch to Inbox, do it. It's weird, but good weird, not bad weird. Once you get used to it you won't go back.

 

5. One Ring to Rule Them All - Zapier

  • I set up Zapier so that any time I star an email in any inbox, that email turns into a task in Asana.
  • I also have Zapier complete a long list of other tasks but for email, all I need is to turn actionable emails into tasks in one click.

Personal Email Rules - The Basics

Personal Email Rules - The Basics

I didn’t plan on detailing how I deal with email. I figured that it's described well elsewhere. However, after discussing it with a friend, I realized that my email rules are a hybrid of several systems and may be different from any one elses. So, by special request, here is a complete list of my email rules for getting to zero, staying at zero, and some advanced level rules for the hardcore among us.

1. Triage - First time or Inbox over 1000 items.

  • Archive everything that is more than a month old. If it's important, they'll write again. I archive everything and rely on search. I don't file or tag manually, with minor exceptions.
  • If you are running out of storage space, learn how to search for large attachments, then delete or download/delete them.

2. Getting to Zero

  • Before opening my email, I review the rules.
  • Know all the keyboard shortcuts. Clicking is inefficient. 
  • When I open my email, I don't close it until inbox is at zero.
  • Start at the top and work all the way.
  • One touch per email. Deal with each one immediately. No going back.
  • If not actionable or reference, archive with no further action. (This constitutes the majority of messages)
  • Reference material - Drop to Evernote or archive and rely on search.
  • Actionable Quick - If it can be responded to immediately (less than 2 minutes, thanks GTD) do it right then.
  • Actionable Involved - Send to Asana action item list. (See Advanced Class)


3. Staying at Zero

  • When I open my email, I don't close it until inbox is at zero.
  • I block time to clear my inboxes. When the time is up, I archive everything that hasn't been addressed. This forces ruthlessly prioritization .
  • When a conversation is initiated in email and it should be in a workspace, I move the information to the workspace and address it there.

Advanced Class to follow. 

Sticking To vs. Adapting the Plan

Sticking To vs. Adapting the Plan

A common concern when presenting the concept of an in-system strategic plan is, how do we stick to the plan when the system is so flexible? Valid concern. A primary function of a good strategic plan is to provide guidance over time in a constantly changing environment. Therefore, if the plan can change as well, how do we maintain it’s integrity?

As usual, the problems and solutions are more about structure and process than the tools used.

When to Adapt

A good strategic plan (static document or in-system) should describe what elements are fixed and what elements are potentially adaptable. For example, a project could be absolutely required or, if the result could be obtained in a number of ways, it could be listed as the best option at the time but open for discussion later.

During periodic review of the plan, identify what should remain in place and what could be adapted. Identify triggers for this kind of review such as new research data, completion of a key project, or change in the competitive landscape. The existing plan may be weighted higher than a potential change, it would win a 50/50 coin toss, but don’t let the existing plan take precedence when the impact is clearly 70/30.

How to Adapt

The decision to adapt the plan has to be agreed on by the same representatives that made it. Once agreement has been reached, carefully review initial assumptions and document impacts the change may have to other components.

How to Document the Change

When the analysis is complete, save a snapshot and then make the required changes. Making the changes and communicating them from within the workspace is much more efficient than updating a document and then making the changes elsewhere.

In-System Strategic Plan - Examples

In-System Strategic Plan - Examples

In essence, any information documented in a strategic planning workshop or meeting should be considered baseline reference material. In a best case scenario, the data was good, the predictions were good, and you check it regularly to measure against the baseline and adjust. In a worst case scenario, the data was poor, the predictions were unfounded, and the document is useless the day after it was built. When the plan doesn’t match reality, you have to keep coming up with new short term targets and hope that if you hit them, somehow it will all work out in the end.

If the baseline information that comes out of a strategic planing workshop lives in the system you are operating from, the material can be easily built upon and refined.

Examples of what can be done when building an in-system plan…

  • Attach reference material to the actions that follow off of it.
  • When an unknown is defined, include next steps on learning more.
  • Assign early warning risk triggers to their owners.
  • Break down key metrics to their component daily tasks and assign them.

Examples of what can be done (and I do regularly) when executing…

  • Status update meetings don’t require building decks, manually compiling metrics, and comparing progress, it’s all included in the workspace.
  • Shifting priorities can be assessed and agreed to without digging through documentation.
  • Research data can be attached to research projects in the workspace, which can then feed next steps.
  • Competitive intelligence activities can exist in context with the collected results, analysis discussions, and next actions.

There is no practical limit to the what can be done in contemporary project management platforms when structured correctly. The only limits are the organization and communication skills of the teams putting them together.