Project Lifestyle

In the second of a series of posts on the subject of Global Single Instances I wanted to talk about how many you should have and how your ability to ramp up WAN capacity is a key consideration.

Oddly, as the subject implies, you should only aim to have one GSI. Of course Part 1 of the series debunked that idea right away. The idea is to…

Consolidate your business systems and business information to as few places and platforms as possible.

In other words, as many as you need, but no more than that…

This one came in via my PM Blender Feed (aggregated feed of blog posts from various sources). Check the right hand side of the blog there to find it.

Original post was over at Glen Alleman’s blog Herding Cats

A great presentation of Time and Money on (construction industry) projects. You know, houses, schools, bridges…that kind of stuff. They have many of the same challenges we face (and some different ones as well – I never had an ERP project delayed due to bad weather)

Also you can download a summary and detailed version their reports on this from their CIOB website.

Managing the Risk of Delayed Completion in the 21st Century

Managing the Risk of Delayed Completion in the 21st Century - Summary Report

How many languages do I need to install in my Single Instance? Can I get away with just using English (or French/Spanish/Chinese/German depending on where HQ is in the world)?

Over the years I have had this discussion on many occasions. Here are some basic truths that keep popping up. Please note that these comments are primarily applicable to functionality in Oracle E-Business Suite but you may be able to extend the ideas to other applications. Your mileage may vary.

I’ll adopt a FAQ format. For simplicity I will assume English as the default base language. You can substitute any other language here for your case – but English always remains installed no matter what.

Also see  the Homework section for additional reference information basics and background regarding NLS (National Language Support) and MLS (Multilingual Support).

How many languages do I need to install? What are the main drivers for making the choice?

Obviously this depends on the number of different language areas you will be covering in your program.

Oracle E-Business Suite R12 supports up to 30 languages (see MetaLink  Note 412218.1 Software Translation Matrix) so there is no lack of choice.

As each additional language installed carries a maintenance and performance overhead you need to choose carefully. Main drivers for consideration are:

• Lack of  foreign language (English) skills amongst the shop floor workers. These are the people using the system for the Procurement and Manufacturing processes. If you are only implementing Financials (for example in a SSC) you may be OK with English only - due to higher education levels/language skills of SSC personnel.
• Workers council sign-off. In some countries you will not get formal system acceptance without a formal workers council sign-off.  You can then encounter a situation where the workers council can give a negative (and binding) ruling against the implementation if the local language had not been installed (due to the previously mentioned point).  This needs to be part of the business case for installing the language.
• In many countries you are expected to provide your statutory reporting in local language.
• Desire to provide trading documents in local language of customer/vendor/partner

 What is the impact of installing all of these languages?

There is an impact on maintenance. About 80%+ of patches have language specific components (i.e. translatable) - so you have to install the translated version of the patch for each of the installed language.

This means increasing number of languages = roughly linear increase on number of patches to be applied. Luckily this need not translate to linear increase in amount of time require to perform the maintenance. 
Specific patching and maintenance best practices can be used to keep maintenance time down, even if you have multiple languages installed.

For detailed info on patching best practice here some links from Steve Chan’s excellent blog.

Release 11i: Patching

• 2008.08.27: Reducing Patching Downtimes with Staged Applications Systems
• 2007.11.27: Which Are Better: Family Packs or Consolidated Updates?
• 2007.06.19: Top 7 Ways of Reducing Patching Downtimes for Apps
• 2007.06.07: Top 5 Myths About Patching Apps Environments
• 2007.05.09: Reducing Patching Downtimes via Shared Apps File Systems

Release 12: Patching

• 2008.08.27: Reducing Patching Downtimes with Staged Applications Systems
• 2008.03.25: Downtime and Apache Restricted Mode in Release 12
• 2007.11.27: Which Are Better: Family Packs or Consolidated Updates?
• 2007.06.19: Top 7 Ways of Reducing Patching Downtimes for Apps
• 2007.06.07: Top 5 Myths About Patching Apps Environments
• 2007.05.09: Reducing Patching Downtimes via Shared Apps File Systems
• 2006.12.15: Patch-Related Enhancements in Release 12          

Do I need to test everything in every language?

Experience shows that (regression) testing every patch or setup change in every language is not needed. What you need is a good set of regression tests in your base language (English, say) supplemented with some random samples for one or more of the other installed languages. You only need to look further if tests in one of the extra languages show problems that are not present in the base language. This much more efficient and cost effective.

Where can I find more reference material?

Links are to relevant notes in MetaLink/My Oracle Support.

Release 11i

• Multilingual Support in Oracle Applications Release 11i
• Oracle Applications NLS Release Notes, Release 11i (11.5.10.2)
• Oracle Applications 11i Internationalization Guide

Release 12

• Globalization Guide for Oracle Applications Release 12

Crew (or Cockpit) Resource Management (follow the link for the Wikipedia article)  is a safety concept that originated in the aviation industry. Research had found that the primary cause of the majority of aviation accidents was human error, and that the main problems were failures of interpersonal communication, leadership, and decision making in the cockpit.  CRM is a mandatory training program that addresses exactly these issues of interpersonal communication, leadership and decision making. CRM encourages a culture of open communication, where it is OK to question authority in the interests of flight safety. It is aimed to increase the ability of the crew to effectively manage flight within the context of wider aviation system through better situational awareness. Even if you are a single pilot aircraft you have to deal with the wider system of Air Traffic Control or other ground services, other aircraft, terrain, weather etc…

As a project or program manager, what aspects of Crew Resource Management might help you avoid crashing your project in bad weather?

An article on the BBC News website gave me an insight in how CRM applied to a specific kind of project environment (surgical operating theatres) could reduce patient deaths by 40% and post-operative complications by more than 30%. All they did was introduce a single A4 page checklist that needs only a few minutes to complete. It focuses on basic good practice before anesthesia is administered, before a patient is cut open, and before a patient is removed from the operating theatre. So simple but so effective in improving outcomes for the primary stakeholders (the patient).

http://news.bbc.co.uk/1/hi/health/7829910.stm

So what kinds of simple changes could we make in Project Management adopt and adapt?

In another vein I thought I would create a small movie on the subject. Interesting what 90 minutes spent with MS Powerpoint, CoolIris (they have a nifty ppt plugin)  and Picasa build for you.

A different kind of improvised explosive device.