mide sowunmiWeb Developer| General MotorsAtlanta, Ga, United States
After over 10 years working on Agile project teams as a Software developer this is what most PMPs seem to be concerned about:
1/ How long will it take to complete your tasks?
2/ When will you finish?
3/ Have you finished?
All PMPs seem to ask those questions or slight variations and that's all they seem to care about. Perhaps if PMPs had more understanding of what developers actually do they could ask better questions and thus build better communication channels with the technical team members Saving Changes...
Vijay PanditaManaging Director| OptSoft IT Busniess Solutions Pvt. Ltd.New Delhi, Delhi, India
I believe doing things in a collaborative manner increases the communication process. Things done in isolation make it difficult for the team management to understand how and when task will finish. Since one of the principle of Agile is "collaboration", if followed properly, PM won't have to ask questions like "How, When" etc. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Sep 13, 2016 11:03 PM
Replying to mide sowunmi
...
Thanks for all the responses... so many issues have been raised let me try my best to answer.
The topic is something that seems common in different companies where I've worked. Each organization implements Agile differently, some have SCRUM with daily stand-ups, a few have scrum masters but usually the PM takes that role, some have two week sprints etc. I have tried to make a very general statement.
It's true that communication should be in both directions but then it can be difficult explaining something technical to a PM with no programming experience. Even though the PM should not be involved in the details it would be helpful if he/she understands without relying too much on expert judgment.
Part of the problem here is that it appears most of PMs I've worked with only involve developers in Scope and Time/Schedule management issues. Although some have been involved with team building activities. Other areas like Stakeholder management, Quality management, HR management seem to have been neglected.
It would be helpful if developers are made aware of important project documents like requirements traceability matrix, work performance reports, mile stone list... And other information that will help them understand how their work affects the whole project success.
There are PMs who do an awesome job working with software developers however a lot can still be done to improve
The problem is: PM must not understand technical problems. PM has to transform technical problems into risk and issues if applies and working in finding actions plans. A PM must not accept excuses (too much technical details when a problem arrives are usually excuses) but she/he must be a facilitator to make the work done. Some PMs forgot something critical that they must performed when they are assigned to an initiative: they must perform eliciation activities to understand all related to the domain and be able to talk with all the stakeholders. Take into account: I come from software field and I was a programmer and I have performed all related positions (some of them do not exists right now) in the software/IT field. So, I understand the point.
...
1 reply by Mayte Mata Sivera
Sep 16, 2016 2:10 PM
Mayte Mata Sivera
...
Agree @Sergio a PM must not understand technical problems.
As a PM I'm not fan of micromanagement, instead of work in understand what is the exactly the line of the code that is creating a bug in the system, I've prefered to work in communication tools that allow to the developer to explain without too much technical words, like this the technician will develop his communication skills and could participate in a meeting with C management or users.
Saving Changes...
Lena WiedemannVice President| M&T BanKEast Concord, Ny, United States
Sep 15, 2016 8:19 PM
Replying to Adrian Carlogea
...
Lena, I strongly agree with your opinion, however in the case of software development if your are not a SME (a developer) you will never understand the developers "business".
Project managers that have never written a line of code in their lives will only be able to see the actual software development process as a black box. They can give requirements to the developers and expect in return effort estimates and then they can ask developers to start working on some requirements and then monitor the progress. That's about it, such PMs will never be able to get inside the black box and see or influence the way it works.
Learning basic software development/IT concepts will be of much help to the PM as he/she will be able to better communicate with software developers but in this way the project managers will still not be able to understand what the developers are really doing.
Software developers take all the technical decisions completely independent from the PM, they only have to tell the PM how long each task will take and then during implementation what is the status of each task.
Agree Adrian - at the end of the day, the PM is not the SME - the developer is and there has to be a level of trust between the PM and developer that what the developer has indicated is true.
That said, it's really important that PMs don't fall into the "well my developer told me" excuse. The longer and more closely you are able to work within your team the better basis you have for asking questions. As you get more comfortable with your team members you know when to be 100% confident in what they are saying and when to do more questioning or ask for additional information. Every experienced project manager has had that moment where someone has told them something and it hasn't seemed right - based on past experience, intuition or common sense. We have all probably worked with the developer who is eager to satisfy the PM or Sponsor and will tell you they can deliver whatever is asked for even if they really can't. We have all also probably worked with that developer who is conservative to the extreme in every timeline or response they give you because they want to ensure they can deliver. Both of these responses come from team members wanting to do the right thing, but as the PM, you need to be able to get some middle ground and know enough to asked for good supporting explanation of why things are the way they are. I have seen that less experienced project managers I've worked with are sometimes afraid to question anything that is shared with them by the team and I always encourage them to push past that discomfort and ask. It doesn't have to be aggressively or in a challenging way.
I don't expect the PM to know it all and recognize that ultimately they need to rely on their software developer (or the same goes for any team member really) that is the expert in that topic to be the expert. However, being confident on the answers your team is giving you is critical and sometimes you need to dive in a bit deeper to get that confidence - particularly when working with new teams. Saving Changes...
The problem is: PM must not understand technical problems. PM has to transform technical problems into risk and issues if applies and working in finding actions plans. A PM must not accept excuses (too much technical details when a problem arrives are usually excuses) but she/he must be a facilitator to make the work done. Some PMs forgot something critical that they must performed when they are assigned to an initiative: they must perform eliciation activities to understand all related to the domain and be able to talk with all the stakeholders. Take into account: I come from software field and I was a programmer and I have performed all related positions (some of them do not exists right now) in the software/IT field. So, I understand the point.
Agree @Sergio a PM must not understand technical problems.
As a PM I'm not fan of micromanagement, instead of work in understand what is the exactly the line of the code that is creating a bug in the system, I've prefered to work in communication tools that allow to the developer to explain without too much technical words, like this the technician will develop his communication skills and could participate in a meeting with C management or users.
...
1 reply by Adrian Carlogea
Sep 16, 2016 5:34 PM
Adrian Carlogea
...
Maria, the decisions taken to resolve the technical problems from within a project have a tremendous impact on the success of the project. If, as a PM, you don't understand the technical problems then you are going to be totally excluded from some of the decisions that are going to have a huge impact on the success of the project that you manage. In other words others will take decision for you and you will never be able to judge by yourself if those decisions are good or not until it is too late.
In a book about project management the author was comparing weak and strong matrix organizations from the project management point of view. According to the author the main difference between a strong and a weak matrix is given by the technical expertise of the PM, if the PM is a good technical expert then he is able to lead the project team and as such a strong matrix results, otherwise the PM works in a weak matrix environment.
I don't want to underestimate the value that project management brings in areas that are not technical in nature, but saying that a PM that does not understand technical problems can fully manage a project is a claim that I strongly disagree with, and I am basing my opinion mainly on my own experience.
Agree @Sergio a PM must not understand technical problems.
As a PM I'm not fan of micromanagement, instead of work in understand what is the exactly the line of the code that is creating a bug in the system, I've prefered to work in communication tools that allow to the developer to explain without too much technical words, like this the technician will develop his communication skills and could participate in a meeting with C management or users.
Maria, the decisions taken to resolve the technical problems from within a project have a tremendous impact on the success of the project. If, as a PM, you don't understand the technical problems then you are going to be totally excluded from some of the decisions that are going to have a huge impact on the success of the project that you manage. In other words others will take decision for you and you will never be able to judge by yourself if those decisions are good or not until it is too late.
In a book about project management the author was comparing weak and strong matrix organizations from the project management point of view. According to the author the main difference between a strong and a weak matrix is given by the technical expertise of the PM, if the PM is a good technical expert then he is able to lead the project team and as such a strong matrix results, otherwise the PM works in a weak matrix environment.
I don't want to underestimate the value that project management brings in areas that are not technical in nature, but saying that a PM that does not understand technical problems can fully manage a project is a claim that I strongly disagree with, and I am basing my opinion mainly on my own experience.
...
2 replies by Mayte Mata Sivera and Sergio Luis Conte
Sep 16, 2016 6:08 PM
Sergio Luis Conte
...
Adrian, that is the point, a PM has not to take the decision. The PM has to coordinate all related to make that other people, the subject matter experts, take the decision. That is a hard work indeed, but is the work to do. If not, it is impossible for a PM to take multiple different projects in the same organization or moving from domains between organizations. That is the big shift a PM has to do. The PM is a facilitator. No more than that.
Sep 16, 2016 6:41 PM
Mayte Mata Sivera
...
Let me explain me with an example (sorry is more long than expected)
Situation: Unit test phase in a manufacturing plant. New software implementation. Users went to PM with a red flag because they cannot create the post goods issue with the RFG tool.
Where D is the developer PM is the project manager
From my point of view.
POINT 1 - The nice to have conversation as a Project Manager
PM – Hi, let me check with you, something that maybe is a gossip or an user misunderstanding, is there some issue with the post goods issues?
T – Yes, the user raise a defect, because there is some bug. We already know that the interfaces between the ERP and RFG are working perfectly, now we are checking the coding in the ERP system. Delivery and post goods issue process aren’t standard maybe we’ll need all day to find it.
PM – As post goods issue is critical during unit test, I would like that you keep me updated following the communication plan procedure.
T – Ok, don’t worry. We’ll prioritize this task, when I’ll find the issue I’ll inform you about timing to resolve it.
4 hours after.
Mail from T to PM
Hey, we’ve just found the issue. After analyze the bug, is something that is not easy to resolve. I need 8 hours for codding + 2 for documentation the issue and transport to UAT system
The new coding will be transport on Monday night.
Mail from PM To T (After review planning, risks and others)
Go ahead with modifications and documentations. Keep me posted.
POINT 2 - Micromanagement, bad communication, PM in a role of SME because the PM was before developer, and other don’t desirables common topics that we see in IT.
PM – Hey, there is a bug in the system, the user cannot create post goods issue, did you check it?
D – Yes, we are on this topic. But this is standard code and is difficult.
PM – Did you check it the last upgrades? And communication between RFC and ERP?
D – Yes, I did, I spent 2 hours reviewing the communication between systems, I didn’t had lunch, and now you are asking me about it and wasting time.
Regarding the upgrades I’ve checked but in the last notes there is nothing about the user exit that John implemented in order to allow the post goods issue after 12 am, it means that we need to debug and read all the code.
PM – OK, keep me posted or let me know in order to check the system by myself.
4 hour latter.
Mail from T to PM
After 4 hours reading amazing code, I’ve discovered that there is an issue in the badi implemented by John, it’s weird because he always is a good programmer, but this time, maybe as he is also assigned to another project he didn’t realized that using this kind of code
If select single *
(super screenshot)
With the new upgrade, the line marked in blue (as you can see) doesn’t take properly the bar code that is in the product.
We need to solve it.
Mail from PM to T
How long will it take to complete your tasks? When will you finish?
Mail from T to PM
My answers in blue
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Sep 16, 2016 5:34 PM
Replying to Adrian Carlogea
...
Maria, the decisions taken to resolve the technical problems from within a project have a tremendous impact on the success of the project. If, as a PM, you don't understand the technical problems then you are going to be totally excluded from some of the decisions that are going to have a huge impact on the success of the project that you manage. In other words others will take decision for you and you will never be able to judge by yourself if those decisions are good or not until it is too late.
In a book about project management the author was comparing weak and strong matrix organizations from the project management point of view. According to the author the main difference between a strong and a weak matrix is given by the technical expertise of the PM, if the PM is a good technical expert then he is able to lead the project team and as such a strong matrix results, otherwise the PM works in a weak matrix environment.
I don't want to underestimate the value that project management brings in areas that are not technical in nature, but saying that a PM that does not understand technical problems can fully manage a project is a claim that I strongly disagree with, and I am basing my opinion mainly on my own experience.
Adrian, that is the point, a PM has not to take the decision. The PM has to coordinate all related to make that other people, the subject matter experts, take the decision. That is a hard work indeed, but is the work to do. If not, it is impossible for a PM to take multiple different projects in the same organization or moving from domains between organizations. That is the big shift a PM has to do. The PM is a facilitator. No more than that. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
In the middle of all this valuable discussion, something I missing to say is: the questions @Mide has stated above are not appropriated to use with any agile software development method. I have to agree with that. Saving Changes...
Maria, the decisions taken to resolve the technical problems from within a project have a tremendous impact on the success of the project. If, as a PM, you don't understand the technical problems then you are going to be totally excluded from some of the decisions that are going to have a huge impact on the success of the project that you manage. In other words others will take decision for you and you will never be able to judge by yourself if those decisions are good or not until it is too late.
In a book about project management the author was comparing weak and strong matrix organizations from the project management point of view. According to the author the main difference between a strong and a weak matrix is given by the technical expertise of the PM, if the PM is a good technical expert then he is able to lead the project team and as such a strong matrix results, otherwise the PM works in a weak matrix environment.
I don't want to underestimate the value that project management brings in areas that are not technical in nature, but saying that a PM that does not understand technical problems can fully manage a project is a claim that I strongly disagree with, and I am basing my opinion mainly on my own experience.
Let me explain me with an example (sorry is more long than expected)
Situation: Unit test phase in a manufacturing plant. New software implementation. Users went to PM with a red flag because they cannot create the post goods issue with the RFG tool.
Where D is the developer PM is the project manager
From my point of view.
POINT 1 - The nice to have conversation as a Project Manager
PM – Hi, let me check with you, something that maybe is a gossip or an user misunderstanding, is there some issue with the post goods issues?
T – Yes, the user raise a defect, because there is some bug. We already know that the interfaces between the ERP and RFG are working perfectly, now we are checking the coding in the ERP system. Delivery and post goods issue process aren’t standard maybe we’ll need all day to find it.
PM – As post goods issue is critical during unit test, I would like that you keep me updated following the communication plan procedure.
T – Ok, don’t worry. We’ll prioritize this task, when I’ll find the issue I’ll inform you about timing to resolve it.
4 hours after.
Mail from T to PM
Hey, we’ve just found the issue. After analyze the bug, is something that is not easy to resolve. I need 8 hours for codding + 2 for documentation the issue and transport to UAT system
The new coding will be transport on Monday night.
Mail from PM To T (After review planning, risks and others)
Go ahead with modifications and documentations. Keep me posted.
POINT 2 - Micromanagement, bad communication, PM in a role of SME because the PM was before developer, and other don’t desirables common topics that we see in IT.
PM – Hey, there is a bug in the system, the user cannot create post goods issue, did you check it?
D – Yes, we are on this topic. But this is standard code and is difficult.
PM – Did you check it the last upgrades? And communication between RFC and ERP?
D – Yes, I did, I spent 2 hours reviewing the communication between systems, I didn’t had lunch, and now you are asking me about it and wasting time.
Regarding the upgrades I’ve checked but in the last notes there is nothing about the user exit that John implemented in order to allow the post goods issue after 12 am, it means that we need to debug and read all the code.
PM – OK, keep me posted or let me know in order to check the system by myself.
4 hour latter.
Mail from T to PM
After 4 hours reading amazing code, I’ve discovered that there is an issue in the badi implemented by John, it’s weird because he always is a good programmer, but this time, maybe as he is also assigned to another project he didn’t realized that using this kind of code
If select single *
(super screenshot)
With the new upgrade, the line marked in blue (as you can see) doesn’t take properly the bar code that is in the product.
We need to solve it.
Mail from PM to T
How long will it take to complete your tasks? When will you finish?
Mail from T to PM
My answers in blue Saving Changes...
Daniel KrompholzPrincipal Maintenance Systems Specialist, Asset Management| The Port Authority of New York & New JerseyJamaica, Ny, United States
This topic made me laugh... In my experience working in a PM/ coordinating capacity with software engineers, I believe eliciting the best answers from them requires strong interpersonal skills. A strong friendship with your coworkers lays a foundation for seeking honest, candid answers to questions they may not be comfortable knowing with certainty. Good luck!
...
1 reply by Anupam
Sep 27, 2016 8:40 AM
Anupam
...
I agree with Daniel.
Bridge the communication gap, adapt to coaching style, and open up more.
This topic made me laugh... In my experience working in a PM/ coordinating capacity with software engineers, I believe eliciting the best answers from them requires strong interpersonal skills. A strong friendship with your coworkers lays a foundation for seeking honest, candid answers to questions they may not be comfortable knowing with certainty. Good luck!
I agree with Daniel.
Bridge the communication gap, adapt to coaching style, and open up more. Saving Changes...
