Hi Joroen,
Sometimes authors can provide quick experiential substitutes for surveys when they summarize norms (and limits).
Here are some comments from Eric Verzuh, author of "The Fast Forward MBA in Project Management: the portable mba series" published by John Wiley and Sons 1999, page 281 to 285 quoted and summarized below:
"No matter which kind of project information system a company might choose, there are a number of considerations that will influence the effectiveness of the system and the effort to install it. Here are some guidelines for developing.. [one].
"Start with reporting requirements... the information requirements for the system must be clear. The basic questions that drive the entire system are:"
"Who needs information?"
"What information do they need?.. what decisions or actions will be based on the information?"
"When do they need it?"
"Where will the information come from? does it exist anywhere now or does it need to be created?" there is a need for consistent standards for entering data at the detail level (pg283) [It seems that an ability to assign to any instance (financial, calendar, resource, content) with at least one WBS reference (which designates responsibility and authority roles etc.]
suggests "top-down design of a work breakdown structure"
Customization is a given part of any off-the-shelf system
"if your organization runs many small and medium-size projects, you'll want to use the simpler applications at the project level. These lower-end applications may not have enough power to pull data together from all the projects, however; you will need to choose one of the high-end applications to handle that chore" [I think this implies ability to dump data to spreadsheets or external DBs for starters]
a pm system only works if it gets used consistently and completely --ie users don't bypass it, suggesting that the system needs to be user centric and user friendly.
"The true potential of a consistent approach to pm is realized only when the discipline is extended to the organizational level and used to choose, monitor, and cancel projects. The ability to link projects to the operational and strategic goals of an organization has far-reaching implications for the effective use of resources, particularly people."
"Like good pm, portfolio management delivers the best results when it is based on facts and data. The project information system empowers the portfolio management process by providing the facts that drive decisions".
"The Spectrum of Project Office Models... The two factors that govern a project office role are responsibilities and authority (full, partial, none). [Hmm. this granularity should adapt well to the user-group permissions in dotLRN (as I understand them)]
--end quotes
I think these comments suggest some rudimentary customizable resource/info sharing packages that where hinted at previously. Since OpenACS' strengh focuses on collaborative work, I don't know that it would be wise to model after non-colaborative pm-based software solutions, given that pm systems work best when the entire project team participates. These packages need to be user-centric while providing the pmgr with the necessary operating info also.
