Archive for the ‘Book Review’ Category


“Distance is dead, but time zones are not!”

Comments (0)

I do not 100% agree that the issue of distance no longer exists; however I agree time zones are here to stay! According to the authors of, “I’m working while they’re sleeping”, we do not have a problem communicating across distances because there are so many tools available to ease this process, however, issue of differences in time is still there and will remain. Even some of the evidence the authors present in the book, on team dispersion versus productivity, refutes the claim that the issues of working across distances are all in the past. This part I did not get….. One of the examples given was the issues teams experience, even when they are located in the same building, efficiency still goes down……probably due to people thinking that less effort is needed if you are in the same building. I think we have all seen this, even with a difference in floors, in the same building, there tends to be knowledge on some floors that has not been dispersed to people on other floors. However, the authors gloss over this issue for the book, stating there are no more issues across distances, but rather concentrate on talking about the issues caused by time zone differences.

This is the third book which Erran Carmel has been an author on, which I have reviewed. Therefore I was anxious to take a closer look at it. For me it was the first book that I have seen, that concentrates chiefly on time zone differences. I am vacillating as to who is the best targeted audience for this book? After reading through, I am thinking it would be most beneficial to those who have already worked, at least once, with teams across many time zones. The situations discussed would be very familiar and it would be easier to pick up tips of what to do next time, than to pick out planning tips that could be used for your first “distributed across multiple time zones” team. The authors seem to elude to this as well, that time zone differences and how to deal with them, is not a concern until it becomes a problem; i.e. not usually seen as an area to talk about upfront when starting a team. However, I do see this as a book that could be very useful for the person who is looking to become, or has been tagged to become the “global liaison”, as the author’s refer to the person who works between teams in different locations (this person could also be the product manager, project manager, project coordinator, or have a host of other titles).

The book itself is broken up in to three sections: The Fundamentals, Time Zone strategy, and the last section is titled, “Time and a Half”. I had to laugh at the comment in the section on fundamentals, about outcomes, and that, “The advantage of distributed work is that you can blame distributed work for the project being late……”. An excellent point is made, that bears repeating, that we need to understand when coordination is truly necessary. One team may be effectively coordinated but at an extraordinary cost, thereby driving team performance outcomes down. A good example of this is when a coordinator (or global liaison) manages too few people, not an optimal number; the cost is high and the performance is lower than it could be.

An oft repeated topic in books related to virtual teams, or global team management, and frequent topic of conversation among project managers is a discussion of the pros and cons of complete time overlap for a team, versus receiving at least some benefit from only having some overlap (not in the follow the sun type of way or round the clock meaning, but just two or three hours of overlap). Working during the same time, of course provides the widest window for same-time interaction, but it also leads to more interruptions. The authors add further research to this discussion that gives food for thought. Having some kind of a time difference may force the team to establish better practices, which includes having some quiet time for individual team members. This is where the question comes in. What is better for the team members? All knowledge workers and team members will have an opinion on this. It is seen as a benefit of distance that less time overlap means less interruptions, or at least interruptions can be more planned. It is a well-known fact that interruptions cut down on productivity, it is harder to get back to what you were doing before after every interruption. However, the book contains interesting research that shows that 44% of the interruptions we face during a day are self-imposed (checking our email, checking Facebook, getting a cup of coffee or tea, playing a game of ping pong (one of my favorite interruptions), etc.), and that actually with interruptions, we tend to be more productivity. We tend to try and make up for interruptions and work faster. However, allowing for these interruptions does tend to raise our stress levels. So it seems that because of 44% of our daily interruptions are self-imposed, we tend to work harder, and be more productive. However then the other question I have is, if 56% of our interruptions are not self-imposed, do we work harder to make up for those interruptions as well? The experiments do point to the fact that the social interruptions may be very beneficial (whether virtual or face to face) for generating ideas, or to get a break from a difficult problem and come back with a fresh head and perhaps a new way of looking at the problem. This I think we all know from water cooler or kitchen discussions which pop up during the day and that can be very helpful. Appendix D continues the discussion on the science of interruptions and is worth the read.

You will want to pay attention to the time zone strategies introduced, some of which are familiar; Follow-the-Sun, Round-the-clock, and real-time simulated co-location. As well as the six time-zone configurations that are discussed. The authors discuss examples to determine what works best for what type of activities; i.e. can software development really be done using a follow-the-sun strategy, i.e. every shift is handing over work to the next shift. As many people know in this industry, this strategy has been tried and tried again. Technically it can work in certain situations and with the right structure; i.e. the right combination of developer sites, to reviewer sites, so one location does not become a bottle neck. The authors discuss examples of companies which have tried this method; what worked, what did not work, and how they eventually tried to sort things out.

A benefit to reading the book is to pay attention to the benefits and target activities for each time zone strategy. For example according to the authors, the Follow-the-sun strategy, which involves; unfinished work that is handed off to the next sit on a daily basis, it is about speed, sites are very dependent on each other. Works best for activities like: Rapid prototyping – creative task, with serious coordination.

However, I thought it was very interesting that based on the examples used, the authors drew the conclusion that with follow-the-sun quality goes down. The reasons being that the tasks are more complicated, maybe there are more questions, and the team cannot ask them during the day, so they are guessing, and guessing wrong. What I am wondering is, especially in a situation like rapid prototyping, can any benefit be gained by a follow-the-sun methodology? Is there any benefit to having the team work in a silo (at least for several hours in a day)? Would you, or could you get something unexpected, that turns out to be better than what was planned for? Instead of direction coming all from one location or one source, ideas come from many locations with different backgrounds and differnet takes on the project, which could make for a better product in the end? I am wondering if this theory has been tested. I suppose it has somewhere, just need to dig for the results. I am also curious if the “reduction in quality” that was sighted for follow-the-sun, has been full researched? What do they mean by quality? Sometimes it means the product was not done the way I would have done it. If you are going to be working on something like rapid prototyping, global teams should have a lot of autonomy to make decisions on their own. That seems the only way to get the full benefit.

