-
If there is a software architect (or engineer, skilled lead developer) on a project, than project manager doesn't need programming background.
On small projects there could be 1 person who manages the project and handles all technical aspects of software development cycle in a role of engineer or architect. But for bigger projects those career pathes separate considerably.
A project manager is the person
accountable for accomplishing the
stated project objectives. Key project
management responsibilities include
creating clear and attainable project
objectives, building the project
requirements, and managing the triple
constraint for projects, which is
cost, time, and scope.
A project manager is often a client
representative and has to determine
and implement the exact needs of the
client, based on knowledge of the firm
they are representing. The ability to
adapt to the various internal
procedures of the contracting party,
and to form close links with the
nominated representatives, is
essential in ensuring that the key
issues of cost, time, quality and
above all, client satisfaction, can be
realized. - Wikipedia
So, programming background is just a plus for PM and not a requirement.
In general the person who started learning PM in collage and then begun his working career in this role righ away after graduation has more chances to be a great project manager than the other one, who has spent a few years in jr. to sr. programming role, 1-2 years in software engineer role and then switched to project management.
-
A project manager needs to have enough programming knowledge to know when someone is trying to snow them with an estimate.
Having actual experience with the tools being used also lets them know what it is actually like to use the tool, rather than just believing the marketing hype from the glossy brochures.
I've worked for people that believed the marketing hype and had no idea how awful the tool was to actually use.
HTH
cheers,
-
Project management is (sorta) on a different career path to programming. I certainly don't see it as a natural progression as programming focuses on technical skills and communication whereas project management is basically about effectively dealing with the business, clients and other stakeholders and managing people.
Project managers don't need a programming background. Should they have one? Not necessarily. Is it useful? If managing software projects, absolutely.
-
A project manager with NO technical understanding (and I have worked with many of them) is nearly always detrimental to an IT project.
So give me a project manager with a programming background (even in a totally different language / area / discipline - in fact that will often be better) over one with no technical knowledge any day.
-
The best manager I ever had was a non programmer.
He was great in
- giving motivation
- team building
- focusing company resources for our purposes
- setting deadlines
- giving feedback
- measuring productivity
- guiding
But when programming we were to ourselves.
-
Some of the best managers I've worked with have a coding background... and some of the worst too. Managers without coding experience can be OK, perhaps they need more suppor in some areas such as estimation of schedules. On balance I have generaly found it easier to work with managers who have dev skills, but it is no guarantee of management ability.
-
Experience in hands on programming no, but in software engineering yes
I say software engineering cause, as previously mentioned, unless a skilled architect is on the team the PM will likely be responsible for design decision. In time like this it's important that the manager steers the team the right way by helping put a software design philosophy in place for the team (agile or what have you). They will then have to defend it to higher management tiers and it can't hurt if they know what they are talking about.
This will help them in the long run with estimation of cost/time/features.
I seriously think that most PM should be familiar with the core principles of:
Code Complete, at least the first few chapters before reaching the programming sections (http://www.cc2e.com/)
and
Software Project Survival Guide (http://www.stevemcconnell.com/sg.htm)
With that said...no one is perfect! Do your post mortem wrap up and learn from the mistakes!
-
No, project managers shouldn't necessarily have a programming background. They should be familiar with the stages of the Software Development Life Cycle but that isn't the same as programming to my mind.(1) No, the natural way of evolution is into team lead or group manager which is different than project manager. PM should be a good maanger with a basic understanding of a software development methodology and people skills to handle the execution of the project plan and its evolution. There isn't necessarily a need for fundamental knowledge about the technology I use since in a sense that can become quite the rabbit hole to jump down, e.g. how much about IIS and ASP.Net would they have to know and then the differences between versions that can add some more to the story.
I've had pretty good experience with each kind of manager in terms of project managers. Some that came from a programming background gave the ease of bonding over horror stories in using this or that for developing stuff and I enjoyed working with them as some ideas don't ever seem to go out of style. Others that didn't seem to have a technical background may still be good if they have the other key attributes like attention to detail, methodical mind, and creativity to handle changes to the plan.
1 - Programming, which is the same as writing code, to my mind is almost purely design and implementation which ignores the other elements of designing software which includes the earlier stages like requirements gathering and analysis as well as the end stages of testing, deployment and maintenance.
-
Well as the term Project Manager already suggests,
the described person should care about the project
and be a good manager, which includes all the soft-
skill, motivation and group hug stuff ( ;-) )
The skills of a good programmer are usually not important/wasted
in management. I see this often, brilliant engineers climbing
the career ladder and finding themselves suddenly
only managing, coordinating and team building.
The shift in priorities/skills is great for some, but for
some it isn't.
Skills in the things he
manages are usually an asset and help in his management
decisions, but not really necessary.
A good manager, in the nowadays often glorified metaphor,
carefully listens to his 'underlings' and works his ass
off to make sure they can be as productive as possible.
He has no time for coding.
Additionally a brilliant programmer should not be burdened
with management work, better give that to someone who
chose programming, but isn't all that good with it.
(this is not meant as a joke, even if it's funny)
So the constellation with a good manager aided by a programmer
he can trust would truly be the best thing.
Well, that's my opinion only, but there it is :)
Cheers.
-
Normally, a good project manager should be able to manage projects in different industries (please notice the bolded word). In order to do that, he needs to have a person (or a group of persons) with the technical knowledge in that domain, to rely on technical decisions and not to try to take those decisions by himself.
However, having the experience in that industry (e.g. IT), can be a significant advantage.
In most of the IT projects I saw, the project manager actively participated to the technical decisions (e.g. architecture, design, etc.). This, of course, involves tehnical knowledge. However, it should not be the responsibility of the project manager, but more of a technical leader.
-
In my experience as a Project Manager, having software engineering experience has been a great help. Its not the most important thing. Being a leader/coach is MORE important, but engineering experience enables a better relationship with the engineers, as well as helps you do reality/sanity checks on the plan, the estimates, the current status.
I believe engineers will chew out a PM which has no engineering background whatsoever, or who is turning his back on any technical matter even if he has relevant knowledge.
-
I've worked with project managers in different verticals (ASPs, finance, train control systems) and most of them did not have a programming or software background. Some of them came from very "social" backgrounds, i.e. political science or business majors. The main concern when you lack a technical background is that technical folks get questions like "Can you tell me how many LOCs this feature will be? I'll estimate the time based on that." Without a better understanding of the process of building software, it's very hard for them to do their job effectively.
However, the most important traits I think a PM must possess are a through understanding of the domain, the ability to communicate it clearly to the team and the skill to talk down clients on crazy fringe requirements. This is much more valuable then a programming background. A great PM is a like a developer's wingman.
To answer the original question, I believe that a skilled developer / architect could progress into this role, but it's not a "step up". I think PM is a specialized niche which fit certain personality types. I do know that in general, the PM career path tends to lead to senior / executive management - take from that what you will.
-
a good project manager with no programming background is better then a crappy one who used to be a programmer.
that said, if you have these choices:
a) a good project manager with no tech background
b) a good project manager who used to be a programmer
then 'b' is better. there is a whole swag of advantages for a PM who used to be a developer when working on an IT project.
for instance, there have been times i have been able to help junior developers debug problems, even though i didnt know C# at the time (i 'grew up with' ASP3).
when you go meet clients to do requirements gathering, you can speak competently about technology, and when your senior developer/architect isnt available to go to requirements meetings, you can fill in quite nicely.
as to weather PM is a natural progression for a programmer - no, its not. i went from programming to project management because i like it (plus i wanted to earn more money). PM isnt right for many developers because you have to learn a whole swag of new soft-skills.
-
A technical background is preferrable in a project manager as well as prior experience at managing a technical project/technical team - but I don't think having a technical background is essential.
A project manager does many things which do not require a solid technical understanding or experience and this can often be overlooked by a team who are focused on the technical aspect of a project.
Project management is as much about product/project delivery as it is facilitating communication between stakeholders and the project team. Assuming there are other experienced senior team members (an architect, lead developer, etc) those team members should guide the project manager and provide their technical experience in effort forecasting, analysis etc etc.
In other words, I think it's more important to have a project manager who can actually manage projects over one who has a technical background and can "manage" things.
-
I have been a practising project manager for the past two years. I have always found it helpful about knowing the Technical detail of the product helped me set the right direction.
While the Dev and Test Designs are going on, several times I challenged them as to why they take certain approach. This resulted in uncovering big mistakes early on in the development phase.
This is the only reason I felt a Project Manager with the right technical Aptitude brings in a positive difference to the team.
However - there are some cons to it - sometime it may stop those creative juices of team members from flowing.
I believe, having a holistic Technically view of Product Architecture/Design instills the confidence on the way things are moving and uncovers the risks upfront.
The most important thing though is to be patient and be open to appreciate the team's thought process at times.
An idea that seems to be a stupid mistake at first glance - is worth relooking into it since it may be a TRANSFORMATIONAL and highly innovative idea and may pay huge returns down the line.