One of my favorite projects – 3

Continuing the series, as part of a large IT transformation that I helped drive, it was necessary for us to hire 20+ talented IT professionals. And add to that around 30 mostly Indian colleagues that were to join us to run the Transition and Transformation (T&T) program. And add to that at least two other large IT teams we wanAnd because we had so many people, it was necessary for us to locate and rent a building dedicated to IT. So I had a once-in-a-lifetime opportunity to take off my IT transformation hat and put on my facilities management hat.

This blog series recollects a bit of the journey before too much time passes and I forget some of the more interesting details.

Ongoing third parties

I’ve worn a few different hats in my life: cook in a restaurant, forklift truck driver, landscape gardener, and professional housepainter to name just a few of the most important ones. So it is not only fun but a privilege when life gives me the chance to establish working relationships with people in varied trades.

One of the most fun people I dealt with was the head of the cleaning service company we contracted. I won’t mention her name here, but anyway she is retired. She was around six-foot five feet tall, and when she first shook my hand she literally crushed it (no kidding, I could not play the banjo that day!). She was from Stuttgart – and I lived many years in Stuttgart – and if you know anything about the passions of the people Schwabia  – and I am saying this because they are great people – then you know that quite probably cleaning is the only topic more important on their scale of life than finance or even religion!

I learned a few things about cleaning.

One thing I learned, the cleaning contract is built around a very specific checklist or work to be done (wipe desk tops with damp cloth, clean outside of refrigerator, complete vacuum of carpet, spot vacuum of carpet for visible dirt, etc.) and how often each step is to be done (daily, weekly, monthly, on demand) and when (e.g. after working hours).

I also learned that after the contract was signed, at least in my case, the cleaning company assigned a dedicated resource to handle our cleaning needs. I hardly ever saw her, because she I don’t think she came to building until around midnight. And I also learned that she took a lot of pride in her work and very often cleaned up even when it was not clearly written in the contract.

I also learned that we had an obligation to provide a rather large room to store the cleaning materials (I never consider this when I did my original planning!). Think about it: vacuum and mop. But you’ll need a huge shelf space for the cleaning products and chemicals, as well as the consumables. Believe me, there are many, many more consumables than you might first think about!

And finally, the little stuff. Like most people, I’ve used toilets all my life, maybe not always exclusively, but usually when I had the chance and the need!  Also living in Asia I became rather proficient at Asian style squat toilets.

But in addition to my role to help drive the IT Transformation, I was as a facilities manager now, the and toilets were my responsibility, and this means all of them, both men’s and women’s (and the shower).

Now here are a few things you might not think about in this snap:

Think a little bit about the consumables. The little white dispenser is for alcohol – this needs to be discussed with the cleaning company, and you’ll need a part in your contract about how often its checked. And the other consumables – and there are more of them than you think: sanitary products, bags, toilet paper, soap, paper for drying your hands, bags to line the towel basket, bags to line the waste basket – and a few more I’ll let you figure out yourself!

And although it’s not shown here, the restrooms contained a spray bottle of a scented fragrance that periodically (few times a day) shot a burst of fresh scent into the room: which scent would you like? How often should it be checked? How often should it spray? Who checks that it sprays and who replaces the little battery when it‘s needed?

These were just a few of the challenges you face when you are a facilities manager!  It’s a bit overwhelming at first, but as time goes on you start to take these things in your stride!

 

One of my favorite projects – 2

Continuing the series, as part of a large IT transformation that I helped drive, it was necessary for us to hire 20+ talented IT professionals. And add to that around 30 mostly Indian colleagues that were to join us to run the Transition and Transformation (T&T) program. And add to that at least two other large IT teams we wanted to co-locate. And because we had so many people, it was necessary for us to locate and rent a building dedicated to IT. So I had a once-in-a-lifetime opportunity to take off my IT transformation hat and put on my facilities management hat.

This blog series recollects a bit of the journey before too much time passes and I forget some of the more interesting details.

Negotiating the lease agreement

No photos here. The negotiations about rent were a nice learning experience for me. At least in this area of Switzerland the value of the building is tied to the rental price, so the owner was absolutely unwilling to lower the rent. However, that does not mean we could not negotiate: we discussed how many months “rent free” we would get. This included not only the building itself, but the parking spaces adjacent to the building. As well as other topics, such as the needed paint, carpets, small cosmetic repairs, upgrades to the kitchen, and the like.

I also thought the negotiations had a somewhat detached and less emotional character than I had expected. The building was in fact owned by a large company that owns buildings, so the passions that I somehow expected after dealing with normal landlords and rental agencies in Europe were not there. As Michael Corleone said, “Nothing personal, it’s strictly business.”

Finally, the terms and conditions (in German: Allgemeine Geschäftsbedingungen): they were straightforward, and the procurement specialists of my company did not insist upon any changes. Probably the whole contract was no more than 15 or 20 pages, tops. What we key for us, however, were the termination clauses and exit conditions, since my company was considering a general consolidation of all offices in Switzerland into a central location.

What was also part of the contract is how and how often the exterior of the building would be cleaned. Most buildings in Switzerland have windows that are covered with louvers, and these get dirty and need to be periodically cleaned.

One-Time Third Parties

There were two categories of third party providers I was involved with: one-time, and ongoing.

