Archive for the ‘Outsourcing SMB's’ Category

« Older Entries
Newer Entries »

Here goes a review practically longer than the book!

Wednesday, February 23rd, 2011

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” -     http://www.amazon.com/Quick-Interaction-Styles-Working-Remotely/dp/0971214476/ref=cm_cr-mr-title

“Leading Virtual Teams – Expert Solutions to Everyday Challenges”
2010 Harvard Business School Publishing
http://tinyurl.com/5vbnhhs

Tags: , , ,
Posted in Book Review, Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams | No Comments »

How do we get remote team members to take responsibility?

Thursday, January 20th, 2011

How do we get remote team members to take responsibility? It is a common enough question, but is there really a difference for getting this done for remote team members versus team members who are co-located with you. I don’t think it makes a difference. How you do this is the same whether the team is co-located or whether they are remote. The issue is usually having a good management process.

Tips for helping to get your team to take responsibility:

#1: Clearly define who is responsible for what tasks. It is great to have a meeting with the whole team, discuss all of the tasks, what needs to be done, etc. But don’t end the meeting without clearly stating who is doing what. That can be done by having team members volunteer to take on certain tasks which are within their skill set, or “volunteering” someone if necessary. Every project/every task needs an ultimate responsible person.

#2: Clearly define when a project/task is due. This due date may be set because of outside forces; a promise to a client, a government requirement deadline, or other. Or you may have the opportunity to give the responsible person time to look closer at what needs to be done and to estimate the time it will take to get the task done. If that is the case, set a deadline for when the estimate needs to be done.

#3: For longer tasks, periodically check in to see how it is going, rather than waiting until the final due date for the whole project. Many managers do not like to do this because they feel it is micro-managing, or if they ask, they ask a very “generic” question such as, “how is it going?” which often elicits a standard response of, “ok”. How the “checking in” is perceived and how effective it is, depends greatly on how the question is asked. Common ways people ask about tasks include, “did you finish xyz task like you said you would?” which gives the impression that you are already thinking they could not have finished the task. Or a manager may go to the other extreme and just ask generically, “how is it going?” which may elicit just an “ok”. Try instead, as the project is going on, asking about specific tasks, “How did that research on xyz tool go that you needed to do? Did you find out what you need to?”. Asking in this way can help you get more information and more of a feel for how things are going rather than putting someone on the defensive.

#4: Make sure there are consequences for missing deadlines. Don’t let missing deadlines become a habit. There may be valid reasons for a deadline to be moved; a requirement absolutely needs to change, chosen technical design won’t work, etc., but in these cases the deadline should be moved before the original deadline is reached. The responsible person should know that the deadline needs to be moved much earlier, not at the last minute.

As the manger of a remote team, you are responsible for making sure that your team is as productive as possible. It starts with you. Being clear with what needs to be done, by when, and by whom, and then holding team member responsible, goes a long way towards making your team very effective.

Tags: ,
Posted in Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams | 56 Comments »

Do we choose based on location?

Sunday, December 19th, 2010

It had seemed to be a trend for quite a while to worry less about location, and be more concerned with what the vendor can provide you with and do for you.  A recent article in CIO magazine confirmed this  with the CIO stating very clearly that they chose their vendor two years ago, not based on location (the location was China) but based on the fit of the vendor with their company.  “Our selection was based on the qualities of the IT services partner and whether they met our specific criteria rather than the location of the delivery center,” according to the CIO.  But still I have been seeing many reports talking about particular locations lately.

So what can you get out of looking at a location? 

Below I look at several areas traditionally used when researching different locations where to work. I list characteristics for each area that may be affected by the country, and how companies in other countries will try to mitigate this being an issue in their country. It may give you something to think about the next time you are looking at who to work with. 

-          Educational infrastructure and levels: 

  • Affected by country:  Types of education offered, traditional areas of education, who gets educated and who doesn’t, overall literacy rates.   
  • How do companies mitigate:  There are ways to replicate necessary IT education quickly.  Companies have been doing this for decades, putting people through express technical training for so many weeks or months. Quickly giving people the skills necessary for competing in the industry. These skills may be good enough to let people go a long way in the industry. 

-          Time zone:

  • Affected by country: This one obviously is affected by the location and can work to the benefit of the buyer; is one location more convenient for you to work with over the other; based on overlap of work hours, or one company workingat one is not going to change. Do you have a specific requirement here

-          Language skills –

  • Affected by country:  Countries can have more education in foreign languages than others or offer complete education in other languages giving people a lot of experience working and living in other languages. Accents can also be affected by native languages; as to whether or not they are easier to understand in other languages. 
  • How do companies mitigate:  Vendors everywhere work to mitigate languages issues by pushing foreign language training (the actual languages will depend on location); both internally and externally. 

