Project Management For Programmers?

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?"

Comments

help your PM help ypu

[chongo]

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.

Stop whining, start doing.

[smoon]

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.

Re:Stop whining, start doing.

[ThePilgrim]

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.

Re:Stop whining, start doing.

[Fnkmaster]

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.

Re:Don't want to discourage you, but...

[lennart78]

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.

They told you no because you knew *too much*?

[ObviousGuy]

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.

Don't mix management and architecture

[rsmah]

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

[soegoe]

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.

In a nutshell.

[Fross]

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 ;)

Fross

(a technical architect working as a project manager!)

Only bad managers demand the impossible

[Skapare]

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.

Re:Only bad managers demand the impossible

[Surak]

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.

Re:Only bad managers demand the impossible

[Aceticon]

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)

<SELF-COMMAND RANT-MODE="OFF"/>

Re:Only bad managers demand the impossible

[gallen1234]

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."

Re:Only bad managers demand the impossible

[Beliskner]

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)

Re:Only bad managers demand the impossible

[Grab]

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.

Grab.

Re:Only bad managers demand the impossible

[Surak]

When my current manager informed me, a month before the project deadline, that oh-by-the-way, the program would have to be distributed on separate systems *on segregated networks*, and I took a deep breath and tried to meet him half way, he put held up his finger to silence me. He turned to the whiteboard and wrote the word NEGOTIATION on it. Then he turned back to me and said, "This is NOT THAT. I am the manager. I do not negotiate."

This guy doesn't know what he's doing. Any third year CS/CIS student can tell you that the only way you can be sure to get a systems development project done on time and on budget is to get ALL the requirements down before anyone writes the spec document, and well before anyone writes a SINGLE line of code. Otherwise, your project is most assuredly going to be wildly off schedule and cost way more than the budget.

If I told you to write a quick- & dirty ANSI C compiler for some platform that needed one (and you couldn't use gcc for licensing reasons) for some reason, and then one month before the deadline I told you that oh, BTW, it has to compile C++, C#, and Objective C code too, you'd probably tell me that you had to rewrite at least half the code.

That's because you started with the basic assumption that you were writing only an ANSI C compiler, and therefore didn't plan on any other languages in the interests of getting the thing done as quickly as possible.

You know this, I know this, but it's clear your boss doesn't have a clue, and therefore shouldn't be managing professional software developers. I think you don't need to be a programmer to manage programmers, but you DO have to have a grounding the basic concept of programming.

Project Managers don't need to be techies...

[PinglePongle]

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.

It's all about trust...

[Kaneda]

I am a project manager in a technical environment, and learnt a few important things.
Having former programmers as project managers can work, but it's certainly not a recipe for success.

A project manager's role is about being able to zoom in from a general, bird's eye view, right down into the details, and then knowing who to defer to for decisions when they are out of their depth. A good project manager will identify and document the risks way ahead of them becoming problems, but won't necessarily dig in and try solve the problems themselves.

It's all about managing the project - that means the customers, the timelines, the risks, the documentation, the testing and the delivery.
It's not about managing people or code.
Yes, I've seen managers fsck up projects because they have been tempted to make technical decisions that they are not qualified to make.
But a good project manager will know when to take the advice of experts.

Re:Don't want to discourage you, but...

[anshil]

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?

Nope

[AppyPappy]

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

[the eric conspiracy]

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.

How to NOT be a manager

[standards]

> 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.

People Skills

[Retard Sevant]

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.

Not Quite

[BoBaBrain]

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".

Engineers are NOT Project Managers

[Thunderheart]

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.

Read XP Explained

[foo(foo(foo(bar)))]

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...

Nothing beats a good PM

[hagbard5235]

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.

I couldn't disagree more...

[gustar]

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.

Try Using eXtreme Programming

[poiu]

http://directory.google.com/Top/Computers/Programm 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 http://www.xprogramming.com/software.htm)

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!

Just the reverse ...

[Kope]

'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?"

Managing you PM's like Non-Tech clients

[oliverthered]

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
So,
'I want a button that save the file in x format'
becomes,
'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.

What we had to do...

[C_Mattie]

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.

The solution is a solid project plan

[Delgul]

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,
Delgul

Re:Eject, eject, eject

[robathome]

Never work with a project manager who hasn't been a developer himself.

If one were to follow that advice, one would be in a constant search for employment in today's world. The fact is that the vast majority of Project Managers are business grads who have little, if any, technical knowledge. Their responsibilities are to develop the business cases and ensure that the product meets their needs.

The problem arises when one of two situations occurs: the project manager wants to make technical decisions, or the developer refuses to take the business case into account. As a systems engineer and product developer, I see both of these frequently, and the key to resolving them is tact. In a development role, I always try to keep technical scope and specifications under control. I also consult with the PM to ensure that I understand the business need, so that I may prioritize development efforts. Too often, developers feel the need to do what they consider the "Right Way" or "elegant", and completely miss the mark on what the end user wants.

become a project manager yourself, it's not rocket science.

Yes, sometimes you do need to think like a manager. There will be times when expectations are totally unrealistic. Then, your own management skills must kick in. Negotiate priorities, flex timelines, get more resources allocated. If the parameters are completely bogus, you need to be able to not just point out what won't work, but to offer workable alternatives in order to achieve the desired end result. If there's no budging on any of these criteria, then perhaps you're in a bad situation. However, to dismiss every PM out-of-hand because they haven't been in the trenches as a coder or engineer only sets one up for failure.

Have a requirements list at your hand ...

[nograz]

Whenever you have a meeting with your PM, have a in one form or another a list of the current project requirements at hand. Whenever he asks for a new feature you show him the list and say something like: "Ok, here we have our current requirements. Which one would you like to put back in favour of the new feature" (politely). From practice I can tell you that this works wonders ...

Take a Project Management certification course

[nvts]

I recently found such a course offered by Villanova university. I talked with a Villanova rep and he indicated the response from companies hiring people going through the course is very positive. The course is completely online and you have like 8 weeks to do it all.

Taking a course like this would put you ahead of those that have neither the project management background or skills and those with a tech background who want to move into project management but don't have a background in it.

Make sure you understand the real role of the PM.

[debest]

I am one of those "non-technical" project managers you refer to, and I can assure you that your company is a rare breed: one that does not put a "subject matter expert" at the head of project implementations.

However, you should know that the role of a project manager does not mean that he/she should be able to personally implement any of the tasks that need to get done. The PM is, above all, an administrator. The PM's responsibility is to formulate the project plan (with the project team's input), monitor the execution of the tasks, control issues/risks/changes/etc., and manage the hand-off of the project deliverables into the business' day-to-day operations.