The most important one-time third party was an electrical company that I contracted to finalize all the needed power and LAN cable hook-ups.  The building floor was elevated, so this meant snaking the cables to holes located under what would be the future desks.

Here’s a nice snap that shows one of the holes:

This was an interesting experience for me. It was a true learning moment – and if you are new to this business, maybe you can learn from it too?

Together with Christian (see my last blog series) we contacted three different electrical companies in order to get competitive offers. Each of them sent an extremely experienced person for discussions with us and to collect our requirements. This gave me – still very naive in these areas – a pretty good feeling of confidence.

But . . . after we made our selection and the installation crew showed up, it was an entirely different situation!  First, we weren’t sure exactly which language the crew spoke, but it was neither German nor Swiss German nor English nor any other languages we knew!  This is not an exaggeration by any means – we were completely unable to communicate with the crew except by using hand signals. Thankfully, our hand signals for “what the f–k are you doing???” and “get the f–k out of our building” are international in nature and gladly, were immediately understood and acted upon.

Second, even after breaking through the communication barrier, we realized we’d get the best results if we managed them quite closely. Much, much more closely than I wanted to do – but I thought back to the inputs that a real building renovation project manager gave me sometime earlier, and this seemed to confirm to me a close approach was the right one!  If my efforts here would have been greater, than I would have escalated back to the company itself – but when the end is in sight sometimes the direct approach is ultimately the easiest.

Finally, the topic that Americans refer to as “sweat equity,” or saving a lot of money by doing some jobs yourself. We determined we could save an enormous amount of costs by doing a significant chunk of the work ourselves. For it was necessary to snake LAN cables to each of the holes under what would be the desks, and this requires an incredible effort to label the cables. It’s not an effort that requires the experience and training of an electrician, so by doing this ourselves we saved four figures of cost!

Paint and carpet

I did not have any big efforts here, as the painting, minor bugfixing, and carpet installation was contracted by the building owners.

Here you can see a snap after the carpet was laid and the walls were painted:

I did have a bad experience, however, and I hope other people can learn from my mistake. It turns out that whatever combination of carpet, carpet glue, and paint were used, it left an intense smell in the building. Fortunately, the planned move in date was nearly six weeks after this work went done, so I simply opened all the windows and vented the building 24×7, which removed the problem nicely. Nevertheless, after opening, there were a few colleagues that suspected we had a case of “sick building syndrome.” Sadly, it was never easy to verify this claim, since the building itself was located just a few dozen meters from a chemical factory.

Pretty tame so far, but just wait for future blog posts when I tell of the amazing adventures that were in store for me!

 

 

One of my favorite projects – 1

As part of a large IT transformation that I helped drive, it was necessary for us to hire 20+ talented IT professionals. And add to that around 30 mostly Indian colleagues that were to join us to run the Transition and Transformation (T&T) program. And add to that at least two other large IT teams we wanted to consolidate. And because we had nearly 150 mostly IT staff, it was necessary for us to locate and rent a building dedicated to IT.

So I had a once-in-a-lifetime opportunity and priviledge to take off my IT transformation hat and put on my facilities management hat.

This blog series recollects a bit of the journey before too much time passes and I forget some of the more interesting details.

What not to do

I’ll begin at the beginning with this message: if you are planning to move your staff to a new business location, there are consulting companies that are specialized in helping you move. Sadly, we had no funds to use such a service. But it is something I highly recommend. During my tenure as facilities manager there were many, many, many instances where – purely because of sheer luck – we somehow avoided pitfalls with enormously high costs. The only way to avoid these costs in a planned, risk-managed fashion is to get professional help.

Picking a building

I looked at a few different properties. They were all empty when I saw them, so you really have to use your imagination about what it would look like if your organization was located there. I also relied on architectural blueprints of the floor layout that we transferred to Microsoft Visio and super-imposed with desks and furniture.

Electricity (enough power in the right locations) and IT (the needed IT infrastructure, such as LAN cables) and telephony are also important considerations. Fortunately, I had my good friend and colleague Christian Neuenschwander involved. He is not just a hobbiest in these areas, but in fact he has a professional-level of experience in these topics, as well as being a certified electrican. Had I not had someone of his caliber involved, I would have insisted on using a professional consultant. Why? In Switzerland there is a law which says you can take over any existing electrical infrastructure, no matter what status it’s in. But . . . if you need to make improvements, then you need to bring the entire area up to the most modern version of the building codes. That is a huge financial risk that could easily by six-digits of cost!

This is the location I finally recommended to the team – but I took great pains to ensure buy-in from everyone. At the end, it absolutely needed to be a  team decision.

The building was very light and airy, there were almost two dozen glass-walled conference rooms, there was a air cooling system, and the whole place was located about 50 m from a convenient stop on a public transportation tram line. We had two-and-a-half cafeterias, plenty of power in the right places, a raised floor in which power and network cables ran below, and two network closets. Four restrooms (2 male, 2 female) and a shower. Ample number of parking spaces. And the building was situated around 50 meters from a tram stop frequented every 5 minutes by trams.

The only thing we were a bit worried about what that a selected area of the building had CAT-3 wiring instead of CAT-6, but we felt it was a risk we could take.

We could not have found a better spot!

For successful systems, debug the people problem

