I reflected on my post of a few months ago – on building load bearing teams

I have just updated the post with a couple of additional links to very relevant articles from two other interesting bloggers on this topic. Go have a look.

Conventional wisdom on how a team should operate. Click the picture to take you to the source article in John Foster’s blog.

Over the summer I finished reading Douglas Hubbard’s new book “The Failure of Risk Management: Why It’s Broken and How to Fisk It”.

I did also contribute a review  on the Amazon site (I sure you will be able to find it).

Needless to say I think he does a good job of arguing that many aspects of modern risk management are poor…The lessons for us in the world of Project Management are clear…

It also led me to discover how good our Oracle Crystal Ball product is for data analysis and performing Monte Carlo simulations.

Am now busy trying to apply this tool to our estimating models….more on this later.

My biggest surprise, having corresponded with the Douglas on a couple of his examples in this book, was to receive a call from him! 

I also completed reading Nassim Nicholas Taleb’s The Black Swan: The Impact of the Highly Improbable while we were on summer vacation in Brittany France. In combination with Hubbard’s book this was nothing short of a revolution in my thinking about risk and dealing with what we do not know.

Brand New Role

A further development I should comment on (which partially explains my lack of updates over the summer months…)

As part of a wide ranging reorganization of our Oracle Consulting business in Europe I decided to fold my International Projects team back into the new Western Europe Applications Consulting organization.

WE Apps has been created by amalgamating the Oracle Consulting organizations in UK, Western Continental Europe and EMEA Divisional Consulting (my team was part of EMEA Div). 

This left me without a role.

Happily I was offered a role managing the delivery teams within the new WE Apps Managed Services line. I am very excited about the role as it is (again) an international role managing teams in the UK Netherlands extended with near- and off-shore folks in Malaga, Spain and Bangalore, India. It also gives me the opportunity to implement a number of the things I have been studying during the Spring and Summer months in the areas of (internal) program management and risk management.

In the meantime I will continue to comment on the Project Lifestyle….

I took Bas De Baar up on his kind offer to do a guest post over at his Project Shrink blog. It took a couple of weeks longer than planned due to some other things going on in my day-job and a spell of fantastic summer weather (one has to prioritize!).

Bas kindly published it today. The post deals with the concept of project rhythm. Follow the link to read it.

In Part 1 I opened the discussion by looking at why issues are such slippery things to manage. I then got perspectives on managing issues from various colleagues who know a thing or two about them.

In Part 2 I applied the Getting Things Done productivity process to derive a workflow for handling issues in a project setting. The key idea here is to introduce a robust, repeatable process to capture and work through project issues. I make the point that

• Issues running around in the wild are the dangerous ones.
• Once you capture them, you can tame and manage them.
• So doing, you exercise a lot more control over the unknowns in your project.

In this post I want to look how some concepts from the social sciences seem to offer proof that a robust issue management process will contribute to improved project outcomes overall, and that this is the secret life of issue lists.

Perhaps I could start by repeating my assertion that projects typically fail due to a build-up of unaddressed issues in one or more areas.

Whether the issues have been recognized, or not, is not relevant at this point. Nor is the failure mode (common mode failure or cascade failure or otherwise: although project failure modes is well worth a look in a separate post).

The key thing is that issues can tip projects into failure.

So where do the social sciences fit into this discussion about issues and project failure?

Some of the theory mentioned by Malcolm Gladwell in his book The Tipping Point caught my attention.

He suggests that one aspect of rapidly induced change is context. Environment shapes behavior.

Specifically the Broken Windows theory is advanced to show how small issues left unaddressed (broken windows left unrepaired, litter left on the streets) can create an environmental context that accelerates the growth of urban crime.

“A successful strategy for preventing vandalism… is to fix the problems when they are small [my emphasis, AS]. Repair the broken windows within a short time, say, a day or a week, and the tendency is that vandals are much less likely to break more windows or do further damage. Clean up the sidewalk every day, and the tendency is for litter not to accumulate (or for the rate of littering to be much less). Problems do not escalate and thus respectable residents do not flee a neighborhood.

The theory thus makes two major claims: that further petty crime and low-level anti-social behavior will be deterred, and that major crime will, as a result, be prevented…”

The theory is not without it’s critics and supporters. Empirical evidence does seem to show that there is a measureable, beneficial effect.

So if we create a project environment we have strong processes to manage the knowns (our methods tasks/deliverables) and strong processes to manage the unknowns (our issues handling process), what effect will that have on the project participants?

I suggest two effects:

• Improved ability to surface and capture issues (because your team and stakeholders know you have a robust, formalized, transparent process to address their concerns)
• Improved ability to manage and resolve issues (because it is simpler – though not always easier – to manage and resolve issues that you know about

This then is the secret life of issue lists.

So how does this blog project look 7 months in?

Great! If I may say so myself.

However based on some feedback and encouragement from an old teammate of mine (thanks Nilo!) I want to refine and clarify the scope of the Project Lifestyle blog a bit.

In my initial post Scope, Objectives, Approach I stated my focus would be on:

discussing subjects in the field of Project Management, with a particular focus on implementing packaged software: Oracle Applications, in the broadest sense

In practice I have found myself frequently exploring two themes

• The human factors element of project management. To borrow from Bas over at Project Shrink: projects are about people: deal with it!
• Oracle Applications themes with a special focus on ERP, and Oracle E-Business Suite in particular. Global single instances and multinational implementations themes make a regular appearance as this is where I have spent a large amount of my professional life

The Software Industry resembles the Fashion Industry in some ways: it’s all about This Years Model.

So while most Oracle-facing pundits (internal and external) continue to focus on features & functions of the Next Release I will continue to report and comment on the hard and tricky work of getting it all up and running and delivering business value.

The project work style has moved from being infrequent or incidental to a continuous stream of parallel and overlapping projects for our customers, many of whom are poorly prepared and equipped for this reality. This led me to look at the phenomenon of projects as a lifestyle choice. Hence the name of the blog.

Maintaining a Global Single Instance presents a number of unique challenges to the IT organization, all of which can be overcome with some common sense, discipline and by taking advantage of all of the relevant features that the software and hardware infrastructure offer you.

Where for art thou Downtime?
The most obvious challenge for GSI maintenance is finding downtime to execute the maintenance. What influences the (potentially) available downtime? Key influences on downtime are listed below in no particular order.
Instance Status
Typically it costs more to have a production instance offline than a project instance.
However, one usually has more project instances to maintain as there is usually a many-to-one relation of project to production instances. Furthermore, project instances often need to be maintained more frequently to support project progress or to promote patches through the test instance set to production.
In some cases project instance downtime can be very costly. The cost of project team delays (including expensive consultant time) can add up quickly and is frequently overlooked.
Equal care can be required in planning project and production instance downtime depending on the project phase.
Instance Functional Footprint
The downtime cost for an instance depends to a degree on the business processes supported by the instance.
Revenue side or customer-critical operations (e.g. billing, manufacturing, shipping or some CRM functions) carry a higher downtime cost to the company.
These business processes can frequently have a 2- or 3-shift or 24x7 character.
Timezones
The more "global" an instance is (the number of timezones to be supported) the more difficult it can be to find a maintenance window that does not impact production (or project) operations somewhere. This can be made even more difficult when you add a new region to the program (e.g. adding project operations in Asia-Pacific to instance with Americas & EMEA) or dealing with regions with a shifted workweek (e.g. Sunday - Thursday)
System Overheads
Some system aspects do not impact the available downtime as such, they impact the scope of what has to be executed in each maintenance window. Examples of this are multiple languages installed (linear impact on number of patches to be installed) and synchronization feeds to reporting instances/DWH (requiring stop/start/resynchronize time in the window).

GSI Maintenance Management
Each of the influences on downtime can be be mitigated.
Communication First
First and foremost all maintenance schedules need to be clearly communicated, highly visible to all relevant parties and frequently updated with the planned activities to be executed in each window. Communication needs to be a combination of static information on the project/IT website on the standard maintenance windows and similar relevant information and dynamic updates via email blasts, news/rss updates on the planned activities for each window and maintenance start/stop notifications. All of this builds an operational environment where maintenance is an expected element of the landscape and there are no surprises when an instance goes offline for patching or other maintenance.
Planning
Allied with communication, plan the instance maintenance windows 6 - 12 months in advance (for *all* instances) and publish the plan. This becomes a framework for negotiation (particularly with the project instances) but at least everyone is starting with the same baseline of information.
Slots and Kaizen
Use a kaizen process of refinement to keep maintenance under control and drive performance.
Plan 2x - 3x per week windows for 4 - 6 hours (say) for project environments. Publish as SLA. Then drive to improve to get to 1x or 2x per week.
Plan 1x per week 4 - 8 hours window for production environment(s).  Publish as SLA.
Then keep driving process improvements to get to 2x per month, then 1x per month then 2x per quarter...

Remember it is not about the starting point, it is about the journey of continuously reducing the frequency of planned downtimes and improving reliability and predictability of the process.

Which Slot? Timezones
As stated in the section on influences - timezone coverage can squeeze your maintenance window slots badly. But you can also take advantage of this. Maintenance windows from 0200 - 0600 CET can also be expensive in terms of overtime if your data center staff are also in the CET timezone.
Using (for example) staff based in  IST (India) combined with PST (California) or EST (East Coast US) can mitigate this very well and give 24x7 coverage. Make the timezones work for you.
Use Available Technology
Invest time in understanding how to get the best out of the technology you have and what additional technology you may need to acquire to meet your downtime requirements. I will always recommend colleague  Steven Chan’s excellent blog for more detail on this subject – but here is a grab bag of suggestions to follow…

• Invest in the hardware infrastructure (e.g. disk technology) to speed backup and recovery operations
• Hot backups must be routine
• Use the well documented features of Oracle E-Business Suite to minimize patching time. Some examples:
• Minimize the number of individual patches and human interference in patching by merging patches
• Minimize the software distributions to be patched by consolidating to a single shared software directory
• Run the patches faster by spreading multiple parallel patch utility worker processes over multiple servers
• Install patches in offline staging area (staged APPL_TOP technique)
• Analyze which patch (components) can be installed hot according to Oracle Development guidelines

This is the second part of a discussion on the secret life of issue lists in our project lifestyles.

In Part 1 I opened the discussion by looking at why issues are such slippery things to manage. I then got perspectives on managing issues from various colleagues who know a thing or two about them.

In this post I’ll see how some of the latest thinking in personal productivity intersects with issue management in projects.

Issue Management and GTD

I compared my colleagues’ perspectives on issue lists and issue management to some of the concepts outlined in the action management method "Getting Things Done” (GTD) developed by David Allen.

Basically this method rests on the principle that a person needs to move tasks out of their mind by recording them somewhere.

That way, the mind is freed from the job of remembering everything that needs to be done, and can concentrate on actually performing those tasks.  Hmmm…sounds like the projects lifestyle to me…

Two things distinguish GTD from other time- or action-management systems.

GTD is not about prioritizing up front.  It is about dealing with things as the come using a standard workflow.

Secondly GTD the idea of grouping tasks by the context (defined as a place or set of available resources) in which they are to be performed.

Really I wanted to see what would happen by applying GTD workflow to the project context and the issue process in particular. 

Here is a MindMap I built to document the steps in the workflow. You can grab this file directly from the link and view using the free MindManager Viewer.

You will need to view this in IE or install the excellent IE Tab plugin for Firefox to view this embedded MindMap Viewer.

For the truly afflicted you can grab the mind map as a pdf file.

Built by Mindjet LLC

The biggest thing really is the concept of collecting issues out of the minds of project team members and users and getting them recorded.

Issues running around in the wild are the dangerous ones.

Once you capture them, you can tame and manage them.

So doing, you exercise a lot more control over the unknowns in your project.

In the next and final post I will examine how better management of issues may have an overall impact on project outcomes by referring to Tipping Point theory.

Take project issue lists for example

As a key project document I first started getting interested in them about 10 years go when I was doing a lot of Critical Accounts & remediation work. It was impossible to go into a project and have an agreed issue list waiting there, ready for you to work on.

Nothing has changed. Getting agreement on what the key issues are and their status still feels like getting blood out of a stone.

Recently I decided to have another look at issue lists in projects in the light of some of the latest thinking in the fields of personal productivity and sociology. I wanted to see if that led to any new insights on how those concepts could be applied in the context of project teams.

Obviously the underlying question is "If we manage issues better, will that improve our project outcomes?”

I was pleasantly surprised with the results. 

Slippery Issues

I wanted to better understand why issues were such slippery things to manage.

I had the feeling that issue lists tended to generate a feeling of antipathy or resistance on the part of the PM or the team, especially on the part of the customer. There seems to be a fundamental disconnect in expectations.

The common expectation seems to be that projects should be like a straight race.

The reality is that they more often resemble a cross country or steeplechase event.

Issues are like a bunch of inconvenient truths standing between you and your project goals.

“Ugh! I'll do "something" with them "sometime" because the methodology says so." is often the unspoken thought of many PMs.

I decided to discuss this phenomenon with some colleagues to get other perspectives.

Perspectives – Critical Accounts

I talked to Sharon Smith, a Director in Critical Accounts. Critical Accounts is all about issue management - so they might know a thing or two on the subject

Her key points were about discipline, capture, technology and ownership

Not everyone understands that you need to be a bit disciplined about issue management in projects. Issue management needs to be a formal process in projects. Unfortunately it is an informal one just about everywhere else.

The customer may feel that it is OK to mention something vague about a problem when they meet an Oracle employee at the coffee machine. That does not mean that Oracle, or the project team, has formally registered that issue.

Another example is where the customer has logged a software issue in their internal IT system, but it’s not logged as a project issue (or vice versa) and not logged with Oracle Support (or Development if it is a bug or an enhancement request).

To manage issues you need to capture them. Issues “in the wild” just tend to get bigger.

Technology does not always help you get to grips with capturing and managing issues. Sometimes it can make it worse. Any system for collecting issues needs to be simple and accessible if people (project team members and users) are going to actually use it.

Ownership. Not just each issue, but also the issue process as a whole needs an owner. Hint: the customer needs to at least be part owner so the process can continue when the consultants have left the site. No owner(ship) equals no progress.

Perspectives – Risk Management

A conversation with Risk Management (Suzi Weinmann-Jaffe and Bernadette Uesbeck) brought other aspects to light particularly in the areas of organizing and review and reporting. 

In complex or escalated projects (where we typically assign more experienced PMs) the issue lists are a key focus area and tend to be well organized, thoroughly maintained and frequently reviewed. In Risk Management’s view there is a clear correlation between PM experience and quality of issue management.

In organizing the issues we looked at the idea of supersetting & subsetting.

Mature PMs (either on the customer side or on the consulting supplier side) realize that both parties will have issues related to the project that are not necessarily for public consumption. Oracle (for example) may have resourcing or other internal issues to deal with in the same way the customer PM has.  A project issue list may just a part of a superset of issues that add Oracle and Customer-specific issues that may need to be kept separate from the public issue list. The key here is to accept this and to manage them appropriately in both parties best interests.

Conversely you need to recognize subsets.

The project issue list needs to be a snapshot of all of issues that have a substantive effect on project scope or effort. This is not to say that this is the only detailed list that everyone works to. We need to recognize that the list itself is not the only place where the issues are worked (and we should not try to make it so). It does have to have placeholders to track progress on key issues that are being worked on elsewhere (e.g. SR/TAR's Bugs CEMLIs). The trick is

Reporting Is Not Equal To Managing/Reviewing

Suzi made the point that reporting on issues in the project progress reporting often seems to suffer the same resistance problems as actually capturing and managing issues in the project. People often just go through the motions of issue reporting to satisfy “external” processes.

Risk management or IT Audit or other departments are not the true customer for the issues reporting in projects. You and your project’s stakeholders are. It's all about stakeholder management and consistent reporting of the issues - even the difficult ones so you can change gear and escalate when needed and it is no surprise to anyone.

A common theme in less well-managed projects or customers is a pattern of no No News, No News, Panic!!

Certainly it is the consistent reporting of issues from early in the project that is a hallmark of experienced PMs and in-control projects. So the pattern there looks more like

News, News, Escalate, News

Perspectives – Program Manager

I continued the discussion with one of the PM's in my team - Thomas Elwers.

We followed on from the Supersetting/Subsetting discussion. Can we unify issue lists?

We talked about the wide variety of issue lists (logs) in Oracle’s Methodology OUM (I counted 6!) and whether that helps or hinders good issue management.

It’s difficult. The main thing is that you get a complete overview. Use as many different lists as you need – but no more than that.

All of the "stuff" that emerges in a project can be reduced an issue. An open loop - something is not where it is supposed to be, but can have a substantive impact on scope or effort.

What is substantive? Depends on the size of the project and the phase.

There are different flavors of "issue" - like (software) problems or risks (risks = issues that have not happened yet) Some things we track are not issues - but resolutions to issues. For example:

• Scope change
• Resource load change
• Business process change
• TARs/SR//Bugs/Enhancement Request/Patch
• CEMLI

It is also interesting to note that the concept of issue lists does not appear in the PMBOK. PMI prefer to stick to management "risks". OK by me – though I tend to think of risks as issues that have not yet happened.

Thomas confirmed that he really uses the issue list as a core element in managing project execution. It echoes the point made by Risk Management.

Everything that emerges – “stuff” that is not on the scope document, the original plan of tasks and deliverables, milestones and resources – gets managed via his issue list.

Managing the scope deliverables& tasks per the contract is about managing the known’s.

So here we could say that issue management is about managing the unknowns of a project as they emerge.

For me this was a key insight into the secret life of issues lists. They are central to the good running of a your project, not just a list in inconvenient things standing between you and your project goals.

In part two of this post I will look at issue lists using some of the latest thinking from the fields of personal productivity and sociology.

Behavioral economist Dan Ariely's talk from the TED conference last month was recently posted online. In his talk, Ariely (who wrote the best-selling Predictably Irrational) addresses, through his own experience, a topic that is also quite relevant for innovators in an uncertain environment: the importance of testing assumptions through experiments.

He also makes some great comments on cheating (of all things).

• Everyone cheats, a little. But only to a point where it does not challenge their self image of being a “good” person
• People start cheating (more) when a member of their in-group blatantly cheats
• People stop cheating when a member of an out-group blatantly cheats 
• People cheat less when confronted with moral standards (people lie less about remembering the 10 commandments, for example)

In our project lifestyles we come across this phenomenon all the time. No so much cheating as social behaviors like groupthink that we as project managers need to find ways of combating.

A good start is to be aware from the outset that people are sometimes “predictably irrational” and may not be sensitive to your rational, evidence-based arguments…

Many project or program managers have no firm idea on this subject and delegate the decision making to the technical lead/solution architect/chief propeller head.

This is OK if you accept that having no firm idea = having no clue. Alternatively (waxing lyrical here):

If you don’t stand for something you’ll fall for anything.

So what do I recommend PM’s need to know? It depends on the size of the rollout and the solution footprint.

My thoughts on program (test) instance requirements follow two main scenarios.

First case is medium – large rollouts with a high degree of solution commonality. An example would be Financials and/or Procurement implementations where common business processes are externally prescribed to an extent (e.g. fiscal reports) or gives business advantage (e.g. aggregated procurement to generate vendor leverage).

In this case the answer is a six-pack (instances that is, not beer). 1 Production and a constellation of 5 test environments should be enough to get you through quite a number of locations. In one regional instance project we got through 95 locations in 15 countries on a six-pack of instances. Typically the instances might look like this:

Second case is where you have rollouts with any degree of parallelism over multiple sites with a heavy revenue-side footprint. By this I mean supply-chain, planning, manufacturing, CRM or other revenue/customer critical processes. In these cases there may be a very low level of business process commonality of the different locations. Furthermore, attempts to make the processes common may be inappropriate as they are key to competitive advantage. So what do you do in this case? A dozen usually works well enough.

So what are the alternative models?

If, as PM, you take a laissez-faire attitude (or using corpspeak: use an emergent strategy for instance requirements) you will get instance proliferation. Simply stated you will get more instances than is good for you.

Take my work for it; once you get above 20 project instances you will have no clue what you have or where it is. Configuration management and validation of the holy trinity of setups, patches and customizations across the instances will become a nightmare.

Proliferation of test environments also costs a lot of money. Work out what each test instance costs you (or your customer) to provision and do the math. One estimate I made with a customer came out at US$150,000.00 per test environment. This number included server/disk infrastructure plus support costs on very cheap, high-performance gear. It all adds up.

So it is easier to keep it tight and provision new instances grudgingly – and charge for them!

The six-pack/dozen model is a good starting point if only because it is easy to remember.

Make instance planning a regular element of your weekly program/project review meeting. Inevitably there will be a lot of negotiation and horse trading around clone schedules with project teams needing refresh dates that conflict with other teams using the same instance. All part of the fun. The key element is that the negotiation becomes part of a generally accepted process that all of the teams buy into. Sometimes they will get their way, sometimes they will have to compromise. I see the PM’s job as helping all of the project teams feel that, in general, their needs are being met and that they can roll the program out without (too much)  undue delay waiting for other teams who are playing in the same instance.

This post concludes the initial series of Global Single Instance architecture strategy posts. Further material on this subject will appear on an occasional basis going forward.

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.

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

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

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…

In many conversations with many customers over the years it is amazing what criteria are perceived as valid for deciding how many instances of their business system they’ll deploy. 

So, to help frame the discussion let’s assume we’re starting with a multinational company.

For me there is only one main consideration in figuring out how many SI’s (lets leave the “Global” off for the time being) you need and where they should be hosted.

Choose number of (single) instances and their hosting location based on your ability to ramp up your (intercontinental) WAN capacity – including redundancy - to meet the requirements.

You (and your network provider) need to be able to (afford to) do this in a timeframe that matches the project timeframes otherwise you’re sunk.

This can get interesting when;

• You plan to implement the system for multiple global geographies (APAC, EMEA, Americas)
• Rollout is planned to “exotic” locations (read “poorly served by networks”) 
• Shop floor and shipping (or other revenue-side or customer critical elements) are in-scope

So what are flavours that other folks have chosen?

As a rule of thumb – more than 4 and for me it doubtful that you are really looking at Single Instances…

Also as a hint. Considering splitting GSIs by business process (e.g. Global Financials, regional Manufacturing). Don’t bother – that concept is just not worth the integration and data integrity hassle.

Feedback, questions and in particular criticism is more than welcome.

Andrew