(Or how a picture can divert 1,000 eyes)
This post was first written for ProjectManagement.com who were doing a series on Visual Project Management at the time. I was excited when I heard about the theme since I am a big fan of adding meaning through visual tools to all kinds of project elements, whether it is methodology scope, project progress, or risk lists. As a visual thinker I like to make sense of a concept spatially before adding detail or explaining it to others. Yet I have found this to be a weakness as well as a strength, because what cannot easily be visualized can often get trivialized or forgotten.
Plans and prototypes are great because they easily bring people together to debate and collaborate on important project elements. Since we have something to point at and annotate; discussions and agreements progress quickly because consensus making is greatly facilitated. However what about conflict management, decision making across teams, or business engagement issues? These are more difficult to visualize but arguably more important than if a web site should have a blue or a green background.
The idiom of “Out of sight, out of mind” speaks to the dangers of an overreliance on visual management. So how do we address this threat? I believe there are two main choices: first, find a way to somehow make it visible, or second, consciously bring extra attention to it.
Another project saying “What gets measured, gets managed” might hold a clue to helping find ways to make things more visible. I think there are some parallels between the visible / invisible issue to the measurable / immeasurable issue. Many of the things we can measure on a project are not helpful and many of things we would really like to measure are intangible and difficult to measure. Einstein summed it up nicely with the quote “Not everything that counts can be counted, and not everything that can be counted counts”.
This is why some project teams misguidedly pay lots of attention to easy to measure metrics like lines of software code written or hours worked yet fail to track things like collaboration and information sharing – that stuff is just difficult to track and influence. However Nucor Steel found a way to influence it through measurement. As a plant manager at Nucor Steel your bonus pay is not based on how well your steel plant performs, but instead on how well all the steel plants perform. Lower down in the organization the pattern is repeated, team leads are not rewarded on how well their teams do, but how well all the teams do, and team members performance pay is based on team rather than their individual performance.
By measuring one level higher than your span of control the system rewards global rather than local optimization. In other words, if you find a way to get your job done better you are incented to share that with others so everyone’s performance goes up and then so does your performance pay. A subtle shift in measurement creates a culture of more positive change. So, how do we do this with important, but not readily visible aspects of project life?
We can abstract difficult to visualize project activities like decision making and consensus building up one level to something that can be made visible like cycle-time. Slow decision making and poor consensus building steps will stifle an otherwise productive project. Stakeholder arguments and political standoffs have resulted in many a failed project. Graphing decision cycle time or change request cycle time shows the average time taken for a change request or decision to flow from inception and capture through discussion to decision and distribution.
In the graph above the average change request cycle time is shown over the duration of nine one-week iterations along with a target threshold of twelve hours (1.5) working days. On this project a goal was to ensure change requests did not pile up creating a technical debt of waiting enhancements or a cognitive debt of what has been proposed or agreed in principle, but not yet ratified or implemented.
By establishing a target of 1.5 days (12 hours) for change request approvals and explaining the costs of “carrying” undecided suggestions the project community brought some visibility to the status and costs of slow decision making. Early in the project, in iterations 1-4, average cycle time was often above the 12 hour target, but in subsequent iterations it was kept below 12 hours. A target is set to establish an agreed region of effective operation.
The goal was not to drive decision time down to zero since this would result in snap decisions that are likely ill informed and lacking proper consultation and buy-in. Instead the goal was to bring attention to this difficult to visualize yet important project dynamic and then discuss and agree on an acceptable range of decision making time, which will vary from project to project.
Within the decision making process there will always be people who agree with the proposed decision, those that disagree, some for whom it is not their preferred choice and the gamut of places in between. Jim Highsmith described the use of a visual Decision Making Spectrum that allows people indicate their state of (dis)approval. One benefit of using such a spectrum is that when people are given an opportunity to indicate their feelings about a topic and explain why they feel this way, they are then much more likely to accept a group decision having had there say (plus it gives them potential for an “I-told-you-so” rebuttal later!).
There are other tools and techniques for visualizing project attributes that upon first inspection may not seem that visual. For instance queues and approval delays can be visualized with cycle-time, Kanban boards and cumulative flow diagrams that show queue lengths, rates of progress and constraint points. However, what about things that don’t have an easy to illustrate measure or proxy?
Stakeholder engagement is always important and especially so for agile projects where designs evolve based on frequent feedback and discussions. Disengaged participants will slow progress and erode the benefits of an iterative approach. Visualizing participation can be done, but I question if the cost is worth it, instead good old fashioned nagging might be a more cost effect solution. John Stasko created some stunning visualizations for his presentation on “Social Visualization”.
This “Flower Garden” image depicts the number of posts made by an individual on a message board. Each post from an individual gets a new ‘petal’ added to the flower and the stalk length indicates the time on the board. This would be a very interesting way to graph who is providing the most input and feedback on a developing system. It tends to highlight significant contributors rather than shame or identify non contributors, but without specialized software could be very time consuming to create.
Instead of thinking of ways to visualize everything, I believe project managers need to checkpoint the Time vs Importance of topics being discussed. Visual things are easy to discuss and so people will gravitate towards them, but this is not the best use of time if more significant but harder to articulate or illustrate topics get short changed as a result. Before a demo or review session check the risks and issues logs to determine if topics that might be hard to display are getting skipped. Ask questions about these topics to make sure they get appropriate ‘air-time’.
Think also about undocumented project elements, maybe the “elephants-in-the-room” that can hang over a team and affect performance, perhaps it is a company acquisitions, down-sizing or off-shoring rumour. These are best handled directly; smiley-face graphs and mood-walls are considered trite and condescending in many cultures. It is better to address these issues directly and compassionately, life is often messy and most people appreciate an honest opinion on future options more than graphs.
Likewise disagreements and disputes whether they are internal to a project or external generally don’t transfer well to diagrams and graphs. Categorizing disagreements may be viewed as trivializing them by those they involve and act only to alienate people. Many project variables can be effectively illustrated to help communicate a better shared understanding. Other topics are more delicate and need personal handling and discretion.
Managing is more than spraying information at stakeholders in a variety of formats. That is a part of it, I admit, and I love maps, graphs and animations as much as the next person, but project managers need to be conscious of what is getting discussed and what is not getting discussed. If we have just 10 minutes left in a review session with the business should we look at the feature burn up graph, the animated timeline component, or review the Issues list? Try to balance the seduction of slick graphics with the value information exchange.