On Edward Tufte's site there's a fasinating discussion on project management graphics. The discussion hinges on the way one might effectively show project progress, or status, or future plans in a graphic.
Nice idea, but projects can be so complex that I don't think that any one graphic format is going to do the job.
A well designed 'dashboard' type presentation might help. Such as some on Charlie Kyd's site, but I think there is an air of futility in attempting to capture the complexity of a project in a single presentation format.
For summarising progress, the One Page Project Manager has some useful approaches, I think, as is a simple S-curve of cumulative progress. Another short piece on the S-curve.
But we have been beguiled by the notion that a project scheduling package is a project management package, and that the complex multiplicity of project information can be captured in a single graphic display. A project needs to be understood as a business. I don't think that a business would run on a single graphic! Although, the Balanced Scorecard approach comes close to consolidating the status information of company performance. Perhaps something like this for a project would be applicable.
However, the challenge is an inviting one. I hope to post some ideas for graphics later.
Meanwhile, one thing that must be bourne in mind is that projects need to be managed on a moving lens approach: that is plenty of detail for coming actions, less detail for those further out, with performance analysis for past work; and thus the lens moves on like a magnifying glass; all the time with the forecast out-turn cost and completion date updated. In construction projects I've worked on we have a master schedule, but develop 'look ahead' schedules at the micro activity level (per zone, or trade) for the next 6-8 weeks, updated weekly.
Wednesday, June 26, 2013
Monday, June 17, 2013
Project information 2
In a post a little while ago, I touched on the management of project information as being one of the unspoken 'secrets' of project management: not a secret now, of course.
Just a mass of information in a spreadsheet will not do once the project gets to any size: and I mean once it creeps over even a couple of million dollars worth of construction, or thereabouts, depending on project complexity.
The information that floods through the project needs to be tracked to the relevant parts of the project in some way. Drawing numbers might be a way to do it, but inadequate. A BIM system may allow information to be linked to the particular parts of the model, but this remains too atomistic for my liking.
I think there are probably three basic dimensions that can be used to 'locate' any piece of information in 'project space' and have it reliably available and easy to track in a way relevant to the project.
The obvious one is location: a BIM will do this, drawings won't due to locations being repeated at different scales on different drawings. The BIM will also give hierarchical contextualisation of information: e.g. an item in a room, will also be on a floor, in a wing of a building, in a block of a campus, etc.
Tagging the information by WBS package is also probably a benefit. But this limits the locus of the information to just that WBS package. Good, but it needs more.
Less obviously, but possibly of greater utility is location by building element (see the Summary of Elements as an example), this is because a building element will reach across the entire project, and can be then referenced to a WBS package and a locational nesting. The element 'key' can also sit in a hierarchy to generalise the information item in running a query. The element might be 'external envelope', or within that 'external openings', or within that 'external windows' as an element class.
Other dimensions that could be useful could be material, trade or supplier, functional or operational element, etc.
Thus a piece of information could be tagged primarily by element, then at a second level by its WBS and locational parameters. Then a query of the database could be run to find, say, all outstanding issues pertaining to the superstructure in block Z, or the floors in wing J, etc.
Just a mass of information in a spreadsheet will not do once the project gets to any size: and I mean once it creeps over even a couple of million dollars worth of construction, or thereabouts, depending on project complexity.
The information that floods through the project needs to be tracked to the relevant parts of the project in some way. Drawing numbers might be a way to do it, but inadequate. A BIM system may allow information to be linked to the particular parts of the model, but this remains too atomistic for my liking.
I think there are probably three basic dimensions that can be used to 'locate' any piece of information in 'project space' and have it reliably available and easy to track in a way relevant to the project.
The obvious one is location: a BIM will do this, drawings won't due to locations being repeated at different scales on different drawings. The BIM will also give hierarchical contextualisation of information: e.g. an item in a room, will also be on a floor, in a wing of a building, in a block of a campus, etc.
Tagging the information by WBS package is also probably a benefit. But this limits the locus of the information to just that WBS package. Good, but it needs more.
Less obviously, but possibly of greater utility is location by building element (see the Summary of Elements as an example), this is because a building element will reach across the entire project, and can be then referenced to a WBS package and a locational nesting. The element 'key' can also sit in a hierarchy to generalise the information item in running a query. The element might be 'external envelope', or within that 'external openings', or within that 'external windows' as an element class.
Other dimensions that could be useful could be material, trade or supplier, functional or operational element, etc.
Thus a piece of information could be tagged primarily by element, then at a second level by its WBS and locational parameters. Then a query of the database could be run to find, say, all outstanding issues pertaining to the superstructure in block Z, or the floors in wing J, etc.
Saturday, June 15, 2013
PM in the library
I slipped up to Dubbo in central NSW this week, care of REX airline, and during some down time from work, I dropped into the local library and relaxed browsing through its project management collection.
The books I grabbed off the shelves were:
All not to bad, as far as books go, but, again as far as books go, rather reductionistic, making project management a rigid, lock-step series of phase-bound actions hanging on a formulaic approach captured in templates, and, of course, relying on a scheduling package.
But, while this might be a good underpinning framework; in practice, it has to be both looser, and more disciplined. Some of the disciplines were there, of course: preparation of a work breakdown structure, a light touch on configuration management, etc. and even the ritualistic mention of the iron triangle.
I don't think any of them talked about how the iron triangle has to flex through the project, and how trade-off parameters have to be found as circumstances evolve and risks come and go.
The risk management approach was almost uniformly naive and unhelpful, ending up with a matrix populated from the mathematically nonsensical product of risk likelihood and effect, but almost no discussion of cost-effectiveness in management of risks delineated in terms of project out-turn value.
What was fundamentally missing, and this is probably inevitable in book-land, is the daily cut and thrust of moving a project along: constant meetings, e-mails and phone calls to marshall stakeholders, get suppliers in line, achieve delivery by the team and keep on top of the torrent of information that flows in and needs to be captured in documents that flow out; all the while applying your understanding of the mission to project actions.
Then, there is the 'continuo' of project work: acting when you need to act, to efficiently effect the project: acting neither too late nor too early, tracking lead times for your actions and for production to be achieved, and dealing with issues and planned action to keep the tempo right; all the while preparing monthly reports to the executive in charge and defending those reports in a meeting.
The books I grabbed off the shelves were:
- Project Management in Easy Steps by John Carroll;
- Project Management: a Competency-Based Approach, by Stephen Hartley;
- The Project Management Workbook by Nancy Cobb;
- The Fast Forward MBA in Project Management by Eric Verzuh and
- Manage Projects by Ken Langdon
All not to bad, as far as books go, but, again as far as books go, rather reductionistic, making project management a rigid, lock-step series of phase-bound actions hanging on a formulaic approach captured in templates, and, of course, relying on a scheduling package.
But, while this might be a good underpinning framework; in practice, it has to be both looser, and more disciplined. Some of the disciplines were there, of course: preparation of a work breakdown structure, a light touch on configuration management, etc. and even the ritualistic mention of the iron triangle.
I don't think any of them talked about how the iron triangle has to flex through the project, and how trade-off parameters have to be found as circumstances evolve and risks come and go.
The risk management approach was almost uniformly naive and unhelpful, ending up with a matrix populated from the mathematically nonsensical product of risk likelihood and effect, but almost no discussion of cost-effectiveness in management of risks delineated in terms of project out-turn value.
What was fundamentally missing, and this is probably inevitable in book-land, is the daily cut and thrust of moving a project along: constant meetings, e-mails and phone calls to marshall stakeholders, get suppliers in line, achieve delivery by the team and keep on top of the torrent of information that flows in and needs to be captured in documents that flow out; all the while applying your understanding of the mission to project actions.
Then, there is the 'continuo' of project work: acting when you need to act, to efficiently effect the project: acting neither too late nor too early, tracking lead times for your actions and for production to be achieved, and dealing with issues and planned action to keep the tempo right; all the while preparing monthly reports to the executive in charge and defending those reports in a meeting.
Friday, June 14, 2013
When to do VM!
Quote from Project Workout, by Robert Buttrick:
Gerry is right if VM is done when the project is largely committed and all the valuable change opportunities have gone. VM is only of any use done early; and best coupled with project planning and definition workshops with the main project users participating. The NSW Value Management guide, as an example which I've made use of in many project development workshops, makes the point on this quite succinctly.
Decisions taken at the early stages of a project have a far reaching effect and set the tone for the remainder of the project. In the early stage, creative solutions can slash delivery times in half and cut costs dramatically. However, once development is under way, it is rarely possible to effect savings of anything but a few percent. Good upfront work also reduces the likelihood of change later, as most changes on projects are actually reactive to misunderstandings over scope and approach...As I read this, a post at Construction Survivor was my immediate reference: Value Management -- the great con trick.
Gerry is right if VM is done when the project is largely committed and all the valuable change opportunities have gone. VM is only of any use done early; and best coupled with project planning and definition workshops with the main project users participating. The NSW Value Management guide, as an example which I've made use of in many project development workshops, makes the point on this quite succinctly.
Wednesday, June 12, 2013
Walk-in sculptures
Comment I added to http://projectmanager.com.au/education/methodologies/strategy-project-design-management/
One of the issues with implementing a design management system is that the architectural profession, obsessed as it often seems to be with building 'walk-in sculpture' photo opportunities, doesn't really seem to have a usable theory of design: not an art-derived theory, but a theory as to how requirements are orchestrated parsimoniously into a built form. There is no theory, afaik, on which to hang Corbusier's dictum that an architect is an organiser, not a drawing board artist.
One of the issues with implementing a design management system is that the architectural profession, obsessed as it often seems to be with building 'walk-in sculpture' photo opportunities, doesn't really seem to have a usable theory of design: not an art-derived theory, but a theory as to how requirements are orchestrated parsimoniously into a built form. There is no theory, afaik, on which to hang Corbusier's dictum that an architect is an organiser, not a drawing board artist.
Tuesday, June 11, 2013
Risk management's funny side
Some time ago I chaired a Gateway Review of a major building redevelopment.
The review panel made a few comments about the project manager's approach to risk management, including its unrigourousness. For example, there was no evidence of a systematic identification of risks on the basis of even a high level work breakdown/project breakdown structure, or against a mapping of dependencies to identify risk sources.
The fatuousness of the exercise concerned all panel members with our concerns confirmed when we saw the risk schedule: the lead risk in the project was the location of the public car park!
Not sizing of the project for its market, or customer access (it was distant from a large proportion of its customers), or future demand (would there be too much or too little service capacity in the facility), industry capacity to deliver, or even something as simple as sub-soil conditions. No, it was the car park!
Moreover, there was no probability attached to the risk...to any risk in the list, and no range of effect on the project value: that is, the range of the dollar effect of the risk event on the net present value of the project, given the cost the risk event would cause to be incurred, or revenue deferred or avoided. There were no numbers at all in fact, so it was hardly a risk schedule of any kind, more a type of ceremonial gesture than anything of decision-making benefit.
Donnez moi une break!!
The review panel made a few comments about the project manager's approach to risk management, including its unrigourousness. For example, there was no evidence of a systematic identification of risks on the basis of even a high level work breakdown/project breakdown structure, or against a mapping of dependencies to identify risk sources.
The fatuousness of the exercise concerned all panel members with our concerns confirmed when we saw the risk schedule: the lead risk in the project was the location of the public car park!
Not sizing of the project for its market, or customer access (it was distant from a large proportion of its customers), or future demand (would there be too much or too little service capacity in the facility), industry capacity to deliver, or even something as simple as sub-soil conditions. No, it was the car park!
Moreover, there was no probability attached to the risk...to any risk in the list, and no range of effect on the project value: that is, the range of the dollar effect of the risk event on the net present value of the project, given the cost the risk event would cause to be incurred, or revenue deferred or avoided. There were no numbers at all in fact, so it was hardly a risk schedule of any kind, more a type of ceremonial gesture than anything of decision-making benefit.
Donnez moi une break!!
Monday, June 3, 2013
Project information
Everytime I come across a computer application that purports to be a 'project management' application, I wonder.
Rarely are they, in my view. There are scheduling applications aplenty, task managers by the ton (as if a project is just a collection of tasks!), and so on. Some scheduling applications do a good enough job with resource planning and work package cost management, even earned value management, but project management? No!
Managing a project does entail work that is aided by such applications, but the heart of it, in my view is being able to manage the continual wash of information that flows through and is demanded by a project. This information is variously in documents (a document management system is essential for all but the tiniest projects), meetings, e-mails, other correspondence, notes, conversations, and so on.
When an application claims to be a project management application, I think of products such as Prolog by Meridian, Expedition by Primavera (not sure if this vanished in the Oracle take over) and Project Administrator. I do not think of Microsoft Project, as useful as that application may be for scheduling.
Rarely are they, in my view. There are scheduling applications aplenty, task managers by the ton (as if a project is just a collection of tasks!), and so on. Some scheduling applications do a good enough job with resource planning and work package cost management, even earned value management, but project management? No!
Managing a project does entail work that is aided by such applications, but the heart of it, in my view is being able to manage the continual wash of information that flows through and is demanded by a project. This information is variously in documents (a document management system is essential for all but the tiniest projects), meetings, e-mails, other correspondence, notes, conversations, and so on.
When an application claims to be a project management application, I think of products such as Prolog by Meridian, Expedition by Primavera (not sure if this vanished in the Oracle take over) and Project Administrator. I do not think of Microsoft Project, as useful as that application may be for scheduling.
Subscribe to:
Posts (Atom)