In the field of IT you may think things change fast, but the timeless principles really don‘t change at all.

If you don‘t believe me, just read on and I guarantee I can convince you otherwise!

In September of 1974 my father was editor of the world‘s first magazine dedicated to computers. This was long before the days of personal computers and smart phones and cloud computing. He wrote an article that I used as the title for this blog.

I‘ll reprint a few paragraphs here – and I send out a challenge: this article was written 45 years ago, and you tell me if it doesn‘t still apply – word for word – to the IT industry today!

 


For successful systems, debug the people problem

By Charles N. Ritley, September 1974

As executives are discovering that turnkey computer systems can solve their paper problems, they‘re also finding out that a brand new computer can bring with it a new set of problems – people problems – that could diminish the advantages they paid for. Professional systems analysts are aware of people problems that arise with new systems and plan for them. The executive installing his first system will profit by knowing the potential problems and how to cope with them. His reward will be a smooth running system, and good customer and employee relations. Plus, he‘ll get all the computer power he paid for.

Why people?

A system is simply a means of receiving information from one group of people and preparing it for another group. Now matter how sophisticated the hardware becomes or how many jobs it eliminates, a computer system still requires people to create, process, and use the information. Fear of the unknown is one universal problem that can‘t be solved electronically. Your new computer will change job structures; it will take over routine work now being done by people. Your staff is going to wonder how their jobs will change, and wondering and worrying will make them less efficient.


To read the complete article, please click here.

Pause powers performance

A friend of mine is an IT engineer-turned-HR-consultant, and he summed up leadership in a single word:  SEXY:

  • S = Strategy
  • E = Empathy (for others)
  • X = Execution
  • Y = Yourself (know yourself)

My take on this, not his: S and X are up to you – but E and Y are what‘s in you and probably beyond your ability to significantly influence.

I‘m not a big fan of self-help books about leadership, precisely because E and Y are so out-of-reach, but recently a colleague at work put me on to a book written by a friend of hers. This is Kevin Cashman:

And this is his book, The Pause Principle:

In a nutshell, quoted from the book: The Pause Principle is the conscious, intentional process of stepping back, within ourselves and outside of ourselves, to lead forward with greater authenticity, purpose, and contribution. This book focuses on X (Execution) and not one of the SEXY attributes more difficult or impossible to control. In many ways it reminded me of the survivalist Ray Mears‘ advice if you get lost in the woods: don’t panic or take immediate actions but rather sit down, use your bushcraft knife and firesteel to make a fire and brew up a nice cup of pine needle tee; and only then think about what you‘ll do next.

The landscape of milk

I’m currently in a project where I am designing and documenting various IT architectures and landscapes: organizational, applications, infrastructure.

So while in this very “IT landscape frame of mind” I stumbled across this very interesting diagram on Wikipedia,

I think it’s just brilliant!  I’ve always been interested in the vast number of milk products – even more so after living in Eastern Europe and Western Europe and seeing products (such as quark and saline cheese) that are not available in the U.S.

And it is wonderful that someone could classify all the milk products in this way, to create a very colorful and easy-to-understand visual taxonomy.

Is the slashed zero now dead?

Things change, and in the field of Information Science they change faster than most.  A delightful story of change is provided on the homepage of perhaps the world’s most famous computer scientist, Donald Knuth:

A note on email versus e-mail

Newly coined nonce words of English are often spelled with a hyphen, but the hyphen disappears when the words become widely used. For example, people used to write “non-zero” and “soft-ware” instead of “nonzero” and “software”; the same trend has occurred for hundreds of other words. Thus it’s high time for everybody to stop using the archaic spelling “e-mail”. Think of how many keystrokes you will save in your lifetime if you stop now! The form “email” has been well established in England for several years, so I am amazed to see Americans being overly conservative in this regard. (Of course, “email” has been a familiar word in France, Germany, and the Netherlands much longer than in England — but for an entirely different reason.)

I’d like to single out something similar, probably only known to those of us (like me!) whose history of Information Technology and computers pre-dated with the development of computer monitors: the first application I used was on a teletype machine at a laboratory at U.C. Berkeley.

Slashed O

When programmers started programming in the days even before punched cards, zero’s and one’s were so important  – and in those days, numbers were far more important and frequently used than letters. Therefore, programmers and also typesetters most frequently wrote “slashed o” instead of the letter O, in order to distinguish the uncommonly used letter from the very commonly used number.

If you look on Google you can find many examples of this, usually images of very old computer manuals, like this:

 

Slashed Zero

At some point after the introduction of high level computer languages, the letter O became more important than the number zero, so programmers use “slashed 0” instead of the number zero, in order to distinguish the uncommonly used number from the very commonly used letter.

Here is a good example of what that looks like:

 

0 = O: Leave it to the fonts, high resolution displays, and good eyes

Today, it seems rare to see the slashed zero anymore. The computer fonts used in many editors make it very difficult to distinguish between “oh” and “zero” – usually relying on highlighting the entire word or variable when the programmers application developers get it wrong.

I don’t know when the slashed zero fell out of use, but it would be nice if some language scholars have studied and document this before it disappears from human memory.

FYI, most programmers application developers I know not only do not use this convention, but also have never heard of it – so it goes to show you how quickly things change and the past is forgotten!

 

 

