Inside Outsource

Managing expectations...

2011-10-07T07:30:00.004-04:00

This week, I said good bye to an old friend. For years, I worked on a product called Connected Online Backup. (Connected was bought by Iron Mountain, then sold to Autonomy. Autonomy is being bought by HP.) I've been using this backup product for years, and have needed to recover files maybe twice. But given the change of ownership, and the fact that I was using a "friends and family" free service that was part of an employee benefit package from 2002, I thought maybe I should actually upgrade to a backup service that I, you know, paid for.

So I looked around, and liked what I saw from Carbonite. They recently went public, and raised a decent bit of money, and probably helped enrich the lives of a number of software professionals in and around Boston.

Their software was easy to download, easy to install, nice modern user interface. But what struck me about something they did was how well they managed user expectation. Backup technology hasn't really changed much since I worked at Connected, and all the problems that Carbonite must struggle with are the same problems we struggled with. One such problem was the duration of the first backup. (First backups are "full" backups, everything else will be block-level incrimenetals, which means that unless you download or create several GB of data a day, your second, third, and etc. backups will be quick, especially compared to the first one...)

We always fought against the sales objection of "the first backup takes too long." We put significant work into speeding that process up, invented block-level checksum analytics to backup "symbolic links" to common files, to reduce the size of the first backup. We sweated this problem, and made it better by small percentages over many long years.

Carbonite took a different approach. They put, front and center - in their Buy page, in their FAQ, in their EULA, in their application - text to the effect that THE FIRST BACKUP COULD TAKE DAYS, OR EVEN A WEEK. Mine took a day. I suspect most take a day. But this is just brilliant expectation management.

Product Development Moral: If something is likely to take a day or two, tell the user it may take up to a week. Then, when it only takes a day, instead of viewing the performance as a reason not to buy, they'll be happy!

I wish I'd thought of that - maybe Connected Corp. would have made a big splash with an IPO!

pretty pictures

2011-07-29T13:16:00.003-04:00

apropos of nothing...

I picked this up off another blog I read, and thought it was a really interesting and beautiful slide show. It's a short series of photos from NYC and Bombay, showing the relatively striking similarities in daily life in the two big cities...

One Life Photos 2011

Click through, and enjoy...

It's a major award...

2011-06-27T08:11:00.004-04:00

So, I acknowledge it as reprehensible and unforgivable that I haven't written in this blog since early June, 2010. My bad. I jumped into a leadership position in a small startup (building search and sourcing tools for the recruiting and RPO industry) and have been heads down making and shipping software for nearly a year.

But... silence seems to be a useful strategy for blogging.

Even with a dearth of new posts, I just won a major award.

(Props to you if you get the movie reference...)

I was recently named one of the top bloggers in the shared services and outsourcing industry, as selected by the fine folks at The Shared Services and Outsourcing Network. (I posted about them some time ago, here.)

That confirms what I hoped, which was that this pile of information that I wrote up when I was working on my (stalled and probably abandoned) book would be useful to people... Mission accomplished.

At any rate, Inside Outsource has been honored at one of the top 15 blogs in the industry. And, for your reading pleasure, there is now a great list containing a link back to me, as well as to 14 other great blogs (many with content written, you know, recently) here, at SSON. Read and enjoy.

Also, Major Award:

Freelancing in Ukraine

2010-06-17T07:38:00.002-04:00

Companies like oDesk, eLance, and uTest have built a good business connecting freelance engineers with jobs and job-work. I've recently started working closely with a major crowd-sourced collaboration company on a project, and have developed a very favorable opinion of the work they get done.

So, this news strikes me as interesting, and a bit dangerous to their business model:

http://news.slashdot.org/story/10/06/15/2256227/In-Ukraine-IT-Freelancing-Under-Threat

More info after the jump to Slashdot, but the gist is that the Ukrainian government is after the tax income from freelance associates paid by foreign companies. It's inevitable that this part of the economy would come under scrutiny, but probably wrong-headed to put onerous restrictions in place that shut down the ability for these freelancers to work on global projects...

Anyway, hopefully the guys at the above-mentioned companies are on top of this, since there I've worked with some great engineers in Ukraine recently.

A new time zone tool

2010-05-04T06:46:00.004-04:00

I just this instant stumbled on a very nice tool that provides a quick, easy to understand graphic representation of time and time-offsets in (nearly) every time zone. It's called, cleverly enough, "every time zone."

Click here to launch a new browser tab in which this tool will load, in all its glory.

It looks as though this tool uses IP address geolocation to discover your local time. Then it gives you a slider so you can move your target time around, to see who you have to wake up early or keep up late for your next international conference call.

Having done this in excel for several years now, this is a nifty upgrade! It's in Beta, so keep your eyes on this one. Apparently it works on iPad as well, so one may hope for an iPhone and/or Droid version of the applet as well.

Some thoughts on change management

2010-04-26T10:59:00.014-04:00

No pun intended, but the broad topic of change management has great currency in the business world today.

What people typically mean when they say "change management" is some structured approach to understanding the stages humans go through as they understand and cope with change.

This is prescriptive if you are attempting to manipulate or engineer human behavior, so it has great relevancy to Industrial/Organizational psychology. Thus it finds its way into the business world.

Like software development lifecycle models, there seems to be a change model to fit any mood or mental predisposition. I've seen these three commonly referenced in business world, and I'm sure someone with better Google fu could find even more change models:

In each of these change models, the important and useful takeaway is that the model defines and codifies some phases of acceptance or resistance to change. When the business world talks about change management, they usually mean something prescriptive, along the lines of:

Step 1: Adopt a model of change. Hire consultants or highly paid experts to train people to understand said model of change.

Step 2: Help people move from one stage of the change model to the next. (characterized, for the sake of my allusion, as "Eh?")

Step 3: Profit! (Usually for the consultants.)

In the interest of full disclosure, I will now reveal that I am a highly paid consultant, and that I sometimes make money helping organizations cope with change.

This is all interesting and good, but... this model of merely defining and facilitating adoption of change leaves a high-order problem unsolved.

That unsolved problem can be most figuratively described as "the death of a thousand little cuts."

A visual and graphic metaphor I've used to describe this part of the change management problem follows:

Imagine you are a surgeon, as am I, as are five or six of our best friends. Further, imagine that we have a patient in front of us. I have to do an appendectomy. You have to do a repair to the patient's ankle. Someone else is working on a shoulder repair. Someone else is elbow-deep in the patient's lower intestine. Each of these surgeries is survivable. Not exactly out-patient, but not a big deal these days. The patient would be expected to survive each of them, individually.

