What I discovered from this simple experiment is that our perceptions of project work is (sic) massively distorted by the various common artifacts (billboards if you like) of the project management community. The Gantt chart is a prime example. It reflects very little of the project experience ahead. An itemised to-do-list would do a better job. And in many cases I’ve found this is actually what is used.It would indeed be a concern if people mistook the artifacts of project management for the conduct or the outcome of the project! It's also amazing that a gnatt chart and not a network of some kind is the representation of choice for a project's activity sequence.
If people are so wary of gantt charts, I am led to wonder if a quantified delivery risk is applied to each activity, or each work package, and if this is accumulated at stage gates for tracking (as per the critical chain method), and if there is a firm grasp of the outcomes and how they are to be firstly achieved, then measured. That is, what do we need to do and how do we know we've done it?
But, more than this disquiet, the enquiry betrays a machine view of projects, when this is as far off the mark as one can get.
It is naturally possible to model and run a project using some machine like representations, but these are only the documentation of a community process and represent an abstraction required for the organisation of the more intense and responsive discourse and joint action. And, no, I'm not going 'touchy-feely' in using this language, but being fair dinkum. A project is done by a collection of people, in various contractual relationships moderated by a joint desire for (mutual?) success. It is this informed interaction that gets projects done. It is the work of, what I like to call, a 'community of intent'; characterised by communication to find resolution and progress.
This has attracted various terms over the years, but I find the thinking that Hal Macomber used in his Reforming Project Management blog, and that David Ing at Coevolving Innovations refers to to be on the right track.
Just think about a project you've been involved in (I mean a serious project, not the kiddie stuff that recruitment agencies sometimes refer to): if it is anything like one's I've worked on, it is run by lots of meetings and less structured conversations, a zillion e-mails and phone calls, and a high degree of flux; sometimes at a frenetic pace. All this is done in the light of the theme expressed in the formal documents and representations; which, in a well organised project, will be updated continuously and in the light of the outcomes sought and risks met and dealt with.
In many ways this is like the work of general management (see Henry Minzberg's various writings on what a manager really does); its artifacts are similarly uninformative about the work: cash flow statements, production schedules and balance sheets; but few people mistake these for the business.
Jon gets down to the to-do list and hangs his hat on it. Well of course. Day in day out, its a simple list of what you need to do, or what the project needs to achieve that lubricates activity. In construction this is the 'look ahead program' (a similar concept is commercialised in the Last Planner method): the next two or three weeks' rolling schedule done in great detail to co-ordinate interfaces between work packages and project events.
In my experience a project is produced by the complex information flow between participants, organised, themed and paced by a set of artifacts that recognise the limits of information and contraints of risk properly quantified and expressed.
If you want to talk to upper management about a project, you've got to use risk talk and not let them get locked in to a too neat gantt chart that over-simpifies reality and ultimately mis-informs them. As Glen Alleman insists, quoting Tim Lister: risk management is how grown ups manage projects.