Use of "Role" goes beyond Project Management and Estimation

We've been trying to see if there is a standard list of roles that can be encapsulated in the OSLC interface that estimation and project management tools will use to communcate. I think we've established that "role" is a standard concept that goes by different names in existing tools (e.g. "labor category"). So I think we're in a good position to say that "role" (that's the term we agreed on) can be part of the OSLC interface used to connect PPM and estimation tools.

But it's more problematic to establish a standard list of roles. We found that Galorath's and QSM's "default" lists were pretty close with just one or two differences that probably can be handled. But this isn't enough evidence that the list of roles should be standardized in the interface. In particular, we should look at how various tools use the concept, and at what level it needs to be configured.

Two issues: who "owns" the configuration of role, and at what level is it configured?

a) Estimation tools use "role" to help determine total cost of a project (a role has a standard rate, so you can estimate effort by role and use the standard rates to get total cost...that's part of why "total effort" isn't a very useful metric). Also, I presume (though we haven't explicitly discussed this) that estimation tools use actual effort by role to assess progress through a project and for re-estimation (so that's the other reason "total effort" isn't so useful). Project/Portfolio management tools use "role" for other uses--total cost, like the estimation tools, but also to find people with the right skills to fill the roles: staffing the project. (Also perhaps for re-billing a customer at different rates based on actual effort by role).

But other tools use the same (or related!!! this gets interesting) roles for other purposes. Tools throughout the ALM life-cycle adjust the process by which the tools are used by role (who can change artifacts and what can be changed, preconditions/postconditions when someone acts on an artifact, workflows and approvals). Now in this case, "role" may be modified from what the estimation/project management tools need. For example, the estimation tool may say we need three designers (all of whom have the same "standard rate"), but one of them will be appointed "lead designer" with certain approval responsibilities. So the RACI matrix may have "sub-roles" assigned (justifying the name "labor category" for what the estimation tools use, perhaps!).

I would argue, in fact, that "process" tools are the "owners" of the list of roles used, and both estimation and project management tools should get that list from the process.

Also, reporting tools/data warehousing tools will use "role" as a dimension, measuring the actuals that the estimation tools need, and for cross-project analysis of process improvement.

b) What level is it configured at? Probably multiple levels--this is always the hard part of configurable metadata. There may be an enterprise wide definition that can be overridden (or perhaps refined is better) by a group of projects (we need a "project template" resource that has the list of roles!), and may in fact be overwritten/refined by a specific project. The estimation tool needs to know "what roles are used for a specific project" which could come from any of those levels.

And why is "refined" better than "overwritten"? Cause, for example, the enterprise reporting tool will have to "map" the roles to a standard set of values it uses at the enterprise level.

Implication for the OSLC interfaces: There's probably no need, and I suspect not wise, to have the OSLC interface standardize the list of roles. Instead, there should be a "role" element of the project definition which has a URL that points to the list of roles (which lets it be owned at any level!!!) and is used by both PPM tools and Estimation tools. That URL could then point to the list used by the project, project template, process, or enterprise wide list as appropriate.