It was also good to note, and get straightened out that may global teams think they do the follow-the-sun approach, but if they are doing any part of a parallel approach or phase approach, then they are not really taking advantage of time zones. i.e. this location is working on this independently, and this one is working on this independently. The workers just happen to spread across the globe. That is not true follow-the-sun. Another key of course to making follow-the-sun really work, is to have the right development methodology. The authors believe that agile works the best- short time bursts, iterations. I think the key here is that the team is big enough that some function is always being fully developed and fully tested each day and can be delivered continuously. In this way the different time zones can concentrate on development, testing, and review and acceptance. The authors make a good note for agile development which is that personal time-boxing curbs perfectionist tendencies, procrastination and prevents an individual from over committing to a task.

Finally in the last part of the book, the authors offer two radical options for handling time zones. The first strategy is to establish a 24 hour culture within a company. People who work all hours are supported, but it is important that anyone in the company realizes that at any time they may have to work night or day, depending on when the client is working. The question is, can this be sustained? The second radical strategy is to engage in Real-time simulated co-location (RTSC) (of course this one also really requires the 24 hour culture…….). For this strategy, always on audio/video is required, something similar to Cisco’s Telepresence. Also needed is an awareness technology such as a shared dashboard to look at key project data. Co-located teams work in the same room, where developers work together, elbow to elbow. The rule for co-location strategy is (near) perfect time overlap. Video overlap screens let anyone look at who else is working. Then you can just walk up the screen and call the person you need to talk with. I think some teams would like this, to be able to see who is working and to know if they can bother that person at that moment with something. Would it lead to more spontaneous discussion like a discussion the kitchen, I am not sure. Also, what does this feeling of being “watched” do to the developers? It is one thing to be in the same room with people, where everyone is getting in to their own zone, but to know that in the back of your mind, a camera is on you……not sure. It may seem more like something to be used by management, just to see that people are working, rather than as a tool for more collaboration. But I think this perception will be changing. In any case, both of these strategies require a literal 24 hour culture, and who is going to be the major time shifters? That will be a power struggle between locations, and between countries. So I am not sure either one of these strategies, as described in the book, would be the answer for the long term. I do agree though, because of technology improvements we will continue to move in the direction of being able to walk up to a wall and seeing who is working thousands of miles away and connecting with them immediately (as opposed to what we now which is ping them in skype or call their phone and see if they have some time to talk).

Categories: Book Review, Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, startups, Virtual Teams |


I was so hoping to learn something new!

Comments (2)

But did I?  I just finished reading Terence Brake’s book, “Where in the World is my Team?”.  I was intrigued by the reviews saying it was not a regular business book, and of course the topic of virtual teams, so I decided to pick it up.

If you are not familiar with this book, indeed, it is not like usual business books in that there are actually points in it that will make anyone laugh. At the beginning, we are introduced to Will Williams, the new assistant to the CEO at a gaming company, The Fun House.  He is working in London, but there is a whole host of characters all over the world, with whom Will interacts. Will is tasked by his CEO, to put together a Briefing Report on the new workplace, working virtually, technologies that aid the new workplace, etc., for her upcoming TV appearance.  The readers “learn” along with Will, as he wades in to the new workplace.

The set up having to go through Will’s introduction in to working with virtual teams is a bit much, having to go through each of his meetings, and his personal feelings on meeting with his ex-girlfriend or the “interesting” analyst, whose work Will never bothered to read, dealing with his parents, his new love, etc.  But you really can’t skip any part of the book. The dialogue of a relevant conference call talking about ways to improve communication in virtual teams may be between a few paragraphs about the crazy analyst or Will’s colleague in the next cubicle.  You can certainly skim those parts though.  By doing it in real world fashion though, every reader, who has worked in global virtual teams will recognize similar mistakes they have made as they have learned to work with virtual teams.

Many of the points made in the book, building virtual trust, communication, etc., have been stated in other books, but I do like the diagrams that are used to show the different points.  For example the Collaboration Controller is good.  I also like the diagram on pg. 25 on virtual trust and its different aspects.

Some of my favorite points include:

–    Being in a virtual team, and especially leading one, means communicating when you don’t have to – not just when you want something from someone.  Only when you want something makes it very shallow relationship.  Do you know anything else about them?
–    Also under process I like the emphasis on the transition from establishing a relationship to going in to the task.  The delicate balance between these two processes – of course I did not see in the book any details about how to actually do this transition.
–    Working in isolation, means less communication which builds paranoia, people get anxious.  Which I have talked about many times.
–    The confusion caused by vague communication, lack of transparency, etc.
* I like the example given – an American to a Brit – “I created a “straw man” agenda for the upcoming meeting, and I have a “hard stop”, at 3:00pm”.  What does that mean?  Writing something like, “I created a preliminary agenda for the upcoming meeting and I have a deadline of 3:00pm, can you provide feedback until then”, would do.  Why do we write in the first way?  I think a lot of Americans can relate to this example, we tend to use a lot of buzz words and are almost judged on our use of them.
* I also like a lot of the comments in the book, such as why do we waste time being vague… there is enough distance between people!!! It just leads to a lot of second guessing…..and the need to communicate a lot more in the future….

–    With virtual teams, problems can easily be blown out of proportion!  – so true!!!
–    I like the emphasis on understanding the purpose – the book puts it out on the “purpose” of the team, or the “why” the team is doing what it is doing.  I have always liked the emphasis on the “why” as to “why” the users need to work the way they do, why the system needs to work in a certain way, but I like the emphasis on “why” the team has formed.
–    Team members tend to side with those who are located closest to them
–    I like the list of 10 Behavioral Rules for The Fun House –  10 rules I think are great for any team!

About halfway through the main portion of the book (and one too many paragraphs about Spinks – read the book if you want to know who this is), I decided to skip to the Briefing Report located in the appendix,  to see if something could be learned from reading that portion of the book only.

There are some points that I think could stand on their own if a reader was looking for a quick reference.

