text:
Hello everyone,
I am a Project Manager for construction projects, and I have just been hired to help with the planning and oversight of a $100 million construction project. My primary task at the moment is to make sense of the schedule, milestones, critical path, and, in general, make a very complicated project more comprehensible.
Yesterday I received the current schedule, which was done in MS Project (Gantt view), and is now 770 lines (18 pages). Gantt charts have a lot of good qualities, but at this size they are very hard to read.
After thinking about it for a minute, I realized I have never seen a construction schedule that I would consider an "excellent visual diagram."
Does anyone have any ideas for me?
Construction schedules need to show tasks, the durations of those tasks, and how the tasks relate. That's it for my purposes, at least.
I am inspired by the Cyclogram (see http://www.edwardtufte.com/1359855346/tufte/posters), and the chapter "Parallelism" in "Visual Explanations," but they are not directly applicable.
It is suprising to me that I haven't seen better task-oriented charts. Could it be that this is an area in need of some real innovation?
Comment and Ideas welcome. Thanks for the help.
ps. I am not limited by tools - I know several programming languages, have access to PC's, Macs, Unix computers; all the latest software, and the result does not need to be "automatic" like MS Project. ie, I pretty much have a free hand.
-- David Person (email)
Project Management Graphics (or Gantt Charts), by Edward Tufte
Computer screens are generally too small for an overview of big serious projects. Horizontal and vertical scrolling are necessary to see more than about 40 horizontal time lines for a reasonable period of time. Thus, for large projects, print out the sequence on a big roll of paper and put it up on a wall.
The chart might be retrospective as well as prospective. That is, the chart should show actualdates of achieved goals, evidence which will continuously reinforce a reality principle on the mythical future dates of goal achievement.
Most of the Gantt charts are analytically thin, too simple, and lack substantive detail. The charts should be more intense. At a minimum, the charts should be annotated--for example, with to-do lists at particular points on the grid. Costs might also be included in appropriate cells of the table.
About half the charts show their thin data in heavy grid prisons. For these charts the main visual statement is the administrative grid prison, not the actual tasks contained by the grid. No explicitly expressed grid is necessary--or use the ghost-grid graph paper. Degrid! See The Visual Display of Quantitative Informationon chartjunk, Envisioning Information on layering and separation, and Visual Explanationson the ghost-grid graph paper. Here is an excellent bad example:
The typography can be improved. The practice of first-initial-caps makes every word read a proper noun. Other problems are all-caps, poorly chosen fonts, mysterious acronyms.
The column of tasks too often is organized in an elaborately baroque hierarchy, emulating the organization chart. Maybe tasks should be organized differently. For a start on clear thinking in this regard, see the great book by Fred Brooks, The Mythical Man-Month,which is about managing large programming projects.
Project management must have a vast literature; presumably business schools teach this all the time. What are the deep principles and how can they show up in the design and organization of a project? That is, have some real analytical thinking behind the chart, not the guesses and generic thinking about project management made by those who write Project-type charting programs.
Find out what the very best project managers do.
How could all those big projects in the last 3,000 years ever been done without a Gantt chart? Very complex things can be done without the aid of the central authority of the Gantt chart.
The graphical timetable might be an alternative model. See all the time/activity schedules in Envisioning Information,particularly on pages 45, 101-119.
The design of project charts appears to have regressed to Microsoft mediocrity; that is, nothing excellent and nothing completely useless. (Is the reduction of variance around a modest average the consequence of monopoly?) Most the project charts (do Google search on "project management charts" or "Gantt charts" to see plenty of examples) look the same and make the same mistakes: analytically thin, bureaucratic grid prison, not annotated, little quantitative data. The computer Gantt charts, so lightweight and tinker toy, do not appear to have been designed for serious project management.
Of course, there is also the perfectly reasonable common sense of the Gantt chart. Such a chart might be helpful, if only to reveal guessing, but don't make a big deal about it. Just put a big long roll of paper up on the wall, updated every so often.
Ten years ago I sketched out a project-management interface. The ideas are:
Multiple series of different types in parallel at top. (See chapter on parallelism in Visual Explanations).
A context-bar for overview, with the detailed display shown beneath. The color box on the context-bar should show the overall location of the detail below. This is the same idea I used in the thunderstorm animation described in Visual Explanations;that is, a large-scale animation ("large scale" means the houses are big) placed in context by a still-land small multiple showing the entire history of the storm.
Vertical linkage showing how the elements are sequentially inter-linked, over several functions simultaneously.
Fairly detailed notes exposed on the top; further animation and data residing underneath each box.
Grid is self-defining by position. No lines for grid prison at all. Pixels are devoted to content, not heavy-handed lines.
The global project chart then can go at least two ways. First, pull apart local detail for special subgroups. Note the labels on both sidesof graphic--for the categories (left and right) and for the times (top and bottom). Also note that manyboxes are enlarged, not just one.
Then there are multiple projects, which can be looked over by bringing together multiple context bars from the various projects,for whatever that's worth.
-- Edward Tufte
On collaborative project management by air-traffic controllers and by IMF economists, see our thread here on "Thinking and Paper" at http://www.edwardtufte.com/1987563815/bboard/q-and-a-fetch-msg?msg_id=00008c&topic_id=1&topic=
We at GSA's Public Buildings Service are struggling with the same issue of scheduling, interface design, too little or to much detail. We have over 175 projects, valued at more than $9.1 billion in the capital construction pipeline (typical 7-8 year time frame), extreme detail during construction, very little detail other than stages of deliverables (15%, 35%, 65%, 95%) during design (usually a 12-24 months segment of th overall timeline), little or no detail at beginning (3 years of planning effort), and limited visibility at the conclusion, which is tenant move-in and rent start and the ultimate objective of the project.
An integration of MS Project with Visio might be the technical answer, but it truly comes down to a good interface, which we would desperately like to get some new ideas on.
One question for ET if he can answer (and I am pursuing separately), are the graphics at the NY Times automated?...is there a graphic program they have developed which interfaces with data tables?
Steve Hagan
-- Stephen R Hagan FAIA (email)
A bit of provenance for me first. I have been involved in
Project/Programme management for some 25 years. A typical
large project has involved managing 1500 people, a dozen
separate consulting firms, and eighteen countries in three
continents speaking four languages.
My view is that there is still no IT solution to the display of
operational information for large projects, nor will there be until
screens are available to hang on the wall with dimensions of
three metres by one at a resolution of 150dpi. My solution -
which works (enabling me to save a recent client US$5.0million)
- is to use whatever PM system (MSProject, MacProject,
OpenPlan, Oracle whatever) to do the number-crunching and
dependencies but to display the day-by-operations on a wall
chart from eXcel. Day-to-a-column across will give you just short
of a year, tasks down as many as you like - and colour-fill cells to
create timelines. Distribute to Project Leaders, print out on (say)
21, 24, 27 sheets of paper, cut and paste physically and stick on
the wall. Hold all project discussions in front of it, write all
comments, ideas, issues, problems, phone calls etc on it. Get
Project Leaders to behave the same remotely. If they are away
from the printed copy, get them to log notes on the digital
At the end of each week collate all comments, enter on master
digital version, reprint and rehang on the wall. Takes an hour or
so, but it is worth it. Do not delete previous comments, errors, or
things no longer relevant. They might just become so again.
The wall document (and its remote duplicates) become a living
sand table that takes the immediate imprint of operational
activity. People stand in front of it and read it in idle moments.
CEOs and the President wander in at the end of the day, note
things, ask questions, nod, go away satisfied. Occasionally
someone will point to a note of a phone call in the southwest
corner and gaze across to another six months on in the
north-east: "You don't think these two issues are connected, do
And aside from giving you the ultimate in project control, at the
end of the project you have a real live work of art!
Happy to take further correspondence.
Martin Ternouth
-- Martin Ternouth (email)
These are excellent and thoughtful contributions by David Person, Stephen R. Hagan, and Martin Ternouth about the practicalties of project management charts in the face of low resolution IT solutions residing on the interface. Printing out charts and putting them on the wall seems to be the way to go for big, complicated, serious projects.
Placing the plan on the wall is a big help and changes the nature of the discussion. Instead of sitting around the table and talking about what each person is doing, people are more inclined to get up, walk to the plan on the wall, point to a task and say "This is what I'm working on, but I cannot finish until Mary finishes, and I can see that Jim is waiting on me, and he has to complete his task by - good grief, by Friday!". The other people gather around and people are actually talking about their tasks, interdependencies, milestone dates. The stuff you want them to be talking about.
We were taping the paper together, wasting lots of time and tape, when someone said "They print floor plans for furniture and stuff. How are they doing that?" I found a plotter in an office used by the building maintenance guys, so we started printing on this 36" x 150' paper. Much better. Well, we put up these 36" x 48" project plans, and then everybody wanted to know about it. Pretty soon they were printing network diagrams, database diagrams, software architecture plans. People are starting to understand information a lot better.
-- Robert Towry
I have found that wall charts can sometimes be a mixed blessing, although it does give people visibility.
First, if the project manager is analyzing the risks and proactively updating the project plan, the wall chart tends to be outdated as soon as it is posted.
While any major changes to the bottom line (i.e. end date, end deliverables, total cost) should be run by the approval process, changes to individual tasks or methods can and should be done frequently by the project manager and the team, as long as they don't negatively impact the original charter. This is often done to mitigate risks as they are identified throughout the project. Sometimes it's done in response to the technical team's discovery of a better solution.
An alternative method to wall charts is the use of work packages. Rather than including all the minute detail in the project plan, make the project plan less granular, but have hyperlinks to more detailed "work packages", which contain the detailed activity and associated timelines and responsibilities. This way, only the high level deliverable needs be on the plan, making it less cluttered (and one that will more likely be followed and maintained). However, people can "drill down" to the detail.
For more on that, see my article "Project Management According to Napoleon" at www.gantthead.com.
Combined with annotation, that could be a powerful tool. As for the format of the chart itself, the ones listed above by Edward Tufte are, in my opinion, better than any computer generated Gantt chart I've seen. I'd be curious as to what tool was used to create that, and if it could be loaded from MS/Project or Excel.
More and more, I've been seeing the use of "swim lanes" like that (that list the person or group responsible on the sides, and chart out the timeline by responsible party). As long as the resources are somewhat limited (or can be grouped into a limited number of groups), that's a great way of displaying it. I suppose it would even work with a large number of resources, but I haven't seen one like that. It's a great way to show at a glance who is doing what at any point in time.
-- Jerry Manas, PMP (email)
I'd like to add a clarification to my last posting.
If a wall chart is used, and reposted at least weekly, that's certainly an effective option (and may be the only one) for large scale projects. However, I've seen several organizations post a wall chart and leave it up for a month or longer. At that point, the chart could very well be useless. So, the caviat is that it should ideally be reposted at least weekly. In my prior posting, I was primarily referring to people who post a wall chart like it's the permanent plan to be followed (believe it or not, I've seen it done).
I'd still suggest using work packages as well, to make the plan easier to read and maintain.
I'm glad you like my sketches for project management charts. They were sketched out in Adobe Illustrator 10 or 12 years ago for a client. The designs are only mock-ups and alas have no operational code behind them.
An interesting thread!
I've often wondered if MS developed Project as a tool so that SW development could stay as an art rather than a science.
That said, I think it can be an effective tool if one sticks to the basics: tasks, owners, durations, and dependencies.... with all of these captured from the person doing the work.... so it's what they say not what's dictated to them. ("It's your schedule; I'm just keeping it for you.")
From a visual perspective: Distribution to the team as a PDF file keeps the tool from getting in the way of the content.
Posting: At least once a week; sometimes twice a day if needed (the plotter gets a workout). Showing what is completed also seems like good positive reinforcement.
... Rick Sparks
-- Rick Sparks (email)
Hi folks. A really interesting conversation with some great ideas. I agree with the keys so far - big pieces of paper on the walls of project rooms with scribbles, notes and Post-its on them, replaced at least monthly. My background has ranged from being involved in large vehicle development programmes at Fords, to aircraft development at British Aerospace and for the past 10 years or so large scale change programmes inside organisations, with or without technology components. I'd reinforce the point someone made not to confuse the plan with reality - plans are usually the result of good conversations and decisions and a stepping stone to the next set of conversations. In construction projects my guess (not having been involved in one) is that they are more predictable than most. Most of the projects I am involved with have much less predictability e.g. particularly where people and their reactions are concerned. Things that I would have liked, but haven't managed to find a simple way to do yet, for projects would include:
Plans (both work breakdowns and Gantt charts) where the colour, or density of the line, or something can be changed according to the (un)certainty of the item on the plan e.g. if an activity is due in 6 months both its content and timing will be a lot less certain than something due next week, and it would be good to have that visually (fainter, lighter, etc). I would also have liked real models of what is going on, rather than just paper representations e.g. when helping to create an IT systems distribution business what I wanted most was scale models of the warehouses as they were being built, with boxes inside (or not)as the stock was delivered, and supplier factories with the components in (or not) and trucks on the road - I think you get the picture (literally). Certainly I've found images work better than lines and numbers in uncovering issues, because as humans we translate numbers into images anyway. Maybe the computer games analogy is close to this. Has anyone played SIM or similar where you can build cities and watch 'life' unfold?
Connected to this is that plans are only as good as the data you have to put into them, and I have found some great visualisation techniques which helps people to 'see' things about the project which were not just rational/logical and which they 'knew', but couldn't articulate until they (literally) saw things differently. Too detailed to explain here but they include things like walking up and down imaginary timelines for projects on the floor and predicting what the issue will be at that point in the project. Sounds weird until you try it and it works!
A meeting to chat sounds like a good idea - maybe 2 meetings either side of the pond?
-- Alan Arnett (email)
Breaking the project into chunks and allowing a "drill-down" feature is a good idea in my opinion, as I alluded to in my note about using work packages. A way to offer a high level view, but at the same time allow the viewer to see the detail if desired is ideal. Of course, you in MS/Project, you can explode or hide task levels as desired, but the Gantt chart lacks the multivariate data we need.
With this thread, I'm seeing a convergence between the design principles of ET and the current reporting limitations of Project Management, which is intriguing. A workshop exploring the application of these design principles would be an excellent idea. Perhaps it could be sponsored by or held at the Project Management Institute, which is in Newtown Square,PA., near Philadelphia. If it could be endorsed (and perhaps even guided) by ET, that would be utopia. I'm a PMP certified member of PMI and am involved in several of their specific interest groups and programs. I feel they'd be excited about this opportunity. Not sure if any others are involved in PMI, but I imagine so. What are your thoughts?
I'm thinking we could generate questions and agree as to what reporting problems we are trying to solve, and what audiences we are trying to satisfy. We could then identify various ways of solving the problems, and possibly even develop some prototypes and/or recommended solutions. What would really be of value would be to share and examine different best practice examples.
Personally, I feel that there are definite limitations in the current ways of reporting status and associated info) for multiple projects in a way that follows the Grand Principles offered in ET's class. The current toolset just doesn't do the trick, to my knowledge. To me, the solution would have to involve some sort of manual effort (be it updating a wall chart, or posting weekly earned value measures to a graph, etc.). There must be a better way than creating and maintaining consolidated Gantt charts in MS/Project for multiple projects.
-- Jerry Manas (email)
I am a "large project" GAL who is extremely interested in these issues, and would also love to participate in a forum. If anyone organizes a gathering, please add me to the list of those who would like to participate.
-- Lorna M. Feeney (email)
As a project manager for a large IT department, I am always looking at ways to better communicate to my team members. Some other challenges that I have found include:
* Remote teams in multiple time zones (makes wall charts a bit more challenging.)
* Teams that include outside vendors, that do not have access to our inside-the-firewall project databases.
* MS Projects lack of a free reader software package. I use Adobe to publish my timelines, but it is a static view that folks cannot manipulate the information to view it the way they need.
* Lack of and the high cost to buy a roll-size plotter. BTW Kinko's does not have a clue how to handle a MS Project file. I would have to have the drivers for their plotter loaded on my PC (anyone try to get your IT Security department to load additional drivers lately!), then have a static printout. There would be no opportunity to manipulate or modify the print out on screen at Kinko.
* On the data presentation front, It is always a challenge to know how many columns of data to include Task Name, Start, Finish, Resources, etc. A larger view may help or so would a swim-lane style chart shown above.
* How to balance the need for using a structured WBS such as one based on the Software Engineering Institute's SPI model (Initiation, Planning, etc) and desire to view tasks by related business area or manager (the new Grouping feature in Project 2000 helps)
Any way, I would be very interested in any seminar, or ongoing discussion about this. Any PMI members out there? How about someone in the know writing a good reseach article for the Project Management Journal (the quarterly reseach magazine, not the monthly one)?
Charles Snyder, PMP
-- Charles Snyder (email)
I would definitely be interested in attending some sort of forum to address these challenges using Edward Tufte's principles of design. As a PMI member, I would think they'd be interested in sponsoring this research. I had suggested to a few people that Newtown Square may be a good place to meet (PMI Headquarters) if they are willing to sponsor it. If there are enough people interested in meeting there, I could pursue it with PMI.
I also agree it would make an excellent research article for their quarterly journal. The challenges listed by Charles Snyder are just what I'm faced with. Those challenges would be a good start to such research. I'd be willing to co-author it with any who are interested. The best bet may be to begin the forum and then the research article could be a result of the forum (along with our final suggestions).
As mentioned, I like the swim lane approach, as long as it can be applied effectively to large projects. I've seen it used very successfully for high level views. I haven't yet seen it used for very detailed views, although Edward Tufte's examples shown in this thread look very promising if we can duplicate it with real data.
I know that Sean Gerety (as he mentioned in this thread) is working on an interface to extract data from MS/Project and create an SVG file that resembles Edward Tufte's examples. He plans to bring it to the Chicago seminar to get feedback from Prof. Tufte. At that point, he may be able to post it here. I'd be curious to see what it looks like.
After having a chance to think about the diagrams above, I realized that while
their examples look nice and clean (which appealed to me greatly), as a project
gets a bit more complex, i.e., tasks with multiple successors, you'll still have a fair
amount of spaghetti going on (They examples show some multiple predecessor
situations but only single successors).
In addition, the explicit timeline raises another potential problem as well. In my
implementations of critical chain-based project management, I encourage clients
to use display projects with network diagrams (like the one usually called PERT)
rather than Gantts. Gantt charts, with their "predictions" of the future present
too much distracting fiction in terms of the time line and dates associated with
future tasks. The presentation of anything that can be construed as interim due
dates that, if met, imply that the project is "on track," run the risk of introducing
Parkinson's Law behaviors into the project, and threaten the schedules speed and
schedule performance.
A network diagram and an indication of current project buffer status should
suffice to describe a project, its status, and its health. If necessary to determine
corrective action when buffers get too consumed, the PM can dig into the Gantt
info to see where assumptions about future task durations provide opportunities
for improvement.
What I do like, however, about the Tufte diagram is the idea of the vertical axis
containing resources with the sense (if not the detail) of time (via the logical
dependencies) along the horizontal. The resource structure, resulting in a
swimlane-like diagram, will allow resources and their mangers to more easily see
where their activity is, and as tasks get checked off as complete, their approach.
So I guess a reasonable variation would be network diagrams organized by a
vertical depiction of resources.
-- Frank Patrick (email)
Reading through ET's remarks in his first response I had a huge case of deja vu. Until the end of last year I was working at frog design, a product design consultancy, where we had a "skunk works" going that was developing a web-hosted software application for managing complex product development projects. One of the key aspects of the application was a project timeline, which was loosely a Gantt but had many improvements. These included summary bars that contained overall descriptions of what was going on, and then underneath that the more detailed activities (we avoided the word "task" as it's too top-down in nature) could be unrolled if desired. When the sub-activities were rolled up again and hidden, the summary bar stayed there with its description, providing a high-level context for other activities. This is unlike MS Project et al, where the summary bar is extremely data thin, and just shows time.
One innovation was that the names of the activities appeared in the bars themselves, avoiding the "tennis-match effect" of having to constantly move your eyes left and right to see which task listing on the left corresponds to which bar (ET's chart does the same thing). This allowed a quick scan downwards that made the project seem more coherent.
Another feature was that documents could be linked and displayed on the timeline, providing the ability to drill down and see more detail on deliverables (past and present). It also helped new team members or outside vendors quicly come up to speed on the "story" of the project.
There were other small touches such as milestones that could be made to visually spread only within a range of activities, or the whole project, depending on scope of impact and who needed to deliver stuff for them. The project manager could create a top-level summary bar and set of activities to scope the project out, and then let others fill in the details. In effect the project manager could "sketch out" the project (working from the deadline if desired, which most gantt charts don't really allow, though conceptually it's one of the easiest ways of thinking about what needs to be done...), and not get bogged down in the details. One of our tenets was that MS Project and similar applications encourage the inclusion of too much detail, which results in the constant need to update because things always change. Our software drew the line at a day's resolution - anything less than that is ridiculous for multi-month projects.
The project did not have to be arranged by phase or time as most gantt charts encourage, but could be categorized (in the left hand column) by teams for example, which would allow each team to see clearly what its activities were and how they related to other teams', either at summary or detail level. (I.e, each team would get its own summary bar describing high level activities, this could then be unrolled to show detail. In fact, we took to calling this a team-based schedule because it had so many merits. Activities could be linked together, not just thru dependencies as is common, but also through concepts or goals. And if a dependency was set up, the software wouldn't automatically default the second activity to occur after the first has finished, which MS Project does. In reality dependent activities often overlap considerably, and our software was quite comfortable with that.
Because the software and the project database were web-hosted, the timeline could be updated and owned by many people, removing the tyranny of the weekly print-out and the bottleneck of making changes when you only have one owner. This had several side effects: responsibility for detailed planning could be left to the department managers where it needs to be anyway, and the timeline always represented the *actual* not the *planned*. We felt that the actual vs. planned readouts that most gantt charts provide is often used as a stick to hit team-members with when things aren't going to plan. But in reality, things almost never go to plan especially if you're designing a highly innovative product, since by definition you haven't done it before and don't know what problems are going to crop up. Change - deviation from plan - is to be expected. The solution to this is wider disclosure within the company, not hiding information and problems. Again, a web-hosted solution works well here because everyone within the company can see what's going on. We also had plans for discussion threads that could be embedded into the activities so that people could discuss issues in the context of the timeline, not just in email, sort of like putting post-it notes on print-outs of charts.
Finally, because frog is a design firm well known for its interface design and web design as well as product design, the look and feel of the gantt chart was far superior, cleaner, easier to read than others, which as ET says are typically quite clunky.
Sound good? Unfortunately after almost 2 years of development we had to pull the plug due to lack of VC funding after 9/11. And we were only a few weeks away from beta... We did get a number of patents on the timeline, but at this point it doesn't look like it will be going forward, which is really a shame as there was a lot of good stuff there.
-- Adam Richardson (email)
I know this is a discussion of graphical representations of project timelines, but I do wonder if the question as to the purpose of the timeline graphic should be asked. Do we need the graphic to help develop the plan (work breakdown, dependencies, schedule), to manage the project, to communicate with team members, or to report to the client/sponsor/etc.? The requirements of each tend to dictate solutions that are quite different.
While I could theoretically agree that a wall-size graphic representing a project timeline could be used help develop a project plan, in practice I would find the static-ness of a printed graphic too cumbersome to work with. I would instead choose to take advantage of MS Project's outline features (and/or subproject capability) to reduce the scale of what I am working on to something that can be displayed on my monitor while I edit it. I have also used these features in conjunction with a projection monitor to explain project plans to team members and other stakeholders, expanding and collapsing outlines and revising tasks interactively during a presentation. I believe this works better than expecting a group to look at a wall-size graphic that can't be updated in response to "what-if" questions from the audience.
For large projects, I also don't find a printed timeline of the entire project to be an effective management tool. Rather, focus must bear on the tasks or groups of tasks where performance is over budget or behind schedule. Once a project has more than a couple hundred tasks in its WBS, it has to be managed by exception or the team members spend too much time in project communications. For this, I have found that earned-value analysis is very helpful, although it's a technical discipline that many project managers don't practice.
Unless my sponsor was himself a PMP, I would not plan to use a timeline graphic as a way to report project status. Sponsors primarily tend to be interested in when the project will be completed and how much it will have spent, both in relation to the project plan. Reporting which at regular intervals provides a projection of expected completion and final cost, together with a clear assessment of known risks, is in my experience usually appreciated a lot more than a wall-size Gantt.
In fact, although I really tried, I could only come up with one good application for a large infographic showing all aspects of a project's status: to bring a new project manager up to speed quickly on a project that is in trouble. I have been brought in to look at projects in this state, and I can say large project plans tacked to walls are helpful. They tend to show things like tasks with no dependent successors, uncompleted work in the past, and other design flaws that prevent the plan from being used to predict the project's completion date.
I am a strong proponent of the principles contained in Professor Tufte's books and his lecture. However, I believe that most project managers can better spend their time learning formal techniques like plan development and earned value, as well as features of MS Project like the "Update project..." command, than worrying about how to make a more informative timeline graphic, if their goal is to improve the performance of the projects they run.
-- Gib Veconi (email)
(1) Project management charts (like all the ones in this thread) have short names to identify each task. There must be a connection from these short names to a detailed description of the task (in MS Project, the "note" function can handle this). It is quite common, weeks or months later, to have no idea what a few short names referred to in a big project, or to have a serious ambiguity regarding the implied function. In other words: By all means make a beautiful picture of the process, but you will fail without a proper description of its elements.
(2) Please bear in mind that the problem we are trying to solve is often insoluble. We are concerned with managing projects as best we can, just as we maange hurricanes as best we can. For a proof that OBJECTIVE estimation of a project to develop an algorithm (or software) is impossible, see this website for a fairly formal proof: go to www.idiom.com/~zilla and check out the page section titled: "Is software engineering engineering?" You will find links to J. P. Lewis's article "Large Limits to Softare Estimation" and additional background material.
-- tobias d. robison (email)
Let me ask a heretical question. Are Gantt (or PERT) charts necessary? If so, are they necessary in their entirety? Do you need to see EVERY dependency for EVERY task, or just those that have come to attention for exceptions of one kind or another?
MS Project (and several other packages) have flaws or shortcomings unrelated to the graphic display of data. We have multiple costing processes and need to track changes and variances to each scenario... each one can have different staff (in-house vs. outsourced) and getting that data for resources and tasks into MS Project, let alone displaying it coherently, is not possible.
Our solution, not necessarily relevant to anyone else's situation, is to have a Visual Basic program in which these factors (project scenario, task, resource, hours per time period, internal cost, charged cost) are entered. Any change to the system is reflected in the overall time/cost totals for the scenario. Exceptions in time, cost, or completion can be set to simple parameters and cells in the VB grid displaying the requested slice of data will change color to indicate the nature of the exception.
The VB program can export to MS Project, but it doesn't allow for task dependencies. However, our experience has been that if the dependencies involved are too complex for the relevant segment manager to understand and trace, there's no point in making a spaghetti diagram in MS Project to spread the blame. Unless you're building a bridge or an airport, nothing is *that* complicated!
Most of the posts in this thread illustrating better visual representations have made an impression because they displayed simplified fragments of the plan. The point of my post is not to tout my low-tech solution, but to ask whether Gantt charts themselves have outlived their usefulness on complex projects if no one can understand them. Maybe the failure of our visual representation is not due to lack of skill in presenting the data, but that the data itself is telling us that it's useless.
(I have the same objection to Entity Relationship diagrams, but that's another story.)
-- Gordon Fuller (email)
Love this thread. Has anything happened with the idea of a project managment/information design workshop?
-- Mary Quitzau, PMP (email)
This is one of the best discussions I've ever found. I wonder why.
This same problem of viewing information and relationships exists in describing
application requirements. I used to use butcher paper for that, unrolled and tacked
on the wall, then using it as a forum for discussion and notes with the users. There
seems to be some need to see the whole picture rather than the detail. Is it the need
to see graphics rather than data in fonts? Why does a whiteboard work for
There seems to be agreement that current computer screens are too small and need
feedback capability (touch screen, mouse). What size do they need to be? Would a 4' x
6' screen do the job? Two of them?
Has anyone ever seen any research on the mind's ability to process data graphically
vs. textually?
-- John McIntosh (email)
There is Project Management software available called Primavera Project Planner (P3). It's an extremely powerful data driven platform that is used to produce Gantt charts and PERT diagrams. I'm surprised P3 hasn't been discussed in this thread. It's the recognized standard for high-performance project management software. Project activity data can be sorted and filtered for display on screen; however, nothing at this time can replace the need for oversize plots of activity charts. http:\\www.p3.com
-- Paul M Campanella (email)
A superb piece on project management by Christopher Reynolds of the Los Angeles Times describes the work of Terry Bell, who managed the construction of Frank Gehry's Walt Disney concert hall. The hall was designed and planned out with heavy-duty computing--and massive amounts of paper. http://www.calendarlive.com/galleriesandmuseums/cl-ca-reynolds25may25.story
I saw the concert hall over the course of several weeks a few months ago. The stainless steel cladding, curved and soaring, generates amazing reflected light, so beautiful and changing, from the sun. The new Bard College performance center in New York near the Hudson River, also by Gehry, generates similar beautiful light. For both buildings, the light is ever-changing, depending on the angle of viewing and the ambient light during the course of the day.
Does anyone have any information on how movies are made from a Project Management viewpoint? I caught an episode of Project Greenlight last night and started wondering about all of the creative processes that occur from set design to scheduling shoots to when do they eat lunch. How and who keeps track of all of this? And what tools do they use?
-- Sean Gerety (email)
There are elaborate time-by-activity sheets used in staging and coordinating theatrical productions, to synch lights, sound, voices, actions, scenery. In the books on theatrical productions, these sheets are nice practical workaday schedules (although the gridlines are often way too heavy).
Source: Lawrence Stern, Stage Management (Boston, 1992, fourth edition), pp. 29, 108, 117.
Lawrence Stern's book on stage management is excellent, very helpful for mounting road shows, filled with good hands-on guidance.
My gut response to this is to favour the concept of ownership of tasks. I've always had a difficult time getting peers to even acknowledge the existence of the dependency assigned to their domain or department on a thoroughly published and distributed Gantt chart.
I therefore have come up with the intuition that the web-based solution is the only solution.
Because people will avoid acknowledging or taking responsibility for something assigned to them centrally, I think that the idea of bidding for responsibility or "making an offer" and "posting" it to a web-based project makes sense.
This poses the threat of creating a third layer of "as-bid" to the discussed projected and actual versions of a project, but I believe the dissonance between these versions stems from the assets agreeing to tasks that are impossible or unlikely to save face, pushing the discovery of this folly into the future.
Lastly I was reminded of the "Neuromancer" paradigm of data and the net of data where something real, like money, which really represents the reward for effort, takes the form of data which is represented on the net of something physical which can be virtually "sensed". We can't escape this need to virtually model our projects. I favour a consensual model.
-- CHris Fitzgerald (email)
In answer to Sean's question on how movies are organised: the current tool of choice
(according to my film producer friend) is Movie Magic Scheduling (and its partner
budgetting package). These are used for everything from corporate videos to
Hollywood blockbusters.
Before computers (and today, for low-budget or traditionalist producers), they were
scheduled using special strips of paper that fitted "production boards" which could be
easily carried around the studio or location. Each scene has a vertical strip which
shows the requirements of the scene (location, actors, camera, special effects,
vehicles, makeup etc). The strips are then moved around to find the best shooting
sequence. You obviously want all scenes in the same location shot together (as far as
possible), and want to manage the various crew and cast members' workloads.
There's a very quick primer at <http://www.solutioneers.net/cinema/
The beauty of the strips is that it's easy to move things around to meet contingencies
(say the weather's no good on a location or a cast member is ill).
In fact these strips are Movie Magic's printed output format. Specially perforated
paper and mounting boards are sold to complement the product. The Writers Store,
<www.writersstore.com>, sell the software and the boards.
-- David Glover (email)
Thank you for directing me to this discussion; it is more than interesting. Like many of the people here I have often wished to replace the tradtional project reports with more meaningful and effective forms. So I've started experimenting with a method to summarize project metrics and projections into a cost-effective graphic.
The dilemma is in the details. When managing a project like the pros in this thread, the need for detail precludes summarization; a drill-down capability is needed such as the frog design approach. (I've started using a low-cost multi-dimensional data base that is compatible with MS Excel.) Yet program managers and sponsors need succinct and compelling summarization of that project information, and crave visual representations. I would personally prefer a method that reinforces the fundamental ideas and standards of the Project Management Institute. So the process first assembles the essential industry-standard project details in MS Excel, then performs some simple calculations, and automatically produces a succinct graphic plot based upon generally-accepted project management theory. Please forgive the crude nature of this graphic. This initial step is so rudimentary as to be considered blindingly obvious, but I hope to build on this sound conceptual base. I plan to extend this simple approach into a graphical representation that combines a series of the plot snapshots into an accurate depiction of the project course through a three-dimensional space, and will be applicable to any project that contains an industry-standard work breakdown structure.
I've sent a copy of the paper for comments to the Project Management Institute's quarterly PM Journal, and to each of the people listed in this thread. If you or any other reader of this thread have any comments or questions, please send me an email.
-- Steve VanArsdale, PMP, CPA, CPA (email)
Well, it's been a year since I last contributed to this thread, and thank to an email from Steve Van Arsedale (with a fascinating and simple "sextant" analogy to measure project status), I see it's still going strong. I noticed several interesting additions, from movie production ideas to other tools and websites(I once developed software for location scouting for films, and many project management principles apply to film-making as well). I was reminded, seeing Prof. Tufte's examples of movie production worksheets that simple is often still best. I also saw a recommendation for Primavera's P3 model, which I've heard plenty about but haven't used. Alas, I've been stuck in Microsoft-land.
I saw one contribution that suggested that perhaps we may be trying to use the wrong tool (detailed timelines) for the wrong audience. While that's certainly a valid thought (and I agree when it comes to Gantt Charts, I still feel that a web-based simple view to show the status of a project, along with key milestones and major issues, with the ability to drill down to the dirty details for those who dare, would be a valuable tool in the project management community. Perhaps Primavera's P3 does this. I'll have to check it out. I just know that Gantt Charts are not the tool we want to be using to convey project status to a broad community (although they are useful for project managers). I keep thinking of a map analogy. The underlying detail is very complex, but the best maps appear simple on the surface. How can we very simply convey the status of a project, in terms of its cost, schedule, and deliverables, as well as relevant annotated information, such as risks, issues, and milestones?
Perhaps Steve's graphic, which shows the relevant time/cost/scope metrics, would suffice (provided that annotations were added to explain the figures and add approporiate details about risks, issues, and variables - such as complexity, etc.). It appears to be a sound theory that addresses areas that traditional status methods (like Earned Value) do not. Then, small multiples could be used to show trends over time (like watching weather patterns). It's certainly worth further discussion. It's a shame we never got that workshop going. Personally, I think it should be a new PMI standard initiative (project reporting is an area worthy of having an effective standard, as many project problems are due to lack of clear communication).
I wonder if it would be appropriate to weight deliverables at the planning stage, before the first sextant plot... assuming that it would be possible to establish a universal rule as to weights, so that the project sextant results would remain comparable. Then a graphic sextant plot at a weighted milestone would be the anchor point for a continuing line between sextant plots, and the basis for showing trends, risk events, and milestones.
As for the graphs as small multiples, i.e., ET's captivating thunderstorm animation: I have something slightly different in mind. Perhaps one day we will have that workshop to discuss this with Prof. Tufte: Note that multiple sextant plots on a project (in figure 8 of the article) and imagine a year-long project with a sextant at each week. When I visualize the line between the plots, it is more likely to be a curve, eh? At least that's prevailing EV theory. This would be the trend(s) of influencing factors on the project metrics over time.
Given a project where progress is recorded daily (there are unobtrusive methods), and the sextant is computed and plotted automatically (a trivial matter), one can easily visualize the project course in a graceful three-dimensional curve. This curve resides within a sphere of environmental factors, i.e., funding, staffing, organizational mandates, etc. Now with relatively few CPU cycles and an average graphical engine, that sphere could become semi-transparent and manipulable, so that the project course could be viewed from all angles. Each individual point on the curve opens to a table of detail on costs, schedules, milestones, risks discovered and risks mitigated.
-- Steve VanArsdale (email)
A web-based project management tool certainly does offer some advantages (and
some disadvantages as well). An individual can see only the tasks assigned to them,
and, if it is written well, they can see how their activity affects other people in the
I'm working on an open-source project that intends to do just this. We're still in the
beginning phases of it, but it is actively being written, and of course, we'd welcome
more participation. You can read more about it at
The advantage of the web based system is that each individual can look at the
portions of the whole job and see only what is relevant to them. Also, if each
individual has their own list of Tasks, but it is still within a project management
framework, you can give them useful information on the critical path, etc.., and
hopefully find some sort of visualization that effectively conveys how their work
affects the overall project.
The major disadvantages are issues of scalability and other issues inherent in web-
based interfaces.
Work on this will be proceeding a lot the next few months, so check in if you'd like
and check it out. Eventually, we'd like to incorporate a lot of the ideas in this thread.
-- Jade Rubick (email)
One of my clients builds large cross-country gas pipelines and recently gave me a
project chart produced in a package called Tilos, from German software developer
Tilos produces charts that show project progress against location, time and other
factors. For instance the pipeline project I saw showed bushfire and bird migration
seasons for particular locations, as well as rainfall over the pipeline route (which was
shown as a blue background of varying density).
My client uses this as well as Primavera Project Planner, though I'm not sure quite
how they mesh the two. Certainly I found the Tilos printout put an incredible amount
of detail into a location (horizontal) and time (vertical) grid that I was able to quickly
interpret (I'm responsible for a video of the project so need to know what's happening
where and when).
Asta is at www.astadev.de. The product is available in English and German, though
the Web site seems to be in German only. A demo version and manual are available
for downloading at www.astadev.de/produkte/tilos/index.asp.
Hello Folks,
I manage software and other technology projects. For a project such as the one outlined above (770 lines...whew!), I believe the project build-out process is flawed. There is just too much information on the project schedule to be useful. Such a large project should be bucketed into phases, and these phases should be detailed. In order to see the larger picture, software that enhances the capability of MS Project can be used. For example, using several chart options in Project Milestones, one can see where the current phase is in relation to the whole project.
In addition, I have found it to be very helpful to personally brief certain key 'tutors' before I roll out projects. These 'tutors' are managers or individuals who can disseminate information up and down the ranks. On larger projects, these 'tutors' become part of a network and act as conduits of information. This eases the information outflow as well as ensures that I am made aware of any problems as soon as possible.
I have found this forum to be extremely useful and thought provoking. I look forward to reading more comments on this issue.
Hussain Mooraj
-- Hussain Mooraj (email)
Many years ago a friend who was responsible for some of the logistics of the British
Army during the first Gulf War told me that they had given up with computer
programmes and had instead drawn large charts on rolls of wallpaper, which were
pinned up on the walls of the briefing room. After the war, the charts found their way
into the regimental museum.
-- Dean Madden (email)
If you have your gannt chart users install a full Adobe Acrobat, instead of the reader, they would be able to annotate the charts.
Having Distiller would also solve the printing problem with Kinkos by creating a pdf and printing the pdf. Complaining to Kinkos might get them to install MS Project.
-- David Locke (email)
When I worked at NASA/JSC, we used Primavera and Artemis.
With MS Project, you can change your symbology using the style feature.
I document user interfaces, so I use MS Project to map features, then documents, and then the project. I use the zoom feature in the printer driver to make my charts smaller, so they take up less wall space. MS Project was not designed to be used the way I use it. At one conference I attended someone used IEF2 instead.
An MS Project file can be saved to Access. Once there it could be written out as a series of Excel spreadsheets that could be organized into a data cube and pushed into a data warehouse. Once there any number of visualizations should be possible. Last year, we were looking at using business rules and transaction data to do space visualizations of annuity portfolios. The successor-predecessor relationship between tasks is a good match for OLAP databases.
This is a very interesting discussion. I've been using MS Project on and off for several years as a consultant, and I've often had to try and manage users' responses and requests re: why isn't the detail or the visuals on Project easier to read/understand/contemplate.
I really like Edward's work from March, 2002. His detail visuals do a MUCH better job showing WHO is doing WHAT, and to a lesser extent, HOW things are organized.
Not much room or scope (yet) as to the WHY or HOW LONG aspects, though. As they say, a work in progress (grin).
As several people have pointed out, it IS possible to just dump Project data into an OLAP cube, pretty much directly from the source. That allows for an extended amount of creativity regarding the details and how you look at the data overall.
However, this is a rather lengthy and time consuming way for a lot of people, and isn't really very accessible to the majority in the long run, even though it IS a very good idea for many.
Here are some ideas I'd like people to kick around:
1. Build a future version of Project or some sort of PM or reporting style software to support "really large" displays, like say a 50-foot plasma widescreen, like you see in modern day airports that have these types of TV displays.
1a. Also provide support for smaller displays, say from 15 to 100".
1b. Make this wider screen view with varying levels of detail so you can zoom in and out to better emphasize work flow patterns and scheduling relationships.
1c. Allow for multiple levels of detail at the individual resource level as well as the job level, even breaking things down by the hour, and allowing for even the smallest items to be accessible or viewable.
1d. Allow for "big picture" Gantt style graphics to remain, but have smart Tags or icons indicating that there is additional nested or grouped, (somebody mentioned "bucketed", which is right on target) information that could be clicked on to see more or less.
2. If standard views and technology size restrictions are an issue, then include/use iconographics or symbology to better show these mutliple contextual realtionships on top of what is already there.
A very simple and obvious way might be to use large numbers or colored symbols at points on the chart to show connections to other charts or other "pieces of paper".
No doubt Edward has a number of these ideas in mind, and it would be interesting to see "updated" versions of those diagrams with PM style details and information inside (how about it?)
3. David Glover's suggestion of using something like Tilos as a possible interim or alternate software solution is great. Will check it out ASAP and see whether or not this helps - I'm sure that it will provide some neat options to play way.
4. I like Visio a lot, but what it DOESN'T do well is understand and organize Project specific information in a PM style way. It's a little too freeform and loose for my taste.
What we really need is something structured enough to get the detail in cleanly and as visibly as possible, without sacrificing too much of the big picture - an almost Herculean, and nearly, but hopefully NOT QUITE impossible task.
Mark Shepherd
Financial PM/Database Consultant - Access, SQL, Excel, Project - Ottawa, Canada
-- Mark Shepherd (email)
This discussion is perhaps one of the most helpful I've seen relating to PM in the 'real-world.' While, I've not managed large, enterprise projects as yet, I do have a real need to help my small organization get to the next level. After reviewing mountains of theoretical publications on the subject of Project Management, I've found that in our reality, much of what has been written assumes large-scale organizations with a formal PMO and/or dedicated project managers. While we simply cannot afford the overhead, we need enough planning and control to be effective. As you all can imagine, adding software like MS Project, which makes assumptions far outside of reality, would only add to the burden of getting the job done. Nevertheless, we need to find the balance between time spent managing and time spent doing within a backdrop of excellence.
In order to accomplish this end, I've spent a great deal of time over the past few years researching both techniques and tools that may help us improve. There have been modest gains. The use of a software package is very attractive to us because of the promise of efficiency. Of course, there is no replacement for PM skill and judgment. It would be wonderful, however, to remove the time wasted on formatting, calculation, and reporting. I don't believe that there is a "silver-bullet" software package for any organization much less a smaller shop such as ours.
While it may be true that no one software package will automate all of the mundane, facilitate the complex, make the coffee and take out the trash, it must be possible to combine a reasonably robust tool with reasonable PM practice trade-offs to aid the smaller project that does not have a dedicated PM.
Does anyone have any thoughts on that?
Also, it seems that there is a distinct difference of opinion between some of the contributors to this post is that visualization of project data is either an irrelevance or it will save the world. As a professional in adult learning, I would like to point out that both textual and image based tools are absolutely necessary for effective communication. In fact the addition of auditory tools would be greatly beneficial. While many of you have taken the time to provide more scholarly reference to support your points, I lack the time at the moment to gather my resources. What I will mention, probably remind most of you, is that some people tend to see and relate to images more that text, some the reverse. Some tend to relate more to the "big picture" others to the minutia. As you know, the cardinal skill for project manager is effective communication. That means communicating to the entire audience in a manner to which they can relate. Assuming that the inclusion of many different styles and points of view is beneficial, we must trade-off some time and energy for appropriate communication.
Thank you for reading my post. Please let me know if you've any ideas for the project manager/working team member.
Kind regards,
Charles McGinnis
-- Charles McGinnis (email)
Along a similar vein I'm in the process of looking for a software package(s) that allows graphic display what my company calls a "process map". The purpose is to better understand all aspects of our operation and how they interact, plus describe the steps in some detail so that we may develop a set of standard operating procedures. In my case I would like to be able to put together a flow chart that shows all of the steps in our operation (a gold mine), for example, from collecting ore samples to chemical analysis to synthesis of the resulting data.
So far I've looked at Excel, MS Project, even AutoCAD, but nothing seems to fit the bill in terms of ease of editing, detail, and display. In some respects our operation is a linear process, where ore is mined, transported, and processed, but it unlike other discussion in this thread, time and cost data, which is a focus of say MS Project, isn't our main concern. We deal in a constant cycle of material flow, so the chart would represent the idealized flow paths of a single cycle, i.e. multiple tasks occuring at the same time but in different places, such as geologists doing grade control, engineers designing the mine based on grade control, miners following the engineers plan, et cetera. All of these tasks take place at the same time, but for different areas, simultaneous and parallel.
Because there is so much detail involved I would like to have a series of charts that go from a coarse overview to fine details, effectively drilling down for greater detail and more steps in each sub-task. We have roll plotters so there is no limitation to size of the chart. I also like the idea previously discussed of hanging the chart on the wall, and compiling the comments and changes contributed by the users of these data. Keeping it updated on a frequent basis is critical as we are in constantly changing and improving our systems.
Are we best served by Gantt charts, or are there better tools available? As no one in our organization has even considered these issues it's all new territory and the best solution will win out over what is known and comfortable.
-- Dana Willis (email)
I recommend starting with one of Tufte's pads of paper and a set of color pencils.
Don't fall into the trap of deciding on the program before you know exactly what you want to do.
Paper and pens are still far better than any software program for preliminary work.
It sounds like you have a lot of information to represent. Pick a representative subset (or better yet, the thorniest subset) and doodle until you have an idea of how it would look.
Then, pick a software package to implement it. I generally use Illustrator; it is flexible enough for just about anything, and it has hooks into programming languages to automate updates, if that is possible. Visio is also a good choice. AutoCAD would work but requires quite a lot of expertise.
-- David Person (email)
Most people who want to do process maps think of a flow chart that shows the life story of one case. (Typical Visio task.)
However, you are right and perceptive to notice that in fact activities are going on in parallel.
The half way house is to divide your organisation and put each department/function/team/whatever into a swim lane. As your flowchart moves along you draw arrows to show how work is handed from one swim lane to another. It becomes like a project so some kind of project drawing tool becomes a possibility.
The way to fully recognise parallelism is to drop the life-story idea altogether and draw your business as a set of communicating sequential processes. Each dept/team/function is an oval on your diagram. Arrows between them show "channels" for communication. A channel could be a flow of documents of the same type, or of related types, or conversations. (If the documents flow in both directions that's two channels.)
If you want to you can explode the ovals to show what happens inside, which will be more ovals as you break the team down into sub-teams. You can also write little fragments of procedure that show how each process reacts to or uses incoming messages on each channel, and generates messages for outgoing channels.
For this you're back to something like Visio.
I think the life-story and communicating-sequential-process (CSP) views are complementary and would do both. The life story helps you work out what work should be done. The CSP view helps you allocate the work to people and understand how the work will look to each person/team.
-- Matthew Leitch (email)
I think Dana's need could be served by a deployment flow chart. I use this type of flow chart to show how work moves from one department (or person) to another, or how one step might be shared. Most recently I used a deployment flow chart to map a change control process, starting with the user identifying a problem, passing it on to IT for risk evaluation, with the change control board overseeing priorities, validation, and feedback to the user. The flow moves back and forth within three columns. This tool also suggests where there might be inefficiencies in the process, as when the flow repeatedly crosses from one group to another. Further, while the chart itself is often sufficient to show a process, it is also very useful if one must write a narrative procedure. I learned about deployment flow charts from Myron Tribus who used them to illustrate his articles about quality management. Peter Scholtes, in his book The Team Handbook, also provides a very simple example.
I agree that it is best to start with pencil and paper, and use as few of the standard symbols you need to describe the process. In a group effort, we might use post-its cut into the needed shapes and stuck on a white board or wall.
Steven Byers
-- Steven Byers (email)
In response to Dana's question, I do a fair amount of process mapping. I'm fortunate enough to have an excellent (but expensive) software tool to use (ProVision, by the ProForma Corp.) This allows me to build process maps which I can decompose into lower level activities maps. The activities in return can be further decomposed into lists of steps or tasks. With this tool, I can assign a variety of attributes to each activity (time waiting for input, time doing useful work, delays incurred while working, time waiting to hand off to the next activity, costs in terms of dollars and resources, etc.) The line showing movement from activity to activity can be labeled with what is being moved (in my case, it's always information of some kind) and the event that causes the movement. Most simulation software will offer the same functionality.
But when all is said and done, I usually start with colored pens, sticky notes and 11x17 paper to make these swim lane maps. Once you've done a couple of these paper maps, you'll find it's very fast to do.
The other reason I like to start with paper is that I'm frequently interviewing a process owner or stakeholder, and I get better, more sustained participation (and thus more complete information) if the two of us are engaged in moving sticky notes around and talking about them. Having me show up with just my black laptop and sucking information out of the interviewee into who knows what mysterious application I'm using can be intimidating.
-- Andrea (email)
Re: Dana's request - I agree with all comments that pen/paper/stickies/whiteboard etc are the way to start your process chart. I find colour stickies and whiteboard an effective combo (see example below).
For making a pretty diagram, Visio allows you to link to sub-processes in separate pages.
-- Simon Shutter (email)
Accompanying a new NASA safety group, I recently visited the NASA Michoud (often pronounced ME-SHOW) Assembly Facility in Louisiana where the large external tank (ET) filled with LH2 and LO2 for the shuttle is made. We also toured the ET factory where I observed that the tank is very large. It is constructed in a 43-acre plant all under one roof; workers move around on bicycles. There they are working on a redesign of the external tank to reduce the ice debris and insulation foam debris breaking loose from the tank and striking the orbiter (which led to the loss of the Columbia) and to monitor possible debris issues.
In a presentation room, where I saw a 49-slide PP pitch (not all that bad), mounted up on the wall were perhaps 100 to 200 8.5 by 11 inch linked pieces of paper that traced out the RTF (return to flight) plans for the ET. This appeared to be a good way to make a large high-resolution management chart without a fancy printer.
By the way, it is interesting how soon one starts talking in acronyms in the engineering business.
I am a writer with a parallel challenge: "character management." In my current novel, I have nine characters, four countries, three pivotal events, 27 story arcs, and five deceptions. I've been using the long wall/duct-taped note card method to track it all. I need to have it laid out large scale, so I can see it all at once, and on paper, so I can scribble notes, draw arrows, etc.
Doesn't travel well, though; I imagine I'm not the only one who wants to take a hardcopy plan over to someone's office for review. Also, major re-editing is nasty. (And once the cats went after a dangling scene.) After reading through this thread, I will get myself a blueprint-scale printer and perhaps test out some commercial software, either writing-oriented or project-management. I'd be interested in any suggestions on this.
-- Katie Thompson (email)
Regarding Katie's storyboarding inquiry:
I do a huge amount of storyboarding similar to what you describe, using either index cards or post-its. My wife has been working on a complex novel, so I also have some sense of what you're trying to keep straight.
I find a digital camera is all I need to complement the storyboard. I take multiple "tiled" shots so I can read them when printed. That way I can quickly take a snapshot, print it for the road, distribute a pdf to others, etc. A camera is insanely fast compared to software products (which I also use heavily). Just a thought.
-- Dave Lash (email)
One thing that always fascinates me about these process diagrams is that they reflect a rather poignant human desire to predict the future, to capture the chaos of the unknown and render it in a coherent, logical framework as way to assuage fear. In this way they are almost more talismanic than practical. Unlike statistical charts, they try to project what might be as opposed to what has already transpired.
I work in a museum that manages a great number of complex projects, many of them discrete and overlapping, involving many people and tasks, over a number of years. In my experience, when we use the Gantt charts, they are usually used as a crude forecasting device, an attempt to describe the project in an idealized fashion, as it might happen if all went according to plan.
Invariably, it doesn't turn out that way, however. A vender misses a delivery date, somebody gets sick or leaves for another job, a pipe bursts, the fund raising drive falls short and on and on. (What experienced project manager doesn't have a gut sense of exactly how much "slop" is contained in each strand of the Gannt chart? But you don't spread it around. You hoard it as a contigency, a secret shadow fund of time that doesn't get shared on any chart.)
We could go back and ammend the chart, but this rarely happens. By this time, management is tactical rather than strategic. Because we are all experienced in our respective roles, we are usually already each carrying in our appointment calendars, our PDA's, or our heads what we need to know and, usually, we know know how to pull it out. We respond to change and we adapt. We have many spur of the moment conversations to solve immediate problems, we make decisions, communicate outward and we move on. A forensic ammendation is irrelevant.
The chart, it turns out, scarcely carries the detail, the resolution, necessary to capture these kinds of situational adjustments and their rather more minute ramifications, nor is it very useful to add these back in after the fact. The chart is especially poor at predicting sheer human effort, where it will bulge or go slack. Where the burnout closes in, where someone falls idle with nothing to do.
I think the project chart is a comforting reminder that shows that we know what we are doing, that we have some assessment of all the key variables, a feasible plan. Perhaps its most important function is to act as a bellweather, to trigger anxiety when a blown deadline will pile up onto the next link in the chain. It shows us the time critical points which, when we don't hit them, means we'll have to work especially hard to get things done. It's a confidence builder. But its utility seems to be as a beginning rather than an end.
-- Daniel Spock (email)
I am a novice at Project Management and Microsoft Project but am facing the same dilema with respect to the best visual way of displaying projects. Most of the ones I am working on are fairly simple, with about 100 tasks. Most of the people I work with like the PERT because of the ease of seeing relationships between tasks. But the visual timing element is missing. What I just tried was to create a PERT in Excel with the calendar across the top. (Because I am new to PM, please forgive me if this is something that is well known to practioners.) The boxes representing each task are approximately the length of the task so you can see the dates that they should be worked on. The critical path boxes are outlined in red. The task number and name are included in the box. Arrows connect predecessors to successors. It isn't as neat looking as the PERT but the relationships are easier to see than the Gantt. It also highlights tasks that are not on the critical path but have very little slack and could easily become critical. It can easily be printed on a plotter. The downside is the amount of time to create it and then there is no easy way to automate the updates. A software package would be nice! Any more information on a symposium or meeting on this?
-- Norma Maraschin (email)
Daniel S's comments hit the mark...whether managing a project for a museum or a high tech product introduction. The dynamics and realities that he mentions are often the unspoken secrets of large segments of project implementations. Leadership, staff capability, and team follow-through usually take over as the inevitable realities pile on top of the original plan and its rapid obsolescence.
-- Jim Crossett (email)
Excellent thread!
My company uses a 3rd party tool that connects to MS Project to build much more robust PERT charts / network diagrams. We customize the output of these charts so that the boxes for tasks & milestones are more clear and contain more information. We use a lot of plotter paper as we won't hesitate to print out another copy of the project schedule on a weekly basis if necessary. We'll also utilize filters for long or complex schedules so that we're not rolling paper around the walls of a couple rooms.
The teams I've worked with seem to like seeing the "big picture" as well as being able to see what they're supposed to work on on a weekly basis (assuming you've set up your timescales as such). With this method, I can show the critical path to both the team and the client so that everyone is on the same page and sees potential impacts to critical tasks.
For those long distance teams, this tool also has a function to create a website that will allow you to drill down to a "readable" page on your monitor. It's a little ugly, but could work if you have teams all over the place.
The 3rd party tool we use is PERT Chart Expert and was created by Critical Tools.
From a practical perspective, I never rely on any one view in MS Project. Other complex factors like resource utilization and cost control force usage of other views within MS Project or exporting time-phased data to MS Excel.
Ian Coletti
-- Ian Coletti (email)
Here's a teaser...
Now that the U.S. has Sarbanes-Oxley (SOX), will complex project management collapse under the weight of so many factors?
We run multiple long-term projects in which payment is tied to the completion of milestones tied to the Statement of Work (SOW). These milestones may be 18 months apart for government contracts, but like most companies we amortize the expected revenue. If a milestone is delayed or margin decreases, this is no longer an "oops" to be reported when the milestone is actually reached. Restatements must occur much sooner, and with many complex projects this can soon reach farcical proportions. Obviously the effect in the executive suite is far from farcical though, since they have to sign off on the numbers. Our CFO refused to sign the SOX statements until each project manager signed off in his/her estimates, feeling with some justification that he would not be liable unless the project managers certified their own projections.
Several messages in this thread comment on hoarding slack time and other factors to try and blend the ultimate result into the projected schedule, but for public companies your boards shouldn't let you do that anymore. The ability of project management tools to accurately chart the course of a project are not of academic interest anymore.
I wonder what readers of this thread are experiencing. Are your project managers increasing their resource estimates to protect themselves? Are your accounting systems responsive enough to reflect the project changes so that "corrections" are small enough to not draw the ire of the board? Have you strengthened your Change Management systems and tied them directly to accounting systems?
Interesting, this discussion. I too have struggled with the conflicts between the macro views that must be prepared routinely for communication upward and the micro views to which day-to-day management of the project is bound. I have found MS project to be a useful "what if" tool, as has been alluded to by others. Beyond that however, I find that it's enforced conventions don't serve my disparate audiences' needs.
In a prior life, I was attached to a large aerospace firm whose job it was to plan and execute the development of commercial flying machines. When completed, 5-10 years of corporate effort had to bring together some 3 million parts from 3 thousand suppliers in a sequence such that this marvel of imagination could scoot down the runway and take gracefully to the air... at a certain time, on a certain day, which had been announced 18 months in advance.
As I recall, we relied on three principal tools to manage the process. The first was textual and was a listing of individual activities, what they comprised, how much effort they would take, and when they were supposed to be done. Generated from a classical work breakdown structure, the detailed commitments of resource and time were hashed out in a series of scheduling meetings named after the color of the rooms in which they were held when the company was young. They were the micro view provided to the implementers and were used to track and to hammer the day to day events. We statused this as "tier III" schedules. As a minion, all you had to do was to meet the commitments on these sheets and all was right with the world.
A principal tool we used to generate the WBS was called the "number one flow" diagram. Sort of like a swim lane diagram, it's horizontal axis represented time, but rather than organizations or people, the vertical axis listed various tasks. At the very top was what I called (to myself) the Hollywood task, the one that we would track and report on at the summary level to our masters. This looked pretty Gantt like but included milestone dates, description of activities along the way, and the flow time of each activity. Deviations from plan were shown with different symbology, but that's a detail. On the lines below Hollywood, we listed all of the "major" things that were needed to make Hollywood go and drew them in the same Gantt-like manner. A key difference is that "start" dependencies for a task were drawn on that task's line, not somewhere else with an arrow. So if I needed a quote before I could write a contract, the task line started with "quote, 1w" which flowed into "write contract, 3w". This was mostly to simplify the diagram. At the end of each of these little sub tasks, an arrow was drawn up to Hollywood to show when that task would complete. I found that this technique worked well to show the day-to-day people where their work fit in to the larger picture, and to help with planning the workarounds that comprised the bulk of my day.
At the macro level, the big Hollywood lines (called tier II and rolled up from the tier III reports) were shown, but they were on HUGE sliding whiteboards, updated with black tape and little symbols by elves the night before. There were no subtasks or dependencies, these were big enough to stand on their own. These charts were also missing the resource information (which was tracked by earned value methods and reported on separately) but provided "at-a-glance" looks at both the current tactical situation as well as gave a view to the strategic. There was no drill down capability in the large charts, if someone needed more detail then an overhead of the tier III was nervously produced and discussed. Ultimately, the tier II charts were consolidated into tier I charts for distribution to the press and marketing, we workerbees never paid them much heed.
The point of this rather long winded description is to agree with many of the musings of ET with respect to the inability of our automated software tools to actually produce output with sufficient information density. To ask a static tool (software program) to serve my unique needs in the flying machine business and at the same time wow my contemporary who is keeping track of the construct of the plot of a future best selling novel is asking a bit much... in my opinion. Remaining chained to our "tools" simply means that we must eventually change how we do our jobs in order to comply with the demands and limitations of the tool -- the tail will wag the dog. Powerpoint is a shining example of this phenomenon.
The sad part is that it's very hard to automate the production of quality documents. That perhaps, is our grail?
-- Kim Hansen (email)
I'm a lawyer. My grail has been to automate the practice of law. I too have concluded that is asking too much of the software. For 30 years I have adapted the latest computer hardware and software to the practice of law. (I went from engineering to mathematics to law at an early age.) From IBM Mag Card typewriters and TRS-80 and Apple IIc computers in the 1970s to IBM Displaywriters and PCs in the 1980s up to the 3+ Ghz computers spread all throughout my home and office today. I have used mainstream business application software from Displaywrite to WordStar to WordPerfect to MS Office 2003. I use Visio 2003 and have tried out MS Project. My current goal is a daily graphical depiction of my law practice. I am a sole practitioner. I have clients, matters, tasks to do, tasks to follow up on others, time, billing, etc. All are variables but all are finite. When I tried to do this in 1982, the computers lacked the storage and processing power, but today the hardware is up to the task. The problem is that the software has not kept pace with it. My desire is to depict on one sheet of paper/computer screen all of these categories of information. I envision it like the control panel of a nuclear reactor, with lights and buttons and switches that I can press to receive information. I designed a simple website with this machine-like concept
and now want to apply the same idea to my office. It should be tabular with rows of information for each client with the client names locked, and it should have columns of data for each client, but the data should be collapsible like an outline so that I can drill down for details as needed, and it should have conditional effects that light up when certain parameters are met (such as not getting a task done on time or not talking to a client in x days). I have tried creating this in Excel, Word, Access, Visio, FrontPage and even CaseSoft's NoteMap. I have talked to my professional Web designer son. There seems to be no software made for this. None of them had any wizard, sample or autoformat that is close to this. Upon further research, none even had the simple ability to lock a single column of a table so that it could not be accidentally edited (Excel does this if you lock the cell and then protect the entire worksheet). Believe it or not, my final solution was achieved using WordPerfect 5.1 DOS, a 1990 program that still solves these tough problems in a simple, albeit non-GUI way. (It remains my primary word processor, ala Ed Mendelson at
I have a simple page now that at least has every client and matter and to do on it in a way that tells me with a quick glance where I stand and what needs to be done. It just seems odd that I had to use a non-graphical program to get there.
-- James W. Martin (email)
Here are some ideas for showing causal arrows and linking lines that may be relevant to project management charts. (These are draft pages from Beautiful Evidence)
I work in a 'matrix' organization that juggles resources between projects and functional activities (ie ongoing operations). What suggestions do folks have for managing and representing the work of such organizations? At the moment we are trying to fit our functional activities into MS Project so that the project tasks and functional activities can at least draw on resources in one place. A gantt chart view is only useful for the projects. Is there a better way?
At my company, a large aerospace contractor, "cards on the wall" are popular for day-to-day use by large project teams. They have sufficient detail and size to make them useful when the teams have subscribed to the philosophy. Experienced Project Managers say that the translation to electronic project management software such as MS Project is difficult for the many reasons that have been described in this and other threads. The auditing and accounting requirements in our sector make it mandatory to have the program plans in that format.
In a slightly related matter, I enjoy the detailed and thought-out responses offered by participants in this discussion forum. I don't always agree with the comments (or even Dr. Tufte, himself,) the time spent to read and digest the thoughts of people who are interested enough to compose careful paragraphs is well worth the effort. This is in marked contrast to many other online groups in which I've participated over the past twenty years where scattershot replies are the norm.
Ravi Narasimhan
Redondo Beach, CA
-- Ravi Narasimhan (email)
We have done several large moves of data processing equipment infrastructure. The beauty of the wall during planning is great as you find people coming up with things like you can't do this before I do that. (I can't change the network if you have taken it down). But the real beauty is in the execuction phase (the moment of terror after the weeks of boredom) when you put the pert chart on the wall and let individuals responsible for cetain tasks color them in with markers as they finish. What a cool sight to see the thing march along before your eyes and what a neat motivater for the people doing the work.
-- W. P. "Doc" Holiday (email)
Doc Holiday's phrase "wall planning" is a wonderful name, as well as an excellent summary
of this thread. Bravo for our Kindly Contributor, Doc Holiday.
One rule for wall planning: don't make a poster out of a wall plan; keep the type
reasonably small and don't use poster-sized type or images. If done poster-style, then
resolution of the wall plan is lost as the viewer backs away to read poster-sized type at a
Another idea: leave some space for handwritten annotations, to be incorporated in the
next printing of the wall plan.
Another one: make updating routine, frequent, and easy. (It will be easier, for example, to
tack up and collate 11 by 17 sheets than 8.5 by 11.)
Another one: integrate various modes of evidence. That is, use text, graphics, images,
tables, sparklines in wallplans.
There is an excellent wallplan for managing the Shinkansen (bullet train) in Japan that I
picked up in the control room of the Japanese National Railroad in 1985. See Envisioning
Information, page 45. I'll try to post the whole plan.
How about a short chapter, "Wall Plans for Managing Big Projects" in Beautiful Evidence?
Should "wallplans" be one word, like "sparklines"?
It is very interesting how getting a good name for this idea (already up a long time on this
thread) has activated thinking.
1. "Paper and pens are still far better than any software program for preliminary work." -- David Person, above
Why are paper and pen better? My guess is that not only because of flexibility and speed of work they allow; kinetic (body movement) aspect can be a hidden yet important element in the activity of project planning. When I taught a PM course, I asked people to start by drawing the time line, by hand; then mark start and end points, then milestones, stages, and so on. It appears to be a certain challenge, for many, to draw a straight line, and fit all project activities into the chosen length. Aren't thinking and drawing connected?
2. Is the left-to-right straight time line the best representation of time? According to some anthropologists, cultures can be divided into two classes: some use the linear concept of time, some view time as cyclical. Could we use a circle for showing time? A cyclical chart can convey the idea that project must return to its origin (by fulfilling its goal or requirements). It could also function as an illustration of the energy level of the project--first half is downhill, the rest--uphill.
3. There is another very interesting comment above: "project plans are used to initiate conversation". Do hand-drawn (hand-made) (wall) plans perform better in this function?
-- Priit Parmakson (email)
Making visible committed work in the traditional Gantt format creates all kinds of problems. Here in aerospace we've switched to a "style" of program plans called IMP/IMS (Integrated Master Plan / Integrated Master Schedule). In this approach Program Events (PE) represent transition, assessment, or validation points. For each Event, there are supporting Significant Accomplishments (SA). Each SA describes an interim, critical or discrete activity required to complete "before" the event. Accomplishment Criteria (AC) are measureable indicators of evidence that demonstarte the achievement of maturity or progress in an activity.
Finally activities are performed in support of the CAs. The "langauge" of IMP/IMS for EV/SA/AC is always "past tense" with the verb at the end = "Preliminary Design Review Conmpleted." For tasks the verb is present tense and placed at the beginning = "Write PDR Briefing Guidebook."
As well a specific format for MSFT Project is used to show the EV/SA/AC structure along with the "Big Visible Chart" haning on the wall.
In the Scottish example IMP/IMS could have been used to make visible the committed work, lack of progress and missed Events.
In the end though it still comes down to good project managers, cooperative customers, and a viable project.
-- Glen B Alleman (email)
More on the landscape....
The key to the landscape metaphor is showing risk as an elevation - higher landscape features like mountains and ridges become visually prominent and consequently (hopefully) get the attention they deserve. Perhaps what is also important, then, is showing how the risks relate to each other, and reflect this in either terrain or road constructs...
The landscape metaphor suffers from the implication that the project as it is now "is set in stone"... whereas it is actually more like a desert with shifting sands. I'm trying to think of ways to address this.
It is also difficult to capture what would appear to be some critical points in the project: the politics involved and validation of the business reasons behind it. Mind you, I don't know of anything that does capture these.
-- Tibor Grubits (email)
Regarding software that is useful for preparing process charts, I have found Inspiration
(www.inspiration.com) to be extraordinarily helpful. Somewhat like Visio in that it has
preset standard flow-chart symbols, it also allows a high degree of customization and
allows you to toggle between graphic and outline formats. While not robust enough for
serious project management along the lines of the Gantt chart discussion above, it is very
intuitive, cross-platform (Mac/Windows) and inexpensive.
One other inexpensive program I have found useful in its relative lack of sophistication is
FastTrack Schedule (www.aecsoftware.com). The product is at least 10 years old and the
latest version is Version 8. At a beginning level, one can make simple Gantt charts without
needing to embed links, dependencies, etc. As one advances, one can add such
intelligence. However, what is so wonderful is that this is like "smart graph paper" [yes,
you can turn off the grid]. In other words, you can use its low-tech mode to do what needs
to be done rather than having to be a Gantt jockey.
-- Roger Goldstein (email)
With respect to the suggestion that people use Post-its and a whiteboard for the initial
draft of a process map (before transfering to some electronic format), I would like to
suggest the following:
Instead, buy a long role of butcher paper and tape long pieces of it to the wall (or lay it out
on a conference table). Use this surface instead of a whiteboard.
The chief advantage is that you can roll up your draft and move it easily. It can also be
archived for future reference, whereas clearling the whiteboard for the next user or
process removes access to the original content.
Hope that's helpful to someone....
-- peter linde (email)
From a German supplier (can't be more specific I'm afraid, because I've been unable to
trace them to re-order) you can buy rolls of white plastic sheet with a surface that works
like a white board. The rolls are about 60 cms wide and perforated every metre, and
because it is plastic film it will stick electrostatically to any wall without tape. It is
expensive, but you get the advantage of an instant whiteboard of any length, or multiple
whiteboards that can be shifted around into different sequences . . . and you can roll it up
and take it with you.
Brilliant! And also serves to underscore my observations submitted in April 2004. E.T.'s suggestions so far have been with respect to legibility of PM tables which truly are awful and unwieldy. But in essence these charts are predictive and, as such, often must rely on estimations and guesswork. The quality of these prognostications is only evident with the unfolding of time and no chart can capture the fortuitous exigencies any project invariably faces, a priori, and few contain any real visual depth to convey the special character of problems incurred by unanticipated changes. So what makes the project chart rise above "junk content?" The experience and gut of the project manager who, usually secretly, builds in resource allowances for failures. This mixture of intuition and experience is belied by the apparent rationality of the project chart. One of the chief, but often unacknowledged uses of the project chart is to persuade stakeholders of the feasibility of a plan of action and to elist commitment to the execution of each part of the plan within the time resource allocated. In that sense, the project chart is really more rhetorical in nature than anybody has really acknowledged. But if stakeholders are not alert and experienced, well a bad plan charts as rationally as a good one. I suppose, though, that legibility would have the one advantage of making shoddy estimates easier for stakeholders to identify. I guess my main point is that a lot still rests on the skills of the planners and their cohort.
But, to the extent that project charts are about anticipating the optimum timing and sequence of stages of a project, things tend to go wrong with more than just the schedule. It is the interaction of time with the relative volumes of human effort and cashflow that create smooth or dysfunctional projects. As seasoned project managers know, an increase to any one of the three variables almost invariably increases the other two. So what would a project timeline look like that factored in visual representations of all three combined along the same continuum? Such a visualization might be of real use, not merely academic, as it would show more plainly the implications of change factors over the life of a project. Because, let's face it, coping with changes to the plan and understanding implications in a tactical sense, are the great weaknesses of these mostly strategic tools.
Daniel Spock identifies three variables for the project manager: time, money, and effort. Admiral Gehman, head of the Columbia and Cole investigations, identified four in a lecture at the Naval Academy: time, money, quantity, and performance margin. It seems then that time is strictly the passage of time on the calender, not man-hours; quantity and performance margin are the products of effort, and effort is the product of man-hours and the experience gained through previous man-hours. Feynman wrote about how he and Hans Bethe learned to do math faster on the Manhattan project by teaching each other arithmatic patterns. They saved time through effort. In this interview with Chris Capossela, a former director of MS Project, said his group didn't like using their own product to log their work hours. This is admittedly anecdotal evidence, but it certainly seems to support the notion that effort is harder to track than it's products: quantity and performance margin. I suppose this last fact is in covered in Business 101, but I found it an interesting way to arrive.
-- Niels Olson (email)
Re: tracking effort. It's certainly not hard to estimate man hours at the outset and track effort quantitatively by logging actual hours and simultaneously comparing actuals against estimates. What's infinitely harder to do is to make adjustments as needed while in process and understand the relative implications of those adjustments as they are liable to impact delivery on other aspects of a project. Of course this is normally only a major concern if you are running over, not under projections. Of course, checking off deliverables on a list says nothing of the quality of an effort. But an indication of the rejection of a delverable and consequential delay and/or debit to the project should be easy to represent graphically.
I guess my point is that, whether the time charged to a project account is accurate or not (and I agree, this can never be properly ascertained with anything like absolute certainty, especially in projects where you've outsourced big chunks,) time does represent money. In any project, practically speaking, what gets charged against a project, represents the "actual" expenditure and will be where overruns will happen. Big construction projects in the US quite regularly now wind up in court where overruns are litigated one line item and vender at a time.
All project management tools allow for the break out of discrete tasks, with timelines for the completion of each, and even some critical path demarcation to indicate that, if the deadline isn't met, it will interfere with the completion of another contingent task. But a graphic, dynamic, at-a-glance tool that shows you when a delay is starting to incur compounding overruns caused by staff costs still doesn't exist to my knowledge. Might be more useful than the rather two dimensional graphics currently in use? I don't know.
I am a specialty subcontractor working on multiple simultaneous projects from a few thousand dollars to a few hundred thousand dollars. We usually have a dozen or more contracts running at a time. For scheduling, we get either a date or two in our contract documents or the ubiquitous Gannt chart which is invalid before it's printed as it's someone's inexperienced idea of how our work should progress. We are continuously impacted by slow responses from the construction team (contractor, architect, designer, owner) to our requests for information and/or submittals. I am laying out a scheduling grid using the French train schedule format similar to the cover of ET's first volume to chart out contractual schedule requirements (time across the bottom and tasks up the sides) with distance between the tasks relative to the available time for submittal preparation, submittal review (train waiting at the station), purchasing, fabrication, delivery, installation, and closout tied to contractual completion date. I am planning to use a comparative chart on same page to track actuals and update the powers that be as needed to keep them informed of progress or lack thereof. To me this seems like a simple task with an annual grid laid out with colored pencils on a template, scanned and emailed. Does anyone have any other ideas? I am looking to not only push the process forward, but to protect my firm's rights to collect for delays. I may also chart anticipated vs. actual cash flow as we experience schedule slippage and are forced to expedite toward the end of the project to make up for delays by others that impact our work. Thanks for any response.
-- Michael Berry (email)
I have stumbled into a different kind of problem in the realm of project management. We have a number of projects with income from grants (that is, the income is fixed regardless of actual costs).
Some personnel costs are shared among projects. Joe might work on project A and project B. Sue might work on project A and project C.
Project start and end dates are not synchronized. Project A might start on July 1, 2003 and end on June 30, 2005; project B might start on Sept 1, 2002 and end on Aug 30, 2007.
For each employee, we know the percentages of salaries that come from each project. Joe spends 50% of his time on project A and 50% of his time on project B; 50% of his salary comes from A and the other half comes from B. Sue's effort is different - her salary is split 30% from A and 70% from B.
I am looking for some way to view these salaries and their sources over time - so we can easily see when we need to shuffle people and their salary from one project to another when a grant is about to expire. My supervisor suggested Gantt charts in MS Project, but I'm not sure if that is really the best way to visualize this information. Moreover, I'm having trouble wrapping my head around the various project management software packages in order to get them to fit our data. Any thoughts?
-- Jennifer Steinbachs (email)
Fascinating thread! One of the obvious drawbacks to the Gantt chart is that it is such a sparse chart -- each horizontal line contains one and only one task. I saw only one response in this thread that mentioned Artemis, but that tool offers a very simple improvement to conventional Gantt charts -- multiple activities can be grouped together and displayed on one line. Imagine that each line represents a resource (person, equipment, or facility) -- i.e., swimlanes, which have been discussed in this thread -- and the activities associated with that resource are displayed as bars on the right. Resource specific information can be displayed along the vertical axis, and timing information (e.g., milestone dates) on the horizontal axis. Task information can be printed inside the bar itself. The result is a farily dense display of project information that from a distance gives a picture of resource availability, and at a mid-level shows which activities are being done by what resources when, and at a detailed level can tell you specific information about the resources and activities.
This is a view I have seen widely used in a manual fashion for shop scheduling -- I am actually surprised it has not made into MS Project.
-- Greg Gruber (email)
Wow. Nearly 4 years and this thread is still hopping. Must be a record. I must say I've been using the COTW (Cards-On-The-Wall) approach for Work Breakdown Structure sessions and Network Diagram sessions for quite a few years now, and nothing can beat it. The fact is that these are meant to be collaborative exercises, not activities done in isolation.
The vibrant atmosphere of a group of people moving cards and masking tape around on a wall like so many chess pieces in order craft a solution is, to me, the most exciting part of project management.
Of course, if the person you're collaborating with is in a different location (or country), this falls short. In those circumstances, I came across two pieces of software in recent years that are pretty useful for brainstorming (and, no, I don't work for either of these companies). One is Mind Manager from Mindjet (www.mindjet.com). It's extremely intuitive and offers several graphical alternatives for capturing and connecting ideas.
The other is one that I actually came across while storyboarding a screenplay (one of my side passions). It's called Writer's Blocks (www.writersblocks.com). It's really meant for storyboarding a screenplay or novel, but it works surprisingly well for "storyboarding" a project---sort of a technological version of Cards-on-the-Wall.
As for managing and viewing the project schedule itself, four years later, I still feel that Prof. Tufte's example back from 2002 makes the most sense. I'd still like to find a way to put operational code behind that model. To view a schedule in the context of the people and teams working on it is extremely powerful.
Once again, now that I'm more involved in the Project Management Institute (on the leadership team for their upcoming standards for Program and Portfolio Management, and on the Board of Directors for their Aerospace and Defense SIG), and as such can navigate the waters a bit better, I'm going to approach PMI with a proposal for a research project to study new ways to evolve beyond the Gantt chart. There would be no better place to begin such a study than with this thread.
Ladies and Gents,
I find it a huge honour to sit amongst some of the best systems people in the world.
My bag used to be motorsport - F1, Champ & Indy Car, LeMans Car, and we didn't get the opportunity to be late, over budget or anything else. Now in the aerospace game.
Project Management - now I'd like to ask your advice on how to manage actually manage a project (in real terms) visually. I'm not talking about paper/ charts/ computer software, but the reality of visual management (5S) to allow anyone to see (today) where the project is. Departments managing themselves, but using a finite project plan to allow for the fluffy things that seem to be being discussed here.
Q. How can a race car go late? - A. It can't!
Project management is about not having a 700 or 7000 line gantt chart, but being able to identify the little projects trying to get out out of it! ..... and then visually managing them such that everyone knows what is going on!
-- Mark D (email)
I have been messing around with computers and projects since 1950 but have only just discovered the existence of this very interesting website. As I read the contributions I saw that newcomers to the wonderful world of project management are discovering problems that have been around since the Chinese built their Wall and earlier, though disguised in modern terms.
Even with computers there are still many problems to solve, one of the least surmountable of which is that of discussing the detail and progress thereof to non-project people, customers and the inhabitants of the stratospheric boxes of your own company organisation chart; people who run at the very sound of a Gantt chart snapping at their heels.
The key to success is talking to outsiders in their terms, not ours; pictures of their bridge, their phone network, their rail track, not bills of materials, assembly instructions or critical paths. They want to see the thing itself, or at least its portrayal. What we want is their picture, colour-coded in terms of criticality say, tied into our project plan via hotspots enabling the PERT-shy to ask questions and the project manager to answer them merely by clicking on the spot in question. As the manager clicks himself down to the offending detail he explains the circumstances in miraculous clarity even though these particular ones may be hitherto unfamiliar to him.
Let's call this Picture Project Planning and Management. It is what the world had been waiting for until very recently, which brings me on to a potted history of PM systems. The first generation came about during the punched-card, batch-processing era up to about 1979: calculator-friendly. Then came the second-generation interactive era with screen pictures of bar charts and histograms: planner friendly. But now we have arrived at the era of screen pictures of the subject of the project itself: manager and customer friendly.
This has been a far from trivial problem. But it has now been solved and at least one such system, QEI, is now well entrenched in a number of companies. For anyone more deeply interested I wrote an article about it in the November, 2004, issue of Project Manager Today.
-- Norman Sanders (email)
Some of you may be interested to know about a a book which illustrates an early approach to project management -- "Perpignan 1356: The Making of a Clock and Bell for the King's Castle".
I came across it by chance one day in the Engineering library at the University of Toronto. At the time, Gantt charts were being used where I was working and it was fascinating to find a point of comparison for project management which was so far removed from what we were working on (phone billing databases) yet which still yielded so many similarities.
The book is a translation of the detailed account book from the Perpignan bell project. It gives a view of the processes involved at each stage of construction (building the tower, building the foundry to cast the bell) and shows every expense incurred, from the cost of materials and the different forms of labour, to the cost of the food and bedding that had to be provided for the labourers.
A nice companion piece to that book: "The Measure of Reality: Quantification and Western Society, 1250-1600" by Alfred W. Crosby, about the major shift in perspective of which the making of the bell tower was a part.
-- Eleanor Allen (email)
ET asked if someone would post in the PM thread some excerpts from today's Wall St. Journal on Ford Motor Company's "spiritual re-think" within the company, dubbed the "Way Forward."
The operation is run by Mark Fields, who previously ran North and South American auto operations.
'Way Forward' Requires Culture Shift at Ford
By JEFFREY MCCRACKEN
Staff Reporter of THE WALL STREET JOURNAL
January 23, 2006; Page B1
. . .Mr. Fields, who says his goal is to create "a sense of crisis, but not panic," among Ford employees, believes this cultural shakeup will work where others failed because fear is a good motivator. He is fond of using the phrase "change or die" in meetings.
Mr. Fields's focus on culture is evident in the drab, cold, windowless conference room deep inside Ford's Product Development Center here that has become the Way Forward war room. High on the wall, hangs a big, white sheet of paper on which is written: "Culture eats strategy for breakfast." The room is ground zero for the group of managers that has worked for the past two months to develop the Way Forward plan. Among other maxims on the wall: "Culture is unspoken, but powerful. It develops over time -- difficult to change."
In an effort to make this restructuring succeed where the previous efforts failed, Mr. Fields tapped several hundred workers across Ford to be part of the Way Forward planning process. . .
. . .His top two lieutenants on the effort are Anne Stevens, a Pennsylvania native who is chief operating officer of the Americas, and Robert Shanks, vice president and controller of the Americas who worked with Mr. Fields at Mazda and Ford of Europe. . .
. . .Ms. Stevens and Mr. Shanks have had day-to-day control of the Way Forward plan, meeting every day for two hours or more in the windowless conference room with a group of 20 to 50 people who were working on the plan. . .[this is] the Way Forward room, where about 20 sheets of papers are posted around the off-white walls, encircling a long, rectangle table that is actually smaller desks placed together.
Mr. Fields, who banned PowerPoint presentations for Way Forward, said he likes to see plans posted up on the wall where he can see the development of an idea. On these big sheets are detailed lists of what customers Ford wants, a discussion of how a turnaround is supposed to feel "uncomfortable but exhilarating," and something called the "Rules of the Road" which implores employees to remember "conflict is healthy."
At the top of one wall is a chart showing the timeline for the plan that launched Oct. 3 and needed to be wrapped up in time for presentation to Ford's board of directors on Dec. 7. A "Days Remaining" calendar has a big zero showing.
This is as pathetic as the New Orleans recovery plan posted in the rocket science thread.
-- Edwrd Tufte
Sets of Project Variables
Admiral Gehman (above and here): Time, money, quantity, and performance margin
Daniel Spock (above): time, money, effort
Martin Ternouth (here): cost, scope, quality, and time
A loose conversion between the Gehman set and the Spock set is also to be found above. The conversion between the Gehman set and the Ternouth set is probably semantic (Martin?), and so the conversion between the Ternouth set and the Spock set would follow from the Gehman-Spock conversion. The Gehman-Ternouth set then? Are there other sets?
What a great confluence of experience! Music to theater to novel-writing to aerospace to IT and everything else. Except for Mark D, however, who mentioned 5S, I don't see anything from what is termed "lean manufacturing." Don't get hung up on the word "lean." Except for those misusing it, it doesn't mean getting rid of people.
To my point, and I'll add a fuller post soon, the quest for visual management is part of this philosophy, with Toyota being generally credited for its fullest implementation.
A few months ago, I had the good fortune to meet up with Takashi Tanaka, who has had many years experience in product development projects at a world-leading Japanese automobile manufacturer. We worked together on a paper (his knowledge with my writing experience) about visual management of projects. Imaging being asked to design a new vehicle for the European market - a hybrid - twice as fast as products are usually realized. The "oobeya" is the center of the project management, with a set of visual tools that bring all project stakeholders together. Before you say "we have a war room too - what's the big deal?" consider that the key lies in the discipline and subtlety of what takes place there in this company's use of it.
This is a link to Takashi's paper:
If you have trouble downloading, go here and click on the link they have posted:
I also have a flock of lean practitioners who will be fascinated with your work, and can add a lot of different thinking to your discussion. I'll take this further in a later post.
Just wanted to get my oar in right away.
-- Karen Wilhelm (email)
To understand where we need to go from here on this topic of project management graphics, Gantt chart, or CPM diagrams, etc. we need to accept that the schedule - tabular or graphic format with or without logic has now entered the Web era.
The paradigm of this discussion as it relates to the world of project management has changed. We need to look at what affects the web based systems have on the management of the project graphic schedules in the 21st century
So I would like to ask the question what can Project Management Graphic (project schedules) in the Web & Enterprise era be vs. what it was in the pre-Web Enterprise era.
Here are some of the essential parameters and variables of the schedule that is usually put into a graphic format:
Essential Parameters
* Tasks definition
* Task duration, start date, finish date
* Task Logic relationship to each other if you go that far
Essential Variables for updating
* Task Actual Start, Finish
* Task Percent Complete
* Task Remaining Duration
Information required from the schedule for
Management information and decisions making:
* Performance indicators Earned value (actual percent complete)
Schedule performance
* Performance against plan
Schedule Variance (Forecast - Budget)
Critical or at risk tasks
In the web based world what schedule graphic representation is important for what level of management to work with?
Levels of Management:
1. Company Officers
2. Department Manager
3. Project Manager
4. Project Controls Engineer
As we go up the levels of management the type and detail of the graphics involvement increase. A Company Officer manages by performance indicators and executive summary reports. The Department Supervisor produces the summary reports and justifies the performance indicators but manages from one level down in the details from the company officer. And so forth. By the time you get to the project control engineer's level they are developing and managing the most detail information of the schedule.
Is the answer a different and better business orgainization or just better trained PM's putting Gannt chart together with better work breakdown structures?
-- Stephen Wilchek (email)
I have been asked by the RAF (Royal Air Force)to look at the visual management of their projects, so I have read this thread with interest and tried to apply the ideas to a simple exercise. So my attempt at using swim lanes and many of the other suggestions has resulted in quite a good visual diagram.
I was particuarly struck with the idea of an orchestral score so
for fun I wanted to see if it is playable and amzingly it is, I have just done it on the piano, its not very tuneful though. Anyway I hope to have a copy of my simple exercise to post soon.
-- Nicola Bateman (email)
I have read this forum with great interest. I have only managed IT projects (the one office and computer room renovation project I managed pre-dated PCs) apart from personal projects. I really liked Microplanner X-pert on the Mac but my employer preferred PMW, later renamed Niku and now Clarity. However, I have used MS Project quite a bit and it does do some of the things people have expressed an interest in.
I have followed one basic principle which others might not find suitable: keep the projects small - max about 500 to 600 items - as the human brain is limited. You can create sub-projects to provide further detail. When we wanted a wall chart we outsourced the printing to a commercial printer, printing on double A0-sized paper (about 2 sq metres, or about just under 4' by 5.5'). The rest of the time we printed smaller views or partial views on A3 paper which we then stuck together. The big limitation is, of course, your computer screen.
MS Project provides two views that we use: GANTT chart and Network Diagram. Project uses the standard Office feature of a tree-hierarchy that allows collapsing the bottom level tasks to a summary level, which can in turn be collapsed to a higher level, and so on. So a schedule of 500 tasks can be grouped into "activities" (using a non-Project term) of any number of related tasks, thus showing a GANTT with only say, 50 to 60 lines.
The same summing up can be done on the Network Diagram. The advantage of the Network Diagram is that it shows the dependencies between tasks/activities. The disadvantage is that it just stacks them in sequence and does not attempt to arrange them in a spaced-out time-line like a GANTT. I manually drag the boxes so that they are distributed in an approximate time sequence (another reason for keeping each plan small). Project allows some limited ability to modify what details are shown in each box.
I first used this on a systems migration project where we had several teams of people working simultaneously in two countries executing some hundreds of tasks and running thousands of jobs on mainframe computers across a week-end from Thursday night to Sunday night. We had a "control room" in each country with an identical chart and crossed off each item as it was completed and reported to the control room. The Network Diagram showed the dependencies so at points we had to wait for some job to be completed somewhere else before we could proceed. We will be using this on our next major migration project spanning two states at the end of this month.
-- John Yeo, RegPM, Australia (email)
I have just produced a wall chart that combines a few of the topics raised in this forum, and though it was produced quite quickly, it was made me re-think a lot of questions about processes and project management. The chart in question is showing 'Earned Value Management', developed on the back on new Lean procedures on a major aerospace project. It is made from nine, eight foot by four foot printed panels fixed together and mounted on the hangar wall.
The chart uses 'swim lanes' to show the responsibility for actions. Although the layout is fixed (being printed on the boards), the documents that are referred to on the chart are actually in plastic wallets attached to the boards, so it is possible to walk the chart, read and update the documents as required. As long as the process connections are fixed and in place, this should work out ok.
It is quite an investment to print this in full colour at this size (especially if the connections change), but I was surprised how you could actually stand back and follow it from start to finish, before moving in to read actual documents.
-- Adam Poole (email)
In an interesting coincidence, I'm a composer (who stumbled onto this thread via a link from a page that lists open source project-management software, http://proj.chbs.dk).
I've been looking for -- and may end up designing for myself -- software that can graphically represent the life cycles and deadlines of my pieces, their relationships to other things (performers, conductors, grant applications, competitions, etc.) and the relationships of all these things to the rest of my life (travels, money, long-range plans, etc.).
An orchestra score might look complex just because you're not used to the language, but it's actually VERY simple in terms of information design, in that it's completely flat -- there's no need for "zooming" to a lower level of detail, because there's nothing further you need to know/represent about any given note or phrase (i.e., any given task).
The issue I'm tackling (and I see it's a common thread here) is how to make a simple yet highly zoomable design -- one that produces several results equally well:
1) a long-range visual overview I can use for planning and scheduling via eyeballing ("Can I say yes to these January residency dates? Well, let's see which pieces/grants/etc. I'll have in progress that month and whether I can afford to get to that country...");
2) many easily-accessible bits of detail re. each element in this overview;
3) links among all these details, as in a relational database (piece tied to performer and commissioner and deadlines and grant applications -- conductor tied to piece and ensemble and dates and pieces-in-progress-I-should-send-to-conductor -- etc., etc.); and
4) the ability to UPDATE all these details and links by making one change at one central point (again, as in a database).
So far, I've actually been keeping all this info in a set of many text files inside my favorite simple text-file manager (Palm Desktop). This only works because I have a good memory and I'm naturally organization-inclined and good with symbols & abbreviations. I think the time I would spend creating some db/reporting system like this would pay for itself pretty rapidly in future time savings. But I'm only in the first stages of designing it, and I only have the db/etc. knowledge I've taught myself (these ain't skills you accumulate in a conservatory)...
-- Kala Pierson (email)
Another thought, for project managers who need to present complex info to their team members: even more useful than the orchestra-score example is the example of orchestra "parts."
The conductor is the only person who uses the full score with all the instruments' lines. If you're a member of the orchestra, you play from a "part." In a part, most of the page is just your own instrument's notes, but some of the page (and here's the important point for this thread) is taken up by cues. Cues are short phrases of music, printed just above your own notes and using miniature notes, that occasionally show you important things other people are playing. This lets you listen for important moments and it works as a reality check ("Okay, in case you weren't counting perfectly, just know the oboe comes in here and does this phrase, then you start your next phrase just after the oboe plays the B flat, right HERE.")
So the issue with big complex projects is deciding exactly how much an individual needs to see in order to perform her own role perfectly yet avoid wasting time on comprehending (and materially dealing with) the entire project chart. In some cases it might be useful to think of a project manager as the conductor, and team members as the instrumentalists who don't necessarily need to see EVERY detail at once, but frequently need very localized & very detailed glimpses into other people's tasks, in cases where those tasks precede, "cue" or otherwise intersect with their own tasks.
I have a four-metre roll of paper that contains the whole of the last movement of
Beethoven's Seventh Symphony: I use it in seminars to illustrate how reality (a recording
of the movement) cannot be summarised, but can only be visualised by the complex detail
of individual events - the individual notes and their relationships at any one point in time.
Kala is right that not everybody needs to see everything: she is equally spot on when she
recognises that when when you do need to see what other people are doing it is not
sufficient to have an edited summary: "glimpses" must be "very localized & very detailed".
"A company can recover from anything... except running out of cash" - Lou Mobley
The element of cost and more specifically cash management has been lightly touched on in this thread, most likely because of the large scale of most projects alluded to. In some industries, startups and smaller companies, the issues of cash flow and project management can not be separated. Construction projects are regularly delayed because a sub hasn't paid a bill and can't get materials - although they won't tell you that. I have struggled for years to find simple project management software that deals as well with dollars as it does with whether the conference room is available Tuesday afternoon.
This brings up the thought that once the tasks are set, an ideal system should allow each user to specify what elements will impact their task whether it is manpower, the weather, billing cycles or use of a facility. Then the system should ask where the necessary information can be found for all the various impact elements throughout the project. Once identified, the proper user (or satellite weather feed) can be prompted for timely input. The output likewise would be tailored like an individual instrument score complete with different cues.
The difference between an orchestra and an airplane is that the flute can forget a passage while the plane can not be built without the left flap. Somehow the manufacturing process has to be rearranged to make the flap, a symphony can not played in any other order than that in which it was written. This may mean any output based on a score paradigm, may not work too well. An aside on information display. There used to be a notes program, pre windows, called Tornado Notes. New notes came up with different colors, shapes and screen locations at random. Often you might not remember the contents, but you could remember it was yellow, square and on the left side of the screen. A fantastic amount of information could be stored without any key words or index.
-- CG Yerkes (email)
The chart is posted here.
Some very interesting concepts continue to be discussed here, even after all these years. This is certainly the world's leading forum for discussing project management visuals, especially given the eclectic perspectives.
I'd like to contribute a few additional perspectives. First, I've seen several analogies here to orchestral arrangements and parts. While I love the visual and multivariate data aspect of musical notation, there are some nuances in project management that pose a special challenge.
First, most projects are abstract as opposed to concrete. In music, it's OK to lay out a complex orchestral arrangement and people can play their parts and it gels (in fact the parts can be likened to "work packages" in project management).
In projects, however, situations change soon after the project begins. We must have a way of keeping the plan fluid to changing events, but we must also keep the parts in synch. If we're on the subject of music, project management in many cases could be more likened to jazz, where some musicians change tempo or go off in a different direction, still within the general theme (or "rules of the game"). Soon the other musicians catch on and things are gelling again. In music it might be the mood or feel that caused the change --- in a project it might be a fact-based discovery mid-stream, or an unexpected event. Good principles can help insure "controlled chaos." (ironically, "Controlling Chaos" is the name of a popular PM blog site, but I digress).
Also, it's usually not adequate for someone just to know "their part" in project management I'm reminded of the man who walked up to two stone cutters and asked what they were doing. One said, "I'm cutting stones." The other said, "I'm building a cathedral." In most projects, we want people to be the latter or we could get unexpected results.
So, we can probably assume the following requirements for project visuals:
1) They need the ability to be easily changed on the fly---frequently. Of course for some projects in some industries, things are less fluid, but in the IT field, the BDUF (Big Design Up Front) method is rare. More likely projects are progressively elaborated.
2) They need to show the big picture, while allowing focus on one part (or allowing team members to view their part alone or in context with the other parts - including dependencies).
3) They need to show multiple variables during the project lifecycle:
- Tasks (explodable at a summary or detailed level)
- Schedule Performance
- Cost Performance
- Task interdependencies
- Resources assigned
- Technical/Functional Performance (i.e. scope, quality)
- Value Delivered (real value to the client and organization)
- Customer Satisfaction (this should be tracked throughout the project to accomodate course-correction)
- Milestones (with comments or notation on any or all of the above)
The value and customer satisfaction measures in particular are often ignored during a project lifecycle. Often a qualitative measure or annotation would suffice in these areas, but it needs to be part of the picture to avoid project myopia.
I'd be curious as to others' views on the requirements of a good visual, but these come to mind. I still think music is a good place to begin for research because it has similarities (depicting time, instruments, scales, players, etc). Tools like audacity, Cakewalk, propaganda, etc. for recording just keep getting better. There must be some lessons there. We just need to be cautious of the different requirements between music and project management.
Wallcharts and Cards-on-the-wall are great for design and communication, but because of the above requirements, I find them lacking when it comes to a visual tool for status tracking and ongoing management of a project, unless everyone is co-located and the wall is kept fresh.
Incidentally, I've had no luck with the PMI research community sponsoring an official research project on this, so it looks like this thread is the unofficial one.
In project management charts, it would be useful to show, at least in part, what has already
taken place, experiences intensely relevant to theorizing about what will happen in the
project's future. See the NASA slip chart above.
Yes, an essential in all undertakings where reflection is deemed useful. You can also allow others to see what has been left out that should have been included.
-- Roger Daventry (email)
Great point. I missed that one. Even with standard Gantt charts, there's a "progress" version (or "tracking Gantt" in MS/Project) that shows actual completion vs scheduled -- by way of colored bars. Only thing is, there are no annotations to show major successes, failures or ommisions---just a bar marking the time spent. It would be ideal to build into a visual model a way to see that historical perspective where it has some meaning beyond just the passage of time. Sounds like another requirement.
I came across this paper a few months ago after talking with its author. The core is about understanding teamwork and how to design knowledge environments to improve team performance.
By Bill Sharpe
See page 13 on Project Braiding
-- Tchad (email)
Four of us are planning to work on a book together. I was wondering, Professor Tufte, how you organized your last book.
-- John Eckstein (email)
By chapters. Within a few chapters, sometimes an initial historical sequence, which I later
would recast and break up into topics within chapters. Given my actual research and
writing practice, I am utterly unqualified to give advice about effective project
management! Surely there some good essays on collaborative authorship.
Over the years, I've worked with many co-authors (1 book, 10 or 15 articles). Each
collaboration went well and so I have no particular theory about collaborative work, other
than all my co-authored pieces got done a lot faster than my singletons. I expect,
however, my co-authors would agree that none of our co-authored pieces are among our
better works.
It might be a good idea to have the writer with the best style (clear, elegant) do a final pass
through the whole book. Four co-authors might lead to an over-long book so at some
stage near the end there might well be a ruthless pruning and tightening up of the book;
this may be difficult in dealing with author of the original material but will probably make
a better book.
It will be helpful to identify several classic books (co-authored or not) in your field and see
what those books
do in organizing their content.
There's more on how I came to organize my work in the thread on Beautiful Evidence.
Coaches Use Laminated Game Outlines for Any Situation
The New York Times
By JUDY BATTISTA
Published: October 27, 2006
For a project management chart (or perhaps a technical report) in sports go here.
A couple of themes through this thread caught my attention:
1) Reliance on paper charts on walls
2) Emerging web technologies
3) Interacting with data on the gantt chart
and I will say this: after some 20 years of looking at office automation and presentation software, most of these problems are still with us and will continue to be.
My own personal bias is that (1) paper charts get very old very quickly, so that teams lose the ability to collaborate (2) on real data after initial planning is done and that most project managers are not facile enough with the tools to actually reschedule plans after the initial pass when change intrudes upon their lovely vision. Absent a live connection between the team and the management, most projects fail. (3) We also have to be careful that as visualization tools become more complex (OLAP cubes on the desktop) that we don't lose the connection between the data (in a SQL database) and the graphic (whether charting, tabular or graphic in nature), as different minds approach the same information more effectively in one medium or another, and it is critical that one update in one medium also update the other.
It seems to me that some of the features common to Geographical Information Systems (shaded area) would be especially useful to apply to Gantt charts, so that PMs could show relative temperatures (status? risk? value?) of tasks.
I look forward to additional advances in this field.
-- Mark E. Read (email)
We are general contractors, and much of our work is aviation-related construction in a major U.S. city. I have read this thread with great interest and offer my thoughts.
A typical city contract requires us to use Primavera brand Critical Path Method (CPM) scheduling software. This is the big-daddy of scheduling programs. Micro$oft Project, for example, performs much of the same tasks as Primavera. One wonders about the propriety of sole-sourcing a vendor like this, but that's what the contract requires. A city consultant dislikes the more current versions of Primavera, as do I--the earlier versions produce more somewhat detailed GANTT charts, believe it or not! Oversaturated colors and rigid formatting are two complaints. Constant scrolling and reliance on visual memory are major annoyances. Pasting the schedule on the wall is the solution, as others have suggested.
Every pay estimate requires the dreaded schedule update. Every request for extra time (that's not our fault, of course) requires us to demonstrate that the delay has lengthened the Critical Path. Since there are penalties for not finishing on time, a lot of money rides on the Critical Path. The city's consultant checks the effect on the CPM, and will not grant additional time unless the Critical Path has lengthened.
Our contracts are predominantly unit-price, and tying the schedule to individual pay items forces over-compartmentalized, linear thinking. Estimating software vendors will boast "our program will export the estimate into Primavera." Is that such a help? Four potential pay items (catch basin, frame/lid, pipe and stone) could generate four activities. Install a catch basin, then the frame and lid, then some pipe, then some stone, then another catch basin, etc., rather than "install storm system." One time, the engineer on a wastewater treatment plant project insisted that our schedule have separate activities for forming, placing rebar and placing concrete for each cast-in-place structure--no matter how small the structure--even a structure smaller than a typical office cubicle. Obsessing over schedule minutiae distracts everyone from more important things.
I feel that using fewer activities produces a clearer and more realistic schedule. To borrow from another thread: "Better to be approximately right than exactly wrong."
The schedule creation itself is the most useful part of the schedule--the process forces the contractor to simulate the project. At the least, it will show conflicts or bottlenecks at an early, correctable stage. Whether or not the schedule models the project correctly, well that's a different story!
A wise municipal engineer once said: "Schedules are great when they first come out, but after time, they go bad and you just gotta toss 'em out."
-- Jon Gross (email)
Thanks to Kindly Contributor Jon Gross for a most thoughtful contribution.
In reducing detail, It is obviously important to distinguish between routine detail and
relevant/unique/ important detail. The distinction for sorting information should not be the
level or mode of information but rather its potential for problems.
Many problems in project management (PM), including PM graphics, are the result of blending -- and thereby confusing -- planned outcomes with planned actions. Planned outcomes are the desired ends, including interim results expected along the way. The purpose of defining planned outcomes is to provide direction, stability and control. Planned actions are far more chaotic and more detailed, but they are the only way to provide forward motion. Planned outcomes are the best way to describe and organize project scope and they can remain relatively unchanged. Outcomes are the rudder and actions are the oars. Blending outcomes and actions is an error that causes miscommunication -- the most common cause of project failure. This error happens very frequently in the design of the work breakdown structure (WBS), an important first step in project management. I have just posted a complete re-write of the Wikipedia article on Work Breakdown Structures (http://en.wikipedia.org/wiki/Work_breakdown_structure) to convey that a WBS must be composed only of planned outcomes (the ends) not planned actions (the means). Inputs and feedback are most welcome.
Blending outcomes with actions is an information design error that is perpetuated by most PM graphics, including Gantt charts. Even advanced methods such as classic Earned Value Management do not clearly distinguish outcomes from actions. The optimal PM chart will visually distinguish four things: planned outcomes, accomplished outcomes, planned actions and accomplished actions, and provide a direct line of sight between them. Also, outcomes provide context for actions so PM visuals should communicate this context visually.
-- Garry L. Booker (email)
...In other words, "relevant/unique/important detail" include all actions that relate to a SPECIFIC PLANNED OUTCOME of interest. When a project team blends actions with outcomes, simply because their tools treat them as same class of data, one person's signal becomes another person's noise. A high signal-to-noise graphic with rich detail is possible only when planned outcomes and planned actions are treated as a different class of data, and actions are linked to outcomes.
It is far better to be exactly right in ALL details. A team that decides collaboratively on project actions can track great detail with great accuracy, but it requries filtering planned actions according to discrete planned outcomes. For example, I should be able to create an animation of my (or all) planned actions related to "WBS 3.4.1 Foundation Inspection Complete." I can say with some certainty that this capability does not exist today, but it probably will within a few years. There is hope!
Interesting reading, especially in that we all seem to have the same issues, etc. in easily representing various levels of project management information. I think the general sense is that MS Project does not fit the bill and Gantt charts in general display to little info for the space they consume (which is unfortunate since PM and Gantt charts are often seen as the same thing).
The downside to wall charts and any printed information is that, as soon as the project information is printed, it's dated/old and most likely out of date with what is actually going on. The need to have the chart/tool/etc. reflect future planning instead of past occurrence or set schedule (like a train schedule) is probably the biggest challenge in the design.
The tool I most heavily rely upon is MS Excel, I've created some simple spread sheets that show multi-level information by Project such as: Component/Area, Task/Function, Status, Health, Est/Act Start/End Dates, Ownership and a timeline. Here's the link: http://itprojectguide.com/downloads/files/PTimeLine_Example.xls
It's a bit dated, but I think it provides a general idea. This provides for a high level that can be drilled down. It would be nice to have this DB driven so the rollup/drilldown could be automated based on entered info instead of the manual approach.
-- Meade Rubenstein (email)
Deep Principles
Way back at the start of this thread (March 20, 2002), E.T. asked "What are the deep principles and how can they show up in the design and organization of a project?" He also wrote: "Find out what the very best project managers do." Without question, the very best project managers use Earned Value Management (EVM). EVM exploits the principle of the Triple Constraint, by providing clarity and focus on technical performance, schedule performance and cost performance. However, I don't claim that Classic EVM holds all the answers. After all, it has been around for nearly 40 years and only perhaps 1%-2% of projects employ EVM. Innovations in EVM are still needed.
Much of the EVM literature describes the single most important benefit of EVM is cost control. I disagree. That is indeed an important benefit, but I think it is secondary. A deeper principle is the ability of EVM to improve the productivity of the workforce. If the productivity of knowledge workers can be improved, cost control becomes a secondary effect. Cost control is no less important, but productivity is simply a pre-requisite -- a deeper principle.
In this light, I have written an article that was published by Projects@Work today. See the link below. The article defines what I believe are the deepest principles of EVM:
(1) Planned Value a lead measure of productivity -- or it can be.
(2) Earned Value is a real-time measure of productivity -- or it can be.
(3) Actual Cost is a lagging measure of productivity.
The third item is common knowledge. The first two cast a whole new light on Information Design. Classic EVM sums data to a high summary level before exercising its analysis formulas. It also waits until cost data is available before using any of the available data as lead measures or real-time measures. Classic EVM also uses too many acronyms for average knowledge workers.
One of the reasons Gantt charts fail miserably is that they do not employ ANY of the three deep principles listed above.
By the way, the Projects@Work article cites this discussion thread; there is a lot of potential for EVM innovators and Information Design innovators to work together.
See http://www.projectsatwork.com/content/Articles/234573.cfm
It should be noted that I have no experience in project management - I have never worked on a project professionally. However, in order to manage my own, complicated projects (designing and implementing a programming language is the main complex one), I figured out a graphic much better than a todo list.
For anyone familiar with mathematical graph theory, my representation is essentially a directed, connection weighted graph. In more common words, it is a chart of tasks connected by dependancies of varying weight. Low weight connections indicate that ideally, yet not necessarily, one task would be completed before the next. High weight indicates that it is truely imperative that one is done before.
The graphical rendering of this scheme is textual summaries of tasks, with arrows from tasks towards dependant tasks, with arrow width corresponding to qualitative dependance. I would post pics, but they were done more fast than visually appealing.
I realize that this doesn't satisfy the seemingly main requirements of project management, of assignment and timing. I believe that this information could be integrated into the chart. Possibilities include integrating images/names along tasks, and positioning based on time estimates, after the graph has been 'resolved'.
You will find that this view of the task gives much insight into what needs to be done - things which open up more additional tasks are generally higher priority. Sometimes you will have interesting things like cycles - indicating that at some point a dependancy must be broken.
-- mgsloan (email)
Thank you very much for insights. I am the PMO of a business group of a large financial institution that loves PowerPoint and VISUAL scorecards. On the other hand, pipeline and project tracking is held in MS Project. I build scorecards/quadrant maps out of MS Project by using the Gantt chart and formatting the bars/milestones/associated text so that they are just plotting points on a white timeline. Great data/ink ratio, but it does not seem that I can also customize the COLOR or the FONT of the TEXT associated with the "bars" in the bar style customization of MSP, although I would like to also use the text color to convey meaning beyond the words. Does anybody have further advice for me - I believe what I am trying to do is very relevant to this thread and evidence presentation, so I would appreciate publication and help. Thank you .
-- Paul LeBon (email)
The above poster was mentioning how he wanted to do some formatting with his projects,
so hopefully this sparks some ideas in how to get more information onto gantt charts.
And it just happed to tie into something I was already playing around with, which
is trying to reproduce Napoleon's march in a gantt chart. For me it was an attempt at how
much information I could cram onto a gantt chart, and still have it be usable. I'm not
totally happy with the result yet, but I think that there is some potential.
In order to get the relevant information into the chart, I had to use more text than I'd
like (all of the positional information and weather conditions are text). The completion bar
(black/gray bar) is being used to show how much of the original
army is dead. So on the downfall march, its pretty much entirely black. This of course isn't
best since we have different sized bars and the percentage is much harder to comprehend,
but I hope to find a better way. I'm also using resources to show much of the army is dead
at any given time point. At the end 1% of 100% is still alive, for instance.
While this doesn't have the same elegance as the Minard, it can be made by mere mortals.
PDF Version
This was made using the recently released OmniPlan, which I'm
shamlessly plugging, and my current file can be found here. Suggestions on
how to better convey the Minard data glady taken.
-- Rowan Christmas (email)
Rowan's dilligent hard work has done us a service. The graphic is attractive and easy on
the eye, but by attempting the task of representing Minard in this way he demonstrates
just how unsuitable GANTT charts are for displaying information about sequences of
events. Minard communicates instantly to the untrained mind: I suggest that Rowan's
graphic would not be understood without very careful study by anyone who had not seen
the Minard original; and even those of us with long familiarity will struggle.
Rowan's comment about 'mere mortals' interests me. Minard can be reproduced in a
fraction of the time and with a fraction of Rowan's skill with OmniPlan by using two
different coloured crayons on paper. All too often we (I am as guilty as the rest) allow
technology to determine what we communicate, and assume that digital is more grown-up
than analog.
I've saved a copy in case it's deleted here, but I thoroughly concur with Martin. The juxtaposition is marvelous.
Following on my earlier post, I have posted an example of what I am trying to achieve here : http://www.kaboodle.com/pabcbc/project-visualization/talking-gantt-chart-using-bar-styles . Here is the accompanying text :
"I want to show status of projects using as much visual indications as possible. Using default formatting for bar styles on M...ft Pr...t , and then editing one by one tasks to give them a Green Yellow Red progress indicator, this is what I can produce. I could also add the baseline, which I will do in a further iteration. I can add text in 3 positions around each task, but I have not found a way to : 1. make style of individual bars conditional upon flags or attributes and 2. vary the font to add visual indications " - thank you for your interest. I believe that using this formatting and taking out lots of useless data ink to only show progress towards end milestone and thinking of using color/text font to convey information, I am improving standard project reporting a la M....ft P...ct where a lot of useless ink is used to show horizontal bars.
-- Paul LeBon
A fortunate `web-based' stumble led me to this forum and I have spent the afternoon reading through your contributions. Suffice it to say that, due to the fascinating nature of the information offered, I am now famished (having read right through my lunch brake) and also fairly bleary eyed.
I would like to pose a question with the hope that it hasn't already been answered. (There is always the possibility that I missed it in my whirlwind quest to attain Project Management knowledge through this forum!)
Why is the Gantt chart so widely used if it displays information in such an unsatisfactory manner?
I would imagine that it has something to do with its simplicity....? Time on the x axis, activities on the y.
The ability to quickly and easily understand / create something with little or no training goes a long way, especially in a fast paced work environment.
Taking the musical score example, we need to display pitch (translated into an action by the musician) & rhythm (time). From a violinist's perspective, when reading music, the vertical position of the dot dictates the placement of the finger on the string (what action to take), the horizontal placement of the dot indicates the point in time that it is to be played (when to action). To me this seems uncannily similar to the layout of a Gantt.
I have only dealt with a few fairly small projects so far but I have found a large, wall based "Activity vs. Time chart" (dare I say Gantt chart??) at the centre of a kind of spider diagram works well. Descriptions and exploded views of activities linked to the chart with coloured string and tape / pins. Maybe a little "Heath Robinson" but it seems to work and anyone can understand where the project is up to within 30 seconds of walking into the room. Also, scale props and models always seem to be a help. (as discussed above keeping it up to date can be a pain but worth the effort I think)
Maybe I should stop extolling the Gantt chart and go grab something to eat...
Before I go, I cant help saying "TPS" Visual Management, 5S, $18 billion operating profit.... Something works!
-- James Leek (email)
I don't think it's fair to malign a structure without considering their context of use. Gantt charts are an excellent illustration of the Match-Mismatch conjecture:
"In general, every notation or information structure highlights some information at the cost of obscuring other information." [1]
Gantt charts clearly present time and duration information (witness Rowan's astonishment about the short duration of Napoleon's march). But they obscure other information, such as dependencies, unless they are expressible as a tree. And Gantt charts don't scale well to large numbers of items in the vertical.
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.
[1] DJ Gilmore, TRG Green (1984). Comprehension and recall of miniature programs. Int J Man-Mach St 21(1):31--48
-- Brian de Alwis (email)
Response to James Leek
James Leek said "anyone can understand where the project is up to within 30 seconds of walking into the room." An increasingly large portion of project teams are not able to walk into the room, because of their geographic location. But more importantly, we should visit the project team members IN THE SAME BUILDING and ask basic questions like "Are you aware of the latest Gantt chart update?" "Do these updates have a strong influence on how you focus your attention every day?" "Does the Gantt chart tell you anything about our cost performance relative to our scope performance?" "Does the Gantt chart help you communicate YOUR status to YOUR stakeholders?"
While the Gantt chart may be popular for some project managers, it may not be that popular with the front line (or with clients), if we would only ask them. /Garry
Two fascinating diagrams comparing process calls in Linux and Windows servers delivering the exact same html webpage with a picture. Each unreadably small horizontal line of text represents a system call and each spaghetti line connects it to its parents and children. Seems significant to this thread for a few reasons:
Richard Steinnon posted these on ZDNet to illustrate why Windows is less secure than Linux, but it seems to me an excellent way of illustrating how a project can be designed well, or not so much.
Is it really a project? It has a real deliverable and all the Gehman-Ternouth variables can be measured: cost, machine-hours, it is implemented billions of times a day, and there's a quality element in that every dropped call or packet requires implementing feedback loops to correct the error, costing machine time and energy.
The difference between the two also illustrates the Spock effect: time and money can be saved through a difficult-to-quantify-in-advance thing called effort.
As a person with many years of experience in software development and design. I would definately view the windows code as poorly designed. It illustrates a lack of object oriented design. Its very diagram is that of "spaghetti code".
In my professional opinion, its looks like a freshman effort at writing a server with no actual design taken into consideration. Whether or not it can be considered secure is another question, but seemingly its design would lead to many edge and corner cases.
However, while the function diagram is interesting, I don't think it works well as an analogy to project management, especially for large projects. The chart does not take into account execution time. It simply shows dependencies.
-- Matthew (email)
Matthew said:
I don't think it works well as an analogy to project management, especially for large projects. The chart does not take into account execution time. It simply shows dependencies.
A friend of mine from Washington state told me a story of negotiating with a railroad on behalf of a saw mill to get a spur run to the mill. The railroad said it was unfeasible because they would have to either spend $40 million to design a bridge over a river and run five miles of track, at $1 million per mile, or run sixty miles of rail up to the river's head. This friend of mine, driving past the rail yard in Seattle on day, stopped in and asked someone if they had kept the plans for bridges built in the area. Not only did they have that, they had stock plans for bridges of all types, shelved by width and depth of the chasm that needed crossing. Cost estimates were included and the bridge he needed would cost $5 million in inflation-adjusted dollars.
I don't recall if the spur was ultimately built, but the point is that these archetypes have been thought about (particularly I would think in the years after WWII), charts like these Linux and Windows charts can be modeled based on previous experience, and some may already exist. Make them openly accessible and cataloged on the Internet, encourage iterative, public development and project management may quickly develop some amazing meta-forms.
I work at Sana Security. I wanted to correct an error concerning these graphs.
The graph marked "linux server" is actually for the Apache web server running on windows.
The graph marked "windows server" is actually for the IIS web server running on windows.
So this is not about the difference between Linux and Windows, but about the design/software architecture of Apache (open source, multi-platform) and IIS (closed source from Microsoft, windows only).
The graphs were made with the Graphviz software from ATT (www.graphviz.org).
-- Matthew Williamson (email)
My premise that open source beats closed source still holds, though "Linux" must be replaced with "Apache", but thank you, Matthew, thank you for correcting that. For other readers: two people at Sana Security were contacted on 5 February about this thread. Richard Steinnon has been emailed about the error in his ZDNet post and the error has been recorded in reddit's comments section.
Reading through all these responses brings me to the reason why I searched and read this thread. I can't seem to provide acceptable Project Plans, Gantt Charts, views or other means of status that all levels accept. Upper management wants the quick details only with the ability to ask micromanagement questions for the high levels shown. Mid management wants to see the details in their area in a format other than that presented and the contributors want to see everything they will be doing. I have reviewed hundreds of samples, tried Microsoft Project, Excel and even PowerPoint to present, but all are difficult to update quickly for meetings at acceptable levels. The projects I deal with are almost always integration projects with construction, building renovations, IT implementations, office moves and client implementations for call centers. Getting it done successfully isn't the issue, it is that of presentation to encourage better understanding and participation. All the responses are great examples with the same question: "How can it be done better"?
-- Alan Robitaille (email)
I recently completed a design project for an automotive OEM. MS Project was used at the project manager level for whatever segment was appropriate (large projects might have multiple PMs for various sub-projects).
At the executive presentation level, a VBA application was written to take the various .mpp files and consolidate them into several Access reports. These reports would, among other things, show late milestones by project and color-code the degree of lateness. MS Project does not have a good way to document remediation steps for those late aspects - each PM would also have an Excel spreadsheet for issues.
Monthly executive reports would have PPT slides with a simple traffic light metaphor for standard categories of project execution, and the PM would fill in the problem and remediation for each category. For a VP with $80 million of projects running representing 25 different objectives for 12 different business owners, any lower level of detail was self-defeating.
I suspect this is fairly typical, though not necessarily ideal. It's cheap and uses common tools. If there is a one-size-fits-all product out there that can record detail for the team level and useful aggregation for executives, that would be great. But remediation and action items can have a many:many relationship with specific tasks in the project plan and I think any product would have great difficulty in properly making those connections. Once the plan is revised based on the remediation, all those connections must be revisited. Spaghetti diagrams can illustrate complexity, but they don't do a good job of explaining it - there are simply too many connections.
Whatever tool leads to a desirable result - use it!
This past week I've started on a new project at work. One of the first things I was asked to do was put together a project plan. Normally at my firm this is done using Project or (strangely) Excel (columns are dates, tasks arranged vertically). I decided to try something new and use the layout ET prototyped at the top of this forum.
Since no package actually exists to produce those diagrams I did it all manually in Visio (its a smallish project). I must say, the response from the business sponsors was fairly positive.
At the top of the project was a timeline with days and months marked out. Above that were the proposed milestones and textual description of what that milestone was trying to achieve.
Below the timeline were the subtasks that need to be done. Those tasks were divided between Coding, Deployment and general Project Management tasks.
I wouldn't try this on a large project since there are no tools to support this format but the readability and transparency of what and when we are planning on doing things was quite good.
Only issue going forward will be trying to maintain the diagram.
Exceptional information, quite helpful in many instances recently.
As others have themselves noted, I also am not a PM per se. Yet on many projects I have had to communicate schedules/ demands/ resources/ dependencies to varying levels of personnel in a project structure. I have utilized many varying incarnations of charting (Gantt as well as other mutations), be it printed on 15ft rolls of paper or using a projection from a PC onto a writable background supplemented with 'post-it' notes.
Input and feedback being critical, we realized we needed individuals (as well as groups/teams) with ability to provide relevant data, not just an abundance of it. We also did not have funding or time to custom build or hand pick said personnel. We literally stumbled across the book "The Goal" by by Eliyahu M. Goldratt and Jeff Cox. It is a textbook written as a novel, and REALLY helped everyone from the top down to wrench turners understand impact of their actions on a process. The bonuses were: 1)it was cheap, 2)it applied to everything from manufacturing to individual tasks, 3) it took litle time to read and have impact on our tasks/ projects.
We found we had better data coming back to us in the managing teams, better input from all into charting, and personnel having a better understanding of what was charted and what affect they have in our overall process.
But the information from this site's ongoing discussion has been invaluable as well, and I sincerely hope it continues.
-- Henry Lester (email)
In the construction industry, it is common to have to consider "delay claims", which are legal claims against various parties to recover the costs associated with carrying the construction project for longer than anticipated. Because of this there is a considerable interest in "scheduling".
The evolutionary pressures in this environment have caused schedules to become massive lists of short term activities, (on the order of 2 days). In a 1 year construction project for a single moderate size building you might have 700 activities. The problems I have seen are several fold:
Combining all of these misunderstandings, user interface problems, and multiple requirements means that the schedule is a piece of garbage not worth the paper it's printed on. That's why so many of them wind up in court. Because although it's garbage, it is codified garbage, so eventually someone winds up in court claiming money because the plan said one thing and what actually happened was different.
The project plan is a model of reality. Like all statistical models, there is a tradeoff between bias and variance. By increasing the number of parameters (tasks) the project planner/scheduler is seeking to reduce the bias (ie. "leave nothing unaccounted for") however this rapidly moves into the high variance range... any random fluctuation in the actual events rapidly causes the model to break down. In the machine learning literature, a statistical model typically reaches its minimum sum of squared errors with around 4 or 5 parameters. For a typical construction project plan, I suspect that the right number of parameters is usually around 20 to 50, contrast this with 700...
On a computer, tasks are typically scheduled as follows: anything that is not waiting for dependencies is put on a "run queue", based on the available resources, the highest priority tasks are then assigned the resources they need, and are allowed to run. When they block, waiting for a new dependency, they are placed in a wait queue, until the next scheduling timeslice.
This is a completely reactive process, but it is similarly applicable to short term lookahead. By digesting the project plan down to goal achievement, rather than individual tiny subtasks, the project plan can become a realistic model. leaving a project scheduler to look ahead 1 to 2 weeks for short term tasks. The main issue is that subcontractors need to be able to have resources free to service the short term tasks. Long term lookahead can be done at the level of the project plan... arranging several months in advance to have the waterproofer available at some point for 5 days between week 7 and 9... with the two week lookahead giving a much more accurate picture when week 6 comes along.
By facilitating short term scheduling using "run queues" the day to day work can be better managed.
So I guess in summary, what we need is not necessarily better graphics for an existing process, but rather a re-evaluation of the process, and then better computer tools to support that process.
-- Daniel Lakeland (email)
in reading through all these answers (fairly quickly) one thought jumps out
the standard Gantt chart tends to have very low information density (as others have noted) in part becouse it's trying to tie in to labes over on the left
what do people thing about changing the layout slightly so that you don't put any labels down the left side, but instead color/crosshatch/etc code the 'active tasks' at any one time and down below the chart you have the key with the details of what the task is, who owns it, etc.
this sounds like it would go a long way towards improving the information density of the main part of the chart.
if you re-oriented the chart for time to run down vertically (think a long web page instead of a wide one) you could put the key for each new task off to the side even with where that task starts.
and you could re-use colors/crosshatch patterns/etc as long as you leave a reasonable space between uses.
David Lang
-- David Lang (email)
I've seen a lot of forums lately and just ignored them. But boy, this one I read recently is something else.
I'm into project management of large, multidesciplinary construction projects. MS project can do some part of the big job visually on the screen or on the wall.
In most cases, as the project rolls on, understandably the concerns are focused on what's going on in every "what" under "who". Questions and solutions to ever changing task, duration, relationship, delays, cost, resources, etc... can not be handled by one person alone holding a pen and paper.
In my many years of actual experience, I strongly believe that Primavera Project Planner (P3), (wonder why P3 is not discussed here more),... is the one tool that can be relied upon, the standard planning/scheduling tool of large multi task/projects in construction industry today.
Yes, big chart printed and hang on the wall can help in some way, during regular general meetings maybe, but take note, the only way to track/monitor/control everthing, yes, everything, on a daily, weekly, monthly basis, even the minutest task is by using classic features/reporting of P3 organized in any particular needs of the team.
It can be by "Gantt" Time-scaled Pert" "CPM" "who's responsible", "discipline", "subprojects" "percent complete" "Earned Value", WBS", any cost/resource chart/graphics, you name it this tool has it. P3 has been designed as an aid to deliver projects on time and within budget.
It doesn't matter whether in print or on screen, as long as it can aid and deliver every milestones on schedule, just do it.
Val baguios Jr.
-- Valentino Baguios Jr. (email)
I believe Primavera now calls their Project Planner by the name Teamplay.
-- Jason Catena (email)
I am young, I am new to project management and I have just created my first schedule for my first project using Projity: OpenProject (a free, open-source Gantt charting program).
Although I understand that the depth of visualizations that something like automotive manufacture requires are a great deal larger than something as simple as my Peace Corps water projects, the ability to nest tasks shrinks all steps down for a view that is easy on the eyes.
-- Page Weil (email)
I'm interested in a slightly different application of Gantt charts than most of the posters on this thread. I am using them first for analysis, and secondly for communication. My current subject of interest is a schedule of software batch jobs that implement a number of integrations between computer systems.
The schedule is a repeating cycle of events (tasks) that occur on a daily basis, so my timescales are from several minutes to several hours. In the group of integrations for a particular subject area, there are a number of individual integrations. Each integration involves two or more (usually three) systems to run in some sort of sequence.
We started out designing the schedule in a spreadsheet. There are lots of columns for keeping track of various attributes: for each task, the task ID, name, system, start time, expected duration, buffer or lag before starting the subsequent task, expected data volume, dependency on another task or artifact, etc. The detail was great, but the spreadsheet makes your eyes cross -- very hard to glance at it and find problems. Also, the person who started it entered all the data as literal values, making it very tedious and error-prone to maintain.
I redid the spreadsheet to be formula-driven: rather than a static value for start time, duration, expected end time, and the start time for the next task, I put in the start, duration and lag, and calculate their sum to find the next available start time. This makes maintenance easier -- if a job runs longer than expected, I change one number, the duration, and the subsequent jobs automatically move later.
But the spreadsheet data are still very hard to visualize. And the visualization is the most important thing for me. A big part of the analysis involved in designing the schedule is finding dependencies and conflicts. In a grid of numbers, it's very hard to see those things. So I re-entered the data in MS Project, and got a decent Gantt chart that makes it much easier to see where tasks overlap -- in some cases, that's a conflict to be avoided -- and the dependencies between tasks. Hooking up the dependencies allows me to move one task and ensure the dependent ones move automatically. And the chart view helps reviewers confirm I've picked the correct dependencies, and found all of them.
The problems I have with Project are mostly to do with the lack of fine-grained control over the visuals. You can't modify the built-in colors. You're restricted in typography. Setting text to display above a rollup bar makes ALL the rows double-height. The drawing tools are very crude. The dependency lines overlap one another, so if a task is dependent on 2 or more other tasks, their lines and arrowheads merge together. And Project makes it hard (but not impossible) to work in minutes and hours rather than days.
Finally, there's no indication of the cyclical nature of the data -- this 'project' repeats each day, but for Project, it's a single day on a linear calendar -- if I select the wrong date while printing, I get a blank Gantt chart.
The visual problems are mitigated in tools like Visio and Illustrator -- but I find that the more visual control you get, the less automation you get. And the automation is key -- I need to be able to change a number like a start time or duration and have the chart update all the associated tasks. Each step on the path from Project > Visio > Illustrator gives me better visualization at the cost of increased maintenance through loss of automation.
So, unlike many on this thread, my particular problem seems well-suited for Gantt charts -- I don't have too much extra data to cram onto the chart. But while the underlying engine seems to work well, and is a mature domain (there are lots of competitors to MS Project, as noted above), the people who create these tools don't seem to really grok what good graphical representation really means. Maybe Adobe and Microsoft can trade some designers and programmers?
-- Val (email)
During a spaceflight, like the recent shuttle mission STS-123 to the International Space Station, there are very many tasks performed by each crew member. Many of these tasks must be performed in exactly the right order at exactly the right time. To handle this task management, NASA writes extremely detailed "flight plans" for each mission. I've attached an excerpt from the 255-page (!) document. They cover flight day 7 (FD07), the day two astronauts installed the arms on Dextre, the Canadian Space Agency's robotic maintenance worker.
As you'll see, there is a combination of Gantt charts with time increasing horizontally to the right (can't you just imagine the long strips of paper running around the room at Mission Control) and also extremely detailed *vertical* charts, where time runs vertically from top to bottom, that track every action and task of every astronaut in 5-minute intervals. Yes, 5-minute intervals over a 16-day mission. That's why the flight plan is 255 pages long. Of course, there is quite a bit of white space recording the astronauts' sleep.
Because there were so many participants on this mission, the vertical pages come in pairs (3-56 and 3-57, 3-58 and 3-59, and so on.) They can be fairly quickly browsed by focussing on the astronaut's name at the top of each column, for example, the commander (CDR) Dom Gorie.
I wonder how they display these vertical charts? Perhaps flipping pages (or pairs of pages) is sufficient.
There is an incredible amount of information included on these charts. You'll see the date (in GMT), mission elapsed time (MET) and more. One beautiful component is a simple, alternating black and white bar that tracks "day" and "night" on the shuttle/station. With 16 sunrises and sunsets every day, "day" and "night" don't mean much but it is critical information for astronauts outside the Station on a spacewalk.
These flight plans, to me at least, share some of the beauty of ET's favorite graphics. I would certainly be tempted to print off an excerpt and hang it on my wall as a piece of art.
-- Peter Newbury (email)
Val's query is an interesting one, but it is not precisely a project management issue. A project is by definition temporary and unique whereas ongoing operations are a separate issue. I have spent the last 2 years working on a chemical plant construction project, and part of my role was writing the normal operating instructions. These are kept separately from the project plan.
Where tasks are repeated daily the operating staff will typically gain experience and the performance will improve. Sadly I don't have any examples, but for a batch plant which sounds similar to the program in question, we would draw up a Gantt chart based on each resource for a full cycle, then repeat it horizontally and kern them together (for want of a better description). By seeing where the effort bars touch, you then find the critical path, and white space indicates slack. You then can see where you should try to concentrate your optimisation efforts to reduce cycle time and improve efficiency. This is most easily done in Excel, and it allows you to go down to less than 10 minutes resolution for a full day if you show time increasing horizontally. Even more detail if time is vertical.
Because you have fewer stages than for a full construction plan (ours is over 2000 tasks now!) you don't have the problem of sparseness and hence readability of the Gantt chart is improved - but it still isn't perfect.
-- Paul (email)
I have found the following image (via http://www.37signals.com/svn/posts/1091-cook-like-an-engineer).
I wonder how it would scale for projects consisting of, say, 200-300 hundred tasks.
-- Marek Kowalczyk (email)
Isn't that just a PERT chart, but with nested-boxes imagery instead of branching-tree imagery?
(Typically, boxes-within-boxes and binary-trees describe the same structures)
-- Derek Cotter (email)
On the recipe charts referred to by Marek Kowalczyk on July 5, three possible improvements to broaden their
applicability leap to mind:
1. Have the time dimension running along the top horizontally. The horizontal dimension of the boxes could then be
proportional to the time spent on them (although in some cases that might make it challenging to insert readable text
into the box).
2. To expand them to dozens or hundreds of tasks, it seems to me that ET's "small multiple" designs might work best,
especially if they all shared a common time dimension. I could imagine preparing six or eight dishes for Thanksgiving
dinner, each with their own recipe chart. Line the charts up, and you know at a glance when you should be chopping
various things, when you should be minding the stove, and how to plan the use of the oven throughout the day.
3. To aid in those comparisons, color-code the verbs (which state the key activity -- simmer, chop, etc.) so that all
instances of a given activity pop out from throughout the chart. An alternative might be to color-code all applications
of a given piece of equipment, to make sure there are not overlaps/bottlenecks. (And lighten or eliminate the grid lines
to take all of this out of "grid prison"!)
Maybe this is just reinventing the Gantt chart, but at least it breaks it down into modular pieces that can be printed
-- Bill Eisenstein (email)
The Recipe Diagrams are Great. They Remind me of my favorite Software Engineering Tool Nassi-Shneiderman diagrams (http://en.wikipedia.org/wiki/Nassi-Shneiderman_diagram) alhough the Flow is top to bottom instead of left top right NSDs have the advantage of including the standard flow of control elements (if then , while do etc), and also have a great self governing aspect in that when It is difficult to diagram them I take this as the clue to decompose the tasks
-- David Pitts (email)
In March 20, 2002, E.T. asked `What are the deep principles and how can they show up in the design and organization of a project?". I have been planning and managing projects for forty years. The deep principle behind all of this was to "improve the quality of the discourse". But what does that really mean? Well...
In 1978, I was responsible for planning the construction of a billion dollar desalination and power plant in Saudi Arabia. I started my work at the construction company's head office in London. The engineering, drawing, purchasing and manufacturing scope of work was taking place not only in the UK but also at major suppliers and partners in Germany, Italy, Japan and the USA. When the project moved into the construction phase I moved to Jeddah where the plant was being built.
We set up a "war room" on site with schedules and charts pinned around the walls, artist's impressions of the finished buildings and even a scale model of the whole plant showing the mechanical equipment, pipe bridges and cable runs.
Every week we held a planning meeting in the war room. This lasted most of the day and systematically reviewed progress in each area and on each system. This was the opportunity for civil, mechanical, electrical, instrument and commissioning teams to resolve the sequence and priority of work at critical interfaces: where the big cooling water pipes went under the road, how the pipe bridge cut off crane access to the transformer bays, when the continuously-cast chimneys would get precedence on the concrete batching plant.
Dramas of goods lost in transit, failed machinery, even sudden death from heatstroke unfolded, were discussed and consequent problems resolved in this theatre. The meeting was structured so that people need only attend the part that affected them.
The Project Manager chaired the planning meeting. I took the minutes, aiming to have them typed and circulated the same day. On the rare occasions when we couldn't be there, the meeting went ahead without us. It wasn't the Project Manger's meeting or my meeting. It was everybody's meeting; they needed it to do their job. If they couldn't talk about their problems, they wouldn't be able to solve them.
Civil construction (and especially the marine work) was a challenge on this project. Situated on the Red Sea coast, the porous ground consisted of compacted rock and coral. The construction of a quay was a particular concern. We were building this to offload the big roll-on roll-off (RO-RO) vessels that were bringing our three-hundred-ton evaporators from Japan.
A desalination plant is basically a huge kettle to distil fresh water from seawater or rather a series of such kettles. On our project, there were sixty evaporators, fabricated in a Japanese shipyard and shipped to us twelve at a time. These would to be brought ashore by a massive flat-bed trailer.
When the first shipment was already on its way it became clear that the quay was not going to be ready on time. The quay was built of pre-cast slabs resting on forty piles drilled into a shore that sloped rapidly to depths of a hundred feet. Drilling the piles was immensely difficult because the drills could easily be deflected by the granite boulders that were embedded in the coral.
We drew up a bar chart to monitor progress and posted it on the war-room wall. This detailed each step of the process: drilling the hole, inserting the steel liner, fitting reinforcement, pouring the concrete and moving the piling rig to the next position. The piles were all numbered but it was hard to relate the bars on this chart to the piles on the shore, so we put up a plan of the ship-offloading quay and colored-in the circles as each pile was completed.
It was easy to see that we were slipping behind but unclear what we could do to retrieve the delay. So we drew another chart that plotted the number of piles completed cumulatively against a time scale and showed the target: forty piles before the ship arrived.
It was obvious that we would have to double our drilling rate to get the quay ready in time. This was impossible. The existing crew was already working twenty-four hours a day in shifts, and we could not hire another piling contractor as the work demanded specialized equipment which would never get to Jeddah in time.
When we hit real problems on site our Lebanese owners would don their traditional Arab costumes ("thawb", "ghutra" and "igaal": the ankle length cotton shirt; red diagonally-folded headdress; and double-coiled cord circlet that holds it in place), and request a meeting with the Saudi client in the war room.
We were quite open, we told the client that we were having a problem with the ship-offloading quay and that we did not know what to do about it. What did they think?
By now, we had pinned up a photograph of the roll-on roll-off vessel and, to complete the picture, a diagram of the stowage of the evaporators on its deck. Someone noticed that the evaporators were arranged in two rows of six along the length of the ship and asked the question "couldn't we focus on completing a quay of just half the width, moor the ship to roll the evaporators off on one side, re-anchor the ship and roll the evaporators off on the other side?" So this is what we did. By the time the second shipment arrived the whole quay was complete.
Our Saudi clients were delighted to have been invited to discuss the problem and thrilled to feel that they had contributed to its solution.
Summarizing and confirming your understanding of a situation are vital steps in creating understanding. Displaying this understanding in a graphic form - creating one of E.T.'s Visual Confections - is a further huge stride in helping people spot patterns and find solutions.
(excerpt from "Yala: How to manage complex relationships")
-- Geoffrey Morton-Haworth (email)
A callgraph, similar to the Apache vs IIS web server graphs above. This one is by wasapeas, an artist on Flickr.
From the artist:
This is a visualization of a linux boot sequence where each function is a node and each edge represents a function call, direct branch, or indirect branch. Nodes are laid out using an unweighted force-directed layout algorithm, where each node is simulated as if it were electrically repulsive and had springs between nodes.
The little "lobe" on the left is made up the interrupt processing routines (irq vectors, irq_svc, etc). The tail at the top is the bootloader. The main thing in the middle is the linux boot sequence.
The entire graph represents a call chain from the bootloader up until it jumps into userspace to a shell prompt
This is a visualization of a linux boot sequence where each function is a node and each edge represents a function call, direct branch, or indirect branch. Nodes are laid out using an unweighted force-directed layout algorithm, where each node is simulated as if it were electrically repulsive and had springs between nodes.
The little "lobe" on the left is made up the interrupt processing routines (irq vectors, irq_svc, etc). The tail at the top is the bootloader. The main thing in the middle is the linux boot sequence.
The entire graph represents a call chain from the bootloader up until it jumps into userspace to a shell prompt
By comparison, here is a Gantt chart of another, similar, Linux boot sequence. This is the automated output of Ziga Mahkovec's Bootchart program.
At the time of this posting I am a Project Manager for an owner for a medium sized hospital project in California,
taking it from concept through to opening.
I hate Gantt Charts. I loathe MS Project. I'm not that keen on Primavera. But I love this thread.
I like tools, visuals etc. that are intuitive, that come close to 'just working'.
The main problem that comes up repeatedly in projects I have managed is that the participants don't truly
understand the dependencies between tasks. And they don't know exactly what each others' tasks are.
"Oh I forgot to order that!"
"Oh I didn't realize you needed the VP to sign that form before you could get rid of this?"
"Oh I didn't know my ceiling height impacted the ability to get air conditioning installed above it!"
"Oh I didn't realize that by moving the doorway there, I've made it impossible for you to maintain enough free space
in front of that fire-line valve!"
"Oh I didn't realize I can't assume we'll start demolition in March because it's not just dependent the doctors moving
out, it's dependent also on the County signing the environmental report and then waiting 30 days!"
" Oh I didn't realize you only needed to know the weight of the building's exterior cladding, I thought you needed a
full elevation (that's why it's taken me 6 months, I knew the weight in a month) ...."
And on and on and on and on ....
I think for small projects handled by a team of people that's done similar project multiple times before, they may
well inherently understand and be sensitive to all the dependencies of a project (maybe a company installing pools
at residences in the same county) - but outside of that I don't believe that's ever close enough to being true that it
Gantt charts are extremely bad at showing the dependencies between tasks that don't appear on the same screen /
sheet of paper. Even then they only remain clear if you have a predominance of one to one dependencies. They also
often have cryptic abbreviations of what the task is (because if they were long, you either get less tasks on a sheet
(multiple lines in a narrow column describing the task), or you get almost no room to show the bars of the gantt
chart (long single line describing the task)) and that leads to confusion.
You can get the dependencies sorted out using post-it notes on a wipeboard, if the people writing the post-its and
drawing the lines between the post-its are the people who actually carry out those tasks.
In projects you often have multiple many to few to many (again) relationships. And knowing exactly what the
deliverable that the task is to produce can change the dependencies between tasks and the duration of those tasks.
You will typically find that people disagree at first, that there are misunderstandings about what a task is (e.g. when
you say "provide the design to the fabricator" do you mean a design that's on a sheet of paper in pencil, in a 2D
version in a CAD computer program, in 3D in a 3DCAD computer program? Do you want the printout mailed to you?
A pdf emailed to you? Or the working electronic file?).
It's not true that the team knows what it's going to do and all this exercise does is get them to cough up what's
sitting there in their head. The team as a collective mind does not know what it's going to do until it tries to cough it
The importance is that after the coughing up and arguing - there's one plan describing the dependencies, and it's
created by the team that's engaged to execute the plan, and because it's boxes joined together by lines it's visual
and it's easy to understand.
For projects that are not too complex (note; the circular definition :) - ie. not so complex that what I'm about to
describe will not work!) the post-its and lines can be put into Visio and made to look very nice and printed out as a
record of the effort, and then some editing as people see (from the effort to neaten the lines and layout of boxes)
that some if it is wrong but you soon get it to "Correct Version - draft 1".
On complex projects - such as this hospital project - there is some software that I'm using that now has a graphical
interface that puts real planning and scheduling intelligence into those boxes and allows you to generate a sequence
of work that has dates in it that you can then start to adjust based on - is your end date late? , is the intensity of
work looking crazy at certain points, does it all really need to be done?
My main point is it remains in essence post-its on a wipeboard connected by lines, but it lives in software, and thus
can be updated as often as is needed, and printed out (on big plotter sheets, tacked to a wall - still the best method,
even smart board screens aren't as big and flexible as paper on a wall).
I don't use a Gantt view at all except to visually show how a target date for the end of a sequence of tasks has
slipped - seeing the slip as a visual distance hits home harder than seeing that a projected date is later than a
planned date (inside the post-it box,in the post-it on a wipeboard view).
The second an indeed more important part is Replanning. If you don't have a team that can replan fast, and replan
often you may not succeed. On a small project, you can continually revisit the post-its (lots of) on a wipeboard (very
big) and keep tweaking it, and when necessary ripping post-its off, erasing lines and completely replanning sections
of it. The software I'm working with has a rudimentary editing ability that allows me to delete lines to break
relationships and add lines to create them, and add boxes (tasks) and connect them in, as necessary. I.e. I'm trying to
make it possible for the team to continually replan in a visual intuitive way on a complex project.
It's tough to do in MS Project and even harder to do in Primavera I understand.
I'm going to the Edward Tufte seminar in San Francisco on, I think, the second day of the three days he's there in
early December - I'm trying to get some grounding in this very new (to me) concept of there being something called
Visual Design of Data to help me work more with the software company to push their graphical interface to be so
much richer and informative without become a cluttered mess that hides more than it reveals.
I haven't mentioned the software because I'm very keen on this discussion of ideas and principles and am not
wanting to give the impression that there's this wonder tool out there that you just have to Buy to be Happy.
Note: I managed a local General Contractor on a small but complex project at another hospital. He did his planning
in ... Word. And it worked. I found a six page list of tasks, 1 page per week of work, with the days of the week
being noted on the first couple of pages and then not on the later ones, a better visual guide to the project than a
Gantt Chart. And it's much easier and faster to change :) But like I said - this was a project of narrow (if tricky)
enough scope for that to work. And boy did he and his crew know their work, and yes they'd being doing similar
work for many many years. Horses for courses.
I've really enjoyed this thread, and the contributions to date. Keep it coming.
-- Digby (email)
Re: Digby on Gantt Charts, etc.
Some planners/schedulers/managers appear to avoid Primavera, because they expect it to be too complicated. I've used P3 for 20 years or so, and don't consider it difficult, but my opioion might be biased. You can easily use it for simple networks. Then as you become familiar with the other features, it's there for you. I've frequently said that [in using Primavera] you are limited by your imagination. If you don't need to use the enterprise version, i.e. you are only working on one project at a time, then the Contractor version is a good solution and its cheaper than MSP, with all the project level features of the $4,000 P6 enterprise version. There's no excuse not to use Contractor, as a serious planning and scheduling tool. [This is just my opinion. I don't sell it; I just use it a lot and deal with users who could do better, with good tools.]
Displaying logic strings got much easier when Primavera added the capability to sort activities by Float Path, then the Float Order in those paths. This solves the old problem of TF numerical sorts not allowing for different calendars. This Gantt-style plot shows the float paths very clearly, allowing us to confirm the logic, and directly see the results of conservative durations. If you are crashing the schedule, this plot shows you where to concentrate your efforts.
As Digby indicates the Gantt chart has its uses, such as quickly displaying relative dates for users who won't be reviewing the network for more than a minute. The Gantt Chart is only effective with logic, if you are sorting by float paths, as above.
Logic plots [frequently called PERT charts] are a planning tool. That is, when you are planning the job, you are concerned with the relationships between activities. The resultant dates are not usually considered, as they are hard to assimilate as simple date fields. It's more visual to see an activity duration, and the activities that may occur at the same time on parallel paths. The previous version of Primavera P3 3.1 presented a better logic plot that the current P6. The boxes were configured with more data and the relationship lines were more legible. Hopefully, the graphics will be improved soon.
Trace Logic is another interesting logic review tool. This allows us to show the predecessor and/or successor logic before and after, respectively, a particular activity on the screen. Then, as you click on a successor activity, for example, it will now show the predecessor activities for that activity. [I believe this is limited to show 10 levels on each side of the activity at a time, which is more than you can read on the screen.] This is very interesting when you are stepping through and confirming logic.
After the logic is confirmed, then a Gantt chart is plotted as a scheduling tool to confirm the flow of the work. If it appears that all the work is flowing with reasonable dates, then check that the late date bars are also reasonable. Anyone who just looks at the early dates is dooming themselves to failure, as you cannot logically perform all the work on the early dates. Always use a median curve between early/late as your target curve.
Planning and scheduling is an iterative process to get the baseline to the point that the entire team agrees their input is accurate and correctly related to all the other activities.
While all these whizbang features are interesting on the screen, I've found that we can be very effective working with the planning/scheduling activities remotely, using the application share feature in many IM programs.
Then, you confirm this all again with the first and all subsequent updates.
The under-appreciated power in Primavera is the very robust activity coding structure that allows you to sort and select activities. In addition to the WBS codes, you may define any number of codes fields, even hierarchical fields to 20 levels. This permits multiple ad hoc WBS structures, which don't disturb the real WBS. These codes are used to sort and select activities. For example, rather than reviewing a 30-page printout, you can filter down to the dozen or so activities you are actually interested in discussing. It's much more effective to show a subcontractor a print of his work for the next month, rather than sharing a plot of everything, and expecting him to dig out the details.
Primavera is not limited to Gantt Charts, but uses a set of graphics tools for the different aspects of the planning/scheduling operation. We are now seeing more and more add-on programs that use Primavera data for 4D applications, GIS applications and very interesting graphics, which can be very illustrative and helpful. However, we need to build and maintain the network, and that starts with Post-Its or 3x5 cards on a wall, and Primavera.
-- Jim Simons (email)
Publishing 2 million books at Graphics Press over the years has required Advanced Project Management Display
Decision Methodologies. Here's a recent example of APMDDM graphics from my Executive Editor:
Acme is our bookbinder, who may have only 3,000 copies of Beautiful Evidence in storage. It turned out,
looking at further data, that we have more than 3,000 copies left, but, nonetheless, we had better get going
soon on another printing of Beautiful Evidence.
Glad to hear that we are closer to "Elevated" than "High";
local people here were starting to panic - now they can just worry.
We're all looking forward to the new print run, hopefully there
will be a new section tucked in the back on Grand Truths...
FOR EASE OF REFERENCE: Grand truths about human behavior
Best wishes
That is 2 more colors than we use at my company for our stoplight charts. Looks like we need to upgrade.
-- Sam Perry (email)
One of the my responsibilities as a project manager implementing an ERP solution for student applications at a large U. S. post-secondary educational institution was to enlighten the business process owners, and other executive leadership, on the progress of work at a high level. I'm employed by the institution, not the ERP vendor.
The problem was that, although the ERP vendor provided many detailed Gantt charts and status reports at weekly meetings, the senior staff needed a better "picture" of where we were, where we're going, and how we're doing along the way. I would always hear questions like "what are the trip wires", "where are the roadblocks", etc.
To provide a solution I developed a "critical path" graphic using some basic flowchart symbols (from my programming days) to display the work in progress with some content that bubbled up from more detailed schedules maintained by the technical and functional project leads. The attached graphics shows dated milestones colored to fit the current status. If something wasn't green, that was usually a topic of discussion at the status meetings or SCRUM.
This model has lived on, and been adopted in other major projects within my organization. I hope you find it useful, and I encourage any suggestions for improvement.
-- Bob Emerson (email)
I've worked for a Project Management firm for the past 10 years and we have struggled with same issues when using the current scheduling software options. One of my responsibilities has been to recreate or illustrate project schedules in a graphics program so we could have a presentable version. The firm owner and CEO decided there was a real need for an application that would provide an activity network-based process for simplified collaborative interactive planning and scheduling. This was not just about the graphical presentation, he really wanted a tool that would better facilitate the planning process by using graphical tools and techniques that could be implemented directly by project stakeholders. In essence an electronic full-wall scheduling tool, but with real logic and math to configure float and critical activities. Here is a sample schedule from the application. The application is named NetPoint (found at www.pmatechnologies.com).
-- Bryan Ritch (email)
I work for a City Utility and instead of having giant paper maps on the wall and having to change them out with the electric network changes, why can't I project my ArcMap project onto the wall straight from the computer? Isn't there some software out there that would give me a clear image of what I'm looking at on the screen and make it a wall size of 12 x 9 for instance?
-- Dianne (email)
Near the top, ET asked about the deep principles. He then offered some of his "doodles" of an alternate way to show project management information.
I've just been struggling through this issue, and I reached a similar solution to ET. Furthermore, if you look around you can find this concept referred to as a "swim lane" chart or a "cross functional process flow diagram" (what an awful term!). When lots of people are re-discovering a similar solution, it would seem a deep principle is nearby.
Roughly speaking, a project consists of tasks. These tasks must be done by a person at a time. Hence, we have a triple: (task, person, time). The big advantage of a Gantt chart is to make an list of all the tasks, and that's really nice to have. Then you tack on time. Locally, a Gantt chart is dense, but globally it's sparse. Also note that the tasks are almost certain to be different from each other.
The swim lane approach relies on the ability to group all the people into a small number of clusters. This clustering is key because it allows you to plot the data differently. Instead of plotting "yes" or "no" at each (x,y) location of (time, task), you make a grid of (time, who), and then at that location you put the task.
Because you've only got a few clusters for people, the figure is now much more dense. As ET points out again and again, high data density + good design = deep understanding. We have found this to be true in my project.
I'm not saying this approach can or should replace Gantt charts, but it's nice to have a good alternative.
In my recent project, we also needed to share test cells, and there were only 3 available. Hence, we had 4-tuples: (task, team, time, test cell). After some experimentation, the best solution seemed to be two adjacent swim-lane figures. Time goes across the top of the page. There are rows for the teams, and then below that are rows for the tests cells. In the upper part of the figure, the task is put at the (time, team) location. Below, the team name is put at the (time, test cell) location.
-- Ted (email)
We have reviewed this discussion, got interested in the topic and found that we share many viewpoints expressed. To contribute to the discussion, we would like to draw attention to some issues that we believe are important.
We will point out the areas of Gantt charts that we agree are a good candidate for improvement and then we will suggest what we believe to be an appropriate solution.
First of all, we agree that huge Gantt Charts are hard to overview, they contain too much information (low data-ink ratio) and take too many pages when printed out. Also, grid lines really hamper understanding the chart. We also join the viewpoint that, in large charts, one line allocated for each task is really a waste of precious space. Instead, several tasks (if their time phrases do not overlap) could be visually located in a single time line without losses to clarity, however, providing a much more convenient and, importantly, compact overview of the entire project.
It is also important to be able to get a quick overview of project milestones, to both oversee the project "from the top" and drill down to any specific level to view only the tasks and subtasks of that level.
Taking account of the issues discussed above and attempting to free the Gantt chart from unnecessary details, we decided to create a special chart that is called the Project Chart.
What benefits the Project Chart brings in:
We have also developed a Resource Chart that provides some features analogical to the Team Planner:
We are using these charts ourselves and are very satisfied. You can import your mpp files into AxProject and try to view these new charts and you will see how much easier it becomes to understand the project.
-- AxProject team (email)
In this thread there is an example project plan, under the sections THE BASIC DESIGN: DETAIL WITHIN CONTEXT, LOCAL DETAIL IN PROJECT MANAGEMENT and MULTIPLE PROJECT OVERVIEW = MULTIPLE CONTEXT BARS.
Is anyone aware of software that will present project information in this way? Or Excel Macros that will achieve the same result?
[Reply by ET: I sketched these (in part, same idea as my thunderstorm animation) out about 15 years ago but haven't seen any implementations. I haven't looked very much however.]
-- Chris Fox (email)
Project management readings
For a big set of readings on software project management, see
It would be interesting to see how Apple manages projects, given their minimization of process. Also I miss references
in the reading list to Philip Greenspun's books on project management for web sites and software.
We use a simple reporting system to visualize progress on high-rise buildings. A white block
denotes an activity that has not started, a green one that has been completed and a red one,
one that is constrained and cannot start. Three or four charts plotted side by side can be
used to describe a timeline and hence used as a planning tool. Simple but effective.
-- Yannis Lazarides (email)
Project charts on smartphones and tablets
Interesting to hear ET concepts for project management interface for modern phones and tablets. what is a right concept of the interface for iPhone/Android? what is for iPad and Kindle Fire? we have got smaller screen but we also got touch interface. interesting to hear your thoughts.ET response: don't change anything, use the regular interface. On smartphones, users accommodate all the time to websites designed for desktops. A good example is that many many people read The New York Times on the iPhone screen. And the iPad has better resolution than some Dell laptops already and there is no reason to do an iPad-specific chart.
ESPN has a terrible iPhone and iPad implementation (worthy of a PowerPoint slide) and then ESPN makes it difficult to find the desktop version. More generally, avoid product-specific dumbing down of content and interfaces. That why they're called smartphones.
-- Vasyl Mylko (email)
-- Vasyl Mylko (email)
Who owns "float" in a construction project?
Engineering News Record has an interesting article on project float here, along with a deliberately convoluted flowchart of how things can
get complicated.
There are different types float and definitions for each; however, one definition/example
of float is slack time that is available to a particular activity. If an activity with
float is delayed, it won't delay the whole project, until the float is exhausted. For
example, float could enable certain activities to proceed out-of-sequence without delaying
the project. This could be beneficial if, say, a supplier's factory burns down during
construction. That actually happened to us!
Virtually all public works projects have financial penalties if the contractor does not
finish in time. Incidentally, contracts insist on not calling them
Instead, contracts call them by the euphemistic equivalent "liquidated
If a project has
late penalties, then I think that the contractor owns the float.
Others argue that the project owns the float, (now there's an abstract
concept!) and it should be available to
the owner, or
shared between the parties.
When I took Critical Path Methods in the mid '80s, Professor K raised the
question of float ownership. Obviously, the question lingers....
To Jon,
An excellent definition of float can be found here: http://www.projectmanagementquestions.com/28/what-is-float-in-project-management
It's funny how the conversation has derailed from answering one question to answering many questions!
-- Fadi (email)
What a great conversation, and such a relief to discover I'm not the only one grappling with the problem of graphic presentation for projects. Lately I have been trying to locate a copy of a software developed in the '90s, which was called simply GMS at the time. It was developed at the behest of an official at the ONRL near D.C. named Bob Zurcher. The contractor doing with work was called, I believe, SPA or Systems Planning Associates, and t the time they were in Arlington, VA. My recent searches for this company have been unsuccessful.
The GMS software was meant to display and manage large program elements at different levels, such as for an aircraft carrier. At the most condensed level, one might see a hierarchal chart of labeled boxes representing different areas, like hull, propulsion, electronics, and so on. In the top row is the finished carrier. When you double-clicked on one of the boxes, the screen would reformulate and the clicked box would be upacked into its next-level set of boxes shown below the one clicked. You could go on indefinitely as deep as you wanted to. When you clicked again, it would collapse the boxes and re-simplify the diagram. The value of this was that when presenting the project, if someone said "what about detail X," the presenter could jump to that level, answer the question, and then effortlessly jump back and resume the discussion where he or she left off.
Each box was an object to which other objects could be linked without cluttering the diagram. So you could attach spreadsheets, images, word documents, powerpoints, pdf files, and links to external sources, like regulations. So all of the supporting information was available readily, again, without cluttering the basic diagram.
To top it off, the boxes could be linked to one another with attributes. So a link was itself an object. For example, the link could have attributes like funded or unfunded, low, medium, and high risk, or low, medium, or high payoff, or ahead or behind schedule, critical, important, or nice to have, etc. So if someone said show me a picture of all of the critical elements that are behind schedule and underfunded, the presenter could quickly search those attributes and reformulate the diagram appropriately. When done, they could jump back to the top level diagram.
I am really surprised this software never took off. It only ever existed for a PC that I know of, and I am a Mac user, so I don't hold out the hope that I'll be using a copy of GMS. My hope is that somebody finds a copy, is inspired by the idea, and then develops a Mac-worthy version of it.
You can see how GMS got around the issue of Gantt charts with 1,000 lines. Watching a professional do a presentation with it was an exhilarating experience. Hope this helps offer some ideas on functionality that might be useful.
Regards, Eric Brachhausen, email@example.com
-- Eric Brachhausen (email)
The Github Network
Graph is an interesting contribution to software project management visualization. Github is a
collaboration environment built around the Git software configuration management (SCM) tool.
With Git, when a software developer wants to contribute to a project he or she forks the project (see the blue line
that diverges from the black line) and then makes a change (see the dot on the blue line) and then asks to merge the
change back into the main project (see the blue line merging back into the black line where the blue arrow points to
the black dot).
The purpose of this graph is to help the project owner (1) identify risk, (2) decide what change to merge next, and
(3) see what project contributors are working on.
Let's say the owner of the green line requests to merge his or her code back into the black line. You'll notice that four
black dots (changes) have been created since the green line diverged from the black line. That means there is a lot of
risk that the green code is out of date with the latest black code. So, before the green code is merged, the green
developer must first update his or her code with the latest changes from the black code.
Let's say the pink developer is working on a really important feature. The Network Graph helps the black developer see
where the pink developer is in his or her work and what help might be needed to get the pink code ready for a merge.
Other team members can also see what is going on.
Each developer gets a swim lane and each line references commits to the code base that are linked to changes to the
code. That means team members can see what parts of the code other developers are working on and identify potential
conflicts or opportunities to team up.
The Github Network Graph isn't the greatest diagram ever, but it attempts to solve some problems faced by
geographically distributed teams working on largely textual projects that are difficult to visualize.
-- Michael Hogan (email)
You describe an attractive alternative for presenting various views of a complex topic or project. Much of what you describe can be accomplished using one of the several mind-mapping software programs currently available for Windows and / or Mac. My preference is NovaMind - works on both Mac and Windows. One feature - the Presenter - which would help implement something like GMS - is currently only available in the Windows version. Linking documents, web pages, etc to Topics is quite flexible. Navigating through hierarchy works smoothly and sub-maps can be used for some topics.
-- DJ Crane (email)
Hi all,
This thread is an excellent resource for both project management and, the display and presentation of complex information.
I am involved in a complex IT project and have used the input and comments, and the original Edward Tufte examples to develop a version of a Gantt chart which may be helpfull to others, so I have attached an example.
This is not intended to boast or anything like that - more to provide an idea or example that may help, or provide a basis for your own further ideas. The approach was to combine a higher level schedule spread over 20 months - with a more detailed scheduled with associated tasks and resources based on examples in this thread. This is a subset only off all the tasks in the project.
-- Mike Lees (email)
Software implementation of ET's basic design
About 7 years ago, while working at HP, I had the misfortune
to use MS Project to manage two software development projects.
This was my first time using it, and I was appalled and incredibly frustrated at just how
bad it was! Far worse than any of
their other products. Apart from the many shortcomings well-documented above, I just
couldn't believe how hard it was to use.
Around the same time, I became aware of this wonderful discussion thread, and thought
that surely there must be something better out there.
But no, after much searching, all I found were hundreds of clones of MS Project.
I became so incensed and passionate about this, that eventually I quit my job at HP,
and in 2008 began work on developing a PM app based on ET's design,
extended with ideas of my own. Facing many obstacles, getting funding etc, it all took
much longer than I thought it would. But now finally
version 1 is almost complete, and we have a free Beta version available for download at vuedoo.com. The name of the app is
Vuedoo?? - "view all you do" :-)
Of course, in the meantime, MS Project has improved somewhat, and now has a resource
view that bears some similarity to ET's swim lane chart.
But it's not that great and it's only available in the professional version, which is
incredibly expensive and over-engineered. I think ours is better :-)
I would really appreciate any feedback from ET and anyone else in this thread regarding
what you like/don't like about Vuedoo.
Thank you
-- Jarryl Wirth (email)