Project dimensions

Looking on the web-based project management offerings, I'm coming to think that many are designed for projects that I would regard as trivial: you could manage them with either bits of paper, or Excel. They don't seem to lend themselves to what I regard as a serious project. For me that means large construction projects: retail, industrial and institutional projects of at least $100m.

The life-blood of managing these projects is the information torrent.

Matters of schedule, expenditure and performance are there, of course, and set the 'tempo' and objectives of the project, but to get things done, information management is what happens day in and day out.

I conceptualise these projects along two basic dimensions: the project breakdown, and the work breakdown. For spatially large projects there's a spatial breakdown too. For example, a retail centre will fall into a number of organising zones: food court, groceries precinct, major boxes (for the large department stores), fashion precinct, car parking (which will be subdivided in most cases by location).

An industrial complex might fall into warehousing, administration and amenities block, production, packing and distribution.

Hospitals fall into a number of units too, for large campus developments: medical services, wards, ancillary services, research and education wing, etc.

Dimensions

The two basic dimensions which apply irrespective of size are the project elements (the parts of the project) and the work packages (how the parts get delivered).

Elements are unrelated to schedule but organise information, work packages are schedule related and organise activity.

In projects I've applied this scheme to I've thought that the hierarchy of elements can only realistically go 3 or 4 deep, and not across the whole project, or its gets unwieldy. In practical terms the hierarchy has generally been 2 deep, elements being subdivided into items, such as the element 'external works' broken into items: site preparation, bulk excavation, paving and line marking, planting, site services (lighting, drainage, water reticulation, service mains, services diversions, security and communications), retaining structures, fencing, signage.

Work packages are large units of work that deliver a completed project component, or sub-project in some cases.

A work package is delivered through 'activities' (these are the things that usually appear in a scheduling application like Primavera, they roll up into work packages, or summary activities quite easily).

To complete activities a number, sometimes a large number of tasks are done, such as the activity 'clear site' might require the tasks: remove vegetation, protect structures and trees, remove refuse, install siltation barriers, etc.

In summary we have: Elements --> Items; Work packages --> Activities --> Tasks.

Thus, one can see how trivial Web-based 'project management' applications that facilitate 'tasks' have to be; they do not and often cannot put tasks into a useful project context.

Now, how do they relate?

Using examples from construction, in some cases a work package will be identical to an element. For example, the 'external paving' element could be delivered by a single work package for paving (although at the element level, 'external paving' could comprise both vehicular and pedestrian paving, which could be two different work packages, or more, delivered in different locations or at different times, even if done by the one contractor). In some cases, a work package and an 'item' might have identical coverage. More usually an element would be delivered through a number of packages: 'external envelope' could be delivered via work packages for brick laying, curtain wall, glazing, external doors, louvre installation.

Some of these might be items. The item 'external doors' would usually be delivered by a single work package.

Activities could be aligned with 'items', but this would not always be clear cut. The item 'external doors' could be delivered by a package for external door supply and installation, but the item 'water mains' might be finally delivered through a number of work packages: site clearing, bulk excavation, trenching and shoring, mains diversions, pipe laying and connections. In brief, work packages tend to relate to elements, and tasks typically relate to items, but they are not always 1:1 relationships and one does not always exhaust the other.

'Elements' and 'items' serve as means for compiling related production data and project information for consolidated views of the project by its management and delivery teams.

For the manager, the two hierarchies allow selective visibility of progress, but allow risks, issues, documents and changes to be attached to elements for a comprehensive view of factors affecting the project at any time.

The Sensible 12: No. 1

The Sensible Project Manager provides a set of 12 Principles of Project Mangement. This is way more than Glen Alleman's 5 Immutable Principles, so...is that better or worse, or just different?
Over the coming weeks I'll comment on each of the 12, with the first now:

1. The project vision must be clear and agreed to by the stakeholders.
The first principle to success begins with understanding the vision or goal of the project. There is a reason the project was initiated and the project manager as well as all stakeholders must understand the business need and what success looks like. Make sure that all stakeholders understand and agree to the project vision.

This looks right, but the language is too fluffy to turn into action. What is a 'vision' when it comes to a project? Better that a project have a clearly defined busines value with the means of realising that value built into the project. The project must have a stated mission to achieve, and a definition of the capabilty that the project will produce.

This will flow straight into the funds that can be made available, it sets termination criteria to avoid throwing good money after bad for a project bound for failure, and allows objective acceptance when 'done' is achieved.

Vision is fine, but you'd better know what the capability of the product will be and its cost if you want to stay in business.

Then, as part of the work of the organisation, the project has got to be supported by the organisation as a whole, otherwise mission critical will be turned into mission aborted. The IRR on aborted missions is a negative number!

Wrike

Letter I sent to the people at Wrike:

I've had a quick look at Wrike, and like what I see.

Wrike seems to conceptualise a project as a set of tasks, rather than an information flow. Thus information about a task seems to have to be stored at second hand, in an attached document, and is not directly accessible from a task or a folder.

Incidentally, the use of folders for multiple representations of the project is very flexible.  I would use this to organise a project by phase, static element list (e.g. 'design'), by dynamic element (e.g. WBS element, where I'd like to be able to see hierarchical summaries), supplier, functional component, etc

But, back to the information content of a task. A task will have a number of basic information parameters: obviously name, description, WBS number, cost code, RAM nominations, antecedents and dependencies, which are metadata-like, then substantial data such as performance and acceptance criteria, issues, progress notes, risks (derived from a separate 'risk breakdown structure'), Requests for Information, Answers to Requests, decisions, pending antecedents, change requests, etc, each of which will have a status and need to be tracked and reported upon.

Being able to review a project on any of these items could then be facilitated. For example, the number of pending tasks with outstanding change requests, or overdue decisions, or unresolved issues could be looked at anywhere in the WBS hierarchy, or by project element, assigned manager, etc.

I didn't see how Wrike managed communications, including logging emails, which I would guess would be possible, maintaining project requirement sets, meeting  minutes and review lists that were linked to project components and not as binary blobs (ie attached text, spreadsheet or tabular documents that need their own viewing application). In complex projects tracking document issue, receipt and revisions is  vital. I couldn't see how I could do this in Wrike, nor how even simple configuration management could be done.

Project context may be a factor here. My project area is multi $100m property development projects that might take a few years. The illustrations on your website seem to be in other domains.

Flash Blog on PM

A late and uninvited participant in the international 'flash blog' on "what project management means to me".

Simple.

Getting things done through people.

Same as general management, of course, but the things either handle or creating a change in the business environment to attain or sustain a competitive or customer service advantage, defined as broadly as you like.

Here's Glen Alleman's take on it.

The risk in risk matrices

Not only did the consultant-led risk workshop start with a limp, it also ended with one.
For all practical purposes, it drew to its conclusion with the obfuscation of using a matrix to locate risks in a two dimensional space with dimensions 'likelihood' and 'severity'.

The problem with this was in neglecting to deal with the simple measurement error it gave us a result that was misleading; potentially so misleading it was no better than no result at all. The risk cells between different risk intensities have a natural error. That is, while they are bounded by lines, they should in fact be bounded by indeterminate zones where we cannot know the location of a risk.

This means that in a typical 4 x 4 matrix, it is not possible to distinguish between cells that touch at a corner.  But it gets worse: depending on the uncertainty between risk zones, it might be impossible to distinguish between cells one row or column apart in adjoining columns or rows. That makes the exercise pointless, and can lead to gross over- or under-allocation of resources to risk response.

Cox has examined this problem in detail, as discussed by Awati. Alleman also discusses uncertainty in projects.

As Gerd Gigerenza says (Helping Doctors and Patients Make Sense of Health Statistics), the first step in statistical literacy is understanding uncertainty. In risk analysis, above all, there should be some recursive application of uncertainty to that process that is established to deal with uncertainty. Physician, heal thyself!

Risk management charade

A while back I attended a workshop with a client. It was to develop a corporate risk management 'framework' (as they like to say these days). The workshop was facilitated, and probably at great expense (more original art works on partners' walls), by a major consulting firm. Let's call them King Prince.
In what was clearly a canned presentation, that had nothing to do with my client's business (the business is in health services), our bright young facilitator's first text book question was "what is [company name's] appetite for risk?"
OK, so let's think about his. What was [company name's] appetite for risk? That is, how many people should die each year from iatrogenic causes? Is that it?
In this question both the facilitator and the firm, let's abbreviate it to KP, shot their credibility. We continued the workshop politely, but left in awe at their misreading of a client's business.
I wondered how much my client paid for this tosh.
Of course risk appetite has a place, as a question. But its place is more in the world of finance, hedging and portfolio management, were risk can be objectively (sort of) assessed, priced, and managed. It has a completely different place in health provision where death is not tolerated (from non-natural causes, that is), but investigated and avoided.

What is a project?

There are lots of long and tedious definitions of a 'project' around, but I like this one by David Allen:

The project merely describes something in the world looking or being different than (sic) it currently is.