Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Programming IT Technology

Project Management For Programmers? 521

welshdave asks: "I'm a senior web developer in a medium sized company where the project managers have no programming experience of any sort. I'm of the opinion that project managers should understand the projects that they're managing and want to move into project management myself. I'm aware that I may meet resistance from the current project managers - many of them have been hired with no previous experience of anything. Previous suggestions to senior management that myself and other developers would feel better with a technical person running projects have been dismissed. As a result we are routinely told to skip testing or to implement the impossible, with an emphasis on how things look rather than how well things actually work. Has anyone else found the barrier to project management is their technical knowledge. How did you get past it?"
This discussion has been archived. No new comments can be posted.

Project Management For Programmers?

Comments Filter:
  • by Anonymous Coward on Friday June 21, 2002 @06:18AM (#3742375)
    I think that a certain lack of detailed knowledge about what is possible and what is not might be the key to successful project management. Yes, an impossible task assignment is probably going to cause a little confusion among the techs, but it can also be eye-opening in the sense that it teaches them about what people want. Techs commonly have a certain close-mindedness about how things should be done which can be very unhealty to a project.
    • I think you're right in this. A project manager should, in my opinion, be responsible for planning and control, and not for any tech-stuff.
      In my company, there is a group of persons that discusses with the customers about what they want, and what is possible. THAT's a point where tech-expertise is needen. When the specs are settled, it is handed over to a PM to make sure it gets implemented.
      • by sql*kitten ( 1359 ) on Friday June 21, 2002 @08:12AM (#3742676)
        I think you're right in this. A project manager should, in my opinion, be responsible for planning and control, and not for any tech-stuff. In my company, there is a group of persons that discusses with the customers about what they want, and what is possible. THAT's a point where tech-expertise is needen. When the specs are settled, it is handed over to a PM to make sure it gets implemented.

        A project manager has a set of skills that are distinct from by complementary to the skills of an engineer. A project manager who starts their career as a project manager often has great skills for, budgeting, say, and understands the administrative details as a role. The reason that these people fail is that, lacking an engineering background, when creating plans they are unable to accurately estimate time and resource requirement, and even worse they are unable to identify critical paths, dependencies and opportunites for parallelism.

        The ideal structure is to have a project manager to take care of the details, and a system architect to see the "big picture" and have overall responsibility for planning and executing the project. If the project manager is in charge, then that individual should have at leat 5 years experience "in the trenches" on similar projects, and should have the authority to set priorities and trim the feature set if necessary.
      • by Lobsang ( 255003 ) on Friday June 21, 2002 @09:28AM (#3743030) Homepage
        Allow me to respectfully disagree...

        What you're asking for is a ship captain that doesn't know how the ship works! Most project managers have no idea about the inner working of their projects. The end result: flawed deadlines, angry programmers, impossible tasks, annoyed bosses and/or clients.
        • What you're asking for is a ship captain that doesn't know how the ship works!

          No, what he's asking for is a ship captain that doesn't neccessarily understand how the ship's engine works. The captain should understand how to manage the workers in the engine room to get the most productivity out of them while keeping them happy, while interfacing with the passengers of the ship who keep yelling for the ship to go faster or slower so that the workers in the engine room don't have to deal with them. The ship captain should understand how to manage, run, and guide the ship - not tear it apart and reassemble it.


        • What you're asking for is a ship captain that doesn't know how the ship works! Most project managers have no idea about the inner working of their projects. The end result: flawed deadlines, angry programmers, impossible tasks, annoyed bosses and/or clients.

          About 2 years ago, I would have agreed with you. But now, I would say your Project Manager (whether technical or non-technical) is the problem. A non-technical project manager can do a great job of leading/planning a project AS LONG AS that individual does not make technical decisions for their engineers. The PM must listen to his/her senior engineers/architects to accomplish good schedule planning. Give the engineer a good set of requirements and get a resource and time estimate from the engineer. The PM must trust the engineer here. If the engineer conistently produces bad estimates (not from changing requirements, etc), then find another engineer to do estimates. The PM can then use these estimates to make decisions on what features to drop, priorities, etc. That avoids flawed deadlines, angry programmers (hey, they or another engineer made the estimate), etc. I've found this actually works out quite well at my current job. Never been happier.
      • I'd tend agree as well. Many techs make very poor PMs, and can get distracted with the technical issues at the expense of the overall project. (yes, there are exceptions, but in 20 years I have seen very few good techs that make good PMs).

        What can be useful is to have a "Technical PM", who is responsible more for the technical aspects of the project - assigning and selecting staff, approving estimates etc. This person then works very closely with the non-techy PM.

        • A more common term for what you refer to as a "Technical PM" is "System Architect". This sounds nice to technical ears and is (rightly) percieved as a senior technical position. We also have Functional Architects on some projects, whose skills favour the business process analysis side of things.

          The other benefit of this is that the other guy doesn't get called a "Non-technical PM", which you have to admit isn't a very good job title.

          In the (quite large, 12k staff) company I work for, the pinnacles of career (at least for most people's career paths) are

          • Programme Manager - these are the guys the Project Managers work for
          • System Architect - career progression here is measured in terms of the criticality or size of the project you run/work on
          • Principal Consultant - your job here is to be your organisation's main expert on some specific thing (deep skills rather than the wider skillset which is more usual for a system architect)
          We do have some career positions above those, but they're mainly line-of-business and divisional management, Managing Directors of various business units, and so on. We have a dozen or so members of technical staff who are more senior than the System Architects for large programmes and the principal consultantts, but they don't really have specific job titles (as you might expect at that level, people know them by their name and reputation alone).

          We have a group Technical Director (used to be the deputy Technical Director of the BBC), but he doesn't sit on the executive comittee - that may be something it would be best to change.

    • by Skapare ( 16644 ) on Friday June 21, 2002 @06:45AM (#3742448) Homepage

      I've had managers before that varied from well experienced, technically, to not at all. Rarely was I asked to perform the impossible. And in those cases where it was impossible, it really was impossible. I simply pointed this out to the manager ... and I explained in detail why that was the case. In all cases things got corrected. Maybe I'm not so closed-minded as some techies out there, and I know most everything is possible. The better managers I found came to me with the ideas of what they were considering doing, and asked me to prepare a report on the feasibility and costs (mostly in hours of work) of doing it. I usually included an impact analysis as well. But you can be sure that if I tell my manager that it is impossible, then it really is impossible. Usually the truth is "it'll cost ya". Maybe techies need to learn to say that more often.

      • But you can be sure that if I tell my manager that it is impossible, then it really is impossible. Usually the truth is "it'll cost ya". Maybe techies need to learn to say that more often.

        There's the key to successful project management right there.

        As programmers, we know that you can optimize on three things: delivery time, peformance (speed), and features. Pick any two. :) Everything is a tradeoff. If you want me to deliver this program quickly and have a lot features, then I'm going to have to write major bloat code to give it to you, AKA The Microsoft Way. If you want features and optimum performance, this is going to take some time (one reason why so many Open Source projects seem to lag behind schedule.)

        Knowing that is the key...and being able to explain that to upper management is the other key.

        "Oh, you want XYZ feature? That's going to take us another three weeks to deliver and we'll need a budget increase of ."

        And a project manager that doesn't know that will have to work closely with the programmers on the project to determine these constraints. A project manager who's done programming, OTOH will already know the difference, and she will have to be the one that learns to say "It'll cost ya." The project manager is the link between management and the technical team. And that person needs to be able to speak BOTH languages.

        • by Aceticon ( 140883 ) on Friday June 21, 2002 @08:05AM (#3742646)
          You're assuming that you actually have a project manager that's smart/experienced enough.

          Some project managers when confronted with the "there's a trade-off here" explanation will either:
          - Not trust you at all, because they think you are trying to make time for yourself (ie they think you're lazy).
          - Not trust your judgement and think you are overestimating the time it will take to do it (ie the "this looks so simple" syndrom - also common with users)
          - Try to get you to work long hours in the (mislead) belief that if you work more hours a day the change can be made in a smaller number of days (it works for maybe 1-2 weeks, then your productivity starts declining)
          - Insist that somehow (nobody knows exactly how) the whole change must be made within a certain (shorter than you think is needed) timeframe (usually they've already promised it to upper management and/or the costummer)
          - Get you to choose what trade-off should be made (this is my personal favorite - the manager is in practice asking you to manage. Just shows how usefull some managers are)
          - Any combination of the above

          Unfortunatly and contrary (or maybe not) to popular belief, those sort of managers don't actually get fired. Usually they tend to stay forever in a lower management position (ie directly managing the developers)

          • by Grab ( 126025 ) on Friday June 21, 2002 @09:15AM (#3742960) Homepage
            Make sure everyone knows what estimates you gave. Or if you can't make the higher-ups aware, make sure your estimate and your disapproval of your boss's new estimate are recorded in an email to your boss. Then you take as long as it takes, and when it overruns and fingers are pointed at you, you say "I told you so" and point them to the evidence. And if you get fired/downgraded for that, there's a nice little sum waiting for you at the industrial tribunal when you bring that "constructive dismissal" case. ;-)

            Re the trade-off thing, again you need to get written down what the results will be, and send it to your boss. Preferably also CC it to his boss. If the trade-off will mean more bugs, then write it down. Then when there are bugs, you have some comeback by saying "I was forced to release this code without having tested it, even though I said what the consequences were".

            BTW, don't forget to check the "notify on read" and "notify on receipt" boxes when you send the email, then you actually have proof that (a) it got there, and (b) he read it. If he later claims ignorance, or says "Outlook must have eaten it", you've got evidence otherwise. Emails are your evidence when the shit hits the fan!

            There are some bad managers out there. If you get one, don't be afraid to go over his head and talk to his boss, or to your personnel manager. You have a right to do that if you have a complaint about him.

            And if all else fails, find another job. Seriously. If the management at your place doesn't value you, get the hell out.

        • Rarely am I asked to do something that's truly impossible. I've always taken the position that it's not my job to say "no" to my manager. Rather, it's my job to say, "Yes, and this is what it will cost you."
      • You've had a much better experience with this than I have. I've only had one instance so far where I've had to tell the PM that it was impossible but the problem was that he didn't believe me. His reply was "So, you don't know how to do this?" so I gave him a mathematical proof as to why it was possible. This PM has a Masters in Strcutural Engineering from a well-respected university, so I thought that should be enough, however he simply crumpled it up and told me that he would write the code since I obviously didn't understand what he wanted. A couple of months later he raises the issue with me again and tells me that he is having trouble implementing it. Knowing that he is going to ignore my proof if I show it to him again I came up with the most basic and realistic data set that I could that would be unsolvable. I then asked him to try solving this data set by hand. Two days later when he came to me and told me that he didn't think it was possible I had to fight very hard to hold back the "I told you so" because I was hoping that this incident would convince him that in the future if I say "impossible" then he should consider the possibility of something really being impossible. Unfortunately nothing has changed and I am now looking to change jobs.

        Anyone know a company that doesn't treat its developers like morons and that is hiring?
        • Two days later when he came to me and told me that he didn't think it was possible I had to fight very hard to hold back the "I told you so" because I was hoping that this incident would convince him that in the future if I say "impossible" then he should consider the possibility of something really being impossible. Unfortunately nothing has changed and I am now looking to change jobs.
          If you're going to leave the company, shout at the manager first, I mean SHOUT. You should have said "I told you so, you've wasted 3 months of project time, the customer is gonna be very unhappy. I'm reporting this incident to upper management." Take your crumpled up proof with you. You can always go over peoples' heads, if upper management likes you nobody is gonna let you go and your manager will get fired. These CEOs don't get paid > $millions for sitting on their asses.

          Best case: Take him out. Take a counteroffer from another employer to your CEO and get a pay rise for yourself
          Intermediate case: Take him out, he pulls strings and takes you with him (you're gonna leave anyway so you've got nothing to lose, plus you get the satisfaction of ruining his life)
          Worst case: You get taken out (you're gonna leave anyway so you've got nothing to lose)

    • I think you should add some examples....

      I think one popular issue are colors in emails. Really? Why are colors bad in email? (Tell people not to use HTML mail because it's bad?), or even worse RTF?.

      From a technical standpoint I understand very well that emails are text only, no colors, no underline, no bold. But now step backward from your techy knowledge and think about it from a pure users perspective. Now why can't I put colors in my email??? Whats really so bad or difficult about them?
    • I think it is always a handicap to have a lack of knowledge. Not a deadly one, mind you. The killer combination is a lack of knowledge and a refusal to acknowledge it. Good managers listen to what their skilled subordinates tell them about their field of expertise, take into account other things like scheduling and customer demands, and then decide. Not listening to the techies can kill a project stone dead.

    • by DNS-and-BIND ( 461968 ) on Friday June 21, 2002 @07:40AM (#3742580) Homepage
      Ha! The company I was recently laid off from (they just had a round of layoffs, does that tell anyone how well they're doing) had the clueless project managers spoken of above. We ran a custom mail server on big Solaris boxes, and these project managers didn't know so much as "ls -l". Time and time again, we were tasked with impossible projects, which could absolutely not be implemented in the time allowed. As a result, we cut corners on testing, reliability, and system updates, with predictable results. We would get a machine into the field, and it would crash when some user would try to do something "unexpected", like our agents crashing due to buffer overflow when the "Subject:" line of an email exceeded 256 characters (The PM solution to this? Fix the overflow? Nah, they just had the programmers raise the limit to 2000!). Critical operating system patches were never implemented, due to "we'll have to test it, and we don't have time". The result? Hacked and vandalized boxes, and massive time wasted doing pricey reinstalls and customer apologies. Implement a real mail delivery system? Nah, just hack something together whereby sendmail invokes a brand-new shell process which runs an SQL script to inject the email into the database. Two expensive processes for every single incoming email! This particular problem was not fixed until some months after a spammer sent us 14,000 emails in a single hour and the system load rocketed to over 100 (on a beefy Sun Enterprise 4500 [], no less), and basically DOS'd the system. Expensive crash, humiliating customer apologies, the responsible PM being fired, etc.

      It wasn't that the techies were doing poor work, or slacking off on the job. Far from it - we worked our asses off. But a lack of knowledge about what was and wasn't possible resulted *directly* in impossible task assignment, with the entirely predictable consequent frequent outages and customer dissatisfaction.

      Oh, and remember how I said we had layoffs? All the project managers were laid off save one. The surviving PM was universally held as being technically competent and a gem among mud.

    • by gustar ( 125316 ) on Friday June 21, 2002 @08:46AM (#3742810)

      As someone with both extensive technical background and solid leadership and project management skills I can state for a fact that my ability to successfully envision, flesh out (e.g. requirements and design documents), estimate and plan (e.g. develop project schedules and resource estimates which I then translate into MS-project) a project or development effort is inextricably linked to my understanding of that project and its technical underpinnings.

      Over the course of my career I have dealt with legions of formal "project managers", (folks who are pure project managers lacking any technical background) and I have yet to realize any value in my interactions with any of them, beyond the occasional willingness to record meeting minutes.

      To date I have found them to be glorified secretaries, whose primary tactic is to latch on to knowledgeable people and not only drain information but actually get them to perform the real tasks of project management, such as scheduling and resource estimation.

      In addition, many of these folks like to act as middlemen, brokering information and jealously hiding their sources so people must go to them for information. This would not be a terrible thing if they actually understand the project and had the knowledge required to effectively answer questions and communicate the status of the project accurately but that is very rarely (never in my experience) the case.

      In my own experience, I have had a number of project managers assigned to various efforts I was responsible for, ostensibly so I could focus purely on the development effort and on technical leadership. In every case I have spent months working with a non technical project manager, spending 3-4 hrs a day with this person reviewing (creating) the project plan and having to spoon feed information to them (essentially so they could answer questions in meetings) as well making detailed suggestions about how they could overcome some obstacle external to our group that was needed in order for the project to succeed. In the mean time while this significant chunk of my time is being invested into sharpening my puppeteering skills the formal project manager has been horrible miscommunication project requirements and status to other groups.

      So in short order these folks are out and I'm back attending meetings and working with external groups as well internal.

      The primary factor behind the ineffectiveness of these folks is there complete lack of technical background. Successful project management is not just about writing up project plans and throwing dates and times down, its about understand the underlying objectives, as well as the pitfalls and obstacles in the way of those objectives. It's about understanding the project goals thoroughly enough to be able to determine what tasks are required to accomplish the project and making resource estimates that are realistic and effective.

      This understanding and affinity for the project is something formal project managers very rarely have.
  • by chongo ( 113839 ) on Friday June 21, 2002 @06:18AM (#3742376) Homepage Journal
    I found that it was easier to sit down with my PM and asked then the one thing they needed to make their job easier. If it was half way reasonable I went out of my way to give that to them ... in turn they seemed more willing to listen to reason and help form a project timeline that was 1/2-way based on reality.
    • In my experience project managers like to have a technical team member whom they can trust. A sparring partner (might as well stick with PM lingo) who can be trusted to see beyond the technical side of the project and understands the importance of budgets, client needs and so on. Project managers are like most professionals; they don't necessarily want an easy job, but they want to be succesful.

      Don't reject your PMs bollocksy timelines out of hand, but work with him to show what the result of following that timeline would bring. If your PM thinks to skip testing of the product, it's best not to act like the haughty technical prima donna who refuses to release anything untested. Instead, talk about risks and alternatives. If you know of any past famous projects that failed for poor planning, show him what he is getting into.

      Do this well, and PMs will start to know you for someone who helps them rather than someone who'll dig his heels in. Perhaps at some point you'll be asked to be technical manager for alarger project. That's the perfect job for those who are thinking about a management position but not ready to give up on technology.
    • You're on to something, for sure.

      The problem the OP describes usually comes down to a lack of communication between the people doing the work and the people ordering it. Building up trust is a great way to get people to listen to you.

      This is also why the various agile methods (XP, Scrum) work well; short-cycle iterative processes force a lot of interaction, and frequent deliveries build confidence on both sides. Allowing features to be reprioritized every iteration gives managers the feeling that they're in full control, which makes them much less likely to demand impossible things.

      But I have seen cases where this won't work. In an organization of sufficient size, the high-ups are so isolated from reality that they can only manage by appearances; the people under them can succeed just by creating the appearance of success. All programmers know that it's easy to create the appearance of success for v1.0 while leaving a steaming pile of turds under the hood that will sabotage any attempts at v1.5. Truly evil managers will take this every time and then move on to a higher position, leaving somebody else holding the bag.
  • Tech Leads... (Score:3, Interesting)

    by Neumsy ( 201524 ) on Friday June 21, 2002 @06:28AM (#3742394) Homepage
    Right now, I'm working for a big company on a good-sized account. We are working on implementing a big system for our client. We brought in people from the company, but outside the account, even a few contractors. To this point (It's been close to a year), we've been through 2 project managers. I don't think that either one of them have been too technical. The way around it was we have Tech Leads for our small group. These people are basically a mini project manager for just our group. All questions we have go to them. They sit in on the code walkthroughs and sign off on everything for us. Then if we have a problem, they go to the project manager if need be. These are usually the more senior people. The only problem is that if the Project Manager doesn't want to accept their input. Then, there isn't anything that can really be done. The Project Manager is just responsible for overseeing the project and making sure deadlines are met and co-coordinating between all the groups. It seems to work well this way.
  • by chthon ( 580889 ) on Friday June 21, 2002 @06:29AM (#3742399) Homepage Journal

    Project management should at least have an understanding of engineering principles : requirements, design, planning.

    I think that in this case requirements should not be underestimated, because implementing moving targets shifts planning. It should be taken up with senior management that PM and programmers should commit on certain requirements and deadlines, and that shifting requirements are not tolerated, unless taken up carefully and agreed upon by everyone.

    About separation of functionality and good looks, if you think that something is not implemented correct and may lead to future problems, this is risk assesment. If PM does not have any understanding of risk assessment, then this should also be taken up with senior management.

    If you cannot convince senior management about the two points above, then I suggest you find a better place to work and leave them at their own devices.

  • Drink some beer! (Score:5, Insightful)

    by Per Wigren ( 5315 ) on Friday June 21, 2002 @06:31AM (#3742405) Homepage
    You just can't convince a PM that she/he is doing wrong if you are just bitching about it.
    It's very hard to get your voice listened to (not just heard) if you do it in the "you're the boss"-way..

    If you get the chance, ask her/him to follow to the pub after work, or to sit in front of you at lunch. Then you can discuss in a friend-to-friend way instead of the slave-to-master way.. That's the only way to get listened to instead of just being heard.
    • by plumby ( 179557 ) on Friday June 21, 2002 @08:09AM (#3742658)
      Project managers don't have to be "boss". PM is just another role on the project to help coordinate the running of the project, interactions with the business etc. It's neither a higher nor lower role than developer/architect etc.

      Many of the best PMs that I've worked with (there are some good ones, honest) have been of a similar or lower grade than me. The attitude that PMs have to be bosses creates resentment in the rest of the team, and often means that their views on areas that they don't really have knowledge in (such as systems design) end up getting forced on the project over the view of the expert.
  • by 192939495969798999 ( 58312 ) <> on Friday June 21, 2002 @06:34AM (#3742415) Homepage Journal
    I think it's important for people to read this and realize that the PM is the reason that programming sucks 9 times out of 10 in the professional world. As much fun as it would ever be, the PM can wreck it by having no concept of reality. I don't much care if the PM doesn't understand exactly HOW to implement things, but it's been my experience (most recently as a lead programmer at a small outfit) that the PM will make decisions based on the immediate costs, rather than any solid scientific research. The PM will buy the "cheapest" product and force us to use it, when that product makes it much more difficult to maintain the software, eventually costing more than nearly every other solution. Computers are inherently expensive, and it's time to face facts: a cheap solution could be expensive in the long run, and could eventually lead to a catastrophe. I have been the happiest when either I was the PM, or the PM was a technical person with years and years of general technical experience, but perhaps no current programming experience. They generally can help get you good tools, and while they may ask for a difficult task, they allow you to explain your thinking instead of just shooting down any new idea that isn't their own.
  • .. that you know this.

    Where I currently work, the project manager is so clueless as he has no clue as to what he's supposed to do.

    He doesn't know database design.
    He doesn't know anything related to programming.
    He doesn't know how to design the information systems that our clients come to us to have built.

    I mean sheesh, I was taping 9 sheets of 8.5 x 11" paper to form my database diagram poster for a project... and he passes by and says, "another flow chart?".

    So what does he know how to do?
    He knows how to tell people what to do.

    People like this in these kinds of positions will eventually drop the ball, and when the sh*t hits the fan, the higher-ups will take notice.

    My advice would be just to do what the project manager says... even though you know the project's going straight to hell... and when things fsck up, you just say you were doing what you were told, project manager gets canned, then you take the initiative to step up and take their place.

    There's no point in raising a ruckus beforehand... just let the guy screw himself over... and act only when it suits you best.
    • sounds good until you try it. If you are on his team he's been blaming you guys the whole ride down hill, your reputation was trashed before he ever hit the fan.

      Therefore, to execute this plan, you must be willing to state what is wrong... to his superviser for example.

      Or better, for a good solution, try educating him/her and gaining enough trust in each other to work out what it is you each need to do for the project. With trust, he will leave to you that which he hasn't stupidly already promissed his boss. Unfortunately these are the things you can do, but none of it is going to actually help. Best to wait until the afterlife, in which case, um, you don't have a boss and everything is coded in [censored].
    • This sound like my last job.
      I now work in a bicycle shop.
    • by terrapyn ( 259226 ) on Friday June 21, 2002 @07:23AM (#3742546)
      I think the biggest contributor to project failures I have seen is the attitude you are expressing. The project manager has a distinct role that is NOT "database designer", "programmer" or other technical function, but which instead is focused on the coordination and communication among the team members and with outside parties (clients, management, users, finance, etc.) in order to JOINTLY build and execute a plan.

      I think project managers in the IT world at a minimum should understand the basics of software development life cycles and be knowledgable about the specific processes a given organization uses, but they shouldn't have to invent them, just as they shouldn't be expected to replicate your skills and the technical skills of rest of the project team.

      It is easy to sabotage any project or process by hanging back and letting things break. It is also wrong.
      • How is a project manager going to tell the client how long it's going to take when they have no idea what's involved in designing and implementing the desired system?

        How is a project manager going to provide a quote to the client when they have no idea how much time is required, and how many developers the project needs?

        All this stuff about "project managers don't need to know the technical aspects, they only need to focus on the business-side, client relationships, and resource allocation" is pure bs. A project manager *can't* do his job if he doesn't even have a *hint* or a clue towards the technical aspects of the project.

        You can say that "sure he can, he can just have a systems architect by his side and consult the project manager on what is or isn't possible". If that's the case, then it would make much more sense to get rid of the project manager position altogether and have a techie allocate resources, estimate project timelines, provide quotes, much more efficiently.
        • oh, I forgot to mention.

          Since the project manager that you describe - the one that shouldn't have to know about database design, etc - is the manager that I'm currently under. All he does is "resource allocation" (telling people to do what), client relationship management (promising the world to them), and making sure the project meets the deadline (telling us to code faster).

          But because he doesn't has no background or experience in development, the company has been taking a big lo$$ for every project he's responsible for.

          When he gets an RFQ, he comes to the developers to ask "how long do you think this would take, and how much would you charge". Before the precise specifications are gathered... boom... he's already promised them a deadline, a price, and a signed contract.

          project management indeed...
    • Personally, I don't think this is a good idea. What is to stop the PM (Project Manager) from placing all the blame on you and your peers for not doing your job? To the upper management, he PM will look good while you and your peers will take the heat.

      The correct action to take would be to talk to the PM... even try to educate him/her on how things work. But to be safe, remember to keep a journal about the conversations you or your peers have had with the PM... and keep your boss up to date if the PM is not making a sincere effort to understand.
    • He doesn't know database design.
      He doesn't know anything related to programming.
      He doesn't know how to design the information systems that our clients come to us to have built.

      And rightly so. Knowing these things is your job. You are also partly responsible for keeping him informed of problems/options. If he is clueless about the technical issues, it is because he has not been clued-in.
    • A note from a Project Manager....

      Well, here is the thing. A lot of times as a Project Manager your are responsible for the business side of things (i.e. budgets, requirements management, prioritization..I can go on an on). While a project might be technical in nature, there is still a lot of business and ego stuff that surrounds a project that has to be dealt with. Having worked with some technical folks (who are very good at development work and running a development team)they failed at the Project Management aspect of the project because they were too technical (and true to the development process). We all want to be able to follow the steps of the SDLC and create a quality product but in the end its about who gets the product out first or who introduces a new technology into an organization. The PM really should be a strong subject matter expert as opposed to being technical. A good PM will LISTEN to the development team and must be able to sort out what needs to be done versus what would be nice to do.

      If you are technical and want to go into project management, my advice is don't worry about the details (i.e. you really shouldn't worry about what a db schema looks like, you should really be worrying about how well will it scale over time). Shed the idea that you will actually practice your technical knowledge because in the end you will have to deal more with the business side of things. Its painful...but sometimes, its fun.
    • My advice would be just to do what the project manager says... even though you know the project's going straight to hell... and when things fsck up, you just say you were doing what you were told, project manager gets canned, then you take the initiative to step up and take their place.

      No. You will get canned.

      If someone apparently incompetent is in a position of authority, it means that that person is supremely competent in one thing - keeping his job. And that means finding others to blame when he screws up.

  • by Brother_Chubba ( 586342 ) on Friday June 21, 2002 @06:35AM (#3742420)
    Is the fact that I'm posting this while at work. People here simply seem to think I am only here to "do computer stuff" and thus browsing /. is just "work" to them when they pass by.

    HA!! I don't think even the guy who employed me knows exactly what it is I do.

    • Now i do. (Score:3, Funny)

      by Anonymous Coward

      You are fired.

      Your boss.
  • by smoon ( 16873 ) on Friday June 21, 2002 @06:36AM (#3742421) Homepage
    As a developer I've found that most management-types don't give a hoot about technical details, or much of anything else that a heads-down developer might care about.

    What will get attention is an understanding of business need, an attention to detail in terms of reporting progress and delivering systems that work, and positive attitude.

    As a manager I get very tired of hearing about the programmers, sysadmins, etc. complaining that such-and-such can't be done, or otherwise blocking progress. Much more often than not things that "can't be done" just require a re-statement of the problem and some creative application of simple ideas.

    My recommendation would be to make a friend or at least the aquaintance of one of the project manager's bosses, and just talk. Don't attack the current project managers style -- that would make their boss look bad. Don't complain about the impossibility of whatever. Mention that you have an idea of how to accomplish some objective. Show that you have some clue as to what the managers are interested in. Show that you have some interest in the companies performance. Be prepared to give out some 'write ups' that show a very clear train of thought and that make a clear recommendation up front, with backup material and dialogue exploring alternatives explaining why the recommendation makes sense.

    If that doesn't work, then get a job with a company that has a clue. They're out there.
    • by ThePilgrim ( 456341 ) on Friday June 21, 2002 @07:32AM (#3742570) Homepage
      As a manager I get very tired of hearing about the programmers, sysadmins, etc. complaining that such-and-such can't be done, or otherwise blocking progress. Much more often than not things that "can't be done" just require a re-statement of the problem and some creative application of simple ideas

      When a techie says it can't be done. 9 times out of 10 (s)he means it can't be done under the current constraints. Thease break down into time/features/money.

      If you can vary the constraints then you will find that most objections will dissapier.

      • This should be modded up. When we layer on constraints to a development project, eventually you will ALWAYS hit the point where the project becomes impossible UNLESS you are willing to relax some of the constraints.

        I have fought both sides of this battle as a technologist and manager, and I agree massively that a technologically competent manager does make a huge difference, because they can map out the business needs communicated to them and make constraint/trade-off decisions informed by a better understanding of the possibilities and real technological effort involved in implementation.

        Of course, the problem is that there is often somebody above the technically-astute manager who still doesn't know what the fuck is going on, and then the battles just ensue another level up. Unless the company happens to be organized like a _real_ software development shop, which is pretty rare these days.

    • This is part of the problem with PM's not being technical (and most management of tech areas). The wrong question for a PM to ask is, "Can XYZ be done". The wonderful thing about technology is that the same goal can be approached many ways, and technologies combined in unique ways. While lots of things are possible, how many are worth the money and man hours it would take, both in development and support?

      "Can it be done?" should be replaced by "Should it be done?". When the work is done and we step back and start supporting, living with and working with the result of the effort, will be truly get what we say we want?

      More things can be done than should be done. This is where not having fundamental tech knowledge on the part of a PM leads to trouble.
  • Have you demonstrated leadership ability through mentoring or project leading?

    Do you communicate with customers well?

    Do you appear as someone who would be a Santa Claus manager?

    Is your upper management (not your immediate superiors) a bunch of clueless morons? Do they have strong points that make them suited for the leadership positions that they hold?

    If you are looking to be in a leadership/management position, it would be better to stay where you are and learn the ropes, IMO. So many managers come straight out of development at one company and louse everything up at their new company as inexperienced PMs. Unless it's been made clear to you that the only way you're going to move into management is by killing a current manager, stay put and look for opportunities where you can.

    Talk with the boss, if the company is not so big that you are completely alienated from the upper management then you have the chance to befriend those people and politick your way into an authority position.

    Yes, we all know that leadership positions should be based on knowledge and track record and all those other good things, but in reality, you'll never get the positions you want unless you can make the right people understand exactly what you want.
  • by rsmah ( 518909 ) <> on Friday June 21, 2002 @06:38AM (#3742429)
    The problem your firm seems to be facing is that you are mixing project management with system design/architecture. What's the difference you ask? Project management is the process of resource allocation, scheduling, budgeting and task tracking. System design/architecture is the process of figuring out what should be built and how it should be structured internally.

    Good project managers need a different set of skills than system architects. Project managers think in terms of timelines, tasks and dollars. Architects think in terms of system components, their interactions, user requirements and technology. While there are some people who can do both well, they are quite rare as they require fairly different ways of thinking.

    Anyway, I'll bet dollars to donuts that the resistance you face from upper management has more to deal with the fact that you put the system before the company. They want project managers that put the company (or client) first. Big suprise, eh? If you want to lead projects, explain how you (or rather, people like you) can help the company make more money or make the client happier while spending the same amount of money (which, should lead to more money for the company). It's pretty much as simple as that. Cheers

  • Tom DeMarco books (Score:2, Insightful)

    by soegoe ( 580877 )
    Give your managers a copy of Tom DeMarco's Peopleware. And include his novel The Deadline for a bit of light reading. :-)

    Some books on Extreme Programming might help, too. Even if you do not plan to use it, they show how to share responsibilities between management and programmers. It all boils down to:

    • Management decides what will be done (business value blah blah).
    • The programmers decide how long it's gonna take
    • Management sets the priorities.
    This helps to avoid impossible deadlines and to keep up with high quality.
  • by bons ( 119581 ) on Friday June 21, 2002 @06:42AM (#3742440) Homepage Journal
    PMI [] has all you need to know about certification and there are PMI meetings just about everywhere" []. Attend a few of those and you'll either be networked enough to improve things or fins a better job.
  • In a nutshell. (Score:5, Insightful)

    by Fross ( 83754 ) on Friday June 21, 2002 @06:43AM (#3742444)
    One thing both you and the project manager need to understand is:

    The project manager deals with the business side of things.
    The technical lead deals with the technical side of things.

    So while he may be setting (or have forced upon him) aspects such as deadlines, you need to control scope, methodology and quality. Communicate with him constantly. Imply (if not state explicitly) that you need to work on resource allocation, something he may be trying to plan for you right now. to have everything stated down on paper is best for both of you, you can at least then agree or disagree and sort things out.

    It may also help to implement a proper development strategy you can agree on - if he won't listen, just escalate the issue. One that is tried and tested is a good bet, whether it's Extreme programming (a good suggestion) or something coming from the business side of things.

    Whichever it is, the problem here seems to arise from a lack of definability of responsibility and roles, and that's what needs to be set and agreed upon so you can both do your job properly! He's probably as exasperated at you at the moment ;)


    (a technical architect working as a project manager!)
    • You either need a person trained and experienced in both roles managing a project, OR you need two people with equal status in the company who can work closely together without killing each other.
      I've seen lots of structures for doing this. Some work, many don't. Also "project management" at some organizations corresponds to annoying schedule keepers rather than decision makers who recognize and decide on trade-offs, and requirements come from a different group entirely. These are some of the most broken organizations on earth.
  • Eject, eject, eject (Score:4, Informative)

    by vinsci ( 537958 ) on Friday June 21, 2002 @06:53AM (#3742470) Journal

    You're on what's called a death march project. (See AntiPatterns, chapter 7, Software Project Management AntiPatterns).

    Never work with a project manager who hasn't been a developer himself. Find a better employer - there's no way you can really succeed where you are now. Your projects will fail, be late, overrun budget, be of sub-standard quality, all of which are things that will ultimately reflect on your CV's. Naturally, any smart people in your projects all know this and work morale will erode.

    Suggested reading

    • AntiPatterns. Refactoring Software, Architectures, and Projects in Crisis. William J Brown et al. Wiley 1998. ISBN 0-471-19713-0.
    • The Mythical Man-Month. Anniverary edition with four new chapters. Frederick P Brooks, Jr. Addison-Wesley 1995. ISBN 0-201-83595-9.
    • Software Project Survival Guide. Steve McConnell. Microsoft Press 1998. ISBN 1-57231-621-7

    Me? Got 20 years in this business. Lot's of projects.

    If you can't find a better employer, become a project manager yourself, it's not rocket science. Read up, take a PM course, do it the way it should be done.

  • Supervisors supervise. Most companies are currently deploying the managed type of internal structure, with the theory that a manager can manage anything. Fewer companies are using the supervised type of internal structure. Both methods have their pro and cons. But in the long run a supervised company will have fewer employees with higher salaries, but it will cost less to operate.

  • by PinglePongle ( 8734 ) on Friday June 21, 2002 @06:58AM (#3742478) Homepage
    Until recently, I was the development manager at a fairly large internet company; we had project managers who knew very little about software development, database design or how to run software projects. Do you know why ? because that was my job.

    Whatever you may think, technology is not the most important part of the project - delivering what the business wants and making the right trade-offs to get that done is what matters. The intellectual purity of our great code is wonderful, but who cares if it gets delivered 6 months after it's needed ?

    The project manager's job is to work out what needs to get built and by when; they need to get all the external dependencies sorted out, ensure the requirements are either known or the person(s) who controls those requirements is available when required, get the money and resources sorted out, and work with a techie on how to get the deliverables built in time.

    I was that techie - and it worked pretty well. The project manager asks for stuff by a certain date, I work with the rest of the team to see what we'd need to do to make that happen, I negotiate with the PM on what is and is not in scope, and get the techies to start with whatever needs to happen to get the project done.

    Every couple of days, I sit down with the Project Manager to agree out where we are, re-negotiate dates/resources etc. if required, assess new requirements, maybe work out in more detail what the plan for the next phase looks like. If we have to cut corners - and this does happen, coz we don't live in a perfect world - I work with the developers to see what we can cut that will have the least effect on the quality - the PM doesn't make that call, I do.

    Project Management requires skills I don't have - I don't understand the commercial pressures on the company, I don't understand the legal framework we're working in, I don't have the patience to build and update Gantt charts, I don't enjoy endless meetings or chasing people for every little detail of their deliverabes. The project managers know this - they don't think any less of me, just as I respect the fact they couldn't design a database schema to save their lives.

    So, I would suggest trying to form a good working relationship with your project manager by trying to understand what they do for a living, understand that there is more to a project than the technical deliverables, learn to speak their language, and offer alternatives when they ask for the impossible.

    The attitude of most of the posts in this subject has been "huh, we're 200 times smarter than those idiots running the project, they're so stupid they couldn't blah blah blah". Hey, if you're so smart, it's your job to use that intellgence to move the project forward, not whine about how what a bad job everyone else is doing.
    • Asserting that business requirements are more important over technical merits get's you sub standard solutions that people will hate to use and will waste thousands of man hours being unhappy and being unproductive when the technology could be making their lives easier.

      New methodologies are not invented for fun. They are invented be cause they make things better, for developers, users and business.

      Yes, you can sell poor quality software or technology products for a short period of time and make money, but so will selling drugs, doesn't make it ethical or help make the world a better place. Discounting new technologies and methodlogies is also foolish and bad business sense if a PM has no idea why they are being used in the first place.

      The successful way to make good products that you can feel proud of, people will like and that you can sell is by have a wider world view point that does not revolve around money or technology but people and society (and how you can improve their lives *through* business and technology).

      Clearly business is not more important than technology, unless business is your goal. Which is worrying, because it should revolve around people. Business is a way to encorage development in society and technology, it is not a goal in itself.

      It's possible to make money from good products and good practice, a good example would be OmniGroup who have been doing this for many years. They are small but sucessful and make both some free and some commercial software of very high quality and by and large everybody really likes them. I have a couple of peices of software from them, and it's the only commercial software I use day to day.

    • >> Project Management requires skills I don't have - I don't understand the commercial pressures on the company, I don't understand the legal framework we're working in, I don't have the patience to build and update Gantt charts, I don't enjoy endless meetings or chasing people for every little detail of their deliverabes.

      I'm a techie, and I disagree with you on these points.

      I consider it important to know the commercial pressures on the company - providing an IT perspective on the business initiative behind the project can help the business clarify their needs, suggest a simpler solution, and ensure the delivered system does what is needed.

      It is essential to know the legal framework we work in - I've refused to implement code that would be illegal; after consulting with the legal department the customer changed their requirements

      I accept that meetings with customers are necessary to understand what they want (rather than what they ask for). Communication is a cornerstone of good software engineering.

      Although I don't chase people for every piece of their deliverables, I do talk to the customers to understand what the deliverables they expect are, and talk to the other developers to understand what they are intending to deliver. By doing this I achieve many things
      - any requirements gaps are spotted
      - any activities not on the project plan can be communicated to the project manager (who can then resource and cost the project appropriately)
      - I can be certain the developers know what they are doing, or work with them and the customer if they are suffering uncertainty or lack of communication

      All of these things could be done by a project manager, but don't have to be. As a technical person I can bring a perspective to each of these things that a project manager (with their different skillset) may not. And if the project manager is highly technical and is doing these things anyway, my life becomes easier and I focus more strongly on creating my own deliverables, rather than helping the rest of the team with theirs.

  • by James Youngman ( 3732 ) <jay@g[ ]org ['nu.' in gap]> on Friday June 21, 2002 @06:59AM (#3742480) Homepage
    There's much more to successful project management than there appears, particularly when the PM is also managing the relationship with an external client. It's the PM's job to make the client happy and (usually) deliver a profit. In a software context, this normally means delivering some software that works (see the Properly Testing Your Code [] thread).

    As a technical person, skills that you will need to gain in order to be a successful PM will include

    • Understanding the business context and business drivers
    • Managing client relationships (even for internal clients)
    • Estimating and planning skills
    • Tracking progress against plan - and taking appropriate action (pay attention to this one!)
    • An understanding of what timescales are realistic. For example, is it realistic to estimate design:code:test in the ratio 3:2:1? (answer: no).
    • Understand that you need to make it possible for the client to change their mind half-way through
    • Delegation skills (you can't do it all yourself, you know!) and motivational skills (i.e. understand the kinds of things you can / can't ask of people).
    • Risk analysis/mitigation
    • Personal organisation and time management
    • (In some shops) Project accounting skills
    Also, don't underestimate how much work this is. If you are team leading (i.e. working for a PM) then you can expect to lead a team of up to 8 and have the interaction with those staff and the PM take up 100% of your time (i.e. no time left for coding anything yourself). If you are a PM, you won't be able to directly supervise that many staff, because you have the added responsibility of steering the ship. Techies-turned-PMs are frequently tempted to take on the odd technical task - but resign yourself to the fact that you will have to delegate it to one of your staff in order for it to get done on time.

    If you are having difficulty communicating the impossibility of a task, consider making a weekly/monthly report document that shows progress against plan and the outstanding issues and risks. Many of these will not change from week to week, but putting them there provides one place where (s)he can refer to them.

    If something is impossible, then demonstrate in the report why it is impossible, and suggest an alternative. When presenting a problem, your many many times more likely to be successful in getting things changed if you also suggest a workable and realistic solution.

  • by geoswan ( 316494 ) on Friday June 21, 2002 @07:03AM (#3742493) Journal
    "...the project managers have no programming experience of any sort. I'm of the opinion that project managers should understand the projects... As a result we are routinely told to skip testing or to implement the impossible, with an emphasis on how things look rather than how well things actually work. Has anyone else found the barrier to project management is their technical knowledge. How did you get past it?"

    If your "managers" have no technical experience who writes the specifications that you aim to implement?

    If they present you with some kind of brief, insufficient description of the project, you need to write out something more specific, that you can actually work too. You learned, as I learned, in cs 101, that you shouldn't start working on a problem until it has been clearly defined. You learned, as I learned, that if you start programming without a clear goal in mind, you won't know when you "finished".

    So you write this description. Get your fellow team members, if you have any, on side. Then take it to your manager, and get them to read it, and sign off on it. If their original design has some impossible "feature" in it, maybe this is where you explain, in writing, where it is impossible. If it isn't really impossible, just very difficult, and in your technical opinion, of marginal utility, this is where you present your bosses with an honest prediction of the cost of their pet feature. If you explain to them that their pet feature will make the project take twice as long, or three times as long, will they really still want you to do it? Or will they say, "Oh shit, well in that case forget it."

    If they really don't know what they are doing, then they will probably fear a paper trail that documents that you warned them the pet feature would double the time to implement.

    If your boss is an asshole, and says something like, "If you can't do it I will get someone who can!" Or, "If you can't do it within this time constraint I will get someone who can!" Call his or her bluff. If their pet feature really is impossible to implement, they won't find anyone else who can do it.

    Revise your document to reflect the choices they made. Then work to this document. If they wanted you to implement their pet feature, even though you explained it would double the time to implement, you have protected yourself against the complaint that you are behind schedule. Document your work. Each time you complete one of the milestones in your original memo, refer back to your memo.

    So, are you doing tasks which are really the job of the technical manager? Without getting a corresponding raise? Well, yes. But you did, after all, want to move into management, didn't you?

    If you do a good job implementing what you promised in your memo will they reward you with a promotion, a raise?

    I don't know. But you have acted with integrity.

    If it comes time for your annual performance review, is this the time to explain that you have already been shouldering responsibilities that are really management responsibilities?

    • If you explain to them that their pet feature will make the project take twice as long, or three times as long, will they really still want you to do it? Or will they say, "Oh shit, well in that case forget it."
      They'll say, "Find a way to make it work, on time and within budget, and laws of physics be damned". This is the primary problem with most bad PMs; they don't listen. OTOH, this is also the primary problem with most bad (i.e., non-business-knowledgable) coders. In my experience, the proper action is to communicate with the PM, find out why the feature is so important, ask if it's OK that 5 other features won't get done for this one, etc. It may be that the PM isn't clearly communicating, or it may be that the coder doesn't want to do boring work. Which do you think is the case?
      If they really don't know what they are doing, then they will probably fear a paper trail that documents that you warned them the pet feature would double the time to implement.
      You assume they care about the product, and that they have ethics. No, what'll probably happen is they'll either bury the report or play politics. Remember, like everthing else, shit flows downhill.
      If your boss is an asshole, and says something like, "If you can't do it I will get someone who can!" Or, "If you can't do it within this time constraint I will get someone who can!" Call his or her bluff.
      Yeah, that'll make you real popular. Let's play dick-swinging, chest-beating games with our boss. They'll love you after you prove them an idiot to everyone in the office and shove it in their face! Heaven forbid, maybe your boss is having a family crisis, find out what is going on before jumping to conclusions. If they're being unreasonable, then there are things you can do (talk to HR, let them know you're having problems working, see if there's an ombuds, use an employee feedback mechanism...)
  • You say you want to move into project management, so if you haven't done so already, get yourself onto a project management course or three. Apply what you are taught where appropriate, whenever it's appropriate so you have evidence that you know what you are doing.

    Then, the next time you are in one of those post mortems because your useless PM fscked up, tear his/her project apart in front of some senior managers. Point out the flaws. Suggest how things could have been done better and how to get things back on track. Have purdy gant and pert charts and so on to back it all up. Know the facts and figures. Don't directly blame the PM, but leave the implication hanging. For bonus points walk the walk after talking the talk and deliver what you suggested.

    Do it right and you'll get a fat bonus, pay rise, satisifaction of an incompetent leaving your life and kudos from your colleagues.

  • In one word: don't. (Score:2, Interesting)

    by johnjaydk ( 584895 )
    Based on my experience I can't understand why anybody would want to become a project manager. It's a rotten thankless job and you've got zero job security. You're basically being squeezed between management, who hands you an impossible job and to few resources to do it and the techies who cant deliver the goods fast enough. While this goes on you have to do a lot of political infighting to steal more resources for your project, prevent other projects from stealing your resource's and competing with the other project managers to look good in order to still have a job in six months. Being a technical lead is a better job by far (been there) but only if you work with a pm who is actually listening to you otherwise you are a perfect candidate for a scapegoat... The real trick is to focus very hard on requirements even if this means that analysis drags on for ever and the pm is pesting you to get it over with. Make a document that can stand up in court and don't accept any changes without extra resources or a reduction in other functionality. Make a formal procedure for these changes (they will happen). And when the shit hits the fan: ALWAYS SIDE WITH THE TECHIES. The techies are mostly honest and rarely play political games. The pm's are always up to something and ready so sacrifice you in a heartbeat if it helps them in their games.
  • Unless you own the company, let them make their mistakes. Put in your advice, and if they take it and benefit, so be it, but otherwise, you can - and under certain circumstances should - move on at their loss. It's not your company to run, and if the company fails, it's not your fault. Constructively critise, but don't undermine the managers opinions.

    Don't blame the mangers, either - someone put them there, and I have seen poor management come from resentment towards techies as much as incompetence. They are people, get to know them, and you may find that they agree with you in assessing their own shortcomings. From that admission you have options - management need not imply dictation.

    Do your personal due diligence, but if the owners don't ask for your help, don't go out of your way to offer it. Save your energy for bigger stakes, IMHO. ("Owners" is vague, I know, but this is slashdot, and I'm being sweepingly vague ;) )
  • by heretic108 ( 454817 ) on Friday June 21, 2002 @07:13AM (#3742519)
    I worked for the Australian subsidiary of Wang Labs, at the time when Wang was the #2 computer company in Australia.

    Their R&D department was surging from strength to strength, until the Director made the decision to recruit staff from the sales support team to work as project managers.

    Never in my whole computing career was I immersed into such a political cesspit. These posturing pretenders sold out us R&D engineers to the most ridiculously stupid deadlines and functional requirements, skipping testing, fudging demos, and crafting a clever spin which transferred the perceived blame to the engineers for failure to deliver.

    After months of being unable to focus on a project, due to constantly moving goalposts and political bitching, I resigned. One week later, most R&D staff were laid off, and a couple of years later, Wang Labs went Chapter 11.

    In my 2 jobs following, the project managers were veteran engineers, who played an active and respected part in all aspects of the projects, from design through to maintenance. Any non-technical project managers were routinely beaten into submission by technical management. Took me ages to get over the shock. But these companies were notorious in the industry for being able to deliver more, faster, better and cheaper than their bloated, suit-driven rivals.

    For any developer going through interviews, I advise you to ask for some time with one or more project managers, get into technical conversation and see what they know. If they start bullshitting and bluffing - decline the job politely and look forward to the interview with the next company.

    Otherwise, your career may suffer unrecoverable damage. Every month you spend in the industry - you are accountable for that time, and hsve to justify it when seeking your next job. Don't be seduced by slightly higher pay packets with the suit-driven outfits - it'll cost you in the long run.

  • corporate culture (Score:2, Interesting)

    by devonbowen ( 231626 )
    I think the biggest challenge you face is changing the corporate culture. I was in a similiar situation a while back and moved into project management. And, you know, it just didn't matter much because the requests for the impossible still kept coming from above. The only difference was that I was responsible for delivering them. A company needs to have a culture of being realistic and that has to come from the top. Without that, I think it's unlikely you're going to change much in that respect.

    On the other hand, the one thing you can change by becoming a project manager is making the lives of the people under you better. You can deflect the blame a bit more and give people the breaks and recognition they deserve. And that is certainly worth something.

  • Has anyone else found the barrier to project management is their technical knowledge?

    I might counter that you have this backwards. As a long-time project manager with a technical background, my feeling is that the barrier to technical knowledge is project management. :-) I really WANT to code or design, but status meetings and budget reviews keep getting in the way. Sigh.

    In all seriousness, though, work with your current project manager. If they are not technical, then they are glossing over things because they don't understand the importance. Testing is a wee bit critical, and unless they are pulling delivery dates completely out of their backsides with no input from you it is partially your fault for the schedules being pushed so hard. Your job is, quite frankly, to manage your project manager. "Manage up". Tell him/her how things are going, exactly, and make delivery scedules completely clear. DO NOT HIDE ANYTHING! The secret to a good relationship with a project manager is information flow. The more s/he knows about exactly what is going on, the more likely you are to be in agreement with schedules. Your PM is getting pressure from upper management to delivery products on time and under budget, and unless s/he knows about schedule slips way ahead of time, or problems with the design, etc, the less time s/he will have to prepare the executives for a change. You are not working in a vaccuum! Your PM is your best (and often ONLY) advocate to the executives, and you need to make them work for you. Believe it or not, I prefer it when I know all the good AND bad things going on so I can protect my team from unreasonable pressure from above and get them the resources they need to finish the work. If I don't know, I can't prepare the groundwork.

    If you want to move into project management, take on more and more of the role yourself. Gather status reports ahead of time and consolidate them into a summary for your PM. Ask to assist in budget preparations or schedule creation. Make it clear that you are there to help, not to hinder, and make it clear that you want to move into that role. Show the merit of a technical person acting in a PM capacity.

    Good luck. And think seriously about it - if you love technical work, you might want to consider staying there, as PM work is NOT technical and you might feel that you have made a big mistake at some point.

  • Nope (Score:4, Insightful)

    by AppyPappy ( 64817 ) on Friday June 21, 2002 @07:30AM (#3742566)
    Programming skills and management skills are mutually-exclusive. I've always found project managers to be hired as programmers who were later found to be lousy programmers. I remember working with one guy who was hired because of a great resume. His first words when he came in the door were "I'm really not technical". He became a project manager because, although he wasn't technical, he gave great face.

    A project manager is basically a eunuch acting as a catcher in a shitball game.
    • Re:Nope (Score:3, Funny)

      by Fross ( 83754 )
      He became a project manager because, although he wasn't technical, he gave great face.

      Is this some euphenism for oral sex I'm not familiar with?

    • Re:Nope (Score:3, Insightful)

      Programming skills and management skills are mutually-exclusive.

      I don't agree with that at all - I think rather that the skill sets are nearly independent - you can be a perfectly good project manager with no programming skills, however being a good programmer doesn't mean that you would be a bad manager.

      There are plenty of examples in industry of good programmers who also have turned out to be excellent managers. Bill Gates is the most famous case.

  • He was a developer in a former life, so he understands what I have to do to get the job done and supports me 100%. Hell, he's kept the heat off of me when a project went over the time frame.

    As your boss this question:
    Would they rather have the correct answer in a day or the wrong answer right now? Of course they want the correct answer, and that's how you then sell them on getting a technical manager. Tell them that while you test as best as you can, you are focusing on the wrong issues which could allow for bugs which will lead to problems and wrong answers. Of course your next question to /. is how to interview a technical manager.
  • I understand your frustration that you see things going badly and want to do a better job, but knowing the details of developers' work is not the answer.

    The best project manager I ever worked with knew nothing about the details. It was in the early days of the Web, building a very complex Web site for a client, and he barely knew how to write HTML. But here's why he was a great PM: He trusted his team, including the technical lead, he understood the people and knew how to get them to work well together, and he knew the importance of high level issues like testing, clear specifications and change control. He was a good *manager*.

    And here's another key to success: strong sales people. Good sales people will get the right cost estimates from the developers/consultants, and then won't buckle under pressure when they present those to the client. Then you actually have time to do the testing which was factored into the proposal.

    I was a very technical project manager, not quite a developer, but I like to think I understood the tech details very well and got on well with my various teams. But I would regularly get bogged down in the details simply because I enjoyed them, and as a result would spend less time on the strategic issues like persuading the client that they should reconsider their latest idea. I think I did well, but I know I could have done better.

    My advice to you is this: talk to your project managers and sales people, and get them to understand the importance of the various stages of work. Show them that a slip early on can lead to more costly slips later. Advise them, and get them to trust you, so that when you say "We need to spend two weeks testing" they make sure you get that two weeks and don't think "Oh, but I'm sure we can get away with a couple of days".

    As for progress in your career, project management is a lot about people and little about knowing obscure technical details. If it's people you want to focus on, then great. Otherwise perhaps you should aim for being a senior architect. And then your company can charge more for your time, and they'll have even more budget to spend on testing!
  • I used to work for a IT company with a creative vent, as a result they hired project managers with ZERO understanding of the tech side, and knew more about making things purty.

    We got by because the project managers knew that they didn't know anything, so they would ask about everything, but that did put a major strain on the tech department as we ended up being consulted about EVERYTHING.

    I am a strong believer that project managers should understand the area that the project is in, they don't have to be a guru but it makes sense that they should at least understand whats going on.

    However I also know that a project manager needs to understand more than 'joe programmer', as business(tm) (as in harvard business school) comes more into there jobs. And of corse they should be able to buffer the programmers from the clients, I know a lot of hackers who cannot comunicate with each other, let alone a suit.

  • by standards ( 461431 ) on Friday June 21, 2002 @07:56AM (#3742615)
    > I may meet resistance from the current project
    > managers - many of them have been hired with no
    > previous experience of anything.

    Really? Wow, you work in an organization where they hire managers without experience, but they also hire quality programmers? Hum, sounds fishy.

    > Previous suggestions to senior management
    > that myself and other developers would feel
    > better with a technical person running projects
    > have been dismissed.

    As someone who hasn't actually managed a project, you're in no position to assess the situation.

    Clearly you can't see or understand your colleauges' contributions or experience. Therefore, you are likely in no position to be a project manager.

    You get to be a project manager by proving yourself, not by telling your management that you're better than others.

    > Has anyone else found the barrier to project
    > management is their technical knowledge.
    > How did you get past it?

    No, the barrier is being an egotistical programmers who thinks that they're better than non-technical people. That's the real barrier.

    I'm technical. But I appreciate quality management, and I understand that they have critical value to the projects we pursue.

    I think that's a start. But I also think you're many years away from being a good project manager. Given your attitude, I'd hate to work with you.
    • Disregarding your aggressive personal attack, some points you maybe haven't considered :

      Many technical people (myself included) have had to take on various elements of project management on various projects, and/or managed entire projects themselves.

      They also quite often turn down 'opportunities' to become project managers, as they enjoy their current role, or wish to follow a technical career path.

      So just because they are technical it would be foolish to assume they lack project management skills.

      On all my projects for the past three years, I have guided my project managers, giving them feedback, prompting them to do the things that they should be doing, ensuring that things they overlook don't get forgotten, and going straight to a customer if the project manager is either incapable or too busy to give me the responses I need.

      I'm not suggesting the project managers are incompetant - just that I am able to do half their job for them, and usually do. However, I am still a technical person and I'll still refuse any project management role offered to me.

      Suggesting that people like me are 'egotistical programmers who thinks [sic] that they're better than non-technical people' is demeaning and inaccurate. I have a skillset that complements that of a good project manager, and although I perhaps lack certain project management skills I don't lack the ability to identify them in others.

  • People Skills (Score:2, Insightful)

    The main reason highly technical people do not get PM jobs, or any high management job for that matter, is becuase people generally do not speak in binary.

    If you can not sell an idea or explain a problem to business management, they are not going to hire you to lead up there technical crew. How would they then understand what the group is doing? EVEN if the PM is a ditz, they at least THINK that they have a handle on the situation. Most technical people I know have people skills that end with video conferencing with their "clan" of Magic players.

    Image is everything in upper management.
  • Sounds to me, from your description, that your company has a bad attitude towards software development. If they're not willing to listen to the developers (and again, from your description, it sounds like this goes above just the project managers), then it's going to be really tough to change the tide.

    I've worked in places where non-technical people were the project managers, and invariably, they were bad project managers. I'm not saying there aren't good ones out there that aren't technical. I just haven't met any of them.

    Not all developers make good project managers, by the same token. I found I wasn't particularly good at it. I'm just not organized enough, and personally, I prefer the development aspect. The one advantage I did have though, was that I listened to the developers, and I understood the issues. I knew what was possible and what wasn't. I knew when developers were being realistic and when they were unrealistic, same for management. Fortunately, I was able to bridge the gap between upper management and the developers pretty well, and I was able to manage the expectations of upper management.

    If your current company is unwilling to bridge that gap, then your situation is probably hopeless, and you may be better served at a company that knows how to develop software properly.
  • Not Quite (Score:5, Insightful)

    by BoBaBrain ( 215786 ) on Friday June 21, 2002 @08:11AM (#3742666)
    Has anyone else found the barrier to project management is their technical knowledge. How did you get past it?

    Absolutely not. Although I have suffered the problems you mention.
    I have found that these are more often due to poor communication between PM and coder. It's the PM's job to direct the project to a successful completion while keeping an eye on resource allocation. It is the techie's job *clearly* explain the technical restrictions and options.

    If you are relying on one team member to have *all* the necessary skills, then you do not have a real "team".
  • by Thunderheart ( 574412 ) on Friday June 21, 2002 @08:12AM (#3742673) Homepage
    Whether its IT, Municipal drafting Electrical or whatever, Engineers (regardless of how long they have "managed" projects) are NOT Project Managers. You frustrate the hell out of me. I've been a Professional Project Manager for years and an Amateur computer geek. The thing that always stuck in my craw is the assumption that just because a person knows an Engineering Discipline that they automatically know how to manage projects. Project Management is a complex discipline and to manage projects well takes a solid educational background in that arena. It is a skill set unto itself. Document Controls, managing Gaant charts and schedules and (especially) managing the "people" end of things takes a great deal of effort to excel at. But NOOOOOO, Engineers always assume that because they can conceive a project, they MUST be able to manage it, and it always ends up as a grand jitterbug called, "Crisis Management". Now, don't get me wrong. Its not like I hate engineers. Many of my friends are engineers. I have spent most of my life working in and around engineers. Engineers are not Project Managers. Project Managers are Project Managers Engineers have to concern themselves with managing details. Project Managers have to manage the "big picture". In the end, if a correct perspective was given to the Project Management Profession was given more respect (or even an open minded consideration) a LOT more projects would complete more successfully.
  • Pick up a copy of Kent Becks' book Extreme Programming Explained: embrace change.
    Where I work, we are in the same situation, both our project managers and sometimes our staff managers have no technical experience.
    I can tell you that technical folk managing projects doesn't work. What this did to us is cause the project managers to do very little, other than sit around and mandadate scope and delivery dates to the technical lead, who has to then force their developers to produce crappy software.
    So, while I don't have a solution, the XP book at least give me hope that there is a better way...
  • by hagbard5235 ( 152810 ) on Friday June 21, 2002 @08:42AM (#3742792)
    I know that there are a lot of rotten PMs out there, but if you ever have the good fortune to work on a project with a good PM you will never willingly work on a project without one again.

    I miss my PM. Her job was basically:

    • Beat up other people to get us the resources we needed to succeed
    • Block outside people from bothering us about things so we could work on the project
    • Keep track of the pedestrian details of the project so that we were free to actually get the work done

    When prototypes for the project were running late, I didn't have to spend endless hours chasing people down and tracking the issues delaying them. My PM did that.

    When the project had slipped 6 weeks, I wasn't the one on the calls getting yelled at and yelling back about the fact that more than 50% of the TYPES of prototypes we needed hadn't even been delivered yet. My PM did that. I was down in the lab working.

    When I had to attend technical calls ( like bug scrubs ) I didn't have to go dig up the bugs being covered so I could review them for the meeting. My PM always met with us 30 minutes prior and went over the list so that we could get things clearly in mind going into the call.

    And when the shit hit the fan, and we were death marching till 2am for weeks on end, my PM was there making sure we got fed ( on the company dime ), and staying late to make sure we did eventually go home and sleep.

    None of this really requires much technical skill on the part of the PM. All it requires is a respect for the team and an understanding that the most effective way to get your project in on time is to support the team. By the middle of the project we ( the technical guys ) where willing to kill ourselves to meet the project objectives for this PM.

  • Before you apply for project manager, read up [] on project management. To me, it sounds like the entire company is fundamentally flawed, and becoming more senior will only worsen your day-to-day life. This book will help you figure out if there's hope. Carefully assess the situation before you make a dangerous leap.
  • ing/Methodologies/Object-Oriented/Extreme_Programm ing/ []

    I have found that an excellent way to get project owners more involved with doing things the right way is to use Extreme Programming

    1) write the tests first (i.e. define the interfaces for the code that is going to be implemented first ... this focuses you to think about design up front)

    2) short iterations - keeps the project in synch with the owners expectations. If an itteration is 2 weeks (my usual cycle), then the owner is always on top of whats going on

    3) continuous integration - everyone must checkin as soon as they've written the code the completes their current task (tasks should never be longer than a day or two). So, if something breaks at most you've only got a day of code to go through and find out where the bug is. And, since you're writing the tests first (i.e. JUnit or its clones [])

    4) Simple design. Never add code that you don't need right now, because you think it will make adding a future feature easier. Often requirements change. The best case is you guess right and you've already done the work by the time you get to that feature. However, if you're even slightly wrong about the feature, then you'll have to rework it anyways, so don't do it ... ever.

    All of these play together to make the boss or project manager more involved (not what you wanted to hear), but in return you usually get more control (including testing) because the tests are actually part of the design process and have to be written before any code is.

    Good Luck!

  • Call CDW! (Score:2, Funny)

    by DickBreath ( 207180 )
    Haven't you seen the TV commercials man!?!

    Fred, what's the matter? We're only asking the impossible.

    CDW's television commercials suggest that they can solve these impossible problems and make everything in your organization work like it should!
  • I have been a PM for four years. I was thrown into my job with no PM experience and no tech skills. However, I did have certain subject knowledge that qualified me. I have taken it upon myself to learn and refine the PM and tech skills.

    I started going to the local comm college to pursue a programming degree. This knowledge is extremely helpful. I have also read tons of case studies on projects to gain PM experience that way.

    In all I am becoming an effective PM with decent tech knowledge. Even if you only take a few programming classes it is very valuable. Other skills to pick up are:

    • Contract negotiation
    • Client servicing
    • Budgeting
  • by Kope ( 11702 ) on Friday June 21, 2002 @09:01AM (#3742878)
    'm a senior project manager in a medium sized company where the programmers have no business experience of any sort. I'm of the opinion that programmers should understand the business that they're part of and want to move into programming myself. I'm aware that I may meet resistance from the current programmers - many of them have been hired with no previous experience of anything. Previous suggestions to senior management that myself and other project managers would feel better with business person programming on projects have been dismissed. As a result we are routinely told to push out deadlines or that our requirements are impossible, with an emphasis on how technically aesthetic things are rather than how well things meet the business requirements. Has anyone else found the barrier to programming is their business knowledge. How did you get past it?"
  • IT sounds to me that you project managers are behaving like non-technical clients, so treat them that way.

    Guide them through the development process, get well defined requirements.
    manage there expectations.
    Get proper business logic out of them
    'I want a button that save the file in x format'
    'I must be able to save the file in x format' and
    'There should be a UI component to do it'

    Then get a decent definition of the format, work through any problems with them and any possible future requirements, Set up some testing requirements. Why do they need to save the file.

    Once this is done, decide where in the UI the save file should be available from.

    It is your responsibility to ensure that the project managers do a good job. Send them back to the clients if there's something missing, set up decent procedures, make sure testing is defined with the requirements so that it doesn't get skipped, and most importantly make sure things are set out in a clear fashion that everyone understands, with out scope for ambiguity.
  • by C_Mattie ( 524585 ) on Friday June 21, 2002 @09:19AM (#3742982) Homepage
    It seems like this is a common theme in this industry as I am sure anyone who has been in it for a length of time will tell. I am in almost in the exact situation, as a Senior Developer answering to managers (and in many instances a VP) with a limited technical background in web technologies.

    One could go further to say our managers "know enough to be dangerous", often claiming they are "technically minded" and feel they inherit the skills of the team they manage, often changing specifications or routinely trying to influence technical decisions.

    So what do you do? Here is a bit of what we have done to make things better:

    Understand that you have been hired to do a job because you are qualified to perform the task. I don't want to sound like a motivational speaker, but you need to be confident in the ability to do your job as an expert. Any influences you try and make to a superior will not be taken seriously if you don't take yourself seriously. And don't be afraid to say "Let me do my job. I am the expert here."

    Next, do the research. Don't walk in and say something like "We need to test our code." That is a given (or should be). Walk into an office with a formalized test procedure printed out in your hand and say "We need to do THIS." Also, try and site specific project management guidelines they are not following. Speak their speak. If you want to argue that a PM is not doing their job, make sure you know what that job is and how they are not performing it.

    That having been said, if all else fails I will quote one of my colleagues: "Be a cock." If you are trying to influence a project manager in accepting what is an industry standard practice, be it formalized requirements definitions, change request processes, staging areas, federated databases or whatever, sometimes you need to "step up" and push the changes through. But remember there is a difference between being a cock and being an asshole. You don't have to be afraid to argue (or fight) with your boss for the betterment of the project, just make sure you can back up your point. "Why are you fighting me on this when the entire industry acknowledges this at the best practice?"

    Donno if this helps. Hopefully it does.
  • Let me tell you straight off: Your problem is not restricted to software development only. I work in mechanical engineering and it is largely the same.

    What works for me is to always ask for a solid project plan. If all's well, if there is a project budget, there MUST be a project plan somewhere. If there is not, find another place to work! The project plan is your best friend if you want to keep your PM in line.

    A good project plan contains at least:
    - Outline of the project goals
    - Project boundaries (what you will NOT be doing)
    - A project planning with a work breakdown
    - Milestones with deliverables and delivery dates
    - Known risks in the project
    - Backup plans to eliminate the risks
    - A cost estimation

    To use the project plan in your favor do the following (in writing!):

    - For every task that does not seem to fit the goals of the project, ask your PM to explain how this contributes
    - For every task that seems to go beyond the projects' boundaries, ask your PM to explain why this is necessary.
    - For every activity for which the planning seems inadequate or unrealistic, ask your PM the following questions: HOW did he estimate a planning for this activity? Did he actually TALK to the people who must perform this activity? If not, on WHAT did he base his planning? Ask him to replan AFTER talking to the people performing the activities.
    - If you see risks to the project that were not mentioned in the project plan (like not testing and such), mention them (of course with a reasonable explanation) and ask your PM to explicitly mention them in the project plan.
    - Of course, ask him to think of a backup plan for these risks (or deliver it to him yourself).

    Ok, the trick to effectively tighten the leash on your PM is to warn him on paper and then, if he doesn't respond harrass him with your remarks during the review meetings of every milestone! If you have valid points, it will reflect badly on him with the management being there and it will teach him to listen to his techies.

    It may take time and you may need to do this often, but I must still encounter a situation where this doesn't work if you are pigheaded enough.

    Hope this helps,
  • by swillden ( 191260 ) <> on Friday June 21, 2002 @10:05AM (#3743247) Homepage Journal

    The company I work for has developed what is, in my ~12 years of experience as a software engineer, the best project leadership approach I've seen. I can't give you any recommendations on how to get your management to try something like this, but I still think you'll find it interesting.

    The fundamental notion underlying the approach is that good project managers and good technical people are somewhat different, and that projects go smoothest when everyone does what they're good at. Another key part of the philosophy is that neither type of person is more important to the success of the project than the other. Ya gotta have both, and they both have to be good.

    So, for every project we have a Project Leadership Team, consisting of a Project Manager, a Technical Architect (funny term, but needed to distinguish from the next guy) and a User Interface Architect (the UI Architect is optional on small projects). These three individuals are *peers*, and all major project decisions are made by concensus.

    Each person has a well-defined area of responsibility, and decisions which lie strictly within that area are only made by that person, although important decisions should be shared with the team. The team also succeeds or fails as a team; praise and blame will be apportioned equally.

    The PM is responsible for building and maintaining the project plan, tracking progress, communicating with higher management and the client (we're a consulting organization) and generally for ensuring an on-time, on-budget delivery. The PM has to know how to deal with all of the business issues and has to be an excellent communicator. Some technical background is useful, but not strictly necessary.

    The Techincal Architect is responsible for managing the daily technical tasks of the technical personnel (all other personnel management tasks devolve to the PM), as well as having overall responsibility for the technical work. The TA sets the technical vision, development standards and guidelines and generally ensures the technical quality of the result. This person must be a very capable designer and programmer and good at communicating with technical people. It helps if (s)he can communicate effectively with non-technical people as well.

    The UI Architect is responsible for gathering requirements, defining the UI (often via a series of prototypes, and occasionally with the help of human factors consultants), managing the UI developers and QA team and generally ensuring the result solves the client's problem. This person must be a very capable UI designer and programmer and must be able to communicate well with both technical and businesspeople. In the case of my company, there are a number of very senior UI architects who have PhDs in cognitive and industrial psychology as well as being excellent programmers with deep knowledge of a wide variety of UI toolkits. These guys are seriously hard to find but amazingly helpful.

    To put it in a nutshell: The TA makes sure the project gets built right, the UIA makes sure the right project gets built and the PM makes sure the project gets built.

    The team members quickly realize that their areas of responsibility frequently come into conflict and that compromises are necesary. Sometimes they realize that the project as planned is impossible; if all three are on top of things then this realization comes early, allowing higher management an opportunity to find or negotiate a solution with the client.

    This team structure is not only very effective, it tends to engender a healthy respect between the leadership team members, since each gets a chance to see into the others' worlds. Actually, each is *required* to see into the others' worlds, since that's the only way to resolve the issues that come up.

    On small projects, there is no separate UI team and the UI Architect's responsibilities can be divided between the PM and the TA (who then becomes the "A"). On very large projects, each of the three leaders will have a small staff of assistants and in many cases the project will be broken into subprojects that each have their own leadership team, with a senior leadership team taking overall responsibility.

    An interesting insight that was pointed out to me a few years back is that this leadership team approach is an application of the Model-View-Controller (MVC) structure to project leadership. This and other concepts allow my company to maintain an exceptionally good track record of on-time, on-budget deliveries (don't know the exact number, but well in excess of 90%).

  • by e1en0r ( 529063 ) on Friday June 21, 2002 @12:17PM (#3744171) Homepage
    I've been a PHP programmer working under several different project managers depending on the client for about a year now. I should mention that our art dept. does the HTML because it might be relevant later. Some key Project Managers are as follows:

    A - Completely clueless. Asks the same questions over and over again. Gives the design projects (HTML) to programming and the programming projects to design. Has to repeatedly be told what a form action is. Doesn't know a database from a cheese sandwich. Often forwards us URLs that he requested asking what they are instead of clicking on them.

    He's the least knowledgable of them all and the worst to work with for obvious reasons. We're constantly having to tell him what we can and can't do and constantly having to redo things because he doesn't get his point across correctly. I had to bill about 3 hours to a client to put a simple counter on 6 pages because 2 hours were explaining things to him and half an hour was redoing the counter because he gave me incorrect instructions. He's technically useless, unwilling (incapable?) to learn and also an incompetant project manager.

    B - When I first started working with him he was very competant in relaying what the client wanted but wasn't as good with understanding databases and general programming stuff. After working on a major site redesign I explained how databases worked in order for him to provide me with CSV which I could correctly import. It was important he knew the reasons because he had to explain them to the client. I explained a lot of what can and can't be done and by the end of the project he was entering data himself saving me hours of work.

    This guy is a pleasure to work with. He knows enough to be helpful but not enough to be dangerous. He'll ask us how long something takes to do and will accept our answer without questioning it. He'll give us plenty of notice when things are due and listen to our suggestions about due dates. He doesn't always know if something is possible or impossible, but he'll believe us when we tell him we can't do it.

    C - This guy claims he used to be a programmer. He's new, so I have less experience working with him. I just started a new site with him and because he claims to know programming and design he wants to play a big part in all 3 roles. He knows enough to be dangerous and is always asking "why?" and wanting to see my database table structure.

    This guy is a pain in the ass to work with. He seems to know what's possible and impossible, which is important, but unfortunately he doesn't take suggestions because "he's a programmer". He knows enough to be dangerous and his curiosity is time consuming.

    After working with these project managers for a while, this is the conclusion that I've come up with.

    Clueless morons will always be clueless morons.

    Just because someone knows programming, doesn't mean they'll be a good project manager. It depends on the person, of course, but this could actually be a detriment if they insist on sticking their noses into things too much.

    A project manager that you can teach and mold seems to be the most important. If they're competant and willing to learn they'll be the biggest asset. They don't need to understand for loops, but if they listen to you and trust you then you'll do well. The 5 minutes that it takes to quote them a time estimate is not a big deal. The hour it takes to explain to them why that's the case is a big deal.

    Most importantly in my job is the fact that the project managers have to listen us and when they do question us our boss will resolve the situation.

10.0 times 0.1 is hardly ever 1.0.