IT – Does anything ever change?

Around 20 years ago, when struggling to decide if I should shift from a career as a research physicist to a career in IT, I was impressed with the idea that IT changed faster than physics – so I expected a more dynamic, exciting field. What little did I know!

In 1973 my father was editor of the world’s first IT magazine, and he wrote an article entitled “To rollout successful systems, first debug the people problem.”  I’m still trying to find a copy to post. It was all about management of change when introducing new IT systems, and the article is 100% valid today.

A few years later in 1975 an IBM engineer, Fred Brooks, wrote a fabulous book entitled “The Mythical Man Month” containing his wisdom and advice for software engineering projects:

After nearly 45 years, hardly any of the most important core principles has changed. The author himself writes in his newest addition:

In preparing my update, I was struck by how few of the propositions have been critiqued, proven, or disproven by ongoing software research and experience.

So I guess IT has the best of both worlds: new technologies are cool (I was impressed how my Apple MacBook actually logged into my FitBit scale – not the other way around!), new methodologies are exciting (even Agile is now ancient!), but just like in physics, the core principles don’t change.

 

The Mythical Man Month

I rarely do book reviews, but in this case I couldn’t help.

Back in 1975 I was 10 years old, and an IBM engineer, Fred Brooks, wrote a fabulous book entitled “The Mythical Man Month” containing his wisdom and advice for software engineering projects:

The title of the book comes from an important observation he made about software engineering: if you add more people to a late software project, you’re like to make it even later!  But in addition there fabulous observations about other topics, like prototyping, the different between software development for projects and software development for products, and the like.

It’s just amazing: after nearly 45 years, hardly any of the most important core principles has changed. The author himself writes in his newest addition:

In preparing my update, I was struck by how few of the propositions have been critiqued, proven, or disproven by ongoing software research and experience.

Augusta Raurica and User Experience (UX)

User Experience – sometimes referred to as UX – is defined as encompassing all aspects of an end-user’s interaction with e.g. an IT system or, for example, a company, its services, and its products.  And although you might not think about it, museums can provide a wonderful insight into the field of UX.

I’ve recently blogged about a wonderful collection of Roman ruins scattered in the Swiss countryside, Augusta Raurica.

What’s really a nice touch is that many of the walking paths have markers that explain about the history of the site:

The displays are a combination of old ones dating back to just after World War II, and relatively new ones.

Now here comes the truly interesting part.  The older displays are written in both German and French, and they contain extremely dry, extremely boring historical facts, as this example shows.

The newer displays are written in German, French, and English – and they use a very simple type of writing, and they contain topics that are interesting to a wide variety of people, especially including younger audiences:

It makes you stop and think about who designed the original displays and why.  Were people many years ago more literate and interested in boring historical facts?  Or is there simply more attention paid today to the user experience?

Thomas Friedman may have missed the point

This is Thomas Friedman:

He’s famous to older people for being the first reporter to cover some atrocities in the Middle East. And his book From Beirut to Jerusalem is in my view required reading before anyone can have a conversation on Middle Eastern topics.

But today he more famous to the younger IT crowd for his book The World is Flat.

 

In that book, he makes the argument that the modern Intranet has flattened the world, permitting the development of truly global supply chains.

Because the subtitle of his book is “A brief history of the 21st century” he is not strictly wrong. But unfortunately, he never points out the far deeper, far older truth that truly global delivery in fact dates back thousands of years!

In their book Global Management in the 21st Century the authors begin by a humbling story that shows, at its core, nothing much has changed in over 5000 years:

“There is evidence of extensive trade between nations as early as 3000 BC.  Some 2000 years ago Herod build the port of Caesarea Maritima. This served as a major east-west trade route with Byzantium and Rome, which were as much as 60 days away by sail. The harbor handled local products like wine, flax, and grain, as well as exotic products like silk and spices, that were brought to the port from Asia by caravan. Imagine the management challenges associated with coordinating shipping schedules with the arrival of products from Asia and the purchase of local products.”

Still more anecdotes explain the challenges of global delivery and multi-cultural teams – efficiently and expertly solved, with a high degree of goal-orientation, but literally thousands of years ago!

So while Thomas made a good observation about the Internet and the flattening of the world, in fact so many of the global delivery challenges the IT community faces today are the same challenges humans faced thousands of years ago.  And the real question is perhaps not what as the Internet enabled, but rather . . . what has the modern nation-state approach led us to forget?

Global Management in the 21st Century

I almost never do book reviews in my blog.

But a business colleague recently asked me for what I thought was the best book on global management and delivery.

The good news: Mendenhall, Punnett and Ricks wrote a 719-page academic tome that is much broader, deeper, and insightful than any other book I’ve seen on the topic.

The bad news: it is out-of-print and almost impossible to obtain – and I will never part with my worn, dog-eared copy!

I do not believe you can ask a question or have an inquiry on any topic that is not addressed to a deep level of detail in this book.  It contains hundreds of references.

I can only whet your appetite with the Table of Contents:

I – Global Picture – Understanding the international management environment

1. Overview

2. Global mgmt in the context of politics

3. The cultural environment

4. International labor relations

5. The global ethical environment

II – International strategic management and operations

6. Global strategy overview

7. Foreign entry decision

8. Implementing foreign entry decisions