-          Cultural fit: 

  • Affected by country:  Differences in style of how management is perceived, speaking up in meetings, giving opinions and suggestions irregardless of level within the company. The educational system and structure can also play a role here. 
  • How do companies mitigate: Company culture can mean a lot and also help to mitigate cultural and work fit issues. 

-          Government support:

  • Affected by country:  Could be in the form of: support for the development of certain industries with lower business taxes or lower personal taxes for specialists in that industry.   Also could be support for education development. Each of these could result in better resources for the industry or lower rates for buyers for example.  It can also get an industry “started” by providing specific support for it. 
  • How do companies mitigate: Government support doesn’t guarantee the “most qualified” resources, and too much support can even affect how adaptable a company is to changes in their government’s support. 

-          Political stability:

  • Affected by country: Political issues that may affect a vendor’s work may include” closing access to foreigners coming in the country, or making it more difficult for foreigners to come in.  Revolution shutting down the work of the government. 
  • How do companies mitigate: Any good vendor is going to develop their strategy taking in to account the political strategy of their country. They will target those buyers to service that are not as concerned about visiting their location, or do not need to visit the location, for example.

Tags: , ,
Posted in Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine | 112 Comments »

Interview everyone first?

Tuesday, November 23rd, 2010

I see this very often when a company is looking to work with a software development team or persons located outside the US;  high on their criteria list will be excellent language skills. This only makes sense. Everyone needs to be able to talk with each other and to make sure there is understanding of what needs to be done and why it needs to be done a certain way, etc.  But what happens many times is that the company will “rank” higher the person/s who speak English the best, and not take a closer look at the other skills needed to do the job; i.e technical skills, professional skills, etc.  Even if technical interviews are conducted.  Everyone likes a good interviewee, one that talks a lot, gives a lot of clear information.  But does that get you the best person for your team and for the work you need to have done.  Many times it does not.  When you are dealing at a distance, is this standard method of choosing who to work with, really the best way? 

Besides often not getting you the best person for the job, with this method, many companies also often have other concerns such as: 

- Someone out of camera range may be helping the person that I am interviewing, telling them the answers, etc. 
- The person I am interviewing may be taking too long to answer; they must not know what they are doing. The company may not be accounting for the fact that the person does have to do some interpreting in their head to make sure they understand what it is you want. 
- Or the person I talked with does not in the end up working on my project, or I never see that person again. Maybe the vendor I am working with put certain people in place for the interview portion, who could interview well, and then I get stuck with someone else.  Of course this situation more often would occur on a very large project, where it is more difficult to keep track of every single person working on your remote team. 

For these reasons, I believe there is a better way, when working at a distance, to choose who is best to work on your team.  How did companies such as MySQL (now Oracle), which had up to 75% of its work force working virtually, never met in person, decide who to work with? They actually saw their work! Most developers who ended up working closely with MySQL were ones whose work MySQL managers and exec saw as the developers were adding code to the MySQL open source code base. A great way to assess the work someone can do, by actually see what they can do!

Strategy for Success:

If you are looking to work with a person/s, or a team in a distant location, try actually having them do some work first.  Look at the code that they deliver to you, for your actual system. A good way to do this is to work with your vendor to come up with a pilot project or a pilot/test period.  Options for a pilot could be the following:

- One person working on several individual tasks, bug fixes or small enhancements for a set time period, one month, two months;
- Several persons working on several individual tasks, bugs fixes or small enhancements, as many as can be completed during a set time period of one/two months;
- Several persons working on a fixed scope of work, with fixed deliverables, with a fixed deadline.

There are many variants which would let you “try out” who to work with, for a short time period and for a reasonable price, that will give you a much clearer idea of who you are dealing with. This can work as well even if your particular product or application has a long ramp up period, i.e. it takes a while for any developer to get up to speed on your code and application.  Feel free to talk with your vendor about different trial periods/pilot projects which will be comfortable for both sides and give you a clear idea of what the developers working on your project can actually do.

Tags: , ,
Posted in Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams | 63 Comments »

I want my team to be more proactive!

Friday, September 24th, 2010

Have you ever thought this about your remote software development team?  I want my team to be more involved, I want them to be proactive, I want them to come up with ideas, etc., etc.  Well there may be some ways that you are unknowingly setting a different tone for the team, (In reality, these issues can come up for both co-located teams and distributed teams; outsourced or in-house).  