Yes, the PM cannot communicate effectively with his/her team unless he/she has at least a clue as to the jobs that each member does. But seriously, a clue is really all the PM needs! Managing a project effectively does not mean being able to step in to give assistance if a project is short-staffed or the deadline is moved up. It means that the PM will *manage* (facilitate more resources if possible, make sure that the project's problems are reported appropriately if not). Ideally, a PM is MORE effective if he/she is not actually doing any of the tasks to completing the project: such tasks tend to be distracting to the (supposedly) primary job of project management. If the project is small, then (again, ideally) the PM should manage more than one project.

It doesn't sound like the PMs in your company are very effective, but that has nothing to do with being non-techies. ANY PM that dictates unrealistic deliverables or deadlines without buy-in from his/her team is a poor PM, regardless of technical know-how.

You also say that you want to be a project manager. Are you willing to let go of your desire to jump into the weeds when you see problems? Because if you don't, I can assure you that other things are going to slip your notice. And what if you are the "superman" who can be cheif-of-all-things on a project? I would be nervous if I was your company's management and your project is critical. If you were to leave the company (for any reason, including an accident), there would be an impossible hole to fill.

A GOOD project manager can effectively manage just about any project, as long as he/she has a clue. This is not to say that you are not a good PM: I'm just saying that project management and technical know-how are mutually exclusive skills.

Darren Best, PMP

Project Management is management

[MacDude1]

Aside from the obviousness of the subject line, project managers should be, first and foremost, GOOD managers - in all that entails. That being said, a good manager listens to the experts on his/her team and judicously balances that with the needs of the company. Too many PM's allow themselves to be bullied by one side or the other. Sr. mgmt bullies them into the low-cost (on the front end) solutions; while the tech experts bully them into the best technology they know exists (by saying things like 'we can do it the other way, but my way is the RIGHT way to do it.'). That may not always be an accurate statement.

My point is that both sr. mgmt and the tech experts have a stake in their point of view. It is the PMs job to make sure the needs of the company are met - fiscally and technologically. There are always trade-offs between expediency and and technology. That is why PMs have to focus the project. How long does this solution need to work? 3 years? 5 years? What is the true budget for this project? Can I spend a bit more on testing? Do those end users really need those screens re-done or are they fine the way they are? Is it reasonable for sr. mgmt to expect this solution will provide X,Y, and Z when we agreed it would only do A,B, and C?

These are just basic examples, of course. So, to stay officially on-topic, it is important that the PM understand/empathize with the programmers' and designers' work, but not that he/she be an expert in those areas. A PM should be comfortable with all aspects of the project - programming, design, test, build, finance, IT infrastructure, etc. A jack of all trades but master only in diplomacy and management.

On the flip side, a PM who has a programming background may not end up being a good PM because he/she will always want a hand in the actual programming. This is a grave danger to the project because the PM has to take a strategic view of the situation and not a tactical. The PM cannot afford to be up to their proverbial elbows in programming or testing because then they tend to lose sight of man-hours or other critical elements.

Now, move PM from a mid-size or large company to a small business and all this goes out the window! There the PM is usually the one performing one of those key functions in addition to overall project responsibility.

Heh. If this analysis impresses you and you are an employer looking for a PM who thinks this way - give me a call. :-)

Re:Don't want to discourage you, but...

[shayne321]

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.

Shayne

Re:Don't want to discourage you, but...

[Hector73]

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.

Re:help your PM help you

[dubl-u]

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.

Re:Don't want to discourage you, but...

[chris_mahan]