9. Adapting management to foreign environments

10. Managing operations globally

11. Organizing and control in global organizations

III – Executing international decisions through staffing and directing

12. Human resource selection

13. Training for international assignments

14. Managing the expatriate manager

15. Special issues for global firms: women and dual-career couples

16. Communication and negotiation in global management

17. Leadership and motivation in global context

Appendix A – Careers in international business

Appendix B – Experiential exercises

Appendix C – Case studies

Valuable resource for IT project managers

I rarely use my blog to give reviews, but in this case I can’t resist. A long time colleague from our HP days and still a very good friend of mine, Mario Neumann, has used his passions for training, leadership, and project management to create some very valuable and very high quality resources: his website, his books, his podcasts, his trainings, and especially, his project management application.

Here’s a screenshot of his application:

And here’s a screenshot of his webpage, http://marioneumann.com/

(Yes, you can easily mistake him for Ray Mears!)

But where Mario really shines is in his trainings, which can integrate wide ranging topics such as psychology and human behavior, to present a truly unique approach to management.

Only bad news: because he focusses on the German market, most of his collaterals are only available in the German language. Hopefully that will one day change!

 

WeChat and the Great IT Divide between East and West

First things first: this is my WeChat QR code:

If you’re like I was until recently, you’ve probably never heard of WeChat. And that is the AMAZING part – that you’ve never heard of it.  Because it is the top social networking service in China, and it is used by around ONE BILLION PEOPLE!

In fact, as I travelled around the southern Chinese island of Hainan, I was impressed that just about every store, and every product in every store, sported a QR code.

This points to the real crux of the situation: a MASSIVE amount of IT in the West, and a MASSIVE amount of IT in the East, and yet despite all this, two huge universes with much little exchange between them than you might think.

I first learned about WeChat on a recent business trip to China.  All my Chinese IT colleagues and IT business partners were eager that we connect.  In fact, even in formal business meetings, instead of the initial round of swapping business cards, we spent the time scanning each other’s WeChat QR codes.

WeChat is a lot more than just instant messaging: it is online payment, email, and a host of other services rolled into one.

And . . . all content and communication with WeChat is strictly controlled by the Chinese government.  All posts and chats are filtered, and any words or topics that do not meet government standards are filtered out.

Final thought: a fabulous website shows the statistics about the number of languages that comprise the Internet:

A look back at the hype cycle

A while ago I published the most recent Garner “Hype Cycle,” which lists buzzwords and tries to give an estimate about how’ll they’ll develop into the market.

So instead of publishing the latest one this year, I thought it would be fun to have a look at a somewhat older Hype Cycle, going back 5 years:

 

I haven’t done a detailed assessment or comparison, but at a glance it seems like quite a few items from the “Peak of Inflated Expectations” are now in the “Plateau of Productivity.”

Extreme Ownership: If you’re in IT, it’s more than worth a read

This is an INCREDIBLE book!

There is no shortage of books written by ex-soldiers, trying to apply military tactics to business scenarios.  Probably the best known example is Sun Tzu’s Art of War, which dates back nearly 2000 years.  So I’m not all that eager to post book reviews on my blog about these books – you can find dozens, all very entertaining, but few giving you real tools you can add to your leadership toolbox.

That is, until now.

Recently a friend of mine recommended I read this book:

It’s filled with real-life anecdotes about Navy SEALs in combat situations, mostly with bad outcomes. And in each case, the authors point out that taking something called “extreme ownership” of a project / task / situation is a critical success factor to ensure success. This means owning the project completely: managing upwards, not just downwards – looking left and right – going far beyond the standard RACI matrix if needed – in short, taking every conceivable action to ensure success.

In their own words,

 

 

A little known history of IT offshoring – Part 3

Part III – The Solution

By Chuck Ritley & Ken Ritley


 

KEN:  So how did your Indian distributors  get into the picture?  Did you take the initiative?

I wish I was smart enough to take credit.  Coincidentally, one of the Indian principals had some business in the US with another supplier, stopped by for a get-acquainted meeting, and I had a couple of days to fine-tune some technical issues.  The topic of contract work came up.  “Would we be interested in contracting out program development work?”  Their technical staff were well educated, I had seen some of their product, and they could offer hourly rates far lower than the US.  We didn’t conclude anything then, but it gave me some ideas for the future.  These folks were a known quantity, and sold tons of our equipment in India with no complaints.  Clearly they knew what they were doing.

Let’s examine our coding deadline.   We had 8 programmers, and needed 16.  And IBM wasn’t slowing down.  We talked with the CEO about it.  We had other English-speaking assets, but India was the only one with enough excess manpower that was able to sell services.  So it was time to talk with them.  I had hoped for a trip to India, but we settled for the phone.

When we explained the scope of the project, the Managing Director in India showed an excellent grasp of the concept.  And offered us something we had not encountered:  a turnkey coding solution.  In the past, we paid contract programmers on an hourly basis, and had to constantly ride them to keep up production.  The Indians offered a hands-off deal to us:  they would provide up to 12 programmers, bring them to us, pay for their meals and lodging,  they would work under our supervision, and all for a package price.  If production goals slipped, they would bring in more help at no extra charge.

KEN:  Sounds like a good deal.  Almost too good, wouldn’t you say?