–    The Collaboration controller chart on pg. 187, I like the outlining of the challenges and how to counteract them.
–    In general good parts on the 6 items that make a team work well
–    Section 3 on Cooperation is good – similar to other books though, especially on giving and getting trust.
–    The general pointers part of Section 3 is good – pointers for building cooperation, although also ones you can see in other books.  But at least something you can read quickly and get some ideas.
–    Good questions for testing your readiness for managing the team and for testing the preparedness of the team members
–    I like the cultural intelligence section, section 8.   The Worldprism™ model

“Where in the World is my Team”, is certainly not an ordinary business book and it is not dry, so it is something new. One of the negatives I have often found with many of these books is the lack of real life examples.  “Where in the world is my Team?”, provides those real world examples (of course changing the names to protect the innocent!).  The bad part is that you can’t skip significant sections of it or easily hone in on sections that may be relevant to your situation.  The information comes to you in bits and pieces through reading the dialogue of conference calls, or reading email exchanges that Will has engaged in.  It is an easy read and, and I hate to say it, but I found myself wondering what was going to happen to Will’s father, but at the same time I was often frustrated with all of the “filler” stories and was skipping ahead when I could. However, if you are new to working with global teams and with virtual teams, this is a great first book to pick up. Why pick up a regular business book, when you can have a “story” to go along with it!  If you are more experienced, you can still pick up new points, you will just have to wade through a lot of “story” to get to them.

Categories: Book Review, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |


Here goes a review practically longer than the book!

Comments (0)

On one hand there are certain expectations when picking up a pocket book on any subject. I expect some quick tips, checklists, something that I can quickly peruse and refer back to easily. I picked this one up since it was published in 2010 and published by Harvard Business School Publishing. 

My first impression was not good!  Why does a small pocket book, which by definition does not have a lot of room for details, have to go in to “what is a virtual team and why they are becoming more prevalent…….”.  Even if you have never led a virtual team, doesn’t everyone know this by now……   I did pick up a new term though in this section, ”same-place team”. The definition is obvious from the words, i.e. a team where all members are in the same location but I was under the impression that the more common term to use for this is co-located team (A quick scan of google I think corroborates this impression. Googling “same-place team” I get no results, versus the pages of results I received when I google’d “co-located team”.  But not a key point, it is understood.)

After the “Why Virtual Teams” chapter the book does become more helpful. The section on steps for communicating with virtual teams includes “planned spontaneity”.   Agreeing regular times to talk, and everyone knows we will be on the phone or online at such and such a time. Also open for chatting online times which can substitute for the “gathering around the water cooler scenarios”.  Also it includes key items such as agreeing, do you expect someone to respond to an email that you send on a weekend? 

Another important key scenario the book did address is when some workers are co-located and some are virtual, which is a very common situation.  Or even multiple co-located members and multiple virtual members. Sometimes it is easier to manage a virtual team when all team members are virtual than when there are multiple co-located members. It is easier for team members to care about their other co-located members than to worry about the team members located elsewhere.  The individual remote members will be more interested to know what is going on in the different locations because they are usually working “alone”, whereas the ones who are working with a team of two or more in their location, they will tend to be less active in worrying about who is in the other locations.  For these situations the book makes suggestions of how to ease the “isolation” or remote members and get the co-located members involved in helping with those situations. 

Other points I like about the book; I do like the “scenarios” which involve asking the reader what they would do in a particular situation (very realistic situations) and the mentors (authors) provide answers in the form of “what you could do”.  I also like the “Test Yourself” chapter at the end of the book under Tips and Tools.  It is better than most of these “tests”, the scenarios are more details. 

Now on to what I do not like about this book. Again and again I see this in virtual team books, the suggestion that the first meeting with a team, if at all possible should be face to face.  But rarely, if ever, have I seen suggestions of how to do the kick-off meeting if you and your team are in the more common situation of, we can’t do a face to face kick-off meeting, but we still have to start the project somehow.  Where are those suggestions? In this day and age most of what can be done face-to-face can be replicated with online tools. It may take more online meetings to replicate the face-to-face, but it can still be done.  Additionally the Tips and Tools section includes a section of “document layouts” to use for contact information, setting up a virtual team, identifying roles and responsibilities, etc.  The documents, in and of themselves, are just fine and useful, but I would think, given the fact that this was written just recently, that these would be translated now in to an online form and shown that way.  However, this may have to do with the fact that when I look at the references at the back of the book, there is only one article from 2006, most are from around the year 2000.  And the latest source for the book is 2000.  Technology and its use in virtual teams is not a strong suit for this book.  Hence the book was “compiled” recently, but based mostly on old sources.

The idea of a pocket book is one that you can quickly refer to for helpful hints or lists, etc.  (Well besides being one that you carry around in your pocket!!)  Is this, that kind of a book?  No not really. It is a good quick read if you are new to virtual teams.  The scenarios are helpful, the “test” of your knowledge of virtual teams is good, but could you refer to this book again and again.  I think not.  You are better off to make use of the “Quick Guide to Interaction Styles and Working Remotely: Strategies for Leading and Working in Virtual Teams” –

“Leading Virtual Teams – Expert Solutions to Everyday Challenges”
2010 Harvard Business School Publishing

Categories: Book Review, Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |


Book Review – Cloud Security and Privacy – An Enterprise Perspective on Risks and Compliance

Comments (0)

The authors of Cloud Security and Privacy recommend this book for technically savvy business persons who are thinking about using cloud computing and are interested in protecting their information and are wondering about any security concerns.  This is probably the perfect audience for this book, as well as it can be used by business persons who not as technically astute but who are interested in how cloud computing could be used by their business and what issues there may be with it. They can get an idea of the questions they should be asking (which of course technical people are going to love…..).  It also is a book that can be used as a reference, even for technical persons, parts of it include best practices on securing virtual servers.  If not familiar with that, this book can be a good reference, won’t give the entire how to’s but can introduce many of the security areas. 

