Slashdot Mirror
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?"
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 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.
chongo (was here)
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.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
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
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.
No Zen is good zen
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!)
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.
now we need to go OSS in diesel cars
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
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.
Trusted Computing FAQ | Free Dawit Isaak!
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 very well in practice, but it will never work in theory.
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.
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?
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.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
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.
If you aren't part of the solution, there is good money to be made prolonging the problem
> 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.
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".
I am a Karma Library.
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.
I miss my PM. Her job was basically:
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.
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.
This is pure trash. The fact is that most programmers don't and don't really care to understand much about the business. That's exactly the reason that you need technical leads or TPMs who understand both the business requirements and enough of technology to make reasonable trade-off decisions, and either work closely with a business-oriented PM/requirements person, or have excellent rapport with upper-management (i.e. have their trust - not be perceived as a lying technology person).
'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
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.
thank God the internet isn't a human right.
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.
"If you're not failing every now and again, it's a sign you're not doing anything very innovative." -- Woody Allen
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
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%).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
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.