I was familiar with the “mythical man month”, and knew there was a limit to the number of people we could coordinate.  But the fact that they would take the risk was impressive.  And the total cost of the package was far less than I would have paid local programmers – if I could have acquired them quickly, which was no option in Silicon Valley at that time. Our CEO went off with his finance people and VP’s, and said “let’s do it”.  The bottom line was:  if we couldn’t get this done on time, we’d lose the game anyway.

KEN:  Today, of course, we bundle up projects and send them off.  How did you start an on-site deal like this?

Over the next two weeks, I renovated an old classroom with work tables, cabling, and 12 new terminals tied into a dedicated mini-computer.  I rented two small one-bedroom apartments close to the office, choosing “someplace that doesn’t have all that zoning stuff.”  The local government had some occupancy rules and I was cheating a bit.

The first to arrive was a guy who would be my main contact – let’s call him Krishna.  Well dressed, with excellent university English, Krishna explained that he would be in charge.  He rattled off some impressive IT credentials, and said that if I explained what I needed, then he’d interpret, delegate, and see it got done.  All I had to do was keep testing the coded output.  He checked out my workspace and said it was fine, and we went over to look at the 2 apartments.  I thought they were small for 12 guys but he said they’d be fine and I gave him the keys.

The following Monday, they all arrived — 12 programmers as specified.  I don’t recall their names as it’s been too many years.  I recall Kumar and Rakesh, but that’s all.  In my defense, the reason is simple:  only half of them were fluent in English.

KEN:  Now you have your team in place.  How did you get off ground zero?

I had a panic attack at this point, since our proprietary operating system and programming language were like the old Pick language – English-based.  Krishna calmed me down and explained that all of these guys – even those with no English – had been writing programs for their dealership for years and were proficient.  He said that the 6 who spoke no English were from Bangladesh, but that the Indians were all bi-lingual.   And they needed separation from the Bangladesh guys, hence the two apartments.

KEN:  Now you have your team in place.  How did you get the project started?

I got everyone into the classroom, where I had diagrams on the board and a projector with graphics.  (This pre-dated PowerPoint.)   I walked them through the logic of the system, slowly to let Krishna fill in those with no English.  Our own 8 guys, with their own modules to work on, sat in.  But at this juncture, all I could see was disaster.  Remember, this my first experience with an off-shore team.

We had a company van, and the 12 were hauled over to the apartments to get settled in while Krishna and I began working out a revised production plan. (I already had one, but it was geared up to the 8 in-house programmers.)  When I asked him about food, meals, and other necessities, he assured me that he would take care of all that.   My job was to assign tasks and test the output, Krishna would handle the work.   Bear in mind that I had been coding, and supervising coders, for years, but this was a new ball game.

KEN:  So give us a play-by-play of this new “ball game”.

So it began.  The next day they started coding.  Krishna must have re-briefed them that evening, and everyone seemed to know what to do.  They worked hard, with a work ethic I hadn’t seen before. No one broke for coffee, no one chatted with his neighbors, and no one wasted time.  There were problems, of course.  I made them print hard copies of everything so I could inspect all code, since no code works the first time.  And trying to keep up with 20 programmers was a strain on me, since all of the pieces had to fit together.

KEN:  So – so far so good?

All was not well at first.

Even with 12 extra programmers, we were falling behind our CEO’s release schedule.  Krishna was a task-master, drove the guys harshly, and they put in 12 hour days.  They kept to themselves, focused on work, and didn’t socialize with my guys.

A few weeks into the project, he asked if we had spare terminals.  We pulled 6 terminals and modems from inventory, took them to the apartments, and got them hooked into our development network.  Krishna planned to have them put in extra time in the late evenings on-line.

KEN: It sounds, at least, like the work was back on your schedule.

It was. But, at this point, it occurred to me – with much dismay — that I could somehow be stuck in the middle of a slave labor operation.

We were paying a flat fee for 12 people, jammed into two tiny one-bedroom apartments. (I was never allowed inside.) They fed themselves, so presumably they shopped and cooked.  Spare time was spent in extra work on-line. Saturdays and Sundays were just 2 more 12-hour work days.  I had my own terminal at home and I could see new code appearing on week-ends.

So my conscience prickled me – but not enough so that I was willing to tell the CEO that we couldn’t get it done.  Personal and business survival has a moral price sometimes.

KEN: So setting aside your Silicon Valley attitudes, how was it progressing?

 Now, honestly, the work wasn’t the highest quality.  The 12 turned out what 8 of my own programmers would have done.  I spent many hours going over code, editing subroutines, instructing Krishna on what was wrong and how to fix it.  After time, I had some rapport with the 6 English-speakers and instructed them directly.  Or I would have Kumar or Rakesh talk to the Bangladesh guys. That annoyed Krishna, but at this point I had a schedule to meet, and cultural customs be damned.  This, of course, caused some tension.  But, again, this was our first venture into new territory.

Weeks went by, but we made progress.

KEN: Progress in that you were keeping to your schedule.  But, how about the end result?

That was the over-riding potential hazard:  I knew from experience that when we went live, some code wouldn’t work. Does it ever? Programmers know what I mean.  So when the 12 went home, what we had was what we had.  And leave they did, with no fanfare, no long good-byes. I just handed Krishna a check.

