As we all in the project world know, there is a plethora of project management software on the market: both web-based and for local hosting or installation.
Most of the software, to my mind, falls far short of helping one manage a project, and tends to be either for scheduling or task management; sometimes with the capability to upload documents.
I've mentioned this in a previous post, but very little of the software on offer truly supports the management of project information, documents and actions.
Recently I've been considering software for an investigation unit that I am responsible for, and the software that has lead me to looks far more like true project management software than products marketed for the purpose.
Not to say the packages that I've earlier mentioned (Project Administrator and Meridian's offerings) don't do that job, they do; but the cross linking and automation in COMtrac goes further than this.
Capabilities of COMtrac I particularly like are the linking of entries against different categories of investigation action, and the use of those entries to produce investigation logs, tasks, offence analysis, briefs of evidence, statements, etc, without much further work. I don't know of any PM package that can do that. They all entail more work to make useful reports and summaries.
The front page of COMtrac shows recent logged activity and investigation progress at a glance, with information about investigation status, target dates (e.g. for court appearance), persons of interest, etc.
Incidently, its also a much better tool than other investigation databases that I've examined, based on Access, for instance; these have been OK, but were really just electronic filing cabinets, with little cross-linking and built in investigation management or brief/statement creation.
In the project world, Comtrac, like i-nexus, is designed around the project (let's stick with that word) end result. I-nexus works to benefits that must be realised, then tracks back to the actions that will produce the benefits. This is done in an hierarchical manner, with the software providing automatic summaries after the fashion of hammocks in a project network chart.
Comtrac bases the project on the project elements (could be a work breakdown structure showing deliverables, or some other form of project breakdown structure), then links documents and actions to that structure (evidence, actually, in Comtrac's terms). It also provides for a project log, project chronology and analysis of how the evidence links to the elements: easily translated into a project. One can also view the project in terms of the documents uploaded against the elements.
The great thing about it, though, is that it automatically produces draft reports from the data entered, with relevant references to files uploaded, with the reports available by date range, and a few other criteria, and with no further work, unless you want to edit the draft it prepares. I've not come across anything else that does this type of smart work.
For the complexity of a decent sized project, it would require some tweaking, but the basic architecture is exactly that which a useful project management application should have.
So when you think PM software, think of outcome/results/deliverables based management architectures such as Comtrac and i-nexus.
Pair that with Cheops and a decent document management package, and you're unstoppable.
Wednesday, August 7, 2013
Tuesday, July 30, 2013
Show me the money
Every time I've had a cost plan prepared, by a quantity surveyor, or sometimes an estimator, but I expect more from QSs, after all, I went to Uni with some of them, I don't fail to be disappointed.
The cost plan process starts early in the design cycle, typically, and to accommodate uncertainty, there are usually contingency allowances made: a 'design contingency', sometimes a 'project contingency' if the project scope is in flux, and a 'general contingency' to allow for architectural fantasies and client wishful thinking.
The contingencies are applied in a seemingly rote fashion: 10% here, 5% there, and so on.
I once asked a QS if he reviewed completed projects to see how the contingency allowances bore up to the real world. The answer was a staggering "no"! Here we are, with a great source of data to allow good calibration of many building and project types, and it's let blow in the wind.
The other thing I notice with project cost plans is that the estimate tends to increase as the project advances and more detail becomes available.
But, I think that it should go the other way. In the early days of the project, the margin for uncertainty should be quite high (worked out by the statistical history of similar projects), and as more detail is produced, it should drop, with the margins for uncertainty assigned quite clearly to particular elements of established risk. Then we'd be getting what we paid for!
The cost plan process starts early in the design cycle, typically, and to accommodate uncertainty, there are usually contingency allowances made: a 'design contingency', sometimes a 'project contingency' if the project scope is in flux, and a 'general contingency' to allow for architectural fantasies and client wishful thinking.
The contingencies are applied in a seemingly rote fashion: 10% here, 5% there, and so on.
I once asked a QS if he reviewed completed projects to see how the contingency allowances bore up to the real world. The answer was a staggering "no"! Here we are, with a great source of data to allow good calibration of many building and project types, and it's let blow in the wind.
The other thing I notice with project cost plans is that the estimate tends to increase as the project advances and more detail becomes available.
But, I think that it should go the other way. In the early days of the project, the margin for uncertainty should be quite high (worked out by the statistical history of similar projects), and as more detail is produced, it should drop, with the margins for uncertainty assigned quite clearly to particular elements of established risk. Then we'd be getting what we paid for!
Wednesday, July 24, 2013
The basic project questions
It may be a little bold to use the definite article, but for my part, here goes:
What do you need to achieve?
When do you need the results?
How much can you spend?
And the supplementary questions:
Why do you need it (to get the business context, or the overall 'mission' you want to conduct)?
Why do you need it then (just what is causing the timing)?
What value do you need to produce (in NPV terms, I'm thinking)?
Once the project is cooking;
What do we need to deliver?
How will we deliver it?
Has this been done before (by the owner, the project manager, the delivery crew...anybody)?
What resources and skills do we need?
Who will do what?
What could stop us?
How will we know when we've finished (that is, what will achieve the required performance?)
Another take on this is the Five Immutable Principles of project management.
What do you need to achieve?
When do you need the results?
How much can you spend?
And the supplementary questions:
Why do you need it (to get the business context, or the overall 'mission' you want to conduct)?
Why do you need it then (just what is causing the timing)?
What value do you need to produce (in NPV terms, I'm thinking)?
Once the project is cooking;
What do we need to deliver?
How will we deliver it?
Has this been done before (by the owner, the project manager, the delivery crew...anybody)?
What resources and skills do we need?
Who will do what?
What could stop us?
How will we know when we've finished (that is, what will achieve the required performance?)
Another take on this is the Five Immutable Principles of project management.
Friday, July 19, 2013
A coffee would help...
A little while ago I attended a business presentation at one of my consultant's offices. The presentation was on using i-nexus software to develop and deliver projects that aligned with business goals (now, there's a novel thought).
I left my desk at about 10 to 9am after a busy couple of hours on EOFY work, sped down to the venue and dropped into a seat at the board table.
After a flat out morning, I looked around for a coffee; a couple of other attendees were nursing mugs, so I thought, well, I'm a few minutes late, perhaps coffee was for the early starters; but the start time was 9am, not 8:30, so that was unlikely.
Well, the story was, there was no coffee offered, either before or after. The two with mugs must have just been special.
The presentation, of course, had us doing the tennis swivel as we swung our gaze between the mostly pointless images projected onto the screen at one end of the room, and the speaker, sitting at his laptop computer at the other. Good neither for neck nor comprehension!
Then, we got to the actual software on screen. It was great, except that it loaded slowly, endured continuous band-width apologies, and the colours were such and the images so small that it was barely visible and made little sense!
If you are going to use Powerpoint, at least use it with a semblance of professional capability.
I might blog about the software another time, but here are some lessons:
But, there were minor problems as well.
One that sticks to mind is the presentation of graphs showing proportions of samples doing and not doing things. The almost inevitable, and almost unreadable pie-charts; '3D' pie charts at that were flung onto the screen. Not good. Not only are the area relativities almost impossible to grasp by inspection, it is impossible to build the chart to further comparsions. A simple and elegantly done column chart would have been far better. I recommend Charlie Kyd's or Juice Analytics' work on this.
I left my desk at about 10 to 9am after a busy couple of hours on EOFY work, sped down to the venue and dropped into a seat at the board table.
After a flat out morning, I looked around for a coffee; a couple of other attendees were nursing mugs, so I thought, well, I'm a few minutes late, perhaps coffee was for the early starters; but the start time was 9am, not 8:30, so that was unlikely.
Well, the story was, there was no coffee offered, either before or after. The two with mugs must have just been special.
The presentation, of course, had us doing the tennis swivel as we swung our gaze between the mostly pointless images projected onto the screen at one end of the room, and the speaker, sitting at his laptop computer at the other. Good neither for neck nor comprehension!
Then, we got to the actual software on screen. It was great, except that it loaded slowly, endured continuous band-width apologies, and the colours were such and the images so small that it was barely visible and made little sense!
If you are going to use Powerpoint, at least use it with a semblance of professional capability.
I might blog about the software another time, but here are some lessons:
- If people are giving you their time, at least provide a coffee and some light snacks; it's dirt-cheap and for the money is a great investment in a convivial atmosphere. The hospitality shows that you care about your guests' experience.
- If the 'presentation' (I mean, the talk) has no graphic content, don't bore or distract us with Powerpoint slides. Keep them for what's important and learn how to blank the screen between times: press the W for a white blanking, B for a black one! Not hard.
- At least check the equipment beforehand and make sure it works. Don't rely on a live connection, especially if you are overseas: have some videos on a DVD, or a sequence of screen shots to show what you need to; but don't ever think you will impress people with excuses for non-performing software.
But, there were minor problems as well.
One that sticks to mind is the presentation of graphs showing proportions of samples doing and not doing things. The almost inevitable, and almost unreadable pie-charts; '3D' pie charts at that were flung onto the screen. Not good. Not only are the area relativities almost impossible to grasp by inspection, it is impossible to build the chart to further comparsions. A simple and elegantly done column chart would have been far better. I recommend Charlie Kyd's or Juice Analytics' work on this.
Wednesday, July 17, 2013
Is there a design theory?
In a previous post, I claimed that there was no architectural design theory and suggested that this got in the way of efficient design management -- if you don't know where you're going, you don't know if you're getting there!
But, there are elements of architectural design theory around; proper scientific theory, not the art school hoodwinking that passes for design theory and that abounds to the building industries' detriment.
As one example, the work of Space Syntax comes to mind: its work grows out of a theory as to how movement makes meaning of spaces.
Some of the work of the Lean Construction Institute could also go in this direction as would the Design Structure Matrix approach to setting out design interactions.
The elements are there...just needs to be pulled together used as a springboard to further theoretical development.
But, there are elements of architectural design theory around; proper scientific theory, not the art school hoodwinking that passes for design theory and that abounds to the building industries' detriment.
As one example, the work of Space Syntax comes to mind: its work grows out of a theory as to how movement makes meaning of spaces.
Some of the work of the Lean Construction Institute could also go in this direction as would the Design Structure Matrix approach to setting out design interactions.
The elements are there...just needs to be pulled together used as a springboard to further theoretical development.
Wednesday, July 10, 2013
The iron triangle
One of the most popular if time-worn characterisations of projects is the so-called 'iron triangle'. This is usually presented in a diagram with the sides of the triangle labelled 'time', 'cost', 'quality'.
I'm of two minds as to whether this is a useful motif for projects.
On the one hand it is simple, memorable and roughly correct. On the other, it is an oversimplification that omits the principle driver of the three project parameters: the out turn value of the project to its promoter.
The general contention is that to vary any one of the parameters, the others must 'give'. So, to decrease cost, the quality may have to be reduced, or the time extended, because usually to decrease time for a project's completion increases cost. Increase the quality, and you have to perhaps lengthen the project's life or increase the cost, or both.
Within bounds, this makes some sense.
But the terms themselves don't represent the reality of projects: I'd prefer delivery (because we don't manage time, we manage our activity with respect to time to achieve delivery), budget (which should include a buffer for the probability of risk) and performance, which brings together the specified quality and project scope to deliver the required business value (or we could alliterate it into 'price, production and performance'). Changing any of the three will change the value delivered, but sometimes value opportunities can be gained by increases. For example, increase the budget on a retail centre to achieve delivery before Christmas to delivery greater business value.
Max Wideman has some rather complex motifs, but I think that this over-cooks the mix; simplicity is best, but only as a point of departure; and the substitution of the terms I suggest helps, I believe, to clarify their implications; but what should be expressed, rather than implied, is that the result has to always be seen in terms of the business value produced.
I'm of two minds as to whether this is a useful motif for projects.
On the one hand it is simple, memorable and roughly correct. On the other, it is an oversimplification that omits the principle driver of the three project parameters: the out turn value of the project to its promoter.
The general contention is that to vary any one of the parameters, the others must 'give'. So, to decrease cost, the quality may have to be reduced, or the time extended, because usually to decrease time for a project's completion increases cost. Increase the quality, and you have to perhaps lengthen the project's life or increase the cost, or both.
Within bounds, this makes some sense.
But the terms themselves don't represent the reality of projects: I'd prefer delivery (because we don't manage time, we manage our activity with respect to time to achieve delivery), budget (which should include a buffer for the probability of risk) and performance, which brings together the specified quality and project scope to deliver the required business value (or we could alliterate it into 'price, production and performance'). Changing any of the three will change the value delivered, but sometimes value opportunities can be gained by increases. For example, increase the budget on a retail centre to achieve delivery before Christmas to delivery greater business value.
Max Wideman has some rather complex motifs, but I think that this over-cooks the mix; simplicity is best, but only as a point of departure; and the substitution of the terms I suggest helps, I believe, to clarify their implications; but what should be expressed, rather than implied, is that the result has to always be seen in terms of the business value produced.
Wednesday, July 3, 2013
Project graphics
In my previous post on this question, I suggested that the quest for an all encompassing project graphic representation was probably misplaced. Projects, at least large ones, but even smaller ones, are too complex and have too many information flows to lend themselves to comprehensive graphic summaries.
But, that said, a useful summary of progress vs plan at the 'whole project level' (that is, not at the more detailed level of WBS responsibility, resourcing and completion progress) could be as follows.
An actual vs. planned, per month, usually, of:
and tracking of numbers of
But, that said, a useful summary of progress vs plan at the 'whole project level' (that is, not at the more detailed level of WBS responsibility, resourcing and completion progress) could be as follows.
An actual vs. planned, per month, usually, of:
- expenditure
- earned value
- commitments (that is $ committed via contract, or work package commencement)
and tracking of numbers of
- unresolved issues
- activities commenced vs.plan
- activities delayed
- activities completed vs. plan
Subscribe to:
Comments (Atom)