by Nick Krym

Force Majeure

Force Majeure (French for “superior force”), is a common clause in contracts which essentially frees both parties from liability or obligation when an extraordinary event or circumstance beyond the control of the parties, such as a war, strike, riot, crime, or an event described by the legal term “act of God” (e.g., flooding, earthquake, volcano), prevents one or both parties from fulfilling their obligations under the contract.

While working with offshore teams, in particular in countries that are subject to severer environmental conditions such as Bangladesh or Philippines you should never forget about how real Force Majeure is. For my pet project wwhow.com I use support of freelancers from Philippines in SEO and data entry tasks via oDesk service. Here is an email I just received from one of my providers –

Dear Nick,

We had experienced a typhoon Ketsana that hits our area tremendously last Saturday morning since then our power was cut due to heavy rains and floods. Floods were everywhere including in our home. Power was restored last night. In this regard, the two accounts were not able to finish the working hours load for the week.

Rest assured this week, we will continue to post quality deals and able to finish work load. I apologize for this unavoidable circumstances.

—
Kind regards,

Jennifer

Continue reading →

by Nick Krym

Environmental Fears

As I mentioned in At Doorsteps of a New Engagement I have a new vendor to deal with. It is a company that has been working with my team for over two years and thus it’s only new for me. It took about a few days for me to encounter the first set of issues. And that set came from the area so common that it’s worth a post by itself – software environments. Below is an email which I was cc’ed on –

Subject: RE: WCM Publish failed

Ravi,
Please explain to me how the production environment does not match what is in UAT. This is unacceptable and must stop. This is not the first time a production turnover did not match UAT.
We need to review our build, turnover, and documentation procedures. This pattern cannot continue.

Looks familiar? I am sure it is…

If you are in business of delivering software as a service or similar to it the chances you will have the following environments: development, QA, staging, production, disaster recovery. You may also have dedicated environments including Build, UAT, Sand Box(es), Performance Lab, etc. If you work with offshore team the chances are some of those environments are duplicated in the offshore offices.

A number of issues arise as environments proliferate:

Continue reading →

by Nick Krym

At Doorsteps of a New Engagement

I finally started working in my new role, VPE / CTO of PDR Network. It took almost a full year of non-stop activities on two complex M&A projects to get to this point. Medem and its assets moved on to two different organizations and I followed one of those assets. “Asset” in this case meaning product, resources, customers, etc. – basically a business unit. Fortunately, I was able to keep some of my top contributors even though far not everyone.

This economy put a huge strain on teams. I had to let go some people who I immensely respect and enjoy working with. Hopefully the new place will provide an opportunity for some of the guys I lost along the way to rejoin. Well, it remains to be seen; at this point I am facing couple disentanglement and technology merge projects that include working with new offshore partners.

dataquest-idc

PDR Network was formed by merging two assets acquired by a prominent equity firm: Physicians’ Desk Reference, acquired from Thomson Reuters, and the Health Care Notification Network, acquired from Medem. Medem had its offshore partners and Thomson Reuters many of their own. Naturally Medem partnered with small companies and TR with fairly large ones, even though to my surprise not tier 1.

At this point I do not know practically anything about my new outsourcing partners and the challenges they will bring. It feels like you are standing in front of doors to someone’s house and ringing the door bell. From behind the doors you hear a dog barking. What kind of dog is it? Playful Yorkshire terrier, English Bulldog dripping saliva, huge Newfoundland eager to lick you off your feet, vicious Presa Canario ready to rip you apart? It would be great to know before the door opens.

So let me guess what the new vendor will bring to my plate… At this point your guess is as good as mine, the only thing I know of the vendor that they made it to top 20 Indian IT list. Well, I know a little bit about the history and track record, but not much and only at high level / in general terms… So let me put my expectations in writing and see how the actuals pan out:

  • Turnover not less than 30%
  • Majority of the resources would not pass through interview by on-shore team
  • Poor track record of deliverables (late, over budget, low quality)
  • Low quality of code (no comments, inefficient code, etc.)
  • Low quality of the processes (incompliance with SDLC in many aspects)
  • Very inefficient / over-engineered architecture / designs
  • Waterfall SDLC with cushy estimates, slow start and high pressure in the end of each engagement

OK, that’s enough for now. I will keep you posted with what I find out discover over next few months.

by Nick Krym

Herding Cats

You most likely have seen that commercial.

I think EDS has a great point here, managing software organizations is very much like herding cats. Managing software teams with outsourced distributed components take herding cats to a profoundly higher level – doing it on steroids… or should I say on drugs?

How can one survive the ordeal of getting a product out in multi-sourced distributed environment? Language barriers alone brought the Babel project to its fiasco. And you know that language barrier is often much easier to deal with than with communication barriers or cultural differences.

Well, it’s been done, as a matter of fact many times… on time, within budget and over-delivering on customer’s expectations. Is there a recipe I can offer? Probably not, at least not a panacea that will fit any project or organization. As a matter of fact specific combination of project / team / environment demands its own methodology, approach, techniques. Let me offer just one of those, five C’s of distributed project delivery:

  • Casting. That is the first and the most important element – select right tools for the job, find the right providers for the task, put people in positions that match their skills and aspirations.
  • Compensation. Make sure that resources on your project are properly compensated for what they do, that applies to everyone from your in-house architects to offshore worker-bees. Considering that working with offshore throws a huge monkey wrench in your ability to control compensation you may need to start early – when establishing your relationships with providers.
  • Communications. Put a well thought out communication plan in work and enforce it with the vengeance, at the same time review it and improve with every opportunity. Make sure that you cover all channels and take advantage of multiple media.
  • Culture. Cultural differences derailed many projects and engagements. At the same time it is not necessarily as difficult or complex of an issue. Here are just a few things consider – acknowledge / recognize cultural difference, educate the team about them, and keep attention on cultural aspects, in particular when it comes to communications, estimating and delivery patterns.
  • Control. Control execution on an ongoing basis in every aspect of the project – schedule, budget, quality. That is a large topic partially covered in the blog already (see for example Peace in Metrics). I will talk more about it in future posts.