As with any new system, there were bugs to be worked out over time.  But the code was plain, and well documented, so out own guys could handle that. And we got through the those bugs, and actually met the CEO’s deadline with a working system

KEN:  So in the end, everyone was happy about it.  I mean – happy with the results.

Yes, but it was a life lesson for me.  I was used to hard work and long hours.  Anyone who programs is.  But we never worked as hard as that Indian crew.   When I reflect back on it, I suppose it was a preview of things to come as more and more companies tried it.

From everything I could see, this was a win/win situation, or the guys wouldn’t have come and worked so hard.  But it’s hard to forget the 12 guys jammed into 2 rooms, working nearly 24/7.

 

A little known history of IT offshoring – Part 2

Part II – The Challenge

By Chuck Ritley & Ken Ritley


KEN: Of course, today the ERP concept is an old one – it’s the bread and butter of companies like SAP, and you can get degrees at colleges that teach this stuff.  Now let’s get to your challenge specifically – what was your pain point?

I was supervising the coding of a large enterprise control software package. Somewhat later the industry term became known as ERP – Enterprise Resource Planning. We competed with IBM head-on, a tough crowd. This concept included all the functions a company needed from materials to accounting to shipment.  A few dealers who had made this their specialty sold the software, and so there had to be some margin for customization.

Our pain point – time, time, time. We knew IBM was almost ready for market. The design had many new features, and the market was much different than today. The first company to break into a market could easily wind up owning it.  So our management needed to finish our product and start selling it before IBM or we’d be playing catch-up.  And bear in mind, we were a mini-computer company, competing against the giant of the mainframes.

KEN: Today there are many possibilities to solve the time-pressure problem. Hiring good IT people is not that big a challenge – and if you are really under time pressure, there is a huge market of freelancers and even companies willing to take over coding on a fixed price basis.  How was it different for you?

Our programming team consisted of 8 “programmers” – today known as developers or software engineers. Based on our workload, that wasn’t enough. Now bear this in mind: it was a proprietary world. COBOL was standard only for mainframes, so it you wanted a competent programmer, you needed to find one with expertise in another language and train him or her in your proprietary language. Freelancing was just beginning, and pickings were slim.

There weren’t any degrees in IT as yet, and most programmers got their start by attending schools from one of the manufacturers.  IBM and Honeywell, in those days, had large training programs.  Most programmers available for hire had spent time doing mainframe coding for customers of one of those two giants.  And they might not have coded in the areas we were developing.

As matter of fact, I was recruited to Silicon Valley because there had been a shortage of good programmers and I had both IBM and Honeywell experience. So there were good programmers available.  But not overnight.

KEN: It’s certainly much different today. So what made you think of recruiting an international workforce?

Frankly, the international market had puzzled me for some time.  We had distributors in Australia, New Zealand, Germany, Belgium, Great Britain, France, India, and Japan.   What amazed me was that everything we published by way of technical documentation was in English.  The OS, tied directly to the CPU, had the usual English-like commands: edit, erase, format, etc.   The coding language was similar to an abbreviated version of BASIC, rather than the assembler-style used by mainframes.

What impressed me was that each non-English speaking distributor had to have an English speaker on staff.   From time to time, each would send techs to the US, always someone fluent in English, and we would train them.  They would go home and translate everything from OS and programming manuals to the electronic logic diagrams into the native language.  No small task.

But, at the time, the US was the only source of minicomputers on the planet.  IBM didn’t compete at that level.  For example, in Australia and NZ, we were the largest computer supplier.  So distributors who took this route could open new markets at the turnkey level. To support this, we had a programmer and field engineer who worked odd hours to support the time differences and they could provide answers via telex.  (No internet as yet.)

I was most impressed by the staff of our Indian distributors, who were a large multi-product electronics house.  Because English was common, they created their own software with our programming language.  Not surprisingly, some utility software, such as database systems, had market value in the US.

 

Final coming next: Part III – The Solution

A little known history of IT offshoring – Part I

Part I – Setting the Stage

By Chuck Ritley & Ken Ritley


Anyone working in IT has heard the terms offshoring and nearshoring.  Two things about them usually come to mind.  First, that they are supposedly about transferring jobs to low wage countries. And second, they were supposedly made possible by recent advances in technology, as Thomas Friedman describes in his book The World is Flat.

These statements are not entirely correct.  In fact, IT offshoring began much earlier, even in the late 70’s and early 80’s, much before the Internet. And the motivation was less about saving money, but having access to top technical talent.

As an IT guy in the early 2000’s, Ken helped build large offshore and nearshore IT organizations in India and Eastern Europe. This is what we’ll call “second generation” IT offshoring – in which the work is made possible by the Internet and remote collaboration. But in the 1970’s Ken’s father Chuck was instrumental in setting up and directing some early “first generation” work – in which teams of foreign specialists were brought into the U.S.

What follows is a discussion between Ken and Chuck to tell the story of how first generation IT offshoring began, the strong impressions it left on the people involved with this work, and to highlight some differences and similarities between what happened then and what happened now.

KEN:  I recall it’s all about mini-computers, which don’t exist anymore today. Can you paint the scene?   What was the year, what was the industry like, and what were you and your company working on?