How much you want to bet that ship captains don't know how engines work? It's like asking whether truck drivers know how a diesel engine works. Of course they know.

And I bet the ship captain knows too. There would be something funny about a freighter captain not knowing how the engine works as his/her ship battles a typhoon in the middle of the night 600 miles from the coast of China.

Now, he may not know how to tear it apart and reassemble it, but he will know how it works, how much to ask out of it, how long it needs to warm up, how much fuel it takes at what speed, how much maintenance it needs, and so on.

Likewise the product manager and/or planner may not know how to compile C++ code, but he/she should understand what headers are, what OO is, what procedure calls, COM, and that sort of things are. He/she should also know how much work is involved, and how to allocate the right amount of personnel resources, hardware resources, software resources, adequate office space, adequate working environment, adequate communication channels between workers, and so on and so forth. This sort of knowledge does not come in easy, and if the Board Of Director in their Wise and Excellent Counsel fail to realize that a marketing VP cannot lead a team of programmer, then the future is grim, and maybe the typhoon will take that company down to great unchartered depths.

Your tech knowledge is not hampering you

[wealthychef]

It is not your knowledge of technical matters that is hampering you. It is your LACK of knowledge about topics that your managers value that is hindering your efforts. You obviously don't understand their philosophies and probably come across as having an agenda that is different from theirs. Management includes politics and the ability to compromise and see the other side. Work on those skills and regard your techie skills as just one arrow in your quiver and you'll be better off.

Project Management for Programmers

[jjmahone]

You all have valid points about the issues you see, and have experienced. I guess my two cents would speak to project organization, and role definition.

System Manager/Customer: Their job is to understand what problems or opportunities they want an application or blown out system to address/fix. The groundwork is primarily laid out by the customer utilizing the talents of a business analyst during a survey/discovery phase. They are the customer, therefore they're responsible for participating in the project as much as any other group, from requirements delivery, to testing, etc.

Project Manager: They're not necessarily a manager. They're job is to serve as an interface to the customer. Get an idea of what it is the customer wants, the timeline for delivery, facilitate Joint Meetings with the customer and the technical team, track resources, and costs associated with the project, determine milestones within a project, project critical path, etc. The role of a project manager is the role of a coordinator/accountant. The project manager should serve as the communication focal between the customer, the technical team, and the management that both sides respond too. A project manager does not have to be a developer, nor should they be making any technical or design decisions of any kind within a project. That's not they're role, because keeping everyone on the same page, monitoring the product development life cycle and calling attention to scheduling and resources issues, and tracking overall project cost should keep them more than busy enough. Project manager's should also be sharp enough to recognize the requireds in a project . . . make sure agreements are made and signed on, as well as indentify product support issues, and generally understand the overall software product development life cycle, and then the support and maintenance life cycle that comes after deployment.

System Architect/Technical Lead: Their job is to run the development team, schedule all technical activities and administer the work, and provide the overall vision of the product based on requirements that came from the customer. The schedule of activities along with the estimates that have been derived by the system analysts, and developers then goes to the project manager who puts the information into the schedule and works with the the tech lead to mitigate resource constraint risks, and other cost related issues.

Think of a project team in terms of three arms of the project. System Management/Customer, Project Management, and Technical. The roles of couse can shift, but this is a sound view, and will give you a guy idea of who's supposed to be doing what. Another view is that the customer and the development team are two roads that intersect at the project management intersection.

I really don't think a project manager should have to know a thing about development as long as all three of the project arms are there. For crying out loud . . . project management is newer as a discipline than software development. Project Management came from the construction industry as a means by which the overall cost of a construction project could be lowered, by closely tracking deliverables and alerting management and the customer when deadlines weren't being met on milestones.

By the way, I'm a developer.

thinking in a vacuum

[Walter Wart]

Quite a number of people have said, in effect, "Being a manager is being a manager. It has nothing to do with the process being managed." Thus, it is not a problem if software PMs know nothing about the field.

One wonders what color the sunsets are on the planet this people come from.

I've worked in several industries other than software - construction, education, medical research, nursing, and nuclear engineering. In all of them a manager had to understand what it was he or she was in charge of. They were generally senior practitioners in the field?

Why?

Because you would have to be insane to pick managers any other way.

Look at what a PM has to do. He has to make schedules and estimate costs. He has to make sure all the members of the team are working efficiently. He has to handle the unexpected, keep the customers happy, manage the supply chain so that the vendors deliver what is needed without robbing the company blind. And so on.

Unless you have a thorough understanding of the industry you are working in none of this will happen. Estimation will consist of dollar figures and dates pulled out of your butt. You won't have the confidence of the people who are working for you. A crew can deal with a boss who is a competent jerk. But they can't be effective if they know he hasn't got a clue about what he's doing.

The vendors will deliver crud and demand gold bars for it. Because they know nobody will do anything about it.

The customers will be unhappy. How else? They've been promised the moon in two weeks. A year later they haven't got anything. In an established industry like construction the liquidated damages would have begun months ago.

I passed this thread around the office where I work - a medium large construction company. The unanimous response was "How the hell can you make money like that? Are software executives all smoking crack or something?"