Development Costs and Technical Confidence...

Micro-management is often the adversary of creativity and progress; with progress constrained by the rate at which the micro-manager reaches their own level of comfort and understanding.

This applies to technology (software) programmes, even the implementation of pre-pack solutions like OBIA!

For the manager, it's important to understand the RELATIVE impact of software development challenges, when you're delivering solutions driven by software. Why the problem is easy or why it is hard, has a profound impact on programme planning and budgets.

This can greatly increase cost for enterprise programmes, increasing the cash burn rate. For a start up, getting this wrong can be fatal!

Modern day project management methodologies must shoulder some of the blame for producing the pure 'Microsoft Project jockey', but the better manager develops a certain curiosity for software solutions that makes them more able to anticipate difficulties ahead.

As a non-technical manager in these situations, a level of questioning for your development staff is crucial. Try not to make the questioning static, like the real exchange I had recently with a client below:

Manager: That looks technical, what are you doing?
Developer: I'm re-purposing the scripts so they work in both non-clustered and clustered environments!
Manager: That's not something I can help you with, sorry.
Developer: Err... no I guess not!

Questions should be designed to tease out why certain tasks in the solution are important and how they contribute to the overall solution. A better set of questions might have been:

Manager: I understand you're working on X, is that what you're doing just there?

Developer: Not X just now, I'm working on re-purposing the scripts so they work in both clustered and non-clustered environments.

Manager: OK, I'm a little unfamiliar with that work. It sounds important, perhaps you can tell me more about the implications of this?

Developer: Sure... BLAH BLAH BLAH  
 

This level of questioning is extremely important for good project (programme) management!

Once the manager becomes confused by technical complexity, however, they revert to questioning the validity of technical tasks in a plan (solution). This level of questioning can be a waste of time!

As a non-technical manager (read start up CEO working with technical staff), keep in mind what are you trying to achieve by asking these questions...

    - enough understanding of the challenges in your project (programme)

    - a greater appreciation of the capabilities of your technical staff

    - greater control of cost

Recognise, however, once technical aspects become unclear this makes them NO LESS valid. Better developers will have some understanding of the planning and costs you're trying to control.

Keep your questioning open and you'll gain the trust of your developers!

I write a blog under the pseudonym DR. OBI. Feel free to get in touch with me about your programme. You can find me here Justin Townsend.

Use Custom CSS Styles

Look and feel (OBIEE Skins and Styles) is difficult to change for many users. Changes to CSS classes often need a release.

Work on custom CSS styles as an Answers user. The 'Use Custom CSS Style' option processes multiple style arguments separated by a semi-colon.

From DR. OBI

Once you're happy with your custom CSS styles...

background-color:#ED0000; font-size:8pt; color:#FFFFFF

you can group them into a CSS class

.DR_OBI
{
background-color:#ED0000;
font-size:8pt;
color:#FFFFFF
}

Along with the other styles (classes) you've created get them all to be added to custom.css for the next release.

Request Design for Infrequent Users...

Infrequent users will not be so familiar with request content. Adding hints, such as subtitle (shown here), greatly improves the user experience.

From DR. OBI

As your request design includes more interactivity, consider hints / notes for users.
 

Careful Request Formatting

The 'View Selector' is useful, but make sure there are enough visual cues between different views so users relate information easily. Be consistent with:

• View names
• Column names between views
• Column sequence (a consideration for a chart / table view switch)
• Number formats
• Colour cues and...
• Expected format for each view

From DR. OBI

Switching views can feel incongruous to the user, especially when the selected view doesn't meet expectations.

Requests with Round Objects...

If the business requirement persists for a pie or even a gauge then Answers has both of these options.
Pie charts best highlight contributors to a whole, so %-ages are often the best accompanying values. Always showing values forces the pie smaller, think about showing values 'On Mouseover' only or increasing the space (if you have it) occupied by the chart to ensure easy viewing.

From DR. OBI

Stephen Few writes extensively about human desire for all things round, so its not repeated here.

Request Design

Good design will make for compelling requests. Space is always limited, so remove redundant information. For example, a chart with accompanying table of the same data.

From DR. OBI

A good use of the 'View Selector' is to switch chart / table data in one place. It gives greater design flexibility.

Saving Answers Requests

It is good practice to provide further detail in the 'Description' section when saving the request. The OBIEE catalog will grow over time; so using the 'Catalog Search' facility in Answers you'll always find your request quickly and efficiently.

From DR. OBI

Description section provides plenty of space for detailed content write-up, but keywords tend to be more relevant. Briefing books, dashboard prompts and saved filters will not appear in catalog search results in OBIEE 10.x versions.

Available Content

The blog deals with leading practices in the use of Oracle Business Intelligence (OBIEE). Topics focus on the challenges faced in implementing front end components:

• Answers
• Dashboards
• Delivers and
  
• BI Publisher...

If implementation differs because of the datasource (M-OLAP v. R-OLAP), then they are addressed.

You will not find installation steps here, or a discussion of new features except to highlight if it is possible in a specific version.

For this information, many accomplished professionals in the industry deal with these topics through consulting and blogs. Here are some I've had the pleasure of meeting or working with:

• Mark, Jon, Venkat, Adrian et al. down at Rittman Mead
• Dave Atherton and the team at Praesto
  
• Christian Berg, who writes independently on the delicate OBIEE / Essbase combination
• John Minkjan, Ciber consultant, also writing independently on OBIEE and...
• Kurt Wolff, an OBIEE practitioner of long standing writing for KPI Partners
  

And for leading practices in structured training and adoption for OBIEE, Peak Indicators do very good work.

The list is not exhaustive, but remember, in most cases free advice is worth what you pay for it.