Author: rembrandte599

DePaul KSBG Charity Project Summer 2012 – Risk Management

Posted on by rembrandte599

– Risk Management –

 

One of DePaul KSBG Weekend Program’s project management class’ major requirements is the management of a charity project. Boiled down, it is the creation and successful implementation of a project in which all proceeds go to a specific charity of a groups choice. In talking about Risk Management, many faced their wall early-on, when their project was considered unacceptable by our school board. Whatever planning took place in the first week was simply washed away, and the teams facing such catastrophic risks had to revise their plans from the ground-up to make the best of it.

Our team has officially labeled our project “Grace St. Tap going to the Dogs”, in which we hold a social-networking event at Grace St. Tap on July 28, from 3:00PM to 7:00PM- fun and sociable dogs welcome. Despite the initial set-back of our project possibly being cut due to not falling in line with our school’s guidelines, we were able to recieve approval and continue to work forward.

During the course of our project, we were asked to create a risk-management matrix. This is possibly one of the most difficult things aside from the actual implementation, as risks seem to spring up fromeverything. That’s right, that glass of juice you’re drinking? Melts enamel. You think that’s air you’re breathing? … probably is.

The point of this rant is that as any good risk management teacher or text will reiterate, time and again, risks must be identified, assessed, and continually evaluated. We identified several risks and evaluated them as a group- rowdy patrons, rowdy dogs, lack of donations, lack of attendance, etc. We created preventative measures as well as contingency plans for each. All members reviewed and felt the plan had responses to internal and external disturbances.

With another team-member, we went to visit our venue this past Saturday. The website says the venue is open from 11AM to 3AM on Saturdays. However, we met at 3:00PM at the venue… and the place was closed. Not closed for business, just still closed until 4PM.  Definitely NOT expected.

And for those of you who want to get technical, this spawns a whole load of questions- Is this expected to continue? If so, do we need to change our flyer information? If we expect ‘X’ amount of donations per hour that day, how much will that affect our bottom-line(or segment-leading-to-bottom-line), losing that hour?

While in the case presented, the bottom line for us happens to be a grade, such “wrenches in the gears” can be applied to any business out there- and can cost a company much more than a simple letter-grade and a 3-4 figure max monetary amount.

So I ask the other groups in our 2012 cohort and any other readers- what soft of risks have you identified for your project/for your company and what contingencies have you come up with? And if we have any career risk-analyst readers, any horror stories like ours to share? To be honest, we should have seen this coming- it is an obvious sort of risk… but we are just-now learning to think that way, and we’ll have to let you know if it does affect our bottom-line despite our current revisions to our action plan.

 

Lost In Translation

Posted on by rembrandte599

 

Language happens to be one of the most difficult obstacles we face as a Japanese company working with an American company for a technology project. To begin, I’d like you readers to watch a short clip from the movie, “Lost in Translation”.

Suntory Whiskey Commercial

Notice how the director is going on and on about something, and their hired interpreter has basically chopped it down to being “Look into the camera”? That’s a bit like the problems we’re currently facing.

For their latest automation, the customer has a list of requests for the interface. To address any ongoing programming issues, our customer sets weekly conference calls between US and Japan. Our customer does not speak Japanese, and only a select few of us speak both Japanese and English. None of the interpreters are engineers of software or machinery. Long story short-

REQUEST FROM CUSTOMER: Return back to Format “A” for a portion of interface data (Prescription Number + Store Number = XXXXXXXX-XXXXX) as originally used during prototype testing. Current format “B” is  only Prescription Number ( = XXXXXXXX)

OUR UNDERSTANDING/COMMENTS: We never, EVER had the store number displayed before. When was this request made?? We will adjust the software to reflect this change.

THE RESULT: The store number is now visible on the main Stand-by screen, and NOT on the requested areas by our customer. Fix is on the way, 24+ hours lost on unnecessary work and revisions. Again.

How did this happen? Like the Suntory Commerical, weak translation/language barriers can cause various setbacks to the nature of the project and its organization. Adding to this a massive workteam and timezome difference, the delays have a profound effect- loss of one day can equal the compound loss of a week’s worth of other groups’ working time.

The first problem is that our translators, including myself, vary in terms of in experience. Experience, in this case, can mean background, or project understanding, as well as fluency and the interpreter’s available vocabulary.

Now, add to this the problem of the translator’s “style”. Most companies who rely on internal translation/interpretation, they trade the strength of project/product knowledge for wildly variant translations. From our weekly conversations, I’ve heard translations that are “approximate” to “gisting”. And because none of us are career-interpreters who happen to work for the corporation, I’ve never heard a “Perfect”, 100% translation. An example of the types based on the above story-

Customer says: “We’d like the revert the Rx number format on the interface in the fill drug process to the way it was before, with store number after the prescription number.”

Perfect Translation: – (Exactly as above.)

Approximate Translation: “They’d like to revert the Rx number format back to the way it was before with store number.”

Gisted Translation: “They want to add the store number to the interface.”

How have we addressed this problem? The obvious solution would be to hire professional translators- possible experience problem, but nigh-perfect transmission. But seeing as how funding and manpower are limited, our solution has been to have additional written e-mails for more difficult issues that are not being resolved or being “lost in translation”. In addition, the interpreters roles have expanded to include “policing” the conversations. Recently implemented, we’ve not had enough time to assess the effectiveness of our new system, but our “initial” exchanges have proved to be insightful and much more accurate.

So, have any of you had any experience with major translation mistakes during projects? If so, how did your company deal with it? If you had to compromise (as we did), what did it “cost” your company, if anything?