Archive for the ‘Project Management’ Category

« Older Entries
Newer Entries »

Know your Audience!

Wednesday, July 27th, 2011

Edward T. Hall, an American anthropologist, once said, “Culture is Communication and Communication is culture.”  I usually like to deemphasize cultural issues when relating to software development projects, as it tends to be used as an excuse for why a project can’t be completed or why the project is too difficult to do, however, when talking about the communication portion of culture, I think there are steps that a US software development manager can take towards making themselves more understood and getting their message across, to their development team located in another country.  An important aspect to remember about communicating with a development team in another country is not that they understand or have the right technical skills, and use the right acronyms in the right place, but it is for the development manager to remember the key communication mantra, “Know your audience”.

More people outside the US are exposed to the US culture (either the right or wrong version…..) through American TV shows and films that are widely distributed. However, just because someone knows about Survivor (and most likely their own country has its own version of this show…), or has seen “The Office”, or “The Social Network”, it doesn’t mean they know everything about Americans or understanding American English.  Especially in the US business world where a lot of slang is used, with a lot of references being made to sports which are more widely played in the US than in most other countries (such as American baseball or American football).  When talking with your development team outside the US, it pays to think about what phrases you may be using which may need to be explained. For example, telling your developer he needs to “step up to the plate” when you really want him to take on additional work, may not get you what you want.  Or telling a developer who is critiquing a design choice, not to be a Monday morning quarterback, may not stop his input. Some of this type of conversation comes up in “face-to-face” (be it real face-to-face, or online face-to-face) meetings or these phrases may come out in group emails. Certainly your remote development team will be glad to be included as “one of the team”, just be aware that you may need to circle back and make sure that everything was clear to everyone receiving your message.

Effective communication is not only about choosing the right words and phrases to use, but also about being aware how that information is understood by the recipients.  So remember to know your audience!

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

Business expertise versus technical skills!

Tuesday, May 24th, 2011

In talking with a group of product managers recently about working with distributed software development teams, where part of the team was in the US and part of the team was in an offshore location, there seemed to be a big consensus that one of the most difficult issues in working with the offshore team was getting them to understand the “business side” of the system.  For example one person was very vocal about the issues with the developers in the offshore location not always understanding why the payment system needed to work in a particular way, or why the users needed to work in a certain way.  Other examples came up with billing systems and with the developers not understanding why sales commission had to be calculated in a certain way. This got me to thinking as to why this could be occurring?

According to the group of product managers the reason was specifically based on the fact that we are exposed to “how certain things” work more often in the US than in some of the offshore locations.  I agree this can be a factor with understand such things as “calculating sales commission”. Well at least the basics of calculating sales commissions, because as many people know there are many many ways to calculate sales commissions. It can greatly vary by company. So any developer would need to know what is the algorithm/s used by the company. 

After thinking about this question for a while, I started to think about how many companies search for outsourcing partners. A top priority for many companies is technical skills, which of course are very important when choosing who to work with. But I think sometimes technical skills are given a higher priority than if the outsourcing partner has related business or experience with your vertical market.  For example if your company is in the payments space, working with an outsourcing partner which has experience in that space will go a long way towards helping to overcome issues with understanding how the system has to work. Many companies when they start to look for a partner, are thinking, well we have the domain expertise, we are the experts, which is definitely true, and we can help pass that expertise on to anyone that we work with.  What we don’t have is enough technical skills.  If a company makes a concerted effort to pass on the needed domain expertise then the combination of your side having the domain expertise and the vendor having the technical skills, can work. However, in a distributed environment, passing on the domain expertise will take more effort, and it is easy for it to fall by the way side. It seems to make sense then to give, if not equal weight to both business domain expertise and technical expertise, then at least put business domain expertise in a close second place, when choosing a partner to work with your firm on software development.

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

Business case changes the reason outsourcing relationships go wrong?

Sunday, March 27th, 2011

I was reading an article earlier this month about business cases and outsourcing and some of the typical reasons that outsourcing agreements go awry – http://preview.tinyurl.com/outsourcing-business-case. The article was based on a study done by the Outsourcing center (http://www.outsourcing-center.com), which looked at 140 outsourcing relationships; long term relationships during which certainly the business case was going to change over time.  The author, Kathleen Goolsby, a senior writer at the Outsourcing Center has been writing about outsourcing relationships for more than ten years. I find her articles very informative. 

In this one she reviews the most common reasons that the outsourcing relationships, from the Outsourcing Center study group, went wrong and give some possible suggestions as to what can be done to solves those problems if they occur in your outsourcing relationship.

The reasons the outsourcing relationships went wrong, as cited in the article include: 
1. Resource allocation – on the part of the provider, they did a poor job of planning.
2. The buyer’s business model changed – changes need to be made to the relationship and agreement in order for the buyer to remain competitive. 
3. Multisourcing environment – if the provider is subcontracting some of the work and not all of it is within their control or the buyer is working with many vendors and does not have control over all of them. 
4. Attrition – when the service provider is experiencing a lot of turnover.
5. Changes to the pricing model – in this case they refer to affects to both parties if their fiscal years do not overlap, this can affect compensation for the provider. 
6. Changes in IT business-case assumptions – changes in required technology due to changes caused by the market. 

I think I might add one more reason to this list. One that starts before the outsourcing relationship begins and continues as the project goes on. That is – was enough time and therefore enough money put towards making sure that all of the people, within the buyer organization, that need to be involved with the project, are onboard with what needs to get done and is there enough time for them to do what they need to do. Was there actually enough time built in to their schedule for all of the work they need to do on the project: time to review what they need to, to do what work they need to do – whether that is time to compile information and data at the beginning of the project, to review product as it is delivered throughout the course of the relationship, or time for integration when final product is delivered. Also was enough time and money put towards ongoing reinforcement/communication of the reasons for the outsourcing relationship and its corresponding business case. If this was not accounted for before the project and relationship started, there will definitely be some hiccups at the beginning and both parties will have to get together and discuss how to overcome this issue, how to make changes so that the necessary people are able to be fully involved and that all of the necessary work gets done.

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

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 »

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 »

Applying Entrepreneurial traits to software development projects!

Monday, October 25th, 2010

Not too long ago I was reading a blog article on entrepreneurship, which I think really applies to software development projects as well.  The article is titled, “7 Warning Signs Your “Big Idea” Is Going to Flop*”.  I am not saying the article should be titled, “7 warning signs your “software development project” is going to flop”, but maybe it could be. Right now I just want to concentrate on the first warning sign – “You keep changing your mind”. Does this sound familiar to anyone who has defined a new project, or who has run a software development project?  Probably it does! 

I love this paragraph from Mr. Chartrand ‘s blog – “Business old schoolers call it “scope change,” and it can seriously hamper your progress. The more you push the boundaries and keep adding to your project, the more it becomes a time-consuming, cost-heavy monster that never ends. Risks go up, your schedule gets trashed, deadlines get blown and quality goes down.”

Wow, the same thing that happens during a software development project. You can change all you want, but realize it could affect your timeline and it could drive costs up!; if doing Agile development, i.e. you may need to add more iterations or you may be at risk of blowing an iteration deadline if you are not tightly controlling it.  But adding more work tends to mean the cost goes up and the timeline extends!

I like the suggestions given as well for how to overcome this warning: “Give yourself a set amount of time to do research and plan the scope of your project before you start. Take a few days, weeks, or months to really think things through. It’s okay to waffle then because no one else is watching, and you haven’t done anything yet, so you don’t have to backtrack.  But once your time has expired, stop, make whatever decisions you need to make, and move forward. Look at it like a deadline. You can change your mind up until a certain day on the calendar, and then after that, you stick with the plan until you’re finished.”

Applying this to a software development project, means it is ok to do a little planning, think and write out what you want. It doesn’t mean you are not “agile” or not “flexible” just because you think about something or write something down. It just means you have actually thought the idea through. I am not saying write a book, but writing down can help you think about aspects you have never even thought of and it can help orient others to the idea. Also great to have someone read those specs over besides yourself. Can they understand it?  What questions do they have? 

Another great suggestion is to give yourself a deadline. For software development deadlines can be imposed by government regulations, i.e. new banking regulations require you to track and report transactions over $10,000 as of the 1st of the year. Deadlines can also be imposed by your clients, i.e. they promised to their user base that this new feature will be available by this date.  Well it had better be in by then. The harder situations are when you do not have a deadline imposed on you and you need to set one yourself, but set one you must, otherwise you will keep incurring costs and never finish your project.  Even doing agile development, set a rule that the latest that changes will be accepted is 5 business days before the delivery date for each iteration (or whatever is appropriate for your organization). Making changes up until the day before the due date, or even the day of delivery just gets you this, (from Mr. Chartrand ‘s blog – “Risks go up, your schedule gets trashed, deadlines get blown and quality goes down. “ Good advice for software development projects!

* To read the original blog text: http://blog.kissmetrics.com/product-flop/#ixzz13QohVRzb

Posted in Project Management, entrepreneurs, startups | 117 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 »

« Older Entries
Newer Entries »