Since the “cloud” is a moving target, probably parts of this book can be considered out of date already since it was published in September of 2009, however, if you want to know what the cloud is, how the “industry” defines the evolution to the cloud and to learn how or if your company could benefit from it in a realistic manner, this is the book for you.  If you want to know what the cloud is just out of curiosity, this book is way too much for you. 

Cloud computing puts more decisions in to the hands of business people, rather than IT, I am sure we have all heard that before (about earlier forms of Cloud computing – ASP’s, etc.), but a good example of where this has been true has been with the use of SaaS (Software as a Service – which is now considered to be a Cloud service). A wide range of companies; large to small, are already using cloud services such as As well, a large number of small and medium sized businesses are using Intuit’s online QuickBooks service, so more companies are already “in the cloud” than probably realize it. From this book these same people can learn more about the other types of cloud services which may be applicable to their business as well.  

There are still a lot of definitions floating around about what is “the cloud”, and experts still do not agree so the book lays out what may be one of the commonly accepted definitions, or not, but at least it gives a basis for the rest of the book and the range of what will be discussed.  What can be mostly agreed upon by experts with regard to cloud computing are the accepted attributes of the cloud which must be: 

1. Multi-tenancy enables sharing of resources and costs across a large pool of users thus allowing for:
2. Massive scalability – has to allow for massive scale in both compute power, bandwidth, storage. Meaning the ability to scale to thousands and thousands of machines, the type of size that you need if you are an amazon or google and that you needed to build for yourselves, now making that available to others.
3. Elasticity – Users of the cloud must be able to rapidly increase the amount of resources that they need, and then release those resources for others to use when they no longer need them
4. Pay as you go – Traditionally for getting your app out you paid a set price, and often paid for more than you needed, or usually needed because you were building yourself or buying what you would need for peak times
5. Self-provisioning of resources – users can use what they want to use for storage, cpu power, network resources

Also important to define is the three types of Cloud Service Providers (CSP’s); IAAS (Infrastructure as a Service), SAAS (Software as a Service), and PAAS (Platform as a Service). 

Chapters 3 and 4 discuss specific areas of security; infrastructure and data security and storage.  There is a good breakdown for the different types of CSP delivery methods and the different types of security.  The authors make it clear though that many of the security issues are not specifically caused by the cloud and they may or may not be exacerbated by cloud computing. 

A great point of the book is that it emphasizes what the CSP is responsible for, and what the customer is responsible for and where it is still questionable who is responsible for what. This is emphasized throughout the book.  So depending on the service, for example the SAAS model such as or Google Apps, it explains what is responsible for, and then what the customer is responsible for such as operational security (such as user and access management). It also goes in to detail as to what type of security review the customer should do of the vendor such as:  requesting information about the provider’s security practices.  This information should include their application security testing, release management, authentication and access control, etc.  Although to date much has already been written about what type of review an enterprise should do of their SAAS providers practices.  But the sections for the IAAS and PAAS providers will be interesting as well. 
Good points in the Platform as a Service (PaaS) delivery model includes software vendors such as:  bungee, Eucalyptus, CSP’s such asL Google App Engine,’s, Microsoft Azure, etc. In the multitenant PAAS service delivery model, the main security issues are containment and isolation of multitenant applications from each other.   Since applications are developed by the customer, the customer is responsible for application security.

One of my favorite chapters is Chapter 6 – Security management in the Cloud.  After taking the reader through network, host, application, database, storage and web services which include identity services, this chapter steps though understanding the scope of IT system management and monitoring responsibilities that fall on the users shoulders including: access, change, configuration, patch and vulnerability management and those that are the responsibility of the CSP.  

The authors have reviewed the disciplines for common security frameworks such as ITIL (Information Technology Infrastructure Library )and ISO frameworks and they have identified the relevant processes and the recommended security management focus areas for securing services in the cloud including availability management (ITIL), access control (ISO/IEC 27002, ITIL), etc.  So those that are familiar with these processes will find that they know most of what is in this chapter, but if your organization does not yet use a security management framework they will understand the pros and cons of using one.  But it is good that they took standard security frameworks and based on that same terminology pointed out which ones a CSP would have to think about, which ones a user of a CSP has to think about, etc.  

The authors also have identified what security management processes which they feel are relevant to the cloud, the full list is available on pg 113.  Table 1 is a good chart of the security management functions for each type of cloud deployment/SPI.  
A good point that the authors make, that they feel is relevant to cloud computing is that organizations (people and processes) and information systems are constantly changing.   Management frameworks such as ITIL will help with the continuous service improvements that are necessary to align and realign IT services to changing business needs.  So for example this could mean that continuous service improvement means identifying and implementing improvements to the IT services that support business processes such as sales force automation using a cloud service provider.  Security management is a constant process and will be very relevant to cloud security management.

Chapter 8 on Audit and Compliance also does a good job defining what the CSP is responsible for; good list for the users of CSP’s to understand.  For example within Asset management, access control – data protection/segregation/encryption.

The author’s make it clear that audit and compliance are big issues when working with outsourcing vendors as it will be with cloud service providers.  I would have like dot have seen a chart or something which would have shown: what a user needs to think about when using a cloud service provider and what you would not need to think about any more.  i.e. is it a new issue that you have to think about because you are working with a CSP, or do you no longer have to think about it, or does the CSP have to think about it now?   What would be avoided security issues, what would be the new ones, which ones are the same?   

Ongoing this book can be a great reference for operations managers or business owners or managers wanting to know what research how the ‘cloud” can impact their company.  Conclusions in a lot of books can be “weak”, this one is definitely not weak. It is an excellent summary of the security concerns that are applicable to cloud computing. One could read chapters 1 & 2, get an overview of cloud computing how it has evolved and then actually read the summary, get an overview of the issues and then read the appropriate chapter for the type of security concerns. 