You have to understand the IT industry in the late 70’s and early 80’s. It was proprietary and minicomputer-based.  Each company had its own processor design and, therefore, a unique OS and language.  At the main-frame level, companies had their own mainframe programming staff who did custom programs.  But the minis were meant for the small and medium-sized business.  Since those companies could not afford a programming staff, or development time, the minicomputer manufacturers sold turnkey solutions.

The set-up involved a network of dealers, most of whom were specialty houses.  For example, in a large market, there would be a number of dealers.  One might specialize in finance, another in distribution, or wholesaling, or transportation, or retailing.  Most would start with a standard accounting suite of software and then tailor it to the needs of a specific industry.  For example, a trucking company would have different needs than a food wholesaler.

The main point is this:  it was a turnkey solution for the end-user, both HW and SW.

Now, to make this happen, the computer manufacturer would provide the basic accounting package: sales, orders, accounts receivable and payable, purchasing, inventory, general ledger, shipping, etc.  These are root functions that every company does – but a trucker does them differently than a clothing retailer.  They were designed to be customized.  Having customized one for a specific customer, the dealer now had some expertise and could sell the same customized version of the package to other prospects. The concept of having standard modules which could be tailored is probably the root of SAP and other systems like it.

KEN: That’s certainly much different than today.  Today the hardware is standard, the software and programming languages are standard, and the main differentiator between companies is the domain or solution.  Can you provide some details about your domain and solution? 

The system of customizing basic accounting packages was used by most of the mini-makers.  And all of them generally had the same set-up of specializing dealers.  But that wasn’t enough.

There was a need for more complex software suites to handle much more than basic accounting, things that dealers with limited staff couldn’t handle.  Manufacturers and distributors have complex operations and want to use computers for operations like scheduling work, planning lead times, and materials acquisition – far beyond the reach of normal accounting.  So we began to specialize in full-function enterprise resource planning and manufacturing resource planning software. In other words, handling all of the functions a company would need to control every function.  These were also meant to be customized easily at the dealer level, since individual needs vary.  We also had a few others, but these were the most complex, and beyond the development scope of any of our dealers.

We designed it, trained the dealer, he sold it, and then tailored it to the customers needs.  Now,  here is where the problems lay: creating these complex software modules required not only excellence in coding, but expertise in the mechanics of a business.  The solution was usually to have a business analyst working with the programmers to spell out the flow of work in terms that they could turn into code.

 

Coming next: Part II – The Challenge

 

IT Offshoring – It began differently than you might think!

IT outsourcing – offshoring – nearshoring – global delivery?  They’re familiar terms today – in fact, they are buzzwords.  Once they meant only cost-saving, but now these term more often refer to technical excellence.

When I first went to Bangalore in the early 2000’s to manage a global delivery facility for Hewlett Packard, I was amazed. I had traveled India before as a tourist, so I wasn’t sure what to expect from Bangalore.  What I found was a metropolis of IT.  That was 14 years ago.  Today, depending on what source you read, Bangalore is the center of 41% of all engineering research and development (ER&D) and 39% of all global in-house centers (GIC) in India.  In human terms, it has 530,000 trained technical people.  And that’s just the one city.  Directly or indirectly, India employs about 3 million people in direct IT support, and another 7 million in indirect support.

That’s more than 50% of all global outsourcing.

So – when did this begin?  How did it start?  Where did it start?  Why?  Like Henry Ford’s garage it had simple beginnings.  And in 30 years it has become a mammoth industry.

I first waded into this water in 2005.  But my Dad, now a semi-retired systems designer and professor of computer sciences, remembers start-up days back in the 1970’s and 1980’s – literally decades before many people think “offshore” began.  Together we assembled some memories of those first days that we’ll be publishing in a series of upcoming blogs. I think you’ll find it both enlightening and fun.  It’s like looking back at Mr. Ford’s first assembly line.

 

The “offshore” model, with my team in Bangalore:

 

And the “nearshore” model, with my team in Bulgaria:

 

The story begins here on my Dad’s blog, with the link here:  A little known history of IT offshoring – Part I

Jaw dropping experience

Humans aren’t really so diverse as we might think.

Myers and Briggs created a test to classify people based on their personality. The idea being, that there are just a few types of different personalities. There are plenty of free online versions of the test: you spend a few minutes, answer a few questions, and your personality can be classified into one of several types:

Usually when I manage a team, I ask some of my key team members and high achievers to take this test – and, as happened with me, usually people fall off their chair when they read the detailed description of their personality type and see just how accurate it is, as this example shows.

Why do I find this so useful as a management tool?  I really don’t want or need to know about what Myers-Briggs category people fit into – for me, there are just too many categories to make this a useful management tool. But I find when people read their own self-assessment, it provides them a lot of insight into their own personality, which in turn can help them develop in the team.  In German we call this the difference between Selbstbild und Fremdbild.

Where the “exotic niche” is mainstream

On a recent trip to the San Francisco Bay Area, I was shocked / surprised / stunned to see this advertisement on a public transportation bus:

Here’s a close-up of the advertisement:

Even within the IT community, there is probably only a small fraction of people who will understand this advertisement. And a tinier fraction than that who would be motivated to go find out more about this company.

So it is SHOCKING to see that a company expects enough value in paying for an advertisement like this. I don’t know the demographics of San Francisco, but it now must be one high tech city!