Discussion: 'The 50% Expectation'

[MDXpressor]

I have found that serving my user community (finance dept. mostly), that they almost expect to have to adjust a report in some way.  It has been a real revelation for most of my consumers to not manipulate the delivered data.  I call it the '50% Expectation'; where they just want a report authored that delivers the data as a simple set with no formatting, and then they spend a half hour putting the lipstick on the report.  I mean they apply some simple calculations, or some sort orders, groupings or maybe they sift through it to create sections, or whatever.  Worse, they do this every time this report is required.  The point is that it could all be applied in a report and delivered as the end result instead of just a 50% solution.  In every area they have become so accustomed to receiving raw data (normally a query against the source OLTP system) that the downstream reporting became a process of little changes instead a of simple data sanity test.  In many cases, they didn't realize they could deliver multiple stages of reports, or even completely unrelated queries on seperate worksheets.  We have really been cutting into the hours it takes to consume the repetetive reporting we do on a monthly, quarterly, yearly basis simply by delivering the data pre-formattted.

Anyone else seeing similar tendancies in their users?  What are your approaches? 

I like to use working sessions with new users to make sure that I understand the desired end result that will get passed on or presented.  The great majority of the requests can be delivered exactly as they want it.  I find this also helps acclimatize the user to the C8 environment, giving them a taste for its power.    However, I am an internally employed Report Author, it is not nearly as expensive to burn an hour here or there as it is to do that with a consultant.  Do those of you who are consultants use the same approach?

[MikeD]

Today, being my 1st entry into the Cognos realm - forum and work - I see exactly the same issues that i experienced back over in the BusinessObjects world.
Basically it all boils down to the site's procedural path in delivering reports / solutions i.e. the working relationship with the Biz.
If the org has an elaborate process in requesting reports that breaks down to a time & materials / cost level, then you're sure to get a completed specification / requirement.
It's the adhoc / generic IT and Biz relationships that tend to abuse the concept of development, and this needs to be refined on the project manager level.
The problem that most of us face in IT, is that we try to bend over backwards to help the users, oft bypassing helpdesk / ticketing / task management systems - fine and well for the odd solution, but this can expand to the situation that you're facing right now.
It's Catch22 really - the biz never has the time / foresight / forewarning to sit down and strategize / plan all their requirements - and typically get sideswiped by the upper echelon, so everything is a tad re-active.
I have found that users generaly have a rough idea as to the report details, but typically can only apply the fine detailed thinking once they have visual contact.

The line between consultants and permanents is pretty grey these days, but consultants are deemed to be more controlled /costly re deliverables so it falls back on the corporate culture as to how effectively their deliverables are created and measured. The converse here though, is that there could be a culture of - let 'them' do the nasty / techie stuff - and we wil do the nice / easy stuff so it costs the company less lol

.. glad I found this place - and that i could use the same nic as i did over at my previous home - a BO forum .... 8)

 

[acabugason]

I find this post very interesting, although i'm finding out that what is described here is more of the norm than the exception. This is a topic close to my heart.

I am a Business Analyst who belongs to a group that straddles both the IT and Business worlds. A Funtional-Technical liason, if you will. We intercede between these two groups to make sure that all messages are transmitted clearly in each direction. Not only that, we also help the business strategize.

MDXpressor's post points to the heart of the issue. Business users have been used to getting reports in its raw form such that they almost always expect to have to do some sort of manipulation to get it to its final form. Furthermore, Business has this tendency, for right or wrong, to want adhoc reporting capabilities. The real problem is cultural as MikeD alluded to. This culture has to be broken and changed from the ground up.

I'm not sure how this will help, but the following is the approach we are trying to take. We have barely begun and we know it will take a while, so I can't tell you if it works.

The first thing you will need, if you are with IT, is to form a partnership with someone in Business or with someone who can speak both functional and technical languages. Then you will need to identify the business culture, its tendencies, and figure out the business value/case for a more streamlined reporting process.

One thing we realized from the very beginning is that business users do not necessarily know the difference between reporting and analysis. They tend to combine the two. But from an efficiency standpoint, you would want both to be separate. Most of your users are really just report consumers who just want to see the reports. Those who want to do the data manipulation/adhoc reporting really are a small minority. Given the different tools Cognos offers, it boils down to 'the right tool for the right user.' The specific approach is unique to every company but the general idea is the same.

The last thing you want to do is drum up support. A business sponsor at the top executive level is best. This person must understand and support your approach. This person must be at the top levels so that change can be more effectively pushed through.

One more thing we learned is that this cannot be an IT project. IT's job is to provide the support to keep the business running. It is not the business. Ultimately, the business and its needs determine what gets done. IT's role in this type of effort is to provide advice (as strongly as necessary) and expertise. It is still the business' prerogative whether to take up IT's advice or not.

This is a bit long but I hope it contributed positively to the discussion. I'm looking forward to hearing from others about their experiences.