The problem comes when all of us try to operate on the patient at the same time. In that world, the patient certainly dies on the operating table... Too much surgery all at once, and the patient simply can't handle it all.

Leaving you with the mental image of that poor patient, stitched and stapled from stem to stern, we'll move back to the business world, and change models. The high-order bit that seems to get missed in all these model of change management is the apparently novel and foreign idea of change metering.

Back to my metaphor -- what would happen if we each did our respective surgery serially, giving our patient time to recover and heal between trips to the ER? It would cost a lot, but our patient would survive.

In my experience, humans can only metabolize so much change at a time. Further, it doesn't really matter what the change event is -- they are all psychically disruptive. They all require the psyche to adapt and to absorb the change. They all start a journey through some phase model, ignoring which one you like best.

What's important isn't knowing what to call the phases. What's important and mostly missed is understanding the capacity of the system to absorb change, and metering the rate of change so that the system doesn't get overloaded.

So, by long way of introduction, I've got a model I've been using to describe Change Metering.

First, you have to think about what you can do to people. In business, there is a fairly finite list of factors you can change within an organization. I break it down into 7 categories in my little model:

Location - Where do you do your job?
People - What do you do for a living?
Team - Who do you work with?
Leadership - Who's in charge?
Technology - What tools do you use?
Process - What modes and methods are the norm?
Policy - What behaviors are mandated?

Within that 7-fold spectrum, you can have small, medium, and large change events. A few example change events follow:

Technology - Small Change Event: You get a new version of MS Office.
Technology - Medium Change Event: You switch from MS Office to Star Office.
Technology - Large Change Event: You switch from Windows to Linux.

People - Small Change Event: You switch jobs to a new but similar role.
People - Medium Change Event: Your job changes, and some responsibility goes away.
People - Large Change Event: You get promoted to a new job, with enhanced responsibility.

These are just examples, but you get the picture... Each change event in your work life, or in the work life of your organization, will fall into these seven buckets, and will be graded on this scale.

(Oh yeah, Small = 1 change point, Medium = 3 change points, Large = 5 change points.)

So, if you have followed me so far, you can see that using this model, you can easily build a multi-dimensional array of change, over time, over a team of people. It might look something like this:

(click to make this big enough to read...)

Now, as the table shows, you have a change score for every "significant" event that has happened to this team, over a few months. The next bit of this requires some hand-waving, but will work for the sake of explaining why change metering is so important.

Assumption 1: People absorb change at more or less the same rate.

Assumption 2: People can absorb change in about 6 months. Irrespective of the change model you choose to use, or whether you even have a change model in mind, in six months, people will have pretty much gotten used to their new (compiler, operating system, campus, boss, coworker, etc.).

Assumption 3: Change absorption is linear. (Why linear, you ask? Because it makes the math easier.)

Assumption 4: Though these units are arbitrary, accumulating more than 12 of them is bad.

Making these assumptions (and with the caveat that you can make up your own numbers, as soon as you get your own blog), you get a visual representation of the change absorption rate in this small team. (again, click on the image to make it big enough to read)

This can be immediately prescriptive:

As you can see, the whole team is going to be pretty stressed out in June and July.

If you were an executive manager and you were interested in, for instance, launching a big new discretionary initiative aligning your work norms to a new process model, you may want to wait until Q3. That slight pause in your roll out would prevent your change from overwhelming your team, and would give your initiative more mind-share and a better chance at success.

If you were the manager of this team, you should note carefully that you've got poor Amy in a state of perpetual flux. You might want to pay extra attention to her performance, and offer assistance as she absorbs her new role, new responsibility, and all the other change you've thrown at her.

In summary, change metering is more important than change modeling, but few people I've ever worked with have grokked this fact. If this model helps you, use it. Contact me via e-mail to negotiate royalty fees.

And to help amortize the cost of my graduate studies in philosophy, I will close with a quote from Heraclitus of Ephesus:

Πάντα ῥεῖ καὶ οὐδὲν μένει

Nothing is permanent but change

Doc Reviews

2010-04-22T08:02:00.001-04:00

This blog entry has been in draft form for, oh, a long time. Before I forget what I wanted to say, I thought I'd finish it this morning...

Document review meetings are a necessary evil of software development, no matter what you consider "a document" and no matter what your SDLC is.

Whether it's a quick PPT slide review, a white board session, or a formal design specification review, you have to get ideas out of one brain, on to some transfer media, and into another brain.

Given the difficulty of communication in general, and the compounding impact of distance and cultural/linguistic difference, it gets even tougher. So document reviews are important to get right.

I've done two approaches successfully:

1: Conceptual Walk-Through

In this approach, the author of the document isn't the one presenting it. Rather, the author finishes the document (to any level of detail, so this will work in light-process SDLCs too), publishes it somehow (steps away from the white board, sends a PPT out in e-mail, or checks a document in to source control), and gives the recipient or recipients a chance to read or review the document. Then, the recipient, or a nominated representative of the recipients, has the task of presenting the ideas in the document as a walk-through. In this model, rather than a line-by-line or section-by-section review, you're able to test that someone understood what was being presented. The author has to be the judge of the quality of the walk-through. If there are problems with the presentation, then you learned one of two things: Either the reader has poor reading comprehension skills, or the document is unclear about the key concepts or ideas it's trying to convey. Either way, you need to fix something. If the walk-through is clear and on target, then the document is OK, and you have communicated an idea or several ideas between the author and the readers.

2: Line-by-Line Review, with a twist

If you are still committed to line-by-line document reviews (and these only really work for big, long documents like design specifications, test strategy documents, schema definitions, etc.), then you will know that the biggest problem with a document review is that people seldom read the documents in advance. In every design review I've ever attended or run, there are several people clearly reading the document for the first time, IN the review meeting. This is a waste of everyone's time. So, to fix that, you can make a game of the pre-reading. Sprinkle the document with passages of Shakespeare, or your favorite public-domain author. Put in whole sentences, here and there. Count the number of instances of text you insert. (Oh, and save a pristine copy...) Distribute the document with the Shakespeare in it. When you call the Document Review meeting to order, ask people in advance to let you know how many instances of Shakespearean prose they found in document. Do the section by section review, then at the end reveal the number of instances of Shakespeare, and give a prize to the person or people who got it right. There are arguments to be made that this will get people to skim the document looking for "Now is the winter of our discontent," but in practice, I've found that this methodology does get people to read and review the document in advance, and makes for a more productive and interesting document review meeting.