Centralized decision making? Do you have a team that has been working with your application for a long time, they are very knowledgeable and can quickly make changes, fixes, etc., but have you centralized the technical decision making?  For example, are all decisions as to changes in the development environment, frameworks to use, database changes (including such things as adding tables, fields, etc.), porting to a new database, etc., etc.,  made centrally, i.e. at the headquarters without consulting at least some of the developers at the remote location (at least the lead one or two persons)? Certainly you can do it that way that is your right as a company to make those decisions wherever you want.  However if you do that, and continue to do it, you are showing several things to your remote team (or your in-house team if you do not include at least some of them in the decision), that you do not respect the knowledge that they have, that you do not value their opinions, and so on. If you do not include them in these kind of decisions how can you expect them to share with you their ideas or suggestions when you are showing them you do not value their opinion on some of the infrastructure decisions for your application?  They may try for a while to make suggestions, but if they continue to see this kind of centralized decision making, without input from others, their enthusiasm may soon die. 

Why you would want to include more members of your team in your decision making process, at least asking their opinion:  Take advantage of the knowledge they have gained, their day to day work with your system may be able to point out where another technical solution may be better, or where the solution you suggested may cause issues in the long run.  It can be done so that it does not add so much time to the decision making process.

So the next time you are wondering why your software development team is not as proactive as you would like them to be, or not providing you with their suggestions, think about how you work with the team when you have research and decisions to be made for your application.  If you make all decisions yourself, or with a small group of co-located people, next time think about including some additional opinions from other team members.  In the long run it will not only help with that particular decision, but will also help with future ideas for improvements to your system.

Posted in Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams | 1 Comment »

Continuing the “I have a feeling….” situations, and how to handle them!

Tuesday, August 24th, 2010

Continuing the “I have a feeling….” situations, there is one more I wanted to talk about which often occurs when working remotely, that is the, I have a feeling something is wrong, but I am not sure what?”  This is a harder to dissect, because it could be anything.  I have a feeling they are not telling me the truth, I have a feeling that they are not telling me something, I have a feeling they are keeping something from me, and the list goes on and on. 

Certainly these feels are exacerbated if you, as the project manager, are located remotely and the rest of the team is located somewhere else.  Or a large part of the team is co-located with smaller groups of people in other locations.

The only way you are going to “resolve” this feeling is by asking questions.  Many managers have issues with asking questions, especially it seems Americans. They often take it as micromanaging. But if you are working at a distance, with people from other cultures, how are you supposed to feel comfortable with what is taking place “over there”, if you do not ask questions.  Beyond asking, “How’s it going?”.  I think we expect to get a lot of information out of such a question, but sometimes you have to ask more pointed questions, like, “Did that design that we talked about work out for the function you are working on?” Or something like, “Did you find a work around for that issue with iTunes?”  These types of questions are not micromanaging, they are questions to eliminate the “feeling that something is wrong”, and make you feel confident that everyone is on the same page.  There is always the good question that I mentioned in one of the previous blogs on how to handle “I have a bad feeling” situation, “Show me where we are, what is done, what remains to be done, roadblocks?”, “Let’s walk through the last/current delivery so I understand where we are.”

In another example, if you have this feeling that, “they are not telling me the truth”.  Without getting too touchy feely, think about when you have this feeling?  Is it when they tell you that the project is going well, and you do not have to worry? I don’t know about you, but someone telling me not to worry, it makes me worry.  I prefer the, “show me so I do not have to worry!”  With most application development projects, developed using an agile development methodology, it should be fairly quick that you can actually “see” something, and know if the team is going in the right direction or not. If not an actual running app, but can you see something from the area in question, a written design, database design, or whatever may be relevant.

In summary for project managers, when you have these “feelings that something is wrong”: Do not be afraid to ask questions, beyond, “how’s it going today?”, until those feelings dissipate. It does not have to take all day, or even take that much time, and it will save a lot of time in the long run worrying about something that may or may not be a problem.

In summary for team members: Realize that managers and other stakeholders, who may be located remotely from you, and even at your location, need to understand exactly where the project is at, and they need you to be proactive and alert them to potential areas for issues.  Asking questions, and offering suggestions about the app being developed also lets the manager know you are thinking about the project, how to create the best app possible, and it confirms your level of understanding of the project and gives your manager more confidence in your skills.

Posted in Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams | No Comments »

Another “feeling” situation and possible ways to deal with it!

Saturday, June 5th, 2010

Today I wanted to continue our discussion on the “feeling” type of concerns when working with a remote software development team.

For dealing with the situation, “He/she said yes he will do it, or he said he understands, but I have a feeling he/she doesn’t really understand,” I believe it can be handled in a similar manner attempting to obtain concrete data to support or not support your feelings. This feeling can be common when dealing with remote teams located in different parts of the world. If people are dealing with English as a 2nd or 3rd language they may not ask as many questions as you would like which would show they are thinking about the request, or that they understand. The person could be not as comfortable with their English skills to ask the required questions, or they could just be quiet in general, or it could be that they are afraid to ask too many questions because in some cultures it would not be good to question the client. Therefore it is going to be up to you to dig in further and help dissipate your “feelings” that there may be a misunderstanding. There can be several ways to start with this. Ask your remote team to “write down” was is discussing during status meetings and send a recap to everyone in the team, after the meeting. Review these notes to see what is understood or where there may be issues. There is also nothing wrong with asking a team member to repeat what they heard while you are in the online meeting or on the conference call, etc. This request can be validated by simply saying that you just want to make sure everyone is on the same page. No one should have a problem with this type of request for better communication. If you are not satisfied with the oral delivery of what the developer is to do, ask them to put it in an email or an IM. These types of steps should help the PM determine if additional explanation is needed for a particular task. If you now believe you have done all of the explaining you can do, and the developer has explained what he/she thinks should be done, you should at least have concrete evidence as to the level of understanding; i.e. here is what I told them they needed to do, and here is what they think they have to do and the two do not match. If that is the case, it may be time to talk with your vendor about the situation. You may need to make a team member change or you, and your vendor, may need to dig in more deeply as to why there is a disconnect. The last step should bring even more concrete evidence one way or the other. Once the developer starts to actually work on the feature or request, you will also get concrete evidence as to whether or not the developer understands what they are doing. More relevant questions should come up, plus you will be able to look at actual code and very quickly you may be able to look at actual results. All of these results will either help validate or alleviate your feelings that there is a misunderstanding.

I have one more “feeling” situation I want to talk about next time.

Tags: , , , ,
Posted in Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams | No Comments »

Avoid the “Do as I say, not as I do” syndrome!

Wednesday, May 26th, 2010

“How do I get my remote software development team to be more productive?”  It is something we all want to do, be more productive. One observation I have made with distributed co-located software development teams (i.e. more than one team located in more than one geographical location) is there can be an attitude of: “Do as I say, not as I do”. This can come from the team that works at headquarters or any team that is working in a multi-team situation.  This situation can apply to both in-house teams in multiple locations as well as if outsourced teams are involved.

We know that all teams working on the same application/product should have the same goal; to make the application the best that it can be and provide the best service to the company’s customers.  What can affect this goal is perception that one team is not living up to that goal, i.e. not being as productive as possible.  And what can affect productivity is the knowledge that there are different rules for different teams, or more specifically the enforcement or said rules.  The rules I am talking about related to productivity may be rules for design, level of design documents, coding standards, conducting peer reviews, commenting, documentation, etc.  I am making the assumption that there is one set of rules for development for the entire system, which most likely there is, every company strives for this.  But productivity, let alone motivation, can go down real quick if one side sees that they have to follow the rules and another team does not. 

It can be hard enough, but not impossible, to make distributed teams feel like they are one team and working towards the same goals, but when one side sees clearly (and in software development it is not hard to see concretely the differences) that another team is not held to the team coding standards (whether they be team specific standards or industry standards), or testing standards or documentation or commenting standards, etc., motivation goes out the door. If everyone is co-located, we tend to more easily enforce standards across a team, but it is an easy thing to let it lapse when there are several co-located teams in multiple locations.  It is easier to dismiss one team as not being productive, and to not delve in to why that may be occurring.

The fix to this issue is simple. Make sure all team members are living up to the standards the team and the company have set for themselves and for the application and system that is being built and supported. There is never any excuse for one team to get away with not following standards because it is felt they have to push some changes through at the last minute always, for example, and therefore never have time to follow the standards. In software development, what team ever has all of the time that they would like?  No team ever does. If it was truly the case where a last minute fix needed to go in, go back and make the necessary updates to meet coding standards, documentation standards, etc (although most teams would let it slide, for the good of the team, if they saw that this was an emergency situation and rarely occurred). Having one team do their own thing, and tell the other teams, well “Do as I say, not as I do”, doesn’t work for teams the same as it doesn’t work for the leaders and managers of teams. Follow the same rules for all team members, no matter where they are located, and distributed teams will work much smoother!

Tags: ,
Posted in Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Virtual Teams | No Comments »

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

Monday, April 19th, 2010

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 Salesforce.com. 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 Salesforce.com or Google Apps, it explains what Salesforce.com 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, Salesforce.com’s Force.com, 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.  http://gaba-network.blogspot.com/2010/04/cloud-computing-2011.html.   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

Posted in Book Review, Cloud Computing, Outsourcing SMB's | No Comments »

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

Sunday, November 29th, 2009

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 Salesforce.com
  • 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

Tags: , ,
Posted in Book Review, Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine | No Comments »

« Older Entries
Newer Entries »