Now that we have an idea of the Project Database layout (specifically, about the fields we need), we are ready to create a report.  In the project we have created the custom field Element number.  This field groups project tasks across projects to help in our reporting.  Some people in Project circles may call this the WBS number. 

The idea is that for a task, say creating a Web Method, there is the same element number.  So if a department has 25 projects, and 14 projects have one or more tasks that create a web method, we can see actual numbers for how long it takes our group to create web methods.  You can also slice and dice tasks, like create Stored Procedure or get even more fine-grained.  You could have Create Insert Stored Procedure, Create Delete SP, or Create a complex select SP.  Assuming you keep the history, this can help with estimating.

For our report, we want to know which tasks that are standard elements- do not have actual start dates.  If you wanted to enforce your definition of Standard Elements, you should use a code table with those elements in them.  Then you would use that code table as the source for your element numbers.  This can be accomplished by utilizing the Project Wizard to create projects, or you could create a front-end web application utilizing PDS calls to create a project.

We could also specify other information using these custom fields.  For instance, if we had a custom Project field called Status, and Active was one of the values in Status, we could filter the report for Active projects.

For this report (elementsummary.rpt), we use a Cross tab in section 4.  For this cross-tab we will place the element number as the column across the top.  The first row is the project ID (could be the project name).  The major row (furthest to the left) is the project manager row.  So the report will display each major element for each project in the filter with the Planned Start and Finish Dates. 

You can add a parameter, like the Project Managers, in a drop down to make the filter more granular.  Making that a multiple value parameter would allow you to view a group of Project Managers, but not everyone.  If you had other custom fields at the project level, then you could add those as filters as well.  Options for that might include division, technology type, or customer.  It depends on how you slice and dice your projects.