Your mileage may vary, as always.

The Shared Services & Outsourcing Network

2010-02-26T07:46:00.003-05:00

I've recently been hitting this site every few days, for news about the outsourcing and shared services industry. As a news filter, it seems to catch what's important in the outsourcing space, so it's a good one-stop shopping experience for me. There is, within the site, a bunch of content around templates, best practices, and industry events (that they sponsor).

I'll offer the caveat that I haven't really explored their articles too deeply. As I said, I read it mostly for the news feed. But, it's a good site for that!

http://www.ssonetwork.com/

As always, your mileage may vary.

Booster shots...

2010-01-25T09:14:00.004-05:00

Travel remains a constant backdrop to building and running global technology teams. I've written about this before, but thought this was worth a quick reminder to people.

If you travel internationally, it's a good idea before you go to check with a travel nurse and get a professional opinion about what you might or might not need in the way of immunizations.

I'm in my early 40's, and in my last visit to the travel nurse, I was informed that there are some immunizations that guys my age need boosters on (measles/mumps/rubella, I think). And some stuff you can simply protect against with a shot or two (some kinds of hepatitis). But I do NOT pretend to offer advice here, except to say that a travel nurse (or a general practitioner) would be able to lay it all out for you as a cost-benefit, and that's what they do all day, so they're good at it. When I went to India for first time I didn’t do anything with respect to immunization, second trip to Asia, I got the full treatment… Shots, anti-malarial drugs, etc.

As an aside, I've personally opted against the anti-malarial drugs - they give me vertigo - but again, that's just a personal preference so I’d advise seeking professional opinion…

Lastly, for anyone traveling to India or China (or Vietnam, or the Philippines, or whatever) if you’ve never been 9 or 10 time zones off home, you might want to see about getting sleep aids (stronger than over the counter) so you’re not a walking zombie the whole trip.

As always, your mileage may vary, but do consider seeing a travel nurse, and getting the run down first hand, from a professional.

Dusty old dust...

2010-01-15T05:49:00.002-05:00

I remain in awe of bloggers who can, continually, for years on end, blog about three or four interesting things a week. Obviously, this blog has been inert for about 8 months. The bad news of that is that if I ever had a regular readership, they've stopped reading. The good news is that I've been busy as hell working, and I now have a bunch of ideas I need to write my way into and through, so I hope to pick up the pace again.

So, I'm re-launching this blog. Stay tuned for more...

A possible end to the fighting in Sri Lanka

2009-05-22T06:25:00.002-04:00

Sri Lanka doesn't often sort to the top of the list of outsourcing hot spots, but I have been lucky enough to work with several dozen very bright, dedicated, excellent engineers who work for a great OPD company with a center in Colombo. And I've visited Colombo twice, and enjoyed my visit both times in spite of the then heavy military presence. So I've always had a bit of a personal interest in the multi-year civil war there.

As anyone who follows global news knows, fighting between Sri Lanka's government and the LTTE (the Tamil Tigers) has been on a steady rise over the last several months. The LTTE have been fighting and occupying an ever decreasing territory in the North-East of the country. There has been a lot of international pressure on the SL government over the question of civilian fatalities and displacement due to the fighting.

Apparently the military capability of the LTTE was eradicated this week, facilitating a significant move toward peace.

Earlier this week, on May 19 2009, the President of Sri Lanka declared a national holiday in celebration of the end of the 25 year-old Civil War. Sri Lankan army troops have allegedly killed the leader of the LTTE, and the current leadership of the Tamil separatists have agreed to lay down arms and begin peace talks.

While it seems premature to declare a single-day victory in a 25 year insurgency, such are the events on the ground in Colombo this week.

Apparently the general mood in the country is one of elation to finally be leaving a bad chapter in the past. There's a good article on this here, at Financial Times.

I wish the country luck in its peace, and in its rebuilding and relocation of displaced Tamil citizens.

Book Review - The Services Shift

2009-05-18T09:45:00.002-04:00

For the last 8 weeks or so I've been carrying around and reading an excellent new book on outsourcing by Robert E. Kennedy. Kennedy runs the William Davidson Institute, that I mentioned in a post in April. His book, co-authored with Ajay Sharma, is called The Services Shift, Seizing the Ultimate Offshore Opportunity.

I like the book; and I recommend it, But I have to admit that one of my primary reactions to the book is jealousy - the jealousy of an unpublished author for a published author. To explain that comment, I have to digress into a little personal narrative.

When I started my own outsourcing adventure in 2000 or 2001 (a small project doing a Linux port of a server product) I was largely disinterested in the nuances of the outsourcing market. In 2003 I was charged with selecting a vendor for a larger QA outsourcing project, and at that point I put a little more thought and effort into the endeavor. I reasoned that much of what I was having to learn (about vendor selection, locale selection, work selection, knowledge transfer practices, global team management, cultural nuances in the global workplace, etc.) was or should have been known science. So I expected to be able to go to Amazon.com and find several excellent books on outsourcing, study up, and be an instant master of the art.

In 2003 that was not the case. There really weren't any good books on outsourcing, or if there were, they were very difficult to find.

Fast forward to 2008, in which year I dedicated a significant amount of my life to researching, writing and trying to sell a book on outsourcing. The book I envisioned (and partially completed) was positioned for engineers and managers in the USA who are struggling to understand and cope with the global services shift. I intended it to be somewhere between Daniel Pink's A Whole New Mind and Thomas Friedman's The World is Flat. After unsuccessfully pitching my proposal to a dozen or so publishers, I came to the conclusion that the market for books on global outsourcing was pretty well saturated. I have ten such books on a shelf within easy reach of my desk. I have probable read or skimmed another twenty. And there are literally dozens more that I haven't bothered to look at, for various reasons. Publishers liked my proposal, but unanimously viewed the market for this topic as supersaturated, and either had a book in the space already, or didn't see a way to make any money on a new book in the space. (And by the way, I think in many ways it is easier to raise venture capital for a software startup than it is to get a publishing deal for a business book.)

So, getting back to The Services Shift, it might be enough of a recommendation to point out that it was published by FT Press. That's the book imprint of the Financial Times newspaper. (As a further aside, If you don't already read FT, you should start, as I think it uniformly offers a good global perspective to balance the WSJ or NYT.) This is a serious publishing company, and as you'd expect, The Services Shift is a serious book.