Cloud computing events are still hot and heavily attended.  I was just at another on the 13th of April in Palo Alto, California, which included panel members from SAP, Citrix, T-Systems, and AT&T there was a lively discussion of what people are looking for with regard to cloud computing: on demand computing, as needed consumption of compute power.   Models that they are seeing, dominate capacity in-house yet, elasticity is rented out (bursting in to the cloud as needed).  If you are trying to use cloud services for disaster recovery, for example, or contingency purposes, there are still some issues such as getting a VERY large database server up immediately, transfer rates not there yet.  Web servers can be up immediately, but a database server can be brought up only a day later when the data arrives by disk.  Cloud Interoperability has claimed to be a major issue of cloud computing, since there is still no reason for the cloud service providers to work together.  However, the guys on the panel claim it is not a problem.  In reality I would have to agree with this, depending on what you are running in the cloud, and how it was architected you can technically move clouds.  More of the issue, as with most business decisions, is how much effort will it take, as any move requires some effort, and how much will it cost. 

Cloud Security and Privacy – An Enterprise Perspective on Risks and Compliance
By Tim Mather, Subra Kumaraswamy, and Shahed Latif
Copyright © 2009

Categories: Book Review, Cloud Computing, Outsourcing SMB's |


Review – Iterate or Die – Agile Consulting for 21st Century Business Success – By Eric Berridge and Michael Kirven. 2008

Comments (0)

Certainly the reason for this book is for promotion for the company which the two authors started. The slogan, “Iterate or Die” became the bywords for their new consulting company, guiding how they wanted to provide their services; short projects, rapid deliverables, etc. 

But can we still learn something from this book? 

Probably yes probably, but the reader has to realize the following first:

  • The book was published in September of 2008, probably written a year before that at least, thus dating some of the comments,
  • The authors are pro outsourcing,
  • To the authors, the difference between outsourcing and consulting is that outsourcing cannot provide a business result,
  • The authors do not like offshoring because they believe it cannot include consulting or business changes,
  • They do not like big consulting firms,
  • They do talk heavily about SaaS (Software as a Service) being the wave of the future (for the date of when this book was written, probably 2007 time frame, it still seems like a dated statement),
  • Their firm is a certified implementer of
  • They feel they set out to establish a new kind of business and a new philosophy that no one was doing (which is the usual case when starting a new firm),

If you can live through reading these types of comments which are scattered throughout the book, you can learn something from the book.

What I like from this book:

1)      Certainly the basic premise of applying the agile development methodology to the consulting industry.  Actually most of what they talk about can be applied to a software development project or a business process change project.  Concepts such as time boxing, for example, changes can be accepted if they can be completed within the original time box. Otherwise the change needs to be moved to the next iteration.

2)      Appendix A contains their company’s list of “Laws of Consulting Economics”.  Of particular note include the following laws:

a)      2nd law of consulting economics – “A successful business process trumps cool technology”. they talk about this from a standpoint that every company should have a Chief Process Officer –
CPO.  This person is responsible for the business processes of the company (a business process is a series of tasks or operations that perform what is consider a logically complete unit of work. 

b)      The 8th rule of consulting – When it comes to success, communication is everything!

c)       The 9th rule – The concept of having to rely on a “Great man” to come in and save the day, or some heroic effort to make the whole thing work.  Which they say rarely works, and I would have to agree with that. 

3)      The authors refer to a “New Staffing Model”, which is geared towards a particular business outcome.  My first take on this was I thought the consulting industry had already moved to this model long ago, but I guess what the author’s are referring to is the “staff augmentation” business more so, and that industry needs to be more about what the client is trying to achieve rather than I need one person to be a data base administrator and a 2nd person who will be a systems administrator, and so on. For that industry I would agree that that is a mindset change on the part of the buyers of those services, but one that is necessary. 

4)      Overall the book outlines a repeatable process that readers can base their own projects on.  Appendix E includes Sample Success Plans that can be modified for the reader’s own needs. 

Some points that I thought were interesting:

1)      The author’s example of the 21st century consultant– sharing one Database Administrator’s (DBA’s) over several projects.  Not sure why this is a novel concept exactly. 

2)      On page 51 the author’s refer to the question, “Why do companies which need to use IT seem to have to transform themselves in to major IT organizations?”  The idea that you would not generate energy if you did not have to, it assumes IT as a commodity. There is little business sense in diverting funds that should support a company’s core competencies into a major IT infrastructure investment (Perhaps if this book had been written a bit later they would have said that this would be a reason to use cloud computing, as this is one of the common arguments now given for “putting your apps in the cloud”.)  My question is; I can’t believe that this argument is still being used to tell companies that they should outsource.  Aren’t there any newer arguments that could be used

3)      On pg. 72, the author’s state that Agile consulting, as they practice it, will reduce the need for offshoring?  Only because they say Agile cannot be done in a distributed manner.  On this point they do not offer any examples from their experience or the experience of others though. 

Overall there is not a ton new in this book necessarily, but the look at the overall concept of taking the Agile Software Development methodology and crossing it over to the consulting industry is an interesting one, the consulting laws are good points and the success plan outlines are helpful. 

Iterate or Die – Agile Consulting for 21st Century Business Success By Eric Berridge and Michael Kirven.  2008

Categories: Book Review, Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine |


Book Review – “Multisourcing: “Moving Beyond Outsourcing to Achieve Growth and Agility”

Comments (0)

Multisourcing is not necessarily a new term, but since it is appearing more and more in the media, I decided to check out the one book I could find on the topic on Amazon; Multisourcing:“ Moving Beyond Outsourcing to Achieve Growth and Agility, which was published already in 2006.

What did I understand from this book about the term, multisourcing? The author’s official definition of when a company is engaged in multisourcing is: An enterprise consciously and proactively acknowledges, plans and manages the interdependency of internal and external service providers. As an example:  a company outsources to a service provider benefits and payroll processing (a common item to outsource), this service provider is dependent on IT infrastructure services provided by another provider, and perhaps a custom software application written and maintained by a third service provider (if the benefits and payroll service provider does not use their own software application, but yours).  The data needed for use by benefits and payroll is provided via a data warehouse maintained by an internal business intelligence center but managed by internal resources in the finance department.  Multisourcing is managing of this mix of internal and external service providers.

For more specific examples I also learned that a company is engaged in multisourcing when it:

Has an office which centrally manages outsourcing engagements; everything from what should be outsourced or done internally, where it can be outsourced (onshore, offshore), what are the expected outcomes for each service, negotiates contracts, manages the vendors and so on., and you do not allow different departments or different persons within your organization to decide what to outsource on their own and how to manage the process on their own.

Outsources (either internally or externally) more than one service or part of its business (it could be to the same provider).

  Manages outcomes and not how something is done. 

Puts some thought in to the best way to receive each of the services (HR, payroll, data network, customer support, etc.) needed to run your business.

Manages the relationship between Service consumers, Enterprise, and Service Providers

So what is different about multisourcing? According to the authors it is in how multisourcing is managed. To give an illustration, the authors look at how products are typically outsourced versus how services are typically outsourced.  Typically with the sourcing of manufacturing a company will specify the outcome to be achieved.  For example, I want x number of this type of part and it must meet these specifications, but the buyer does not say to the sourcer how many persons need to be involved in making the product, how many lathes to use, how much energy needs to be expended, etc. (Well at least they do not do this if the provider is not exclusive to their company.) The buyer will leave the details up to the provider.  But in services this does not always happen. I believe part of this is the nature of outsourcing services versus outsourcing products. Also typically the first stage of outsourcing for many companies is just seen as the movement or replacement of people from one location to another, so the buyer wants to say how things will be done exactly, they are not ready to give up that control. The authors are trying to get the readers to realize that giving up that level of control does not mean that you, as the buyer, do not get what you need, nor that you do not have to do any managing. You manage the outcome, i.e. what is the outcome that needs to be achieved when outsourcing customer support; clients need to be satisfied with the support services, client issues have to be closed, etc., but every detail of how that is done does not have to be dictated, and if you do dictate every detail you may be losing out on the enhancements and improvements that you could be achieving.

The author’s also put extra emphasis on outlining how to establish good governance and who should be involved with it. I liked the chart on pg. 125, which defined the competencies needed for managing multisourcing. It can be used for assessing your personnel who may be working in your sourcing management office or for assessing yourself as to what skill sets you need in order to be in sourcing management.

After reading this book, I am not certain that multisourcing is so different from the term strategic sourcing[1] which is also a very common term. Gartner defines strategic sourcing as “the dynamic delivery of internal and external, business or IT oriented resources and services to ensure that business objectives are met.” Perhaps it is true that when talking about strategic sourcing it is most often done so with reference to IT related services. That could be because these service areas have been fast growing in terms of outsourcing, or because these service areas are seen as ones where a buyer can receive enhancements from outsourcing and not just money savings (referred to by the authors as efficiency improvements). A service like payroll has been outsourced by companies for years and years, but it is usually not mentioned in books or articles referring to strategic sourcing because payroll is usually not seen as being a strategic area for a company. I believe what the authors are trying to get at is that multisourcing takes a broader look at all services that a company needs and determines how they should be delivered; whether that is internally or externally.

What I see as the main difference in reading this book versus reading a book on developing a sourcing strategy is that many of the books on strategic sourcing will typically revolve around one or two of the services that a business usually needs to have done in order for the business to be successful, such as: customer support, or software engineering or accounting. While this book on multisourcing focuses on looking at all of the different services that a business needs to have fulfilled and to think about the best what to have those services delivered; internally (domestic or offshore) or outsourced (domestic or offshore).

So does it pay to take a look at this book on Multisourcing? Overall the process that is defined in the book, how to evaluate the different services within your company and how to develop your sourcing plan is laid out well and if a company goes through it, they will end up with a good plan. If you do not yet have a plan on how to do that in your company, you can use the outline in this book which is defined over several chapters. Also if you are looking at developing a sourcing management operation, Chapter 4 is good for defining who to have involved in sourcing management and how to go about the process. 

Next month I will be looking at a recently published book on Outsourcing: Outsourcing and Offshoirng of Professional Services “Business Optimization in a Global Economy“ by Amar Gupta

To take a look at the book reviewed here:

Multisouricng – Moving Beyond Outsourcing to Achieve Growth and Agility

Linda Cohen and Allie Young

2006 Gartner, Inc.



Categories: Book Review, Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, startups |


Book Review – “101 Leadership Actions for Creating and Managing Virtual Teams”

Comments (0)

The structure of this book is not new; i.e. one page or a page and a half per idea, but it fits very well for busy managers. I have recommended other books about virtual team management that give ideas that can be quickly implemented, “101 Leadership Actions” is definitely one of those books. You could pick up the book and open up to almost any page and find and an idea that you can implement in part or in whole for your virtual team, but you probably will not want to go through the book in that manner. Perusing the table of contents first will tell you where to start.

I found the first useful suggestions for my own work with virtual teams in the very first chapter, with something so simple that I can’t believe it I have done it before, or thought of it in such a simple manner. Leadership Action #10, Identify the Benefits of Virtual Teams, in and of itself does not sound new until upon reading further the suggestion is made to have the team itself think of why working virtually is going to make them a better team; why not being co-located is going to make them a better team. Often virtual teams which come together for a specific project may do this type of team start-up process, but think of the virtual team that develops more gradually; most development is done in one US city and then they hire an offshore person who works alone in another country, and then they add another one several months later and so on. These teams often have a harder time of thinking of themselves as virtual and it would be a great quick question to ask during a conference call status meeting, So what does everyone think the benefits are for our team now that we are virtual? It puts the responsibility on everyone to think of what the benefits are, not just the manager. Some suggestions that are made that will be helpful are actual helpful for any type of team, not just a virtual team, such as #18 “Regularly redesign your meeting structure”. Which suggests moving the team agenda around so those persons who speak always at the beginning of a meeting know they can tune out after their turn, or those who always speak at the end can sleep during the first half of the meeting. It is a great and simple suggestion to shake things up once a while so people stay awake. To give you an idea of the number of actions which you may find useful from this book, below is a chart of the number of actions I thought I could put to use or put to better use within the teams that I manage:

Chapter # of useful actions
Strategy and Virtual Teams 1
Structure and Virtual Teams 2
The Practices of Virtual Teams 6
The Tools of Virtual Teams 2
Managing Virtual Teams 3
Technology and Virtual Teams 2
Systems and Virtual Teams 0
Total: 16

The result is that I found 16% of the actions immediately useful, not bad for a book that took maybe a couple of hours to read. You may find more or less similar results. Note #80 and #86 are two very useful actions which I continually stress to managers of virtual teams and they cannot be repeated often enough; #80 “Make the Transition from Managing Time to Managing Projects” and #86 “Use the Phone More Often”. I would recommend this book to anyone managing a virtual team as a good resource which will provide immediate ideas that can be incorporated to make your virtual team run better.

101 Leadership Actions for Creating and Managing Virtual Teams
By Ollie Malone, Ph.D
Copyright © 2004

Categories: Book Review, Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Virtual Teams |


Collaboration 2.0 – A book review

Comments (0)

While not news for many of us, much of what is driving the developments in Collaboration and the developments in collaboration tools is the necessity to create a Virtual Team space (VTS).  Early in the book the authors define 10 trends in collaboration, the most interesting to me is the trend which they call, “Presence Everywhere” which means being able to detect which involves basically being able to quickly find a person whether they are online or on the phone or in a conference room. A typical scenario as to when this may be useful is given (and I am sure a familiar one to everyone); A and B are working together via web conference and they need C to help solve an issue. Typically one or both A and B will be looking through their buddy lists to see if C is available online, if not both may try calling C via various numbers; office, cell, etc., and if they are finally successful in finding C it may take several clicks of sending links to bring C in to the web conference. IBM is working on their Sametime product to have this type of capability to reach external contacts. LiteScape also apparently has ways to detect the availability of users not only via instant messenger buddy lists but also from your list of outlook contacts and detect their presence via mobile devices.

If you were not already familiar with the term, the book introduces you to mashups as another trend in collaboration. A mashup is the process of creating a hybrid application built from data or functionality found across a number of different applications. An example of this can be seen in a site listing real estate, for example, which uses a 3rd party site or application to provide information about criminal activity in or around the house which is for sale.

There is no shortage of collaboration tools which the book introduces you to such as TimeBridge which can help you schedule meetings faster, but a great part of the book is the emphasis on the human aspect of collaboration. As they say, collaboration is 10% tools and 90% people.
The second half of the book takes a look at the human side of collaboration with chapter 7 specifically focusing on virtual teams. A very good point is made at the beginning of the chapter that the challenge has traditionally been how to minimize diversity among the people on teams whereas the key in the future will be to embrace the differences and work with them. I agree with this whole heartedly and would extend this to all aspects of working in a distributed manner, for example – time differences, location differences, etc.

Chapters 8 through 14 also focus on different aspects of people and processes. A lot of what was written was review on how teams work, it will most likely be review for a lot of people. What I found funny was, for example in Chapter 9 on Interpersonal communication, the author mentions how important Mirroring/Identifying is in building report, but he doesn’t go in to the next step of how you do this when using collaboration tools.

Chapter 15 is supposed to bring it all together; the human side and the technology side, but I found it a bit lacking. It talked more about the different stages a company may be at in using collaboration tools, and why they may have problems implementing them, but it did not seem to go that step further and talk about how to overcome the actual road blocks to working with distributed teams and actually using the technology.

In general this is what I thought was lacking in the book overall; actual examples or case studies of the use of tools and use of team interaction processes to overcome problems. On pg. 194, the authors discuss the work of one of their clients, and I agree it is an excellent example of an operational agreement between two distinct agencies. There is a lot of detail there, however, there are very few other real life examples given in the book. Adding additional examples and case studies, which I have no doubt the authors must have from their consulting practices, would have made the book much stronger.

My first thought with this book is that it is especially good for larger companies which are working with a number of collaboration tools, or looking to implement them. However, chapters 1 through 6 which relate to the different technologies that are available, as well as the appendixes listing a number of different technologies, can also be very interesting for smaller firms which are often working virtual from the very start of their existence. As well, for most anyone who reads this book, unless you are a study of collaboration tools you will most likely be surprised at the wide range of tools available and perhaps at what is considered collaboration technology. As far as functionaries who will appreciate this book; marketing folks can certainly get a number of ideas for tools that they can use to do their jobs better, software engineering folks, and anyone who has to deal with remote teams on a daily or almost daily basis will benefit from reading this book.

Collaboration 2.0: Technology and Best Practices for Successful Collaboration in a Web 2.0 World
Authors:  David Coleman and Stewart Levine
Published: January 2, 2008

Categories: Book Review, Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Virtual Teams |


Book Review: Offshoring Secrets

Comments (1)

Offshoring Secrets. Building & Running a Successful India Operation
By Utkarsh Rai.

In recent years I have read a number of books about offshoring, outsourcing, offshoring to specific geographical locations, etc. Offshoring Secrets falls in to the latter category, with the emphasis on setting up operations in India. This is the first book that I have read where the author specifically states that one of the primary targets for the books are Indian’s (and others outside of India) who are tasked with setting up Indian operations for multinationals or other firms coming in to India. There are probably other books out there, but I have just not read them yet.

Keeping the intended targets in mind I set out to see if anyone involved with outsourcing could learn from this book and how much a person would learn concretely about setting up operations in India.

To start off in the Preface of the book, the author lists the types of questions which can be answered by reading this book, questions such as: My manager has asked me to setup an India center to save costs, but I am not achieving any remarkable savings within the stipulated timeframe. What am I doing wrong? I like the structure of all of the questions and most of the questions that are listed are very specific rather than general. But as I went through the nine questions that this book is supposed to answer, I found myself putting them in to two categories; 1) Those that would apply to any project any where and 2) those that would apply to any offshore location. Out of the nine questions I put 3 in the any project category and 6 in the any location (or country) category.

I found more specifics that can be applied to any offshore location, with a few specifics for India only, such as the following:

The section on choosing the location of the facility; the smaller your operations will be, the better it is to be located in the city center or to have a central location so that the average commute time is less, thus giving an advantage in hiring. Where as larger operations can be located outside the city since larger operations can afford to finance transportation for their staff to help people get to/from work. This is true in many other offshore locations as well.

The formation of the support team is also relevant irregardless of which offshore country, as is choosing the right work to start with, both of these areas are critical to the success of any offshore venture, with which I wholeheartedly agree. 

No one will disagree that India certainly has some nuances currently with recruitment; receiving 1000 to 10000+ resumes from a single advertisement certainly does not happen every where, but the ideas of how to and where to source can be applied in almost any offshore location. Different types of interview processes described, are standard interview processes used most everywhere (in the west as well, so this is relevant just to those new to the hiring process and how to conduct it).

Chapter 5 is dedicated to culture. Some of the issues discussed can be seen in other offshore locations, such as the issues of sharing salary information and benefits. The fact that people join companies for social reasons as well as for salary, etc., is also not associated only with India. The fact that it is a culture which values seniority to the extent that it does is probably more unique to India than other offshore locations, but can be seen to some extent in other offshore locations as well. The description of India as a “Difficult to say No” culture, is also one of those traits more unique to India than other locations, but also can be seen to some extent in other offshore locations as well.

Issues of how the parent company deals with the offshore company or the team in India, this can be true irregardless of the offshore location. The discussion is useful since it gives suggestions on how to mitigate these issues.

The chapter on People Management, chapter 6, I did not find unique, most of the discussion dealt with issues that one would have to deal with anywhere, so this chapter is most relevant for the new manager.


Chapter 7 brought up something which I thought was a bit ironic for a book about offshoring and therefore about distributed work. A situation was described around what to do to make the execution of work successful. Per the author’s suggestion, the development team and the test departments should be co-located together in an open environment in order to facilitate interaction; otherwise there could be problems between the two groups. Well most likely for any manager anywhere, who is reading this book and is charged with setting up facilities, this would be an ideal situation. But most managers are also realists and the nature of offshoring and outsourcing work tends to mean you work with distributed teams. In many instances the testing team may be located in one country and the development team in another and the testing department just may motivate themselves by sending an email to everyone in all teams talking about a big bug they just found right before the go live date. This may be seen as de-motivating or like the test department is rubbing it in their faces, to the development team, but this situation may occur and it just may be out of your hands if you are the manager of the development team. You can only worry about your team and how to keep them motivated and you have to be able to deal with these situations that arise in distributed teams. If you can’t deal with these situations then it is reminiscent of the reasons for not offshoring such as; we can’t offshore software development, we need everyone in the same location, and this is obviously not true. So any new manager reading this book will have to be able to deal with the fact that they may not have a choice as to having the test and development teams co-located, and they may just have to learn to deal with it in this global world.

For both Indians and others reading this book, it is good to keep in mind that many of the specifics which are talked about; details to look for in rental agreements or what type of legal documents you will need to establish the Indian entity, can be expected to change in India as laws change. As in most of the developing countries, laws change rapidly; exact documents needed change frequently, etc., that is just to be expected.

If you are Indian or from another country and you would like to eventually be able to set up operations for a foreign firm in India, and you are new to the outsourcing industry and all of the administrative and people management issues, this book is a must read. If you are an experienced Indian manager or an experienced manager from another country and you are charged with setting operations for your company in India; chapters 3, 4, and 5 will most likely still be interesting for you. If you are a new manager and you are going to be managing for the first time, a team for a foreign firm in India or in another offshore location, you will find parts of chapter 4 and 5 relevant and chapters 6 and 7 (which will help in dealing with the parent company and in setting up the projects for success) relevant.

Categories: Book Review |


“Managing without Walls” – a review

Comments (0)

The case for many workers in the US and around the world is that they have been working in virtual environments for some time now. The virtual environments may vary; from completely virtual where the person is working independently from home or a small office and rarely sees the people face-to-face, that they work with on a daily basis. To other environments where the worker is in an office with one part of their team and other parts of the team are co-located in one or more other locations. Whatever virtual situation you may be in, if you are managing a virtual team and are fairly new to it, then “Managing without Walls” can help you. 

I usually think I am doing a bad job of managing remotely if I have to continually be up both early and up late to talk with the team (I deal with a 10 hour time difference to Ukraine). One or the other is okay on a daily basis, but not at both ends, unless there is an emergency, then sometimes this type of constant connection is necessary. Chapter 12 gives some insights in to managing emergency or high-risk situations in a remote situation. The natural instinct for the one person who is remote (a lot of times the manager) is to want to be on the phone all of the time getting continual updates. But this often interferes with the other side being able to get the work done to handle the disaster. At the same time the other side has to be willing to communicate more often to explain the status of what is happening. The chapter outlines good suggestions for how to handle communications during an emergency situation. Other issues touched on in this chapter include risk planning. For example; planning for personnel issues such as when one employee leaves and starts recruiting others to join him/her, public transportation issues which can affect teams in the US, and be also disruptive to teams in other countries where public transport is the chief means of getting to work. I love this statement which should help anyone kick start their risk management plan; If the things you are concerned about for your project never change, it is like continuing to worry about your 12-year old concerns when you are 55! This is not a very effective or a good use of your time. It suggests that little progress had been made in the meantime. (pg. 318).

If you are new to managing virtual teams, especially helpful to you will be Appendix A, The Virtual skill set checklists which will help you analyze in what management areas are you ready to manage a remote team and what areas do you still need to work on. Unlike many other books on managing virtual teams, the book does not emphasize the areas where managing a remote team is different from managing a co-located team, save for two areas; the politics of a virtual team and managing conflict within a virtual team.


Whether you are brand new to managing virtual teams, or have been at it for a year or more, a project manager will find something new in this book, just read it though by picking out the chapters most relevant for you. 

“Managing without Walls”, by Colleen Garton and Kevin Wegryn,  Oct 2006.

Categories: Book Review, Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine |