Can one be an effective IT project manager with little IT knowledge, background or inclination?
Anonymous
In your experience, can a person be effective at managing Software development projects, if he/she does not have background or understanding whatsoever in software development, its processes, concepts, terminologies?
If so, what kind of training/mentoring activities need to take place?
I've been asked to help and lead 2 colleagues to become IT PMs and form a PM group. They don't have the same back ground as I do (I'm a former software developer, they have office administrative background) and have not been able to follow conversations in our project meetings. I'm at a loss as to what to do to improve the situation.
They have been taking courses and reading training material relating to CAMP certificated. But from my experience, with a PMP cert., knowing the PMBOK is just the start of doing PM work in IT domain. I would say it's not even the critical part. I have a hard time articulating the less measurable soft skills requirements for the PM roles. What would you say is the required skills for being an effective PM?
I want to support my colleagues in their professional interest. But i think i'm staring at an impossible ask. I foresee that i'll end up doing the job of 3 people at some point, if i agree to lead this group. and that's just not sustainable for me.
I'd appreciate any input/advice/sharable experience you could provide. Thanks, -HP Saving Changes...
Khai Ng.IT PMO | IT Project Manager| TTGROUPHanoi, Viet Nam
My answer is "Can not"
...
1 reply by Peter Rapin
Mar 01, 2021 9:36 AM
Peter Rapin
...
So its settled then. A project manager cannot manage a project where (s)he does not have technical expertise and a technical subject matter expert cannot manage a project when (s)he does not have management expertise. Nonsense!
The real problem starts when either the PM an/or the SME think they can better do the job of the other.
Do they have lots of experience of managing other types of projects, non-IT ones? If not, they are going to have to simultaneously learn about how to be a PM and about the complexities of software development. An experienced PM ought to be comfortable with learning a new subject area, with some mentoring etc., and they can apply their existing PM knowledge while learning the subject. But to learn both together may be very difficult... Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Feb 28, 2021 8:44 PM
Replying to Khai Ng.
...
My answer is "Can not"
So its settled then. A project manager cannot manage a project where (s)he does not have technical expertise and a technical subject matter expert cannot manage a project when (s)he does not have management expertise. Nonsense!
The real problem starts when either the PM an/or the SME think they can better do the job of the other. Saving Changes...
Anonymous
Thanks all.
The situation I have here is like that which Tim mentioned. My two colleagues have neither the software development experience/expertise nor the PM experience.
My personal hurdle is that I'm asked by upper management to create/help these colleagues in again these experiences. So i'm a bit befuddled in how to go about with this ask. I'm even a bit loss on how to convey just how difficult this ask is without sounding like i'm criticizing my colleagues's abilities. Saving Changes...
The PMBOK can be a lot to digest for someone trying to learn about project management AND apply basic project management principles in a practical manner; if they're new to project management AND trying to apply everything from the PMBOK, they're going to struggle.
The PMBOK can provide breadth and depth, but is that what is needed to get started? Certification prep classes may create frustration as they generally teach you how to prepare for the exam, not how to be a project manager. Based on your experience, what are the basic PM principles and practices you need to be able to apply to do your job? If you were to make a list of the basics, what can they do, and what do they need help with? This is the start of your mentoring plan.
With regards to the technical, what is expected of PMs at your company? In my experience as a PM, I've written SQL statements and program code, but it wasn't a job expectation, which is good because my development skills are a little rusty. It may be helpful to understand things like SOAP and what an API is, but having a firm grasp of the product/service development lifecycle is going to be more valuable. Understanding communication and implementation/deployment planning should be more important than knowing the details of pull requests and merging code branches. Don't get me wrong, knowing how the tools, that your team members use, work can help you understand the overall process at a detail level, but is that where a PM should start?
If you need PMs to understand development, in detail, to keep people honest and on track, is that a PM problem, or a people problem?
What are you doing, beyond the basics, that contributes to project success? Is it PM work, development work, or a combination of both? How important is it for the trainees to have these skills? How can they develop them, and who can help them develop them? Who can give them the experiences you've had that got you where you are today? Saving Changes...
If the employee has neither PM skill nor technical knowledge, they *may* develop into an effective PM, but it will take a lot of work from more senior PMs to coach them.
I have led multiple teams of PMs where some members of the team were very new, and had very limited knowledge in both the technical and project aspects. About 50-75% of my time was spent coaching rather than managing my own projects. They need a lot more direction than more senior team members who can be more proactive and self-managed. There was a strategic objective there to bring in an develop new talent, but that comes with a cost. Saving Changes...
Lately software development is done without the need of a project manager.
However, I think that it will be challenging to lead project without any techy knowledge. Example, I came from IT world and I can't see myself leading a construction project, I will be lost in the meetings and for sure the building will fall down or I will miss the doors...
...
2 replies by Peter Rapin and Thomas Walenta
Mar 01, 2021 1:07 PM
Peter Rapin
...
Don't worry Mayte, you would have architects, engineers and other technical specialist that will make sure the structure is sound and that access is to code. All you need to do as a PM is make sure these guys know the objective and talk to each other.
Mar 09, 2021 2:12 PM
Thomas Walenta
...
Mayte,
yes it will be challenging and you will learn a lot.
But if you run your IT projects well, you have a good chance to run any project well. Just give a try, be confident. And get a mentor.
Thomas
Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Mar 01, 2021 12:16 PM
Replying to Mayte Mata Sivera
...
Lately software development is done without the need of a project manager.
However, I think that it will be challenging to lead project without any techy knowledge. Example, I came from IT world and I can't see myself leading a construction project, I will be lost in the meetings and for sure the building will fall down or I will miss the doors...
Don't worry Mayte, you would have architects, engineers and other technical specialist that will make sure the structure is sound and that access is to code. All you need to do as a PM is make sure these guys know the objective and talk to each other. Saving Changes...
Anonymous
Mayte, hahaha! Same. We've gone through the phase of not having PMs. We are a lot more efficient as a development group now. So we're definitely going the PM route.
Aaron: Thank you. You're asking all the questions i'm asking! We don't have a trust and verify issue. But I would expect a PM to be able to set up projects' processes, identify and engage with appropriate SHs through out the process, able to organize projects in to actionable steps and phases, prioritize competing demands on resources, know what to anticipate and plan for through the life cycle of a project, amongst other things. My challenge has been, i can't tell in doing these types of things, which expertise i'm drawing from: software development or PM? Keith has given me some very helpful ideas.
For me to get where I am, it took 4 years of CS education, 6 years of working as Software developer, a couple weeks of PM training (which we all had), and a lot of online article readings and forum interactions like this one. I think that's a bit hard to replicated at this point for my colleagues. So do shortcuts exists? what are they? Neither of them are expected to be involved in technical work, but I can't imagine planning for software development project without deep understanding about the deliverables, and the process it takes to get there.
Keith, thanks (again!) for this. It's becoming clear to me that helping my colleagues can't be done as an aside to my workload. Your message supports this line of thinking.
...
1 reply by Aaron Porter
Mar 02, 2021 12:08 AM
Aaron Porter
...
One thing that I've found helps minimize frustration when working with new PMs is to set clear expectations, making sure trainees understand and agree to them. I don't want to call it a checklist, but that's what it is - a checklist of the basic activities they are expected to perform in each phase of the project. Some items on the list will come easy, other items will have more of a learning curve, and this may vary by person.
As lame as this may sound, it serves multiple purposes:
- It reduces ambiguity, thereby reducing frustration on the part of the trainee.
- It helps you identify areas where each individual has strengths and needs improvement.
- It has the potential to build communication, as you work together and discuss progress on each of the steps and any issues they are encountering.
- Progress builds confidence. As items are checked off the list, both you and the trainees can feel like something was accomplished.
Schedule regular reviews. Projects and people move at different paces, so schedule time to meet and discuss progress and issues. You don't want to hold their hands or leave them floundering. Set the expectation that your regular review is when you'll make time to work with them, but they can come to you if they get stuck and need help. You might find out someone is needy or needs more help; you'll have to find the balance. Set a goal for reducing the frequency of meetings, maybe to phase/release reviews.
Over time, one of two things may happen:
1) the checklist will go away (hopefully because it is no longer needed, and not because of apathy)
2) the checklist will evolve into a minimum standard for project management that your stakeholders can expect from all PMs in your organization
Neither option is always the right option, but there is merit to both.
A couple more random thoughts
- do you have templates and process documentation the trainees can use?
- Do any of your projects have more challenging activities coming up that the trainees can observe, while working on their own projects? Afterward, you can do a quick recap with them to discuss what happened and see what they picked up.
These are just some thoughts. Take 'em, leave 'em, change 'em. You know better what your success will look like than I do.
Mayte, hahaha! Same. We've gone through the phase of not having PMs. We are a lot more efficient as a development group now. So we're definitely going the PM route.
Aaron: Thank you. You're asking all the questions i'm asking! We don't have a trust and verify issue. But I would expect a PM to be able to set up projects' processes, identify and engage with appropriate SHs through out the process, able to organize projects in to actionable steps and phases, prioritize competing demands on resources, know what to anticipate and plan for through the life cycle of a project, amongst other things. My challenge has been, i can't tell in doing these types of things, which expertise i'm drawing from: software development or PM? Keith has given me some very helpful ideas.
For me to get where I am, it took 4 years of CS education, 6 years of working as Software developer, a couple weeks of PM training (which we all had), and a lot of online article readings and forum interactions like this one. I think that's a bit hard to replicated at this point for my colleagues. So do shortcuts exists? what are they? Neither of them are expected to be involved in technical work, but I can't imagine planning for software development project without deep understanding about the deliverables, and the process it takes to get there.
Keith, thanks (again!) for this. It's becoming clear to me that helping my colleagues can't be done as an aside to my workload. Your message supports this line of thinking.
One thing that I've found helps minimize frustration when working with new PMs is to set clear expectations, making sure trainees understand and agree to them. I don't want to call it a checklist, but that's what it is - a checklist of the basic activities they are expected to perform in each phase of the project. Some items on the list will come easy, other items will have more of a learning curve, and this may vary by person.
As lame as this may sound, it serves multiple purposes:
- It reduces ambiguity, thereby reducing frustration on the part of the trainee.
- It helps you identify areas where each individual has strengths and needs improvement.
- It has the potential to build communication, as you work together and discuss progress on each of the steps and any issues they are encountering.
- Progress builds confidence. As items are checked off the list, both you and the trainees can feel like something was accomplished.
Schedule regular reviews. Projects and people move at different paces, so schedule time to meet and discuss progress and issues. You don't want to hold their hands or leave them floundering. Set the expectation that your regular review is when you'll make time to work with them, but they can come to you if they get stuck and need help. You might find out someone is needy or needs more help; you'll have to find the balance. Set a goal for reducing the frequency of meetings, maybe to phase/release reviews.
Over time, one of two things may happen:
1) the checklist will go away (hopefully because it is no longer needed, and not because of apathy)
2) the checklist will evolve into a minimum standard for project management that your stakeholders can expect from all PMs in your organization
Neither option is always the right option, but there is merit to both.
A couple more random thoughts
- do you have templates and process documentation the trainees can use?
- Do any of your projects have more challenging activities coming up that the trainees can observe, while working on their own projects? Afterward, you can do a quick recap with them to discuss what happened and see what they picked up.
These are just some thoughts. Take 'em, leave 'em, change 'em. You know better what your success will look like than I do. Saving Changes...
Community Champion
