Archive for the ‘Project Management’ 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.