Reporting in Project 2007

G

greg

Hello,
I know in Project 2007 there are 2 ways of reporting. OLAP and SRS.
Is that correct?
Should people really pick one of the reporting technologies? Or can a
deployment go with both?
Would you need 2 servers? Or could both be run on 1 additional server?

thanks for any help
 
J

James Fraser

Hello,
I know in Project 2007 there are 2 ways of reporting. OLAP and SRS.
Is that correct?
Should people really pick one of the reporting technologies? Or can a
deployment go with both?
Would you need 2 servers? Or could both be run on 1 additional server?

thanks for any help

You can certainly use both. They have slightly different purposes and
there is no technical reason why one would exclude the other. I can't
imagine asking a customer to pick one or the other.

SRS can also incorporate OLAP data into it's reports.

Generally, SRS provides more flexibility at design time and in
delivery: Reports can include multiple sub reports, multiple charts,
fancier formating. SRS will deliver reports via .pdf, .xls, &c by
email or to a file share, or on demand.

OLAP data provides more flexibility in viewing the data. Slice and
dice, change your filters, add a column, add a caluclated column, &c.
Pivot table stuff galore. It will generally require a little more
formating if you decide you want to then make a presentation style
report from the information.

Both Analysis Services (OLAP) and Reporting Services are included with
MS SQL, so it is very common, due to licensing issues, to have these
installed on one server.

My descriptions of OLAP versus SRS are very general and only scratch
the surface of capabilities. There are many exceptions to what I've
written, so I'm sure some will disagree with me.


James Fraser
 
G

greg

James Fraser said:
You can certainly use both. They have slightly different purposes and
there is no technical reason why one would exclude the other. I can't
imagine asking a customer to pick one or the other.

SRS can also incorporate OLAP data into it's reports.

Generally, SRS provides more flexibility at design time and in
delivery: Reports can include multiple sub reports, multiple charts,
fancier formating. SRS will deliver reports via .pdf, .xls, &c by
email or to a file share, or on demand.

OLAP data provides more flexibility in viewing the data. Slice and
dice, change your filters, add a column, add a caluclated column, &c.
Pivot table stuff galore. It will generally require a little more
formating if you decide you want to then make a presentation style
report from the information.

Both Analysis Services (OLAP) and Reporting Services are included with
MS SQL, so it is very common, due to licensing issues, to have these
installed on one server.

My descriptions of OLAP versus SRS are very general and only scratch
the surface of capabilities. There are many exceptions to what I've
written, so I'm sure some will disagree with me.


James Fraser


OK, thanks for the thoughts
 
M

Mark E. Read

OK, thanks for the thoughts- Hide quoted text -

- Show quoted text -

A little more on reporting:

1) SRS is not set up as part of the standard EPM install, and needs to
be configured. OLAP is a little better integrated into the overall
Project Web Access world, but either can sit nicely if configured
properly.
2) SRS development is assisted by a Visual Studio .Net client, and
knowledge of SQL. OLAP can be drag and drop, although if you want to
dig deeper you can get into MDX.
3) What about Visual Reporting out of the Project Standard or Project
Professional client? This gives you a lot of pivot table and chart
functionality and gets data in OLAP form out to Excel or Visio. This
is mostly client focused, however.

There are lots of possibilities, but remember that even the best
reports in the world fall flat on their face if the underlying data
(in the project plans or within Project Server) is incorrect. You
will likely need to invest more in data quality controls rather than
report development.
 
J

James Fraser

There are lots of possibilities, but remember that even the best
reports in the world fall flat on their face if the underlying data
(in the project plans or within Project Server) is incorrect. You
will likely need to invest more in data quality controls rather than
report development.

I agree with Mark's points, and this raises some questions that we are
often asked:

Accurate data is the foundation for Project Server reporting, but to
increase your likelihood of accurate data, you may want reports on
compliance:
How many of my projects are baselined. When were they baselined? How
many have assignments on Summary tasks? Which projects need to be
republished or have time pending approval? Which resources reported
enough time for last week?

I think this is where SQL Server Reporting Services really shines.
Scheduled email reports that answer these questions with custom
formatting and intelligent summaries can really cut to the chase on
who needs to clean up what data.

Yes, these reports take much longer to develop than OLAP views or the
canned reports in Project Pro, but their value to businesses is
immense.


James Fraser
 
Top