Archive for the ‘Outsourcing Offshore’ Category

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.

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.

I have a “feeling” something is wrong!

Tuesday, June 1st, 2010

We have all had these types of feelings when dealing with people who are located a distance from us.  Or even from managing a project where everyone is co-located.  Maybe it is just part of being a project manager; we are looking for any possible risks that can cause our projects to fail.  Managing at a distance can exacerbate these feelings when you can’t see each other all of the time, or at a moment’s notice when the feeling comes up.  

I have heard this phrase stated in several ways:  

• “I have a feeling they won’t do what I need them to do”,  or
• “He/she said yes he will do it, or he said he understands, but I have a feeling he/she doesn’t really understand.”   Or a more general fear,
• “I have a feeling something is wrong, but I am not sure what?”

I think there are ways to mitigate these risks or feelings that can come up. One of those ways can be to ask more questions and another is to use the work completed as a guide.  

First make sure you feel comfortable with what you have asked them to do and what you are concerned that they won’t do.  Are you concerned that they won’t code something in a certain way?  Are you concerned that if you ask them to make a change they won’t do it? Are you concerned that they “can’t” do what you need them to do?  A lot of these issues are very different but most of them can be addressed by history, if there has been any history of working together, or by asking questions.   For example, if you have not been working together long, and if you have a feeling they won’t code something in a certain way, ask them for a “design” of how they plan to code the feature (for those who are afraid of written documentation, this does not mean they have to write a large document, you are not asking for the world).  This can also be done orally, and if not good enough, ask for a written explanation.  If the design is not what you expected, you have other issues, and you will have to determine and make a judgment as to whether or not the issue is; they did a poor design, it would work, but it is not how you would have done it, or it would work but it is not how it needs to be done for this application.  But at least you will have validated the “feeling” that you had and now you can deal with a concrete situation and not something abstract. 

I will review another one of the “feelings” of concern later this week.

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!

Upcoming Webinar on Ukraine as an Outsourcing Destination

Tuesday, December 29th, 2009

The Central and Eastern European Outsourcing Association will be hosting a webinar on January 13th, on Ukraine as an outsourcing destination. 

The webinar is free, to register:  https://www2.gotomeeting.com/register/765874842

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

Review of the Central and Eastern European IT Outsourcing Market

Friday, August 21st, 2009

For those of you interested in the Central and Eastern European Outsourcing Market, this may be of interest to you.

Earlier this month the Ukrainian Hi-Tech Initiative ( http://www.hi-tech.org.ua ) published their annual “Central and Eastern Europe IT Outsourcing Review 2008″. The research examines key development indicators of IT Outsourcing market in Central and Eastern Europe region: market… volume, number of professionals, number of IT companies providing outsourcing services, cost of one professional for the end customer, etc.
Read More http://itonews.eu/shared/files/CEE_IT_Outsourcing_Review_2008.zip

Disclosure: I did provide a review and feedback of this document before the final version was published.

Can you do Agile development with an Outsourced Team?

Sunday, May 31st, 2009

The quick answer is of course yes! Without really thinking about it we can answer this way because anything is possible, you just have to determine if it makes economic or strategic sense to do it.

Over the next few weeks I want to explore this question further, but before I get in to that I want to pose another question regarding Agile.

According to the Agile Manifesto:  Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

So to me this brings up a couple of questions:

1. Taking this principle in to account, are you still considered to be doing “Agile” development if right before the iteration is due new changes are requested thus pushing back the release date again? If you only release to production once every 6 or so months can you still be doing Agile development?

2. In that same vein, if you request to put off a change request until the next iteration, are you being “un-Agile”?

Another reminder that it doesn’t matter where the person is located in the same country as you or in another country

Friday, May 1st, 2009

Short article from CIO.com, “IT Director Pleads Guilty to Deleting Organ Donation Records”, is another reminder that it doesn’t matter where the IT person is located, they could be located in your office, down the street or at the other side of the world, and still be capable of doing something to your data.  Need to have a process in place, especially when terminating someone to shut down all access, but as well to periodically monitor for all access points for “unusual” activity.

Supposedly the latest on 10 Areas Ripe for Outsourcing…..

Friday, March 13th, 2009

The latest in the list of supposedly new things which are ripe for outsourcing! Unfortunately absolutely nothing new on the list at all. The only good thing about the list is that it does now make a distinction between what areas should be done onshore and what can be done offshore. For example it does stress that parts of integration really need to be done onsite, which is very true. But otherwise a disappointing list.