I like most about this book the fact that it does a nice job bridging theory and practice. It's an excellent, scholarly book, without being too abstract, and without being overly burdened by the business school jargon and theory-bloat that plagues many business books. Think of it as The World is Flat, for a more analytic and intellectualizing audience.

Early in the book, Kennedy sums up what has been the guiding principle of my work for the last several years. The long quote that follows will give you a sense for the direction the book takes, and for the writing style:

"...[Companies" have to be better and cheaper and faster - all at the same time! ... We contend that most of these forces compel companies to look offshore for solutions to at least some of their problems. From a defensive standpoint, they need to lower their costs to compete -- and offshoring certainly offers that prospect. But offshoring also allows companies to be proactive in shaping their futures: by improving the quality of products and services, developing new offerings, and -- over the long term -- creating toeholds in the economies and markets that will be most important years and decades down the road."

This is the "faster, cheaper, better, closer" argument I've made many times, in this blog and elsewhere. Kennedy understands this new imperative, explains it well, and provides keen insights into both the macro and micro level issues in the services outsourcing space.

There are a lot of books on outsourcing. I have a hard time saying that any of them are must reads. But this is a very good book. It earns a place next to The World is Flat, and Multisourcing (by Linda Cohen and Allie Young) in my bookshelf.

If you were just starting out on an outsourcing epic, or if you were trying to grasp the shift toward globalization and devaluation of knowledge work, this book would be a great primer. And if you're already a practitioner, this book is chock full of facts, frameworks, and complex business theory explained in a way front-line technology managers can understand.

And perhaps the highest praise I can offer: The Services Shift is very close in concept and execution to the book I spent a good deal of 2008 researching and writing. And it's exactly the book I wish I could have found in 2003 when I started shifting routine and repetitive work to teams I built in India.

Buy it, read it, reference it.

A bit about oDesk, and props for Inside Outsource

2009-05-03T07:28:00.004-04:00

I've posted several times about the growing list of freelance outsourcing "clearing houses." This week, I discovered another, and possibly the most mature of these sites - oDesk. They take an interesting approach to global outsourcing - Allow direct brokerage between people with jobs and people with talent, without the overhead of a services vendor standing in the middle of the transaction adding margin overhead.

They have over 200,000 freelance providers bidding on jobs, and over 6000 active jobs. The oDesk manifesto says better than I could what they do and why they do it. They've assembled a serious management and advisory team that reads like a Silicon Valley fantasy league roster. They're on to what seems like a great idea, and I wish them much success.

The reason I found out about them is even more interesting, to me at least. They recently published a "Top-100" list for resources and blogs for outsourcing. They ranked the Inside Outsource blog in their top-100 list. (I'm number 23, but the list ranking is topical and alphabetic, not hierarchic.) That's great recognition, and certainly a dose of encouragement for me to pick up my pace and post more frequently. Thanks oDesk, for the recognition, and I hope your readers enjoy both the archive and any future insights.

The William Davidson Institute

2009-04-27T06:07:00.002-04:00

I am the first to admit that since late 2008 a shadow of doubt has fallen over the entire broad field of globalization. From presidential politics to questions about culpability in the global economic meltdown, it hasn't been a good time to be a proponent of and active participant in globalization.

My negligible blog output reflects both this pall, and the profound uncertainty surrounding the business on which I generally comment.

The bad news is that this era of uncertainty about where the global services economy is headed seems to be a new constant, and isn't heading toward clarity any time soon.

The good news is that in spite of this uncertainty, I've got a lot of new ideas observations and ideas to share in the coming weeks.

The first of these is a link to a very interesting and useful resources at the University of Michigan. Check out The William Davidson Institute web site (best viewed with Explorer, as they have some menu widgets that don't work in Chrome).

I stumbled across this institute because I'm reviewing a very good book by Robert E. Kennedy, their Executive Director (more on the book later this week). The institute is an interesting and useful resource for anyone interested in the academic side of globalization, or the more broad areas of sustainable development, poverty alleviation, and general business trends in emerging markets.

With events in Chile, Colombia, Algeria, Rwanda, and Latvia on their Q2 calendar, these guys clearly get around. Their site is worth some time, particularly for anyone who writes or does research in the field of globalization. Their web site has an archive of policy briefs, business briefs, and academic working papers available for download. Most interestingly, the working papers seem to be collected from universities all over the world, and should give an interesting "global" perspective on globalization.

Read and enjoy.

A framework for quality / maturity analysis

2009-03-17T11:14:00.002-04:00

I was looking through some old files recently and I stumbled across a "quality" framework I wrote that actually works quite well as a pre-engagement "maturity" framework, that might lead you to conclusions about whether a particular organization or company was ready to consider outsourcing any portion of their engineering or product development work. It's a long list of questions and concerns, but I figured it might be useful to someone, hence the framework in its entirety is posted below.

As always, while I have found this framework to be useful, your mileage may vary.

Notes on using this framework

This framework can be employed through technical "interviews" with key engineering team staff. Primary targets for interviews are:

Development engineering management
Development engineering staff (small sample set)
QA engineering management
QA engineering staff (small sample set)
Functional area managers for any other engineering disciplines

This framework is intended to get at core quality concerns primarily through "gut feel". This approach is admittedly insufficient for comparative analysis.

Project methodology

Regardless of the software development methodology used (waterfall, agile, XP, scrum, etc.) there are several common constructs that usually have a significant and direct impact on overall quality. These items should be considered in any analysis of product quality engineering practices.

Process definition and documentation

Is the software development methodology well understood by the engineers building the software? (as measured by correlation between various interviewees)
Is the understanding consistent across the team? (as measured by correlation between various interviewees)
Has the team implemented projects using this process before?
Is the process well documented?

Clarity and purity of role

Are roles defined for team members? (for example, "QA Engineer" vs. "Development Engineer")
What are the roles?
Are the roles well documented and understood by all parties? (as measured by correlation between various interviewees)
Do individual team members serve more than one role based function? Do they do so simultaneously?

Process phases

Are process phases formally defined? (for example, Requirements, Design, Implementation)
Are entry and exit criteria defined and documented?
Are formal process phase gate reviews performed?
Are results of phase gate reviews documented and shared with the full team?
What is the theoretic impact of a failed phase gate review?
What is the real-world impact of a failed phase gate review?

Documentation

What project artifacts (internal documentation such as Requirements, Use Cases, Specifications) are produced?
Are project artifacts common across projects (i.e., are they standardized as part of the development methodology)?
Are project artifacts stored in a common repository under version control?
What change control methodology is used for project artifacts?
What traceability methodology is used to track dependencies among various project artifacts?

Project complexity

Has the team implemented and successfully delivered a project of this size and scope before?

Development engineering methodology

Quality engineering starts well upstream of "QA". The following common aspects of software engineering can have significant impact to product quality.

Repository and Build

Is the software source stored in a source control system? If so, what repository?
Does the repository allow highly granular version control?
Does the product / project in question build every day? More often?
Is the build fully automated, and does it proceed from "start" without any human intervention?
What is the outcome of a failed build?
Does the repository and build system allow 100% identical build results (i.e., can any previous build number be reproduced from the repository without human intervention?)

Code Inspection

Is peer inspection of software source code performed?
If so, how often? (all source, only new source, only tricky source, etc.)
Are code inspections required prior to check-in, or simply suggested?
Are code inspection artifacts produced? (code inspection forms, etc.)
What is the outcome of a "failed" code inspection?
Are defect reports entered against code inspection "failures"?

Developer Unit Test

What (if any) unit test framework is used?
Do developers follow a "test first, then code" methodology?
How are unit tests run (automatically, manually, ad hoc)?
How often are unit tests run?
What is the result of a failed unit test?
Are defect reports entered against failed unit tests?

Developer Integration Test

Are developers required to build and test the project / product prior to checking in source?
What is the result of a failed integration test?
Are defect reports entered against failed integration tests?

Build Yield

Is build yield measured through the life of the project? (I.e., X attempts to build, Y successful builds, breaks for reason Z, etc.)
If so, how often does the build break?
What is the outcome of a failed build?
Is there a quality feedback loop from build failures (i.e., is root cause analysis done and corrected?)

Code Coverage Tools

Are code coverage tools in use?
If so, where and when is code coverage measured?

Advanced Diagnostic Tools

Are advanced diagnostic tools in use? (for example, Bounds Checker?)
Who uses the tools, and how often?

Development Environment
Does development engineering have its own systems to develop and test the product in question?
Does development engineering have autonomy within this environment?
Is the development engineering team measured on product quality?

Quality assurance methodology

While quality engineering is significantly influenced by upstream processes and events, as discussed in the previous two sections, the execution within the QA organization is of primary importance to this audit framework.

General QA Methodologies

Is "QA" a separate function?
How empowered is QA?
Does the QA team have a separate reporting structure?
Does QA perform all, some or none of the "testing"?
What is the development engineer: QA engineer ratio?
Does QA staff participate in product design?
Does QA staff participate in project phase gate reviews (if applicable)?

Overall testing approach

What phases or test levels does the QA function define? (for example, black box, integration, performance, beta)

Task decomposition

How does QA decompose tasks in order to completely test all components, sub-systems and functions? (for example, by use case, by feature, by architectural component, etc.)
Is this task decomposition reviewed outside of the QA team?

Smoke Test

Is each build tested for "happy path" to ensure basic functionality?
Are the smoke test "test cases" documented and well understood?
Does the smoke test run automatically?
Is Smoke yield tracked through the life of the project?
What is the result of a failed smoke test?
Are defect reports entered against failed smoke test?

Correctness testing

Irrespective of task decomposition, is test strategy documented?
Is this test strategy reviewed outside of QA?
Are all individual test cases documented and reviewed?
Are validation methodologies and data sets documented along with the test cases?
Is any attempt made to "normalize" test cases (i.e., one function per test case, or "about an hour of setup and verification")
Who authors test cases?
Who reviews the test cases for correctness?
What approach is taken in the presence of complex combinatorial features (for example, testing a function on multiple operating systems)?
Reproducible data sets?
Reproducibility of results?
Feedback loop for defects found outside of test cases?

White/Black Box?

What verification methods are used across the product / project testing?
Are verification methods reviewed as part of test case review?

Function coverage

What estimated level of "function coverage" (i.e., use cases, features) are covered during a given QA test cycle?
What methodology was used to arrive at this estimate?

System (integration) testing

Is System Testing viewed as a separate function from general correctness testing?
Is the full system tested "as deployed", or are only sub-components tested?
Are negative "scenario tests" performed? (for example, pull out a disk while the server is doing some function.)

Load testing

Is the full (integrated) system or product tested in a variety of "over-clocked" scenarios?
Are system components isolated and tested under "over-clocked" scenarios?

Performance testing

Is a distinction made between load testing and performance testing?
Is performance testing done on full-scale systems?
If not, what analysis has been done to facilitate scaled down performance measurement?
How are performance requirements and scenarios determined?
Is the performance testing modeled after customer deployments?

Network Simulation

If the product / project has any network layer dependencies, is any modeling done to determine possible network-layer perturbations?
Is any testing done using WAN / LAN simulation software?

Beta / EFT Testing

Are customer beta programs or "early field trials" part of the QA process?
If so, how many customers participate?
If so, what is the typical duration of the Beta?
If so, what is the typical number of defects discovered during Beta?
If so, what is the typical response to defects discovered in Beta phase?

Pre-release Regression Testing

What methodology is employed to ensure validity of test results through the "end-game" of a release?
How much of the final "gold candidate" is tested pre-release?

Defect Tracking & Measurement

Is a defect tracking tool (for example, Bugzilla, MKS Integrity Manager, etc.) used? If so, what flavor?
Is the defect workflow documented and well understood by all members of the team?
Is the defect schema well documented and well understood by all members of the team?
In which project phase are defects tracked?
Can defects be expunged by the system?
Who gets to close defects?
What defect metrics are tracked through the course of a project?
Are defect trends for existing projects compared to historic projects?
How many open defect reports are there?

Defect Verification

How are defects "committed" for fix?
How are defects verified for fix?
How are defects analyzed and verified for potential "collateral damage"?

Statistical Methods

Are any statistical methods in place to extrapolate product quality (and hence customer satisfaction) from software defect data?

Test case management

How are test cases managed?
Are they under change control?

Test Environment

Does QA team have its own systems to develop and test the product in question?
Does QA team have autonomy within this environment?

Empowerment

Can QA stop a release? If so, how and why?
Has QA stopped releases? If so, how and why?

Customer Experience

Overall quality is best determined by overall customer satisfaction. These parts of the framework attempt to get at the customer experience:

What is the size of customer base?
What is the largest single deployed instance?
What is the diversity of customer base? (range of sizes, market verticals, etc.)
What is the average number of tech support calls per customer per time period?
What is the average number of defects reported per customer (over some time period)?
What is the "work flow" for customer-reported defects?
Is the customer-reported defect work flow well understood and documented?

Special considerations

Product Complexity

How many lines of code in the product?
Are there any measurements of the complexity of the product? (Rose, etc.)
How many components or systems comprise the "system as deployed"?

Engineering Team Scalability

How big is the engineering team?
How many releases (and of what scale) does the team deliver a quarter/year?
How many releases / projects does the team work in at any given point?
Are there any significant staffing or resource bottlenecks?

Sustaining Engineering Methodology

How are customer "issues" handled?
Is there a dedicated "sustaining" team? If so, what disciplines are involved? How many people in each respective discipline?
What is the support model?
What is the triage / prioritization model?
How fast, after a fix has been coded, can a "hot fix" be released?
What level of QA is done on bug-fix releases?
How much of the product / project must be built and released in order to deliver a bug fix?

Too busy to blog, but not too busy to cross-post...

2009-02-20T09:39:00.003-05:00

I've been too busy trying to keep my own little consulting shop fully booked to write much lately, but I saw this today, and thought it relevant, from a cultural perspective, to anyone doing business in Japan. It also underlines a lot of what I've previously written about understanding the cultural norms of the place where part of your team lives...

http://www.boingboing.net/2009/02/19/business-card-etique.html

Read and enjoy.

The Story of India

2009-01-19T15:31:00.003-05:00

"India's history is a ten thousand year epic but for over two millennia, India has been at the center of world history."

The Story of India is a new six hour documentary from PBS and the BBC. It purports to trace the history of modern India from 70,000 BCE to 2007. When I first read this, I thought the goal was too ambitious, and figured the show might not even be worth watching.

But... I was very much mistaken. This PBS and BBC joint production, narrated by Michael Wood, is the first TV or film production I've found that captures the feel of India. I've watched the first four instalments, and have certainly learned a great deal; but more importantly, I've been transfixed by the beauty and intelligence of this documentary.

And the good news is that you can still (in the US anyway) see it on TV for free, on PBS.

If that doesn't work for you, or if your DVR is all filled up with footage of the US presidential inauguration, then you can buy the movie on DVD here.

I won't even try to summarize the content of the first four installments of this six-hour film, but I will say that the photo slide-show here really captures the feel of the film, and the film really captures the color and energy of modern India.

Take a look through the PBS site, and if it looks compelling to you, do try to watch this movie. You won't be disappointed!

Old news, but interesting

2009-01-13T12:18:00.002-05:00

If I were more diligent in keeping up with commentary about the outsourcing industry, I'd have posted this last week. But alas, I was traveling and working, and this is the first chance I've had to summarize the latest big news in Indian Outsourcing.

Satyam Computer Services, formerly India's third largest IT outsourcing company (53,000 employees) is now known as "India's Enron." The company has been embroiled in scandal since the end of December, and as facts unravel, it appears that this publicly traded company, once a winner of prestigious awards for corporate governance, has been manufacturing earnings reports for some time.

So far, the founder has been arrested, the CFO has been taken in for questioning by Indian authorities, the stock has been delisted, and the company's external auditor may be under investigation for complicity.

This is interesting for a few reasons:

It's a fair bet that Satyam won't weather this as a company, meaning their assets, contracts, and more importantly talent might be acquired by one of the remaining Indian outsourcing companies.
This scandal calls to question practical wisdom about corporate governance. Satyam was publicly traded, and gave the appearance of being in compliance with all regulations, standards and best practices for corporate governance. Lots of companies in the US seek to partner with publicly traded companies on the potentially mistaken assumption that SOX compliance (or other similar international standards for governance) will reduce risk and prevent the kind of fraud Satyam is accused of committing. There's still more investigation required in the Satyam case, but being publicly traded is clearly no guarantee of being well governed.
I suppose this is not news, the US doesn't have a monopoly on corruption, though US companies are probably still statistically over-represented in recent corruption cases.

More on this story in these stories from the Financial Times:

Elance

2009-01-04T10:43:00.005-05:00

I posted some time back about a freelance aggregation site called Scriptlance. I just stumbled across another reference, in a blog I read called "Cool Tools." The post in question talks about an aggregation service called Elance. They've apparently brokered $60M in contracted freelance jobs in the last year, with a very small dispute ratio. According to Kool Tools author Kevin Kelly:

Elance's escrow service holds the payment and protects both the work provider and you the employer. The site provides status updates on work done, and plenty of communication between the parties. Workers must pass a competency test to qualify to be listed. Some freelancers can also pass expertise tests in a mild form of certification, say for working on java or ajax, etc. Elance freelancers did about $60 million of work last year and less than 1% of the jobs had any kind of dispute, and most of those were self-resolved by the fact that the entire transaction correspondence is logged. (quoted from Cool Tools.)

I really like this business model. I'm on the verge of bidding out a logo design, and a web site redesign, and I'm going to try Elance. More news on this project and business model as I get it.

Outsourcing and process

2009-01-02T06:52:00.003-05:00

The CMMI Maturity Levels, from Wikimedia Commons

I have had dozens of conversations through the years about outsourcing and process. They usually start with questions about "what process is best" for a given team structure. I have a very pragmatic approach to this problem, that sometimes comes across as heretical.

The process doesn't matter.

I've worked in shops that spent a lot of time focusing on process. I've worked in shops that spent next to no time on process. I've come to the conclusion that process models and frameworks alone have very little impact on productivity or quality.

What matters is having smart people who know how to work well together.

The paradox in my heretical belief system comes in the nearly universal truth that smart people working together will develop and document a process, and will often optimize that process, write it down, diagram it with swim lanes and flow charts, and update it when they change it. It's human nature to develop process.

The best teams I've been a part of developed process communally and adapted the process perpetually.

The lesson for leaders in this observation is this:

Don't spend a lot of time focusing on your process model, whether it's for software development or IT service delivery. Certainly don't do this at the expense or exclusion of first-order problems.
Instead, give your team the mission of determining their own process definitions. Make the mission of developing process definitions subservient to the mission of building software, or delivering service, or doing what ever it is your customers pay you to do for them.
Make sure your team writes their process or processes down. Make sure it's reviewed by some contingent of your leadership team or executives. (That's less to get input from the reviewers, and more to make the staff structure the way they talk about the process.)
Make sure the staff has some way to train new hires or new team members on the expectations around how the team works together.
Make sure there's a feedback mechanism to get inputs and good ideas into the process.
Make sure the process is malleable.

You'll notice that the CMMI process model doesn't define what kind of work flow you should use. It doesn't mandate what format your functional specification takes. It doesn't demand that you make your meetings 90 minute seated affairs with parliamentary rules of order. Neither does it give guidelines that your meetings be held in conference rooms without chairs, to make them go faster. The CMMI process model defines some broad, universal concepts that all projects go through. As a process definition, it really just maps the high points. It's up to you and your teams to fill in the details. I think this is appropriate.

So my ultimate guidance is that the process doesn't matter. What matters is having one, and communicating what it is. (In this, your SDLC can be thought of as just another high-expectation task you need to document.) All a process model is is a statement of expected behavior of people in groups solving problems.

I will add one caveat, because I've seen a lot of teams attempt to adapt their process to integrated global teams -- Agile software development methodology, with daily scrum meetings, does not work well if your scrums have to involve teleconferences with remote teams in different timezones. It's too cumbersome to give the kinds of productivity lifts for which this particular process trick was designed. Instead of doing one big scrum, consider decomposing your project a bit more, and allowing the remote teams to each work on discrete release components, so they can have their scrum meetings be self-contained in their local centers. It won't always work, because you won't always be able to break the project into discrete components, but it's a good hack to allow a bit more productivity across two lobes of a global team.

Book Review - Get Your Frog Out of the Well

2008-12-29T14:11:00.002-05:00

I just finished and enjoyed a short book by fellow New Englander Chuck Boyer, entitled: Get Your Frog Out of the Well - Private lessons for the global economy.

The frog book, as the author privately refers to it, is published by Wiley-India and is currently sold only on the Indian sub-continent. If you're reading my blog from the USA, you're going to have a hard time finding and buying this book. I apologize to my American audience for that, and I urge my Indian readers to head out to the book store right away. Released mid-year, this book has been at or near the top of the non-fiction list in India ever since. And with good reason!

The framework for the book, as well as the source for the title, is a speech given in the 1890's by Swami Vivekananda, a Hindu teacher widely credited with the revival of Hinduism in India and beyond. In the speech, he admonished his US audience to consider the world beyond their immediate line of sight - and to not be "like a frog in a well." (Chuck tells the story better in the book...)

The point of the parable, one I've frequently tried to get across in my blog posts about communication, is that the world is a big place, and that it's naive and foolish to consider only your own point of reference in any attempt to communicate with a global audience.

This parable makes a great start to a book about communicating and working with Americans. It's a fair summary to say that the book is written for professionals working in India's booming IT and software development industry. These people are usually smart, well-educated technicians. But they may not have the soft skills necessary to succeed when they are required to work with peers and managers in the USA. I've experienced this problem first hand, and this book can help.

Well researched and concisely written, this book offers good advice on communication style, keen insights into some broad general trends about Americans, and lots of stories and anecdotes that make the book approachable and keep it interesting.

So I think it's fair to presume that anyone interested in my blog will enjoy and learn from this book.

I can imagine buying multiple copies of this book and giving it out to entire teams of engineers in India It would make a great basis for a multi-part book-club meeting, to help the team talk through communication strategies and tricks to be more effective with their US peers or clients.

If you're lucky enough to be in India any time soon, pick up a copy. You'll enjoy it!

(as an aside, you can buy it here, but I didn't check to see what rediff will charge to ship a copy to the USA.)

Chinese place names

2008-12-21T16:16:00.004-05:00

So, is this Peking duck, Beijing duck, or Peiching duck?

This entry isn't strictly about outsourcing, but since much of what I talk about with my fellow outsourcing professionals is travel-related I thought this bit about place names in China was fair game.

On my recent (first) business trip to China I was somewhat confused by the place names. I had studied my guide books, but the names of cities I saw on street signs and signs in the airports were all slightly different, depending on the context. I presumed it was a post-colonial reversion to a more accurate phonetic interpretation of the place's traditional name, kind of like how Bombay became Mumbai. Turns out I was close, but it's a bit more nuanced than that.

There are two competing conventions on how to render Mandarin Chinese into ASCII. They are:

Pinyin: This is the official phonetic spelling guide for Chinese, as developed by the PRC in the 50's, and since adopted as "official" global standard for pronouncing and transcribing Mandarin. Taiwan (The Republic of China) will adopt this standard in a few weeks, at which point we may presume many of their cities will become misspelled - overnite.
The Wade-Giles System: This system predates Pinyin, and was developed by Thomas Francis Wade in the 1860's, then improved by Herbert Allen Giles in 1912. Both these guys were British foreign service, so I was somewhat correct in my assumption that this spelling discrepancy was a hangover from the colonial era.

There's a link here to a decent site that attempts to make sense of Chinese place names.

In short Chengdu and Cheng-tu are the same city, as are Xian and Hsi An, as are Nanjing and Nanking. In each case, the first name is the Pinyin spelling, and the second name is the Wade-Giles spelling.

Beijing, which is spelled "Peiching" in the Wade-Giles system, is still commonly referred to as Peking (and the airport code for the Beijing International Airport is still PEK).

And sadly, I did not have Peking duck on my trip.

China Outsourcing Summit - Days Three and Four

2008-12-04T09:09:00.006-05:00

Days Three and Four

The final blog entry from my trip to the Gartner China Outsourcing Summit has hit a number of sequential delays. First, I was struck with the news of the terrorist attacks in Mumbai. Then, I was in a deep stupor having partaken of the traditional Thanksgiving feast last week. Most recently, I've been frantically preparing, and last night delivering a one hour talk on outsourcing in China, entitled "China's Century, Hype or Hope?" (more on that later...)

That out of the way, I thought I'd go through my notes and summarize days three and four of the summit. These were spent in session with Gartner analysts, and in boardroom sessions with vendors. I generally don't mind these 30 minute sessions, because they really are more "executive briefing" than sales pitch, and I learn a lot about the companies in question, as much based on their professionalism and presentation materials as based on their slide ware content.

The odd twist in this summit was that the presenters were a mix of companies and provincial government officials. I already explained the CCIIP - China Inc's PR and VC arm. These presentations were by regional affiliates from the target cities supported by the 1000-100-10 Project, in Chengdu to tell people like me about the relative merits of Xian as compared to Shenzhen.

My quick summary of both the vendors and the officials is that there is very little to differentiate one company from another (they are all roughly the same age, roughly the same size, and they say roughly the same stuff about themselves), or one city from another (they are all large and new and populous and beautiful and harmonious and filled with the ephemeral goodness of harmonious socialist state). That said, there are a few companies to watch, and there is a significant cost differential in China as you move away from the coastal cities.

Gartner highlighted the following companies as "top 10" by size. I'm not going to list the sizes here, or for that matter the URLs to the companies, since you can find this info easily if you're interested, and the Gartner stats on headcount were already significantly out of date. Here are the ten "largest" Chinese IT Outsourcing companies today:

Neusoft
DHC
SinoCom
Hisoft Technology
Chinasoft
Vance InfoTech
Achievo
Insigma
iSoftstone
Beyondsoft

My short list of "companies to watch" is:

DHC - These guys impressed me by talking about what they could do, instead of flashing up a bunch of Visio diagrams of network architecture and OSI stacks. They understand how to talk to buyers, which means (I think) that they understand something about business. I think they'll be successful, if they can continue to manage their service delivery. They have also secured significant venture investment from their customers, which I take as a good sign.

Beyondsoft - These guys are big (tenth largest) and have staffed US-based service delivery with US-resident Chinese staff who understand how to do business with Americans, and just as importantly, how to get business done in China.

Freeborders (11th in size, they are the first I've seen to develop significant American-Culture sales and marketing in the US. They followed up with me within two business days from the end of the summit, and have already gotten me scheduled for a lunch meeting to continue relationship building. These guys "get it" in a way that will win them new business in the months and years to come.

Now... about the cities...

As I said, they have all invested in IT Outsourcing infrastructure and capacity. The big difference I see is that the inland cities, such as Chengdu, enjoy a 30% cost-of-living reduction over Beijing and Shanghai. If you're going to China to be cheaper, you may want to head inland past the big port cities, and find a partner in Chengdu, Xian, etc.

A bit about the economics...

China is cheap. Not as cheap as Vietnam, but much more massive, and probably in possession of a more educated workforce. It's really tough to get a straight answer about this from anyone, but as near as I can tell, an entry level developer will pull in an equivalent of $US 12,000 a year. That's compared to about $US 20,000 for the same talent in India, and about $65,000 in the good old US of A. As you get into the senior talent pool for development, the percentage of US scale is even more favorable. But (there's always a but) there is a significant differential in cost of leadership experience (as in India), and good verbal English language skills. As already mentioned, the coastal cities are more expensive than the inland cities. Adding to this advantage are the tax incentives that the 11th 5-year plan has put in place to encourage growth in the IT Outsourcing Industry.

All in, China can certainly deliver Cheaper, if you can manage your vendors or your captive to ensure either parity or improvement in quality and productivity.

I got out into Chengdu both evenings after the conference let out. I found the city beautiful and safe by night, bustling but not in a New York kind of way... I didn't really have much sense of being in China though. It was modern and cosmopolitan. The people were stylish, and "western" in dress. The cars were European brands. I felt, to be honest, more like I was in Vancouver on a Saturday evening.

I did get to eat some genuine (I was told) Sichuan food. It was spicy, in a way I've never experienced in the USA. The "Ma", or numbness from the Sichuan peppercorns, was just amazing. And apparently growing up in the south is good global training for spicy food. I was eating with Chinese and Taiwanese Americans, who were breaking out in sweat over the spice in the food. I was just enjoying it. So either I'm the Rambo of the Mala Chicken scene, or they were giving "the white guy" different food... Either way, my local Chinese takeout joint will never be the same.

Sichuan Tofu Pot - Very spicy...

The trip home was a slow-motion rerun of the trip there. Lots of airplane terminals, departure lounges, a fog of Yan Jing beer, and, 31 hours later, a car ride home from Logan airport.

3 days of travel for 4 days of being there. I'm not sure I'd do it again, but it was a great trip. I learned a ton, and made some business connections I suspect I'll nurture and grow in the coming years. Thanks Gartner, and thanks CCIIP for putting this on!

Mumbai attack aftermath...

2008-12-02T08:19:00.003-05:00

So, I'm not really equipped as a writer to comment on the human tragedy of last week's attacks in Mumbai. But someone pointed out to me a truth about this event, and indeed about all "security."

The truth is this: The risk of traveling in India is no different today than it was this time last week, before the attacks. If anything, this will cause changes that will make it safer to travel and live in India, both for Westerners and for Indians.

I agree, though the emotional impact of watching the Taj Hotel burning is tough to get over.

All that said and done, the CIA's latest travel advisory urges caution, but stops short of advising curtailment of travel. This is quoted from the CIA's 11/28/08 advisory (that expires on 12/31/08).

Americans throughout India should be vigilant about security at all times. The Embassy and Consulates are actively assessing the countrywide security environment. Americans are advised to monitor local news reports, vary their routes and times in carrying out daily activities, and consider the level of security present when visiting public places, including religious sites, or hotels, restaurants, entertainment and recreation venues. If unattended packages are spotted, American citizens should immediately exit the area and report the packages to authorities.

Good advice for troubled times...

Attacks in Mumbai

2008-11-27T09:09:00.003-05:00

I had planned to finish my trip report and write up my impressions of a dozen or so companies I chatted with in Chengdu last week. Until late last night, when my wife checked the news on-line and pointed out this to me.

The summary is that there were coordinated attacks in Mumbai yesterday, at several 5-star hotels, and other places through the city. Apparently the attackers were targetting Americans and Brits.

"The death toll had reached 101 by early Thursday afternoon, with nearly 300 injured. WB Tayady, head of St George’s hospital, said most fatalities had been caused by bullet wounds."

I am largely desensitized to reports of violence in the news. But this... tragic and bad and distirbing and sad all at once. I feel for the victims, and I think this starts to change my opinion about the safety of traveling and working in India...

A few years back, I elected not to send work to a company in Indonesia, because I didn't think I would feel safe there, and I didn't think I'd be able to ask my staff to travel there without worrying about their safety. India, I thought, has a long history of tolerance, and of dealing with conflict peacefully.. Well, maybe not so much any more. It's too early to draw conclusions, but this is a big deal. Fingers crossed for the remaining hostages. I hope they resolve this, and rain vengeance down on the perpetrators.