Should Project Managers be technical?
Tanmay Vora
There has been an ongoing debate around on whether a software project manager should be technical. I have worked with project managers who are technical (a part of them is still a developer) and project managers who are non-technical (people who know how to get things done, and not exactly how to do it).
However, one sure thing is that a project manager must know the processes involved in executing a specific project. A project manager in construction Industry should know the process of how buildings are constructed and similarly a software project manager should know what the software is all about, how is it built and what processes are involved.
Project managers need to understand enough about the technology so that they can make tradeoff decisions (or help product owners make tradeoff decisions) about what will actually make it into the release. The more PMs understand the product under devleopment, the better decisions they will make–or guide the project team to better decisions.
Here are the two extreme situations I would like to avoid: the un-knowledgeable PM and the PM who would rather be the architect. I’ve worked with several organizations who thought that PMs in other industries, such as event planning, would make great PMs of software projects. Nope. Not a chance. The PM needs to understand the process of the project. And in addition to the process, understanding enough about the product and the tools can help a PM assess risk and manage it during the project.
In my experience, the PM as architect is just as bad. This PM understands the process and the technology and ignores the work of the PM. If the PM is focused on development instead of managing the project, the project suffers as much (although differently) as if the PM was ignorant of the project.
As Johanna suggests, a lot also depends on the kind of team matrix as well. If a project manager does not understand nuances of technology but is proficient in management, overall processes, execution methods and scope, it helps to have people in the team who can take up complete accountability on technical aspects of implementation.
What do you think?
I know one thing, that Software project manager should have a solid technical background. Am totally against all those PM Associations who just want to split between the industry and project managers.
What Johanna says here is perfect “Project managers need to understand enough about the technology so that they can make tradeoff decisions “, and in order to be that, you should have enough technical knowledge and experienc.
I think Project Managers should be highly technical. This would avoid developers being in needless meetings, and would save a ton of our time (I am a developer). Non-technical PMs are hard to work with, as they have to be taught the whole software development lifecycle, and they look really bad in front of the client.
I feel the example on construction industry given above is perfect and speaks it all.
A Project Manager should be very strong in the process. Right from the requirement phase he or she has to make sure that his team has a defined process and his team including ( BA, Dev, QA, TechWriting, Training, SCM…Etc) sticks to the process.
When it comes to small projects as mentioned above may be Techy PM will be handy where employees take multiple roles and go through all shortcuts in delivering the Project on schedule, it doesent work for large projects.
Large projects needs proper planning and a PM should spend loads of time with all the leads and team members. A well planned project is half done.
Now to answer the question ? How much knowledge should the PM technically know.
1) Dev: Not required to understand the design of the Application – But should know the basic layers of development required( Eg; UI,BO,DB), the level of effort required is the Dev leads role.) 🙂 A never ending debate. ” I would say leave this to the specialist.”
Get the break down from Leads and there starts your WBS work.( Enjoy this activity and have loads of fun during this phase, this is ver you are taking the team into your command)
2) Testing: Understand the scope of testing: Eg; why are different types of testing executed for the project. And at what phases will these be executed.
Similarly with Automation Testing: Load and QTP: A pm should know when and why it is done and not to know how its is done. PM Should have the abilty to analyse the outcome and discuss with the Dev team in proposing solutions.
3) SCM: Software Configuration Management: PM’s should be very strong on the build Management process. Handling build Request, switching between environments.
A few tips for efective project management.
. Learn to Escalate
. Learn to Delegate
. Learn to log and track issues , Action Items and Risk. ( Very Very Powerful, a must know for all PM’s) Even if it is of smallest level.
. Have good Knowldeg on PM tools
. Should know the process in and out of all the SDLC phases in a project.
. Should be strong in Project vertical processes like Change, Defect, Risk ,Issue.
. Should set up clear communication channels.
. Create an working atmoshpere. “we dont need hitlers here” at the same time know your limits.
. Reporting
And if a PM is doing all that i have said above, i dont see him having time or need to know the application architecture or a tweaking a BA’s requirement.
This is just a 50000 feet overview of it.
Hi Isaac, Thanks for an elaborative comment that just takes expands on the topic.
Irrespective of the project size, project manager HAS TO BE process oriented. I can’t agree more with you on that.
You are spot on when you say that for smaller projects, a techy PM can do. But on larger projects, PM has to be a little more of a manager with ground level technical understanding.
I have seen a lot of PM’s who are very clear on Processes but are not very aware on umbrella activities like configuration management and quality management – and hence your input that they should have a clue on automated testing tools and configuration management techniques makes a hell lot of sense.
Your tips on PM are so good that it demands a separate blog post to elaborate on that.
Thanks for adding a lot of value to the post and keep reading/commenting.
Have a great day!
Never ending debate…!! Infinitive number of arguments can be fired from both sides 🙂
Ketan – yes. Infact, it is very straight-forward. A lot depends on management’s judgement of selecting a PM based on project type, client needs and overall team structure.
But yes, there clearly are two schools of thought on this.
Keep reading!
I read all the discussions above on whether the Project Manager should be technical or only perform project management functions.
I believe if the PM is technical, it gives him the EXPERT power to influence the team to provide him with reasonable time estimates, avoids un-necessary discussions between developers, developers makes no no execuses when their module is delayed etc.
Apart from this, the development team feel confident when the technical PM talks with client on requirements as in the discussion itself, if some requirement is not technical feasible, it will be addressed at that moment.
There are many stakeholders involved in decision making during different phases of project. If the PM is technical, he can talk with different people on technology selection, deployment issues, performance issues, etc.
I do not believe for the PM to micro-manage work of the developers. The PM should have clear understanding on how the underlying selected technology works in the project and issues involved in it.
I am open for discussion on this.
Hi Sam, Thanks for stopping by and commenting.
Technical project managers certainly give more confidence to the development team (from requirements to implementation). For small to mid-sized projects, a technical project manager is best suited.
Importance of non-technical project manager (who is trained to manage project from functional, managerial and planning perspective) is very crucial when scale of project is large. It takes special skills to manage complexity which a non-technical project manager brings on board. What is very crucial here is a right team structure with a strong technical second line who can take complete ownership of technology implementation.
This is a generic argument and a lot still depends on the type of project at hand.
I would love to take this conversation forward.
@Tanmay: I agree with your thoughts on the subject
@Issac: Certainly well crafted illustrations to support your call. I agree with you.
@Sam: You took words out of my mouth 🙂
Technical skills will surely increase the level of Project Managers acceptance amongst his own project team members, the specialists.
@Mujeeb – Thanks for joining in and acknowledging thoughts in this thread.