While developing custom software with a difficult client, it is frequent to see inexperienced Project Managers thinking their job is to fight the client.
I read The Art of War many years ago, but it took me a while to understand most of it. In war, all sides lose much. You must only go to war if you have certainty you will win, and that you will win will be more valuable to you than what you will lose. These three simple concepts have to be in the mind of anyone dealing with a client.
Fighting and conflict might win a small battle but will get you into losing the war. You need to pick your fights since having constant communication and being able to negotiate with the client is one of your main responsibilities as a Project Manager.
A Project Manager should not fight, but solve problems. Use force and conflict only if it's the only way, you have certainty you will win and are sure that what you will get is more than what you will lose.
2 dic 2010
3 jul 2010
Where have I been?
Labels:
responsability
I decided to change a few things in Sincronía in 2010:
Both processes are going on since March, so, I haven't had much time to write. I will be back soon, sharing all the lessons learned while leading this huge and ambitious projects.
- We started with market research and organizational consulting ending in new strategic planning and balance score card analysis.
- To reinforce the operational strengths I leaded the company into a ITMark certification.
Both processes are going on since March, so, I haven't had much time to write. I will be back soon, sharing all the lessons learned while leading this huge and ambitious projects.
13 mar 2010
Just one woman
Labels:
gender,
just thinking
Leading a company in which I am the only woman might not be a big deal for most, but it is for me. Gender issues are present in my daily life. This post is just a thought and hope I have.
Some years back I entered an IEEE mentoring program for women. I started talking to this lady in the US that worked in IT. I asked her about her experience, how she dealt with it all. She didn't understood my questions, she said she went into college and then marry some engineer and all was great in her white picket fence house. What was I talking about? I left the program really fast. Women engineers don't struggle much in the US.
But, I don't know any other women that lead teams in masculine environments. Here in Colombia, women in high positions always hide (or are force to be behind) some man. I really don't have a role model, and sometimes don't know how to get by.
What I do, is pose as a man most of the time. Sometimes I am not so good at it, and my feelings show. I get disappointed and sad, instead of angry when things go wrong and things like that.
I hope that age will help me find balance, so I don´t have to deny my initial instincts, act according to my true feelings and still be able to lead successfully my team. I now think I have to give up to much to be where I am.
Some years back I entered an IEEE mentoring program for women. I started talking to this lady in the US that worked in IT. I asked her about her experience, how she dealt with it all. She didn't understood my questions, she said she went into college and then marry some engineer and all was great in her white picket fence house. What was I talking about? I left the program really fast. Women engineers don't struggle much in the US.
But, I don't know any other women that lead teams in masculine environments. Here in Colombia, women in high positions always hide (or are force to be behind) some man. I really don't have a role model, and sometimes don't know how to get by.
What I do, is pose as a man most of the time. Sometimes I am not so good at it, and my feelings show. I get disappointed and sad, instead of angry when things go wrong and things like that.
I hope that age will help me find balance, so I don´t have to deny my initial instincts, act according to my true feelings and still be able to lead successfully my team. I now think I have to give up to much to be where I am.
24 ene 2010
Geese and your team productivity
Labels:
schedule,
shared leadership,
team productivity
People say that the first job you have as a young professional marks you for life. I agree. When I was a grad student, just after finishing my BA I worked at ACOPI (that is the Colombian Association of Small Industries www.acopi.org.co).
Their most important project at the time was called PRODES: Programa de Desarrollo Empresarial Sectorial. It still exists and its main idea is to group similar small business to potentiate their development. For example, if negotiating raw materials for 10 companies, you could make a better deal than if negotiating individually. You can easily implement quality methodologies if you share the work, etc. It made a lot of sense and it was very successful. I didn't work on the PRODES project, but I was always listening, for I found it quite interesting. Many years later I still run my company having in mind many of the PRODES tips. Working on ACÖPI clearly marked me for life.
A basic principle in PRODES was shared leadership: the group will change the leader periodically. Leading a small company is hard; imagine leading a group of 10 companies on top of that. They used as an example how geese fly. When the goose leading is tired, it gets in the back and the one closer takes the lead immediately. The group always has a leader, but no one gets burned in the process.
Recently I have understood (and am experimenting in) a new dimension for the shared leadership. I now use it to elevate software development team productivity. The concept is simple, keep moving the pressure from one team member to other, never dropping the pressure, but never keeping it on one person for too long.
This is how I suggest you implement it:
Know your project
Functionality will have different levels con complexity: might require knowledge for the business, particular technical skills, prerequisites from other use cases, etc. You need to know as much as the project as you possibly can, keeping a general (managerial) view.
With this knowledge you´ll have what is needed to have estimates for all units of work. We have estimates based on historical averages and a bit of my own personal invention (Delphi technique, so it doesn´t sound so bad).
Know your people
Every person in your team has different skills and abilities. They also have limitations, lack experience or have certain difficulties. Since the PMs job is to make it happen in the time you have with the money you said you would, knowing as much as you can (from a professional perspective) from you team will always help. You will then be able to know what will be a challenge to one person and will kill him/her of boredom.
Know your bias
All PMs have a team member they prefer, just as parents have a kid they prefer (no matter how much they try to hide it). It's inevitable. Bias will make you assign complex use cases to a single person, or silly boring ones to the other. When in doubt, just look at your statics, that might help you remember that the good one is not so good, the bad one is not so bad and that most of the bias is a construction of your mind (we hopefully someday quiet).
Remember it's all about the money
Well, all these know and acknowledge has one single purpose: build the schedule for the development team. Now, define the time period to switch the pressure for one member to the next, and identify your critical tasks. Assign a team member to each task on the critical path, switching responsibility periodically, and shortening the time to do it. Don't use the effort you estimate on critical tasks, use less. Take no more that 10%-15% off; if you go for 50% then your schedule will just be unrealistic. Then, fill the rest of the schedule making sure each member gets a simple task after finishing a critical one. Use the regular estimation on all the tasks that are not in the critical path. Your goal is to use shared leadership in the critical path so the schedule will end with extra time and extra money. Really, it's all about the money.
You still need to monitor closely this schedule, and manage any differences from the planned schedule. But will probably get the best out of your team by using the geese technique.
By the way, PM stands for Project Manager.
Their most important project at the time was called PRODES: Programa de Desarrollo Empresarial Sectorial. It still exists and its main idea is to group similar small business to potentiate their development. For example, if negotiating raw materials for 10 companies, you could make a better deal than if negotiating individually. You can easily implement quality methodologies if you share the work, etc. It made a lot of sense and it was very successful. I didn't work on the PRODES project, but I was always listening, for I found it quite interesting. Many years later I still run my company having in mind many of the PRODES tips. Working on ACÖPI clearly marked me for life.
A basic principle in PRODES was shared leadership: the group will change the leader periodically. Leading a small company is hard; imagine leading a group of 10 companies on top of that. They used as an example how geese fly. When the goose leading is tired, it gets in the back and the one closer takes the lead immediately. The group always has a leader, but no one gets burned in the process.
Recently I have understood (and am experimenting in) a new dimension for the shared leadership. I now use it to elevate software development team productivity. The concept is simple, keep moving the pressure from one team member to other, never dropping the pressure, but never keeping it on one person for too long.
This is how I suggest you implement it:
Know your project
Functionality will have different levels con complexity: might require knowledge for the business, particular technical skills, prerequisites from other use cases, etc. You need to know as much as the project as you possibly can, keeping a general (managerial) view.
With this knowledge you´ll have what is needed to have estimates for all units of work. We have estimates based on historical averages and a bit of my own personal invention (Delphi technique, so it doesn´t sound so bad).
Know your people
Every person in your team has different skills and abilities. They also have limitations, lack experience or have certain difficulties. Since the PMs job is to make it happen in the time you have with the money you said you would, knowing as much as you can (from a professional perspective) from you team will always help. You will then be able to know what will be a challenge to one person and will kill him/her of boredom.
Know your bias
All PMs have a team member they prefer, just as parents have a kid they prefer (no matter how much they try to hide it). It's inevitable. Bias will make you assign complex use cases to a single person, or silly boring ones to the other. When in doubt, just look at your statics, that might help you remember that the good one is not so good, the bad one is not so bad and that most of the bias is a construction of your mind (we hopefully someday quiet).
Remember it's all about the money
Well, all these know and acknowledge has one single purpose: build the schedule for the development team. Now, define the time period to switch the pressure for one member to the next, and identify your critical tasks. Assign a team member to each task on the critical path, switching responsibility periodically, and shortening the time to do it. Don't use the effort you estimate on critical tasks, use less. Take no more that 10%-15% off; if you go for 50% then your schedule will just be unrealistic. Then, fill the rest of the schedule making sure each member gets a simple task after finishing a critical one. Use the regular estimation on all the tasks that are not in the critical path. Your goal is to use shared leadership in the critical path so the schedule will end with extra time and extra money. Really, it's all about the money.
You still need to monitor closely this schedule, and manage any differences from the planned schedule. But will probably get the best out of your team by using the geese technique.
By the way, PM stands for Project Manager.
Suscribirse a:
Entradas (Atom)