Visual Project Management

humans receive 95% of information through visual perception. we spend countless hours staring into laptops reading, analyzing, interpreting and feeling information flows. i think visualization is something we lack in many disciplines and project management is not a lucky exception.

interestingly, latest trends in agile project management do care about visualization. kanban success heavily depends on great visualization. everybody loves task boards and burn down charts in scrum. as you can see, there is some progress, but i think it is not systematic, just a side effect of other activities. it would be fascinating to create an orthogonal movement in agile project management community that focuses on visualization, i call it visual project management.

there is only one really important rule about visualization:

visualization should reveal problems, states and trends

sure, we can add more rules, but they’d be secondary. imagine you can see a backlog and diagnose a disease right away:

• too large
• contains too many old user stories and
• grows too quickly

imagine you see a board, and at the same instant you grasp all the bottlenecks:

• overloaded people
• problematic stories
• quality problems and
• overall development speed

i can’t provide quick visual solutions right away, but i think this approach will change the way  teams make decisions and improve their development process.

i wonder why we still have no good visualization tools for project management. i think the answer is that project managers are not strong in design, and designers are not strong in project management. separation of responsibilities leads to basic, trivial decisions. pm should learn design and data visualization techniques to really invent new visualization. designer should learn pm domain to invent new visualization. the ideal mix is a team where pm knows design and designer knows project management .

let’s review some examples to get a basic feeling of how visualization re-define things.

why kanban board is a great step forward

information presentation really affects the ways we run projects. here are two screenshots that contain exactly the same information. you can easily say which one is better.

this is a simple list of user stories taken from targetprocess (i am working at targetprocess, so forgive me biased screenshots). it contains quite many data about user stories like state, assigned people, effort, etc. however, this data is hidden. to make some decisions, you need to dig  and put some effort into it. it means you have a higher cognitive load. it means you’ll miss some details and sometimes make a wrong decision.

next screenshot is a simple kanban board. while it is not the best example of kanban board , still it is good enough to reveal the difference. you see the same user stories on this screen. however, you can quickly identify  there’re too many user stories in in progress state, but it is not critical, since there are no holes in development flow. you can somehow feel that most likely the team is doing pretty good. in some cases you can’t even quickly explain why you think so, you’ll need to analyze your own feelings to provide logical answers.

but the truth is that you have arrived to some conclusion with enough accuracy, really quickly . that is why visualization is so important in any discipline, including project management.

i believe we can have something much better than a simple kanban board. kanban board visualizes development flow, but misses other important things like people load, local problems, overall progress for all projects etc.

what happens if we have several teams and want to see their work on kanban board? definitely, the board above will not show that. so far,  i haven’t seen good solutions to such problems. software products are not good in presenting large amount of data in an interesting, meaningful manner. this should be changed .

why gantt chart is misused all the time

gantt chart is a great tool as well. it is heavily used in traditional project management, but often with poor results.

most of the project charts look the same and make the same mistakes: analytically thin, bureaucratic grid prison, not annotated, little quantitative data.
e. tufte

this gantt chart is quite good and useful:

this gantt chart is bad and useless:

stop. think a little bit. can you define the difference? can you say why i’ve made such a conclusion?

first chart shows quite large project phases. second chart shows very granular tasks. gantt chart is not a good tool to handle granularity. it works best to visualize long project phases, like releases or iterations. it just plain fails to visualize 500+ tasks in a project.

gantt chart has a large white space, it lacks information density. thus it should be used carefully to visualize important information, not everything you have.

i think the frustration with gantt charts arises more because of tool issues. people’s contexts of use may require information that is obscured by a gantt chart. but gantt charts are the dominant (sometimes only) visualization in many tools, and it’s difficult to impossible to extract and present the data in other forms.
brian de alwis

these were just two examples of visualization in project management. i believe we can be more creative to provide better tools and concepts, invent new ways to present project information and improve transparency. we definitely can do better. and we should.

i will post more about visual project management. this topic is really intriguing and promising to me.