Sweatshops

In tonight's Emerging Markets class we had a lively discussion about sweatshops. Good ? Bad ? There is no Indifferent.

When asked, a few students agreed it is a corporation's role to provide a safe and equitable workplace. Most disagreed.

Questions: Where is the government? Can't the workers organize, or leave?

Most EM nations, and frontier markets, don't care. They are either too corrupt or too eager for the money that sweatshops bring in to really care. Workers often cannot organize, or can be swiftly replaced if they do. The labor market is such that everyone wants to work for the sweatshop. There is a lot of competition for these jobs we Americans show such disdain for.

There was some conflation of issues. Most of us agreed that the low wages are not the issue - the work and pay is not much worse than other options. When it comes to how workers are treated, however - beaten, or crazy hours, or what have you - there was considerable debate.

No one thinks workers should be treated badly, but more than half accepted that as "the way things are".

It was pointed out that fair labor practices might raise the prices of goods. That's one thing if you're discussing, say, a line of premium sneakers. What about low-cost clothes available at Wal-Mart or K-Mart or similar outlets? What happens to a poor American family that suddenly has to feed and clothe three or four children, and the costs for food and clothing have gone up 25 - 50 percent?

Moreover, our professor claims that in his undergraduate class, students from Asia tend to see sweatshops as a good thing. They are progress. It's apparently only us Westerners, first-worlders, who have a problem with sweatshops.

Casing

Normally I try to keep this blog very high-level and professional. I'm relaxing that aspiration for this post. I have to write about casing.

Casing, as any business student knows, is the art of pretending to consult on a business problem presented by a moderator. The moderator has one or more pages of case details, the bare threads of detail that define the problem: profitability, market entry, o what have you. The moderator then presents information, and through a loosely defined protocol, the person being cased sets up a framework, puts information into buckets, and then dives deep to try and solve the problem.

It's a bit like playing Dungeons and Dragons:

Dungeon Master: You are standing in the entry hall of a giant abandoned castle. On the far end of a hall is a might chest spilling over with treasure. However, there is also a giant dragon, guarding the treasure. The dragon wants to know if he should expand his internal medical billing practice into an external business offering.

Player: I'd like to take a few moments to structure my thoughts.

And so it goes. The moderator parcels out information, and the player - that is, the person being cased - takes that information and tries to find a solution to the problem. Sometimes, identifying the problem is part of the problem itself.

Thing is, this is usually just two girls (or guys, or one of each) in a room. Often as not, the moderator is trying to make sense of the case. There are cases where information is mislabeled ("reveal this for part II" that is clearly required for part I). There are cases where the arithmetic literally does not add up. There are cases with fully 1.5 pages of background information that are absolutely irrelevant to the case at hand.

The result, very often, is the blind leading the blind.

That said, I think that's actually apt training. Business school, like professional postgraduate schools (JD, MD) trains you to work through a problem; there is always a solution, even if it is a solution you do not like. However, real life is messy. Clients don't always have their information together, or even know what they're looking for. Consultants may start of with one framework only to realize it is really, completely and truly, irrelevant, and further clouds their ability to see what they actually need to see.

So, as frustrating as it is, casing is valuable. It is real life. It's uncertainty, debate, communication. As frustrating as it is (and hey, we MBAs like to always be right), it's valuable to see where we can go wrong.

Correction: Martin J. Siegel

I inadvertently referred to my Emerging Markets professor by the wrong name in an earlier post, since corrected. The course is taught by Martin J. Siegel, not the more notorious Martin A. Siegel, both formerly of Long Term Capital Management.

Project Management 101

Today I sat in on a meeting where, from what I could tell, eighteen months of effort was being devalued because of a badly managed project.

Basically, there was never any proper intake of requirements.

This is a project I've seen in my peripheral vision; it doesn't really impact me directly, though it takes inputs from some of the processes I manage.

What happened was basically this: a manager wanted a uniform interface between two computer systems that used similar but different technologies. The goal was to provide our customers with a single point of access that they could be trained on, and to provide an access control layer that allowed them to see and modify some information, but not other types of information. This is about as detailed as I can get without getting too technical.

An engineer was hired to build this system. This took about a year. Rumor has it that he built something similar elsewhere, and just had to apply his earlier craftsmanship to the details of our particular environment.

The problem is that the manager simply hired him and said, essentially, "build an interface for these two systems". There was no consultation with the final customers - the people who would use the system. There was no consultation with the people providing inputs into these systems - people such as myself who create objects that are referenced by the system. It would be as if you started selling cars without assessing whether the market preferred right-hand or left-hand steering wheels, automatic or manual transmission, or even the color of the car.

These questions all came after the project was more or less constructed.

The result is that for the past six months, all of the stakeholders have submitted numerous requests for changes, some coasmetic, some minor, a few very major. Because no requirements were even formally defined, there is no way to properly end the project. Stakeholders can keep submitting feature requests, "tweaks" until the engineer finally leaves or stops responding.

It's not a bad system, and it does fulfill a need. However, this project is a clear example of what happens all to often in the business world: resources are dumped into a "great idea" with no assessment of the value of the idea or how it will be implemented.