Ecppm 2004 thursday morning notes part 1¶

See the overview page for the links to the rest of my notes. This day started with two keynotes. Miroslaw Skibniewski (Purdue university) - Web based project management in construction

WPMS (webbased project management systems), you can do it in three ways: do it yourself, buy it, rent it from an application service provider. Especially in the US, WPMS are quite popular, but it is hard to figure out how good the system is. The vendors only mention the positive aspects, so... They started a research to whether these systems are any good. Most interesting (imho) of the research questions: if a WPMS is successful, what's the correlation with the project's success.

The opinion of US experts they interviewed differed a bit from international researchers. For the US, the system's ease of use was the top priority, data quality second, system reliability third. Non-US experts: #1: presence of a champion, #2 experience with the project management ASP and #3 the teams attitude towards a WPMS. (A "champion" is one single person advocating and evangelising something).

Now to the research findings. Contract type and project complexity don't affect the performance of the project management system. Especially the second point is counter-intuitive: you'd expect problems on the harder projects.

Strong effects on the performance:

• the party who decides to use such a system. If the owner does it, the contractor doesn't like it.
• internet availability and type of connection. The better the connection and the more participants have connection at their work location, the better.

(Btw, much too much material to write much down, you should really read the paper if you're interested).

Interesting conclusion: hosting it yourself instead of using an ASP does not yield higher security. Even with sensitive financial data. (Yeah, figure. That ASP will be fried alive when there are serious security problems, probably costing them a lot of customers. So they're bound to have someone dedicated to keeping it all secure, better than you could normally do yourself! See Paul Graham).

Thomas Froese (university of British Columbia, Canada) - Help wanted: project information officer!

One of his students was busy with a company and he was sorely missing information in good, usable formats. Product models, OK, but the information first has to be converted, blast.

For a lot of these systems we invent, the target users are the very busy senior project managers. Highly effective at doing their job. But learning new IT skills is not on the top of the list. So an entirely new kind of way of dealing with information does not stand much chance.

A possibile solution to this problem is to create an entirely new function: the project information officer. So, let's look at a first draft of a job advertisement for such an PIO (project information officer).

Primary duty of the PIO: develop and implement an information management system. Probably includes training and evangelising etc.

Some needed areas of expertise:

• project document management and classification and a collaboration website.
• classification systems, project breakdown structures etc
• model-based interoperability
• requirements management system
• model-based architectural design
• visualisation
• model=based engineering analysis and design
• project costs and value engineering
• construction planning and control
• e-procurement
• e-legal strategy

We want a unified approach to project management, it should fit well to the way the rest of the project is conducted. There is a bit of a mismatch between the current practice and the "integrated IT mindset". The mindset is influenced by the conceptual building blocks that we use to describe and organise the project. Use concepts that invite you to think of the project as a set of interrelated parts instead of as individual, separate parts.

It is important to create good views of the project information. Personalised views. "My plan", "My contributions to the project", "My results" (drawing of the building with the parts I made highlited), etc.

The costs? There is a general assumption that the cost savings are higher than the cost of an PIO. WHen reviewing the performance of the PIO you should be aware that this is for the most part not a direct measure, so it should be assessed qualitatively through a review process. "How trouble-free could you get good information", etc.

Question afterwards (by Jerry Laiserin): why not seeing the architect as the lead information manager, as that is part of his role. Answer: Thomas sees that IF the information ball is catched by anyone, it isn't often the architect, more the lead contractor.

Interesting suggestion: why seeing it as a project information officer, not a company information officer. Now you have to set the cost of the PIO against the savings of every individual project. Isn't a company info officer a very strategic asset for a company? Answer: Thomas prefers the project view, as that is where the real work is done. You want to make sure that the project manager loves your stuff, so sitting directly on the project might be essential.

Ziga Turk supported Thomas regarding the importance of having the PIO on the project. Every project is pretty unique, the PIO needs to be right on top of it. He had some experience that supported this.