My Visualization Tips – Keys to Creative Visualization in all Project Management Phases

Printer Friendly Version

In the last months, we have been writing about Visualization in projects on our blog. We have shared a few tips and our experience in making projects v i s u a l. We covered not only project data in the form of charts and diagrams, but also project relevant information such as requirements, expectations, and budgeting. We focused on using visualization to help avoiding misunderstandings, inefficient meetings and a demotivated project team.

In order to improve my visualization knowledge, I attended a workshop on this topic. I learned how to be creative and professional in team building meetings, project planning phase, or in holding a presentation.

The following visualization is the agenda for the workshop (Source: Visual Braindump): 

There are different ways to approach the different phases of a project – from a project initiation to project retrospective. For me it is important to keep it simple and yet informative.

Here are my personal learning on being or becoming visual.

1) Don’t be shy, be creative

Sometimes I don’t like to talk in front of other people or cannot explain in words what I expect on a project. Putting my ideas on paper writing and drawing my expectations during the project planning phase can help the project team to provoke a reaction and discuss the different topics. In the workshop, we did an exercise and learned that people remember what was discussed in a more effective way than the spoken words when it is associated with a visualization. We were also encouraged to make our own drawings and take our own pictures.

The comment “I cannot draw” is not applicable. The workshop also proved that everybody can draw.

The following picture is the result of drawing something based on our daily work/tasks using every letter of the alphabet:

2) Synthesize complex ideas and task by drawing them

As humans, we can transmit complex concepts using pictures. This is something robots cannot do. Those pictures can be interpreted by people with different cultures and backgrounds better than words. The capacity of synthetizing an idea, problem, task, or risk in form of an image using your own imagination, creativity and experience is endless. For sure, this will catch the attention of the whole team more than 1000s of words.

The following picture shows a roadmap for a beer brewery project:

3) Feel proud of what you do

It is not only the project manager and SCRUM master that leads the visualization process. Team members can contribute visualizations to the project to make themselves part of the decision-making process. I feel prouder of my work when I am part of the decision-making process, no matter how small or big my contribution is. In my experience, this contribution will increase the personal and professional involvement and the consequent success.

4) Be an active part of the Team – You are more than a role

Visual thinking is about communicating and expressing what I see, feel, think, and know, by drawing; like children do. Using visual thinking in every project phase – from team building to project retrospective makes the project alive. I learned that every task can be interpreted and thus visualized in a rational, emotional or practical way.

The following pictures show

  •  A ‘persona’ that shows a potential user

  • Different approaches -head (rational), heart (emotional), hand (practical) to different project aspects.

Free “Going Agile” ePub for PM / BigData /Analytic / BI survey input by 1-Oct

Printer Friendly Version

I am doing some research to investigate success from a project perspective of the different types of decision support projects and their contribution to organizational performance. Join the effort and get a free “Going Agile Project Management Practices Second Edition” ePub or Kindle book (worth 32 USD on amazon).

Project managers, agile coaches, project team members, and sponsors that participated in a big data, business intelligence, or analytics project since 2002 can to take the survey.

So far, people from 14 countries have contributed. Regards, Gloria

Building a Team with Collaborative Events

Printer Friendly Version

The agile coach has the responsibility to build the team into a self-organizing unit that can make its own decisions and resolve its own conflicts as well as collaborate as a team to deliver the product. Building a team is much more than building a working group. ‘Going Agile – Project Management Practices’ says the agile coach has to

  1. form the team and develop it through different stages,
  2. build collaboration amongst the team members,
  3. set the framework for group decision-making, and
  4. facilitate conflict resolution.

He or she has to take a newly formed group of individuals from individuals working together, which would be a ‘working group’, to a team. Teams go through stages of development and they tend to reach their best performance after having been established for a while. Bruce W. Tuckman identified four phases of development concerning interpersonal relationships and task performance:

To ensure the team members are clear about the project goals, the agile coach should use a collaborative event such as the chartering session, and create an environment that allows the team to collaborate in the creation of the product. Collaboration is two or more people or organizations working together to realize shared goals.

Collaboration event – Planning session

The diagram is for a project planning and estimation session. It was developed together with project team members and the client. It was used in the forming stage of the project. It supported alignment of team members towards the project goals and with one another, and a cross understanding of project tasks that needed to be completed. In the opinion of the project manager, it reduced the duration of the storming phase.

At the top of the diagram are hand drawn boxes that would represent phases in the project. Going from an initial deliverable in the first column and to building successive components until the final product on the right side. Wide-band estimation according to Fibonacci numbers suggested by Planning Poker ® were used.

The components of the diagram are:

  • The sticky note (yellow and pink) represents the tasks that have to be completed.
  • The color represents if the tasks could be completed by the project team (yellow) or if it was sourced from a third-party.
  • The tabs represent the estimates for the task.
  • In the lower left is the legend for what colors represent what levels of effort.
  • Each post-it® received an estimate if possible.
  • If it was not possible to estimate the effort, the task was placed in the box in the lower right corner.

According to the visualization recommendations, the design of this visualization fits the recommendations.

  1. Make it action-oriented:  Created during the session; retained as reference during the project
  2. Make it messy: the order developed during the session and its ugliness was retained
  3. Make it specific to the situation — It was for a specific project.
  4. Use different dimensions — it uses different…
  • Position:  represents the evolution of the product over time
  • Colours: pink, yellow, green
  • Shapes: oblong post-its are tasks; tabs are estimates
  • Numbers: are used as estimates

5. Make it interesting – the team was motivated and engaged.


Visualization in Projects – User Roles and Personas

Printer Friendly Version

Agile methodologies suggest the use of user stories that are specific to a role. Personas are one way of representing these roles.

User Story

As Gloria J. Miller writes in “Going Agile – Project Management Practices” the format for user’s story should include a title and the information on the role of the user, the function they need, and the value they should derive from the function. The following is the type layout of the user stories.

As a <user persona> I want to <function; what they want to do>

so that I can <business value; why they want to do>.

A Role defines the characteristics of typical users for the system. It should be represented by a persona or an extreme character. A ‘persona’ is an imaginary representation of a specific user role or ideal customer, a sort of a “prototype”. Personas should be created based upon market and demographic research to ensure the persona represents the target audience or user. It is about focusing on the major needs of the most important user groups. One user can’t be everything to everyone.

A function describes the capability that the user requires. The function should finish with the completion of an activity and not an on-going activity. For example, “as a webmaster I want to manage a website” is something never ends. “As a webmaster, I want to add and delete web pages” is a task that can be checked as completed. Business value explains the importance of the function or the value it derives.

Persona Visualization

A persona visualization that can be used in projects is to create a poster or chart with the personas that are relevant for the system under discussion. The following visualization is an example used in a previous project.


Based on the article a few recommendations for visualization practices in projects, this visual aid fits the recommendations as follows:

  1. Specify your objective for visualization —
    • Deciding and scheduling who got what level/content of training;
    • Setting-up the role and security concept for the system;
    • Making design decisions about who could perform what tasks in the system.
  2. Make it action-oriented — used to facilitate discussions, meetings and design decisions
  3. Make it messy — N/A
  4. Make it specific to the situation — It was for a specific project.
  5. Use different dimensions — it uses different…
    • Position of the persona – was based on organization hierarchy and functional role
    • Role – system end-users’ role
    • Photos/Avatar – real people with whom details could be discussed
    • Text – describing activities that people would need to do with the system
  1. Make it interesting —

Overall, personas are crucial throughout the entire system or product development phase and should be real-life representation. They are vital to launching a useful and usable system or solution.

Project Visualization: Sankey Diagram of Project Effort – by Gloria J. Miller

Printer Friendly Version

Sankey diagram is a data visualization tool that can be used to visualize multidimensional data in different ways. Originally, they were used to visual the flow of resources such as energy or material. The important features of Sankey diagrams is that they represent the physical flow from a source to a target related of a unit of measure (e.g., functional unit or period of time) and that the magnitude of the flow is shown by the size of the link. (Lupton and Allwood, 2017)

For project management, Sankey diagrams can be used to show the flow of effort between such topics as companies, roles, and deliverables. The diagram is a Sankey diagram of actual effort for a technology implementation project. It shows how the total project effort is divided by different dimensions (i.e., company, role, deliverable, and capability) and how the effort flows between the different dimensions.

Based on the article a few recommendations for visualization practices in projects, this diagram fits the recommendations as follows:

    1. Specify your objective for visualization — Demonstrate how effort was spent within the project.
    2. Make it action-oriented  — Not action oriented in print; online each flow can be selected separately and the value of the flow is shown in a tool tip
    3. Make it messy — N/A
    4. Make it specific to the situation  this was the real history of the project.
    5. Use different dimensions — it uses different…
      1. colors, which show effort different sources and targets
      2. size, flow size is relative to amount of effort
      3. Dimensions: based on columns
        1. Company
        2. Project role
        3. Deliverable
        4. Capability
  • Make it interesting — visual way of evaluating project effort
How it was created

The diagram is based on the timecard entries for a specific project considering 1) the person, 2) the roles the people fulfilled, 3) their company. 4) hours worked, and 5) a comment associated with the time entry. The comments were analyzed and assigned to a deliverable and to a capability. The effort was summarized for a three-different source and target columns as follows.

List Source Target
1 Company Role
2 Role Deliverable
3 Deliverable Capability

All three summaries were put into one csv file and visualized using d3js Sankey java script. An example of the csv layout is as follows.The source code for java script at the following location.


Lupton, R. C. & Allwood, J. M. 2017. Hybrid Sankey diagrams: Visual analysis of multidimensional data for understanding resource use. Resources, Conservation and Recycling, 124, 141-151.

Project Visualization: Retrospective Review

Printer Friendly Version

Recently, we published a few recommendations for visualization practices in projects, so let us ‘visualize’ these recommendations through this board.

Any identifying objects for the project or the customer are removed from this version

The first time I saw this picture was in a project retrospective review meeting. I thought “are we playing a game?” It was actually a board in form of a snake, although not for playing, but rather for visualize what happened in the project we had just finished. It was used as a facilitation tool in a lessons-learned session with the core team members from the project. According to our recommendations from the last article:

  1. Specify your objective for visualization  This board was part of a retrospective review to discuss the project history, what happened, and what lessons we learned along the way.
  2. Make it action-oriented — In the review session, we used post-it’s to discuss what to change in the playing fields.
  3. Make it messy — Although it was printed, we were encouraged to change whatever we wanted.
  4. Make it specific to the situation — This was the real history of the project with the actual events that occurred.
  5. Use different dimensions — It uses different…
    • colours, which show effort estimates by week (e.g. black = less than 3 person/day in a week; green = 9-17 person/day in a week).
    • shapes, e.g. block is a week.
    • numbers, which are the weeks in the year (calendar)
    • symbols, which show activities when they occurred
      • inside the blocks = events (e.g. installed the server).
      • outside the blocks = risks (danger sign), holidays, collaboration.
  6. Make it interesting — this is obviously something subjective, but for me this board was catchy and it attracted attention.

The objective of the meeting was to discuss what went well, what went wrong (and why) and what could we have done better. The main idea here was still the act of discussing, communicating with each other as free as possible. This board was an efficient aid for visual communication that encouraged us to evaluate and measure in a comprehensive way.

You can find the template for the board at the following location:


Visualization in Projects – Recommendations

Printer Friendly Version

Data visualization can help project teams envision projects progress, success, failure, risks… It enables users to create, view and manipulate data in more instinctive and effective way than with traditional reporting of just two-dimensions of columns and rows. It can be a powerful tool but we need practices in order to succeed with delivering the right message.

Data visualization in planning is actually a topic that hasn’t gotten much attention on regular project management trainings, but it is a fact that visual information helps users become better communicators. However, not many people use visualization in controlling, steering the project.

One of the processes that is especially important to data visualization is perception. Perception is not only the way you see or understand something, but also according to Cambridge Dictionary the “quality of being aware of things through the physical senses, especially sight”. You see something and you become aware of something in the way something is “regarded, understood, or interpreted”, which usually is intuitive, according to Oxford living dictionaries.

Our top-six recommendations for visualization practices in projects:

  1. Specify your objective for visualization – What do you want to accomplish? Status reporting? Or rather motivation?
  2. Make it action-oriented. Any project team member shall be able and allowed to change the visualization easily. It should be ready to use. People should want to change it, update it. For example, move from a status of ‘doing’ to ‘done’ or ‘on hold’.
  3. Make it messy. People should feel comfortable touching. Is it printed and too pretty? People wouldn’t change anything.
  4. Make it specific to the situation. The categories ‘working on’, ‘in progress’ etc. should mean something.
  5. Use different dimensions – colours and shapes to communicate different things.
  6. Make it interesting. People should want to look at it, read it.

Share your experience using visualization in projects

We are also curious and would love to know: How do you visualize complex projects?
How do you use visualization to help the project team…

  • track project timeline?
  • track progress?
  • plan estimates?
  • prioritize tasks?

Finally here! Updated “Going Agile”

Printer Friendly Version

Since we announced our plans to update “Going Agile” last year, we have now released the updated version.  The first edition introduced different agile methodologies such as Scrum, Kanban, and Feature-Driven Development and practices such as task boards, Kanban boards, and release planning. The second edition adds color graphics and additional field experiences. The book is available in the English version on Amazon and Barnes & Nobles.

Project, business intelligence and analytic practices