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
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.
I have been pwned because my
The Trick (TM) is to get you and your PM (even the whole company) to work on improving it's underlying processes and procedures.
You need a clear Statement Of Work (hopefully up front), and clear procedures on how the entire project plan, development, testing, and delivery should work. It takes time, effort and sometimes blood, sweat, and tears, but it's worth it. You'll be more focused, more productive, and there will be fewer problems from start to finish.
I'm personally of the opinion that good technical people do make good project managers, but only when they are not working as a developer on the same project. Mixing the two usually doesn't work.
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
Most of the clients I've worked with have had project managers of two types:
... the "overcommitting" project managers I've known seem to be doing quite well.
(a) No technical experience,
(b) Outdated technical experience.
The best project manager I've worked with was probably one from category (a). Category (b) project managers tend to be dangerous because they have a superficial understanding of what you're doing and (1) can't understand why it could be hard, or (2) can't understand why you need to use all these new-fangled techniques like object-oriented programming and refactoring. I've only worked with one person who had up-to-date technical experience but he had little power for other reasons, so hard to generalize.
The fact that you recognize that your PMs may be making inappropriate commitments, etc., may mark you as someone who wouldn't fit in well at some organizations. The basic cycle seems to be that the PM gets pigeonholed at a meeting with muckety-mucks and is asked leading questions like "can this be done in a month?" Not knowing, and afraid to tell the important muckety-muck "I don't know, I'll need to get back to you," the commitment gets made. Then they come back to you, intending to force you to get it done. Or they already know it can't get done but intend to show a tremendous amount of effort toward the goal to "prove" to the muckety-muck that it was impossible. ("Everybody worked 70-hour weeks for a month and it still wasn't done on time.")
All of this is not really to criticize PMs -- it takes a brave soul to stand up to that sort of onslaught. The question is, will you be as good at dealing with higher-ups (who do not like to hear the word "no") as it sounds like you will be at dealing with programmers? The first audience is probably more important than the second to your professional success
I did!
But I do know your problem. The problems with skipping testing and implementation is useally not caused by lack of technical knowledge.
The problems is IMO more a project management problem. In the projects I was working, useally the problem was laying the deadline on delivery date. In stead of on the date when the tests are supposed to start.
Time for testing etc. all to often becomes slack. This is because nobody 'represents' the testing period.
The delivery date useally is hard. Either because the product has to start making money or you have a customer that demands delivery.
---
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.Sorry, but I think your project manager is completely right. People don't want programs that work correctly, they want programs that look good. Indeed, the "blue screen" would be much more popular if its design would be more appealing (users would try to crash the system as often as possible if blue screens were replaced by cool animations with a great sound).
Georg
A few years ago I worked for Keane, a company that REQUIRES that programmers learn basic project management and then encourages them to play a role in managing the projects they are working on.
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
Several functions are covered by the term Project Management: engineering management, techinal lead, management of project...
;-) I mean the kind of discussions which also involve managers from documentation, quality assurance, even technical support (to ensure the future supportability of the product.), production manager...
If you complain about Project Managers, it is because your company uses them to do exactly that, manage the project: making sure that the deliverables arrive on time, more or less answer the request from end customers or Product Managers, and in return gather their input or feedback. A project is also the immobilisation of a great deal of money, and someone as to be responsible for that.
That choice of the company calls for a counterpart of the Project Manager, with equal power in the "discussions", a Technical Leader which would enlight them in These Issues that are dear to your heart
I guess becoming a project manager will not be the right answer to your concern...
If they at least have some background knowledge of the production process and the technology behind it.
...... Only in my experience I've found that those without the knowledge don't even know when to ask :0P
:0D
If your project manager lacks the knowledge to make imporant planning decisions early in the project they should at least know when to ask for help and opinions of those that do know
Our company (a very small web developer) recently underwent some serious downsizing, and not by choice. The first staff to go were the project management staff that had been screwing things up by misscommunicating issues with clients and making promises that could not be kept. Since then the more senior members of production staff have been left to manage themselves and the junior staff members.
Not surprisingly there has been a lot less go wrong lately, our relationships with clients has improved in a big way, and our general reputation as a web developer is on the up.
There are disadvantages to being a project manager that knows the tech side of things (eg. knowing when to deligate to others and not take on too much yourself), but IMHO get rid of the nimrods that don't know what the techies are doing and things will run a whole lot smoother
Why do today what you can put off until tomorrow?
The reason is, that a (good) leader-type manager is humble, acknowledges his own lack of technical insight and thus listens to his crew, while a technical manager might fully understand the schedule and risks, but is unable to resolve interpersonal conflicts, favour technical solutions instead of customer-requirements or simply fail to turn the upper-managements attention to important desicions.
I work for a machine-manufacturing company, where software is just one of many ingredients of a machine, and mechanical design is very important. Thus, our PM (and many others in leading positions) is a mechanical engineer from the start, but he is very open to suggestions and arguments from us software designers and gives us lots of freedom.
Despite his technical background, I rate him as a leader-type manager, because of his interpersonal skills and total lack of experience in research-driven projects.
Alas, this is the story being played out in development shops worldwide. By all means you should make a move into management; you'll be worth your weight in gold. Once you are worth your weight in gold perhaps you'll look for a more receptive place to work as well?
As most people who read slashdot know, there is a certain amount of personal interest involved that draws people into the computing field (because right now it's not the money or abundance of jobs). It's a totally different frame of mind that would draw someone to business and I personally don't understand that frame of mind. I doubt that a large number of people who enjoy science and technology have a large interest in business management and vice-versa. This is the reason we have so many managers who don't understand the limitations of technology, and the proper procedures when developing a new program, etc. I suppose in reality the best we can do is try to communicate the complexities of our jobs to our managers; try to bridge the gap.
It's too bad there's no intermediate-level "boot camp" for technical project managers. It's not that I ask for a boss that can *do* my job, merely one that understands what is and isn't possible to accomplish.
amyt
~what, no witty signature?~
echo $wittysigline;
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!
Take this how you want... I'm a PM at Microsoft, and in the Microsoft culture as a general rule project managers with deep technical knowledge are very highly regarded. Some of the senior management have staggeringly deep technical understanding. Myself, I am/was a low to mid level programmer, and my technical skills in my PM role are valued.
:)
So, you could always move to Seattle... soul selling optional
Supervisors supervise. Most companies are currently deploying the managed type of internal structure, with the theory that a manager can manage anything. Fewer companies are using the supervised type of internal structure. Both methods have their pro and cons. But in the long run a supervised company will have fewer employees with higher salaries, but it will cost less to operate.
Get a free ipod.
The fundamental problem at hand is that most projects need to combine "product" or "business" considerations with considerations of technical feasibility and trade-offs. Projects managed with "product" understanding but poor technical knowledge end up late, expensive, suboptimal, and with frustrated programmers. Projects managed with technical understanding but limited insight into the business objectives and considerations end up spending a lot of resources solving low-value-added problems, things that come up during the project are often poorly evaluated, and (notably) those projects frequently err with respect to ensuring a good adaptation to the context in which the technology will be applied (organization, processes and people).
This problem is greatly aggrevated by the fact that "product PMs" tend to believe that they know enough about technical implementation, and techies tend to believe that the "product" part of the job is "piece of cake" compared to the technical challenges of the projects.
Another complicating factor is that project management is a discipline of its own, and anyone without some training in this will be a dabbler and probably underperform. Unfortunately, in my experience, "product" people tend to have a stronger background in this field than technical people do.
The best solution in my experience is to have a "product person" who has final authority in the project, but to have a technical PM whose job it is to execute that persons specifications according to agreed deadlines and budgets (i.e. the technical PM is the one who schedules activities, creates fabulous GANTT charts, pushes for deliveries etc.). I have, however, seen non-tech people do well in the hands-on PM roll. In these cases those PMs have had the brains to understand enough of the tech part to be relevant in their role.
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.
SYSTEM ADMINISTRATION!
I don't need no stinkin' Project Admin's
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.
What you are experiencing is anquish caused by the incompetent management skills of others.
If you care so much about how a job is managed. Perhaps you should be managing? But then who'd do the developing? Someone else?! NEVER!
Almost all developers I know experience what you are experiencing.... It is in the nature of developers to be bothered about how absolutely everything works... Developers are almost always managed by people who are not as diligent or as qualified as themselves.
But you face a choice.. Do you move into management and wasted your talents? Or do you get on with your job?
If you don't like the management. You can always change positions?
i just completed a software engineering masters, i work as a developer and was unhappy with the bare minimum of technical stuff they included in the course. it turns out my year was the last one enrolled on that particular course - the new course next year has ALL technical stuff removed and is purely on project management and testing procedures. interestingly enough part of the course covers seeking correct technical input from development staff and deriving accurate metrics from them - which as a developer i find a bit insulting.
:-(
i think in the future we cannot rely on PMs being promoted from developing staff but being recruited with an entirely different set of skills. inevitably there will be friction and dissagreement between team and PM
You're in big trouble now...
I work in the IS dept of a multinational as a "systems manager", responsible for the SDLC of several existing apps and for guiding dev of a couple of new ones. My background is from the business (niche finance) but I've acquired a fair bit of technical nouse in the last 5-6 years, and I've met lots of "technical" consultants, "business" consultants, god help me "Business Process Reengineering" consultants, along with the developers who have worked with/for me. Some non-techs have been great architects/designers and some techs have turned out to be great "business process" people...
Yes, PMs need to have a good working knowledge of the technology and tools (and most importantly, some idea of what the developer's job is _really_ like), but don't necessarily need to be able to do it themselves...
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?
Then, the next time you are in one of those post mortems because your useless PM fscked up, tear his/her project apart in front of some senior managers. Point out the flaws. Suggest how things could have been done better and how to get things back on track. Have purdy gant and pert charts and so on to back it all up. Know the facts and figures. Don't directly blame the PM, but leave the implication hanging. For bonus points walk the walk after talking the talk and deliver what you suggested.
Do it right and you'll get a fat bonus, pay rise, satisifaction of an incompetent leaving your life and kudos from your colleagues.
UNIX? They're not even circumcised! Savages!
Believe me, from what I have seen, PMs have to put up with a lot more crap from business lusers.
Personally speaking, I would rather be writing code than putting up with the politics and lack of knowledge.
Based on my experience I can't understand why anybody would want to become a project manager. It's a rotten thankless job and you've got zero job security. You're basically being squeezed between management, who hands you an impossible job and to few resources to do it and the techies who cant deliver the goods fast enough. While this goes on you have to do a lot of political infighting to steal more resources for your project, prevent other projects from stealing your resource's and competing with the other project managers to look good in order to still have a job in six months. Being a technical lead is a better job by far (been there) but only if you work with a pm who is actually listening to you otherwise you are a perfect candidate for a scapegoat... The real trick is to focus very hard on requirements even if this means that analysis drags on for ever and the pm is pesting you to get it over with. Make a document that can stand up in court and don't accept any changes without extra resources or a reduction in other functionality. Make a formal procedure for these changes (they will happen). And when the shit hits the fan: ALWAYS SIDE WITH THE TECHIES. The techies are mostly honest and rarely play political games. The pm's are always up to something and ready so sacrifice you in a heartbeat if it helps them in their games.
TCAP-Abort
Unless you own the company, let them make their mistakes. Put in your advice, and if they take it and benefit, so be it, but otherwise, you can - and under certain circumstances should - move on at their loss. It's not your company to run, and if the company fails, it's not your fault. Constructively critise, but don't undermine the managers opinions.
;) )
Don't blame the mangers, either - someone put them there, and I have seen poor management come from resentment towards techies as much as incompetence. They are people, get to know them, and you may find that they agree with you in assessing their own shortcomings. From that admission you have options - management need not imply dictation.
Do your personal due diligence, but if the owners don't ask for your help, don't go out of your way to offer it. Save your energy for bigger stakes, IMHO. ("Owners" is vague, I know, but this is slashdot, and I'm being sweepingly vague
The position of "technical manager" is more appropriate for you. It's the perfect way to add technical knowledge to management.
It won't threaten the other managers as much because you are not competing directly with them. In fact they usually welcome the addition of a technical manager, it relieves them of the technical responsibilities.
It will be more interesting for you than PM because there is only technical stuff to deal with, and none of the "management" stuff that requires an entirely set of logical tools and morals.
Finally, it will be an easier introduction to the world of management because there will be less to learn since you are staying in your field.
If later you are still interested in pure management (why?!), the position of technical manager is a perfect stepping stone.
So, what are you waiting for?
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...
... is well documented. Welcome to the real world
I think it's wonderful you and others have found a creative way of channeling aggression. And of course, much thanks to slashdot - providing an outlet for all this negative energy is a great service.
Man, I feel your pain. I, too, have a non-technical manager; the hell of dealing with this... this... this non-technical manager has got me looking for a new job. A single example. A couple of weeks back, a story about our company broke on a Friday. Over the weekend, several tech news sites picked it up (including Slashdot) and the general consensus was, "Company X are evil, rude, and generally Bad People." On Monday morning, I asked the PHB whether he'd seen any of the terrible press we'd just picked up. His response, dripping with sarcasm: "And *why* would I be reading Slashdot or ZDNet over the weekend?" I gaped at him, barely able to believe my ears. "Er... because you might be interested in events in the industry you work in?" "Not at the weekend, matey! What sort of an idiot do you take me for?"
This guy earns (counts on fingers) about US $100,000 per year for giving me stupid things to do, crossing out my estimates of how long programming tasks will take and reducing them by 40%, cracking lame jokes (and then laughing at them himself), irritating the **** out of all around him and generally being a complete gimp. Worst manager I ever worked for, no contest; and the most hated by his team, and indeed colleagues.
I'm almost tempted to stay, just so I can witness the inevitable payback.
Pick up a copy of "Project Management for Dummies". Leave it on your desk for all to see. Now, walk around the office alot, talking quite loudly about project management and GANTT charts and how you are an expert. They'll love it.
I think there are not many things that "are impossible to implement". Hey, we are technicians, right? We CAN send a man on the moon. It's our mission to do the impossible. I like to say to myself "I'm an engineer, I can do it!"(r).
...but can you afford it?"(r)
There is, however, another side of the story. We can do it. But we need resources. There is a poster here in my office, saying: "YES!
I think you should try to explain to your PM that some things are very EXPENSIVE to implement. Then it's up to him to decide if a feature is worth it - or, to put it another way - is he able to sell it for more than it costs.
I've been working with many different PMs so far. Some of them had good technical background and some of them none. It IS easier to talk with a "techee" PM, but a "non-techee" has other qualities. It is, however, important that your PM understands software development process. But that is another story.
Regards,
Jernej
n0sp4m_jernejkase@hotmail.com
My development manager announced today that Macromedia Flash is the future of e-commerce.
uh huh...
No, I did not read the f***ing article!
I think the biggest challenge you face is changing the corporate culture. I was in a similiar situation a while back and moved into project management. And, you know, it just didn't matter much because the requests for the impossible still kept coming from above. The only difference was that I was responsible for delivering them. A company needs to have a culture of being realistic and that has to come from the top. Without that, I think it's unlikely you're going to change much in that respect.
On the other hand, the one thing you can change by becoming a project manager is making the lives of the people under you better. You can deflect the blame a bit more and give people the breaks and recognition they deserve. And that is certainly worth something.
Devon
Previous suggestions to senior management that myself and other developers would feel better with a technical person running projects have been dismissed.d j0202q/0202q . tm
:
Look at a recent DDJ editorial:
http://www.ddj.com/documents/s=2287/d
Has anyone else found the barrier to project management is their technical knowledge. How did you get past it?
Wrong question. The right one is
Why is there no (or very few) way for technical persons to evolve and be recognized without choosing the dark side of the force?
How come peoples who choose to work with computers, often because they have a straight and scientific state of mind, are obliged, in order to progress, to choose management, which is not the most scientific process?
As for test avoidance and look first, if they can not change their point of view, in the long run, they are doomed. Consequently, you too, if you stay.
"I'm a senior web developer in a medium sized company where the project managers have no programming experience of any sort"
Land of the fucking shit managers who dont know what the FUCK they are doing. "Maybe I should give the programmers the ability to create checkpoints in the version control system we are using?" Yeah, maybe, Sherlock. Who else is going go do it - you ignorant FUCK!
a good project manager is somebody who gains respect of his programmers. These are the 10 ways how - sticks up for his team always - says "no" to unrealistic timeframes set from management - says "no" when management want to ship extra functionality before the release - can help fix the toughest bugs that are delaying the schedule - has been there before in the programming world and has learned a thing or two. - always promotes his team and does the best by them - does not take credit for others :- always distributes it back to the team.
- pushes management to reward his team for performance
- pushes management to give promotions where they are due
- takes the blame if anything goes wrong and quitely works with the team to get it fixed.
Unfortunately, typical project managers have few, if any of these qualities.
Rate your own PM ...
consider coffee a lubricant that helps one penetrate the coding zone
I never tought that someone with no programming experience could run a project ! :)
I think you may try again to push the demand to your boss.
Project leaders must be Programmer/Analyst
Tom DeMarco Rocks! He also has a book called Why Does Software Cost So Much? Overall it's ok, but it has a few choice essays that every manager should read. Tom also has a fantastic essay on professionalism.
The most incompetant people are promoted to the positions where they can do the least harm: Management.
Has anyone else found the barrier to project management is their technical knowledge?
:-) I really WANT to code or design, but status meetings and budget reviews keep getting in the way. Sigh.
I might counter that you have this backwards. As a long-time project manager with a technical background, my feeling is that the barrier to technical knowledge is project management.
In all seriousness, though, work with your current project manager. If they are not technical, then they are glossing over things because they don't understand the importance. Testing is a wee bit critical, and unless they are pulling delivery dates completely out of their backsides with no input from you it is partially your fault for the schedules being pushed so hard. Your job is, quite frankly, to manage your project manager. "Manage up". Tell him/her how things are going, exactly, and make delivery scedules completely clear. DO NOT HIDE ANYTHING! The secret to a good relationship with a project manager is information flow. The more s/he knows about exactly what is going on, the more likely you are to be in agreement with schedules. Your PM is getting pressure from upper management to delivery products on time and under budget, and unless s/he knows about schedule slips way ahead of time, or problems with the design, etc, the less time s/he will have to prepare the executives for a change. You are not working in a vaccuum! Your PM is your best (and often ONLY) advocate to the executives, and you need to make them work for you. Believe it or not, I prefer it when I know all the good AND bad things going on so I can protect my team from unreasonable pressure from above and get them the resources they need to finish the work. If I don't know, I can't prepare the groundwork.
If you want to move into project management, take on more and more of the role yourself. Gather status reports ahead of time and consolidate them into a summary for your PM. Ask to assist in budget preparations or schedule creation. Make it clear that you are there to help, not to hinder, and make it clear that you want to move into that role. Show the merit of a technical person acting in a PM capacity.
Good luck. And think seriously about it - if you love technical work, you might want to consider staying there, as PM work is NOT technical and you might feel that you have made a big mistake at some point.
Weaseling out of things is important to learn. It's what separates us from the animals... except the weasel. -
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
Never work with a project manager who hasn't been a developer himself
This means one thing to me; you are completely incapable of explaining technical things to people in a non-technical manner. If you knew how to communicate a bit better then your project manager needn't be a programmer. What you have above is pure nonsense; the best managers that I've had have been non-progammers who completely understand their business and how our software product fits with the business... programmers often don't get this aspect of things and thus are in a bad situation to make the business case for alternative directions, etc.
Me? Got 20 years in this business. Lot's of projects.
Starting when you were 8 right?
He was a developer in a former life, so he understands what I have to do to get the job done and supports me 100%. Hell, he's kept the heat off of me when a project went over the time frame.
/. is how to interview a technical manager.
As your boss this question:
Would they rather have the correct answer in a day or the wrong answer right now? Of course they want the correct answer, and that's how you then sell them on getting a technical manager. Tell them that while you test as best as you can, you are focusing on the wrong issues which could allow for bugs which will lead to problems and wrong answers. Of course your next question to
III.IIVIVIXIIVIVIIIVVIIIIXVIIIXIIIIIIIIVIIIIVVIII
I met a GOOD project manager. Its easy to blame a manager's lack of competence on lack of technical skill, but thats rarely it.
Of my managers at my current company (I've had six of them), by far the best was one who was non technical. the worst was someone who was technical (DO NOT fall into the "I know XYZ better than the engineer" trap. Even if you do, you need to enable your engineer to resolve the issue without so much as the letters T-C-P coming out of your mouth...)
I understand your frustration that you see things going badly and want to do a better job, but knowing the details of developers' work is not the answer.
The best project manager I ever worked with knew nothing about the details. It was in the early days of the Web, building a very complex Web site for a client, and he barely knew how to write HTML. But here's why he was a great PM: He trusted his team, including the technical lead, he understood the people and knew how to get them to work well together, and he knew the importance of high level issues like testing, clear specifications and change control. He was a good *manager*.
And here's another key to success: strong sales people. Good sales people will get the right cost estimates from the developers/consultants, and then won't buckle under pressure when they present those to the client. Then you actually have time to do the testing which was factored into the proposal.
I was a very technical project manager, not quite a developer, but I like to think I understood the tech details very well and got on well with my various teams. But I would regularly get bogged down in the details simply because I enjoyed them, and as a result would spend less time on the strategic issues like persuading the client that they should reconsider their latest idea. I think I did well, but I know I could have done better.
My advice to you is this: talk to your project managers and sales people, and get them to understand the importance of the various stages of work. Show them that a slip early on can lead to more costly slips later. Advise them, and get them to trust you, so that when you say "We need to spend two weeks testing" they make sure you get that two weeks and don't think "Oh, but I'm sure we can get away with a couple of days".
As for progress in your career, project management is a lot about people and little about knowing obscure technical details. If it's people you want to focus on, then great. Otherwise perhaps you should aim for being a senior architect. And then your company can charge more for your time, and they'll have even more budget to spend on testing!
In my experience project managers like to have a technical team member whom they can trust. A sparring partner (might as well stick with PM lingo) who can be trusted to see beyond the technical side of the project and understands the importance of budgets, client needs and so on. Project managers are like most professionals; they don't necessarily want an easy job, but they want to be succesful.
Don't reject your PMs bollocksy timelines out of hand, but work with him to show what the result of following that timeline would bring. If your PM thinks to skip testing of the product, it's best not to act like the haughty technical prima donna who refuses to release anything untested. Instead, talk about risks and alternatives. If you know of any past famous projects that failed for poor planning, show him what he is getting into.
Do this well, and PMs will start to know you for someone who helps them rather than someone who'll dig his heels in. Perhaps at some point you'll be asked to be technical manager for alarger project. That's the perfect job for those who are thinking about a management position but not ready to give up on technology.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
I used to work for a IT company with a creative vent, as a result they hired project managers with ZERO understanding of the tech side, and knew more about making things purty.
We got by because the project managers knew that they didn't know anything, so they would ask about everything, but that did put a major strain on the tech department as we ended up being consulted about EVERYTHING.
I am a strong believer that project managers should understand the area that the project is in, they don't have to be a guru but it makes sense that they should at least understand whats going on.
However I also know that a project manager needs to understand more than 'joe programmer', as business(tm) (as in harvard business school) comes more into there jobs. And of corse they should be able to buffer the programmers from the clients, I know a lot of hackers who cannot comunicate with each other, let alone a suit.
c.
> 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.
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.
Any streaming sites out there for the Germany/USA match?
Sounds to me, from your description, that your company has a bad attitude towards software development. If they're not willing to listen to the developers (and again, from your description, it sounds like this goes above just the project managers), then it's going to be really tough to change the tide.
I've worked in places where non-technical people were the project managers, and invariably, they were bad project managers. I'm not saying there aren't good ones out there that aren't technical. I just haven't met any of them.
Not all developers make good project managers, by the same token. I found I wasn't particularly good at it. I'm just not organized enough, and personally, I prefer the development aspect. The one advantage I did have though, was that I listened to the developers, and I understood the issues. I knew what was possible and what wasn't. I knew when developers were being realistic and when they were unrealistic, same for management. Fortunately, I was able to bridge the gap between upper management and the developers pretty well, and I was able to manage the expectations of upper management.
If your current company is unwilling to bridge that gap, then your situation is probably hopeless, and you may be better served at a company that knows how to develop software properly.
So the little PM wants absurd things ? Chances are that your project schedule and budget are arbitrarily determined from above anyway. When the schedule is determined by the big boss's promotion schedule, and the budget is determined from how much is left over after they pave the parking lot, well, maybe the best option is to put in your 40, shut up, and be happy. Oh - make sure to not to take any stock options as pay.
If America started to execute retards, there would be 5 people left in the entire 50 states. Actually, maybe its not a bad idea.
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.
The best project managers have a great understanding of technical issues, a clear thinking head, and a willingness to argue their side.
I've also worked for some shit project managers:
I've worked for 'Add up and divide by 2' managers. They listen to two opposing viewpoints and suggest the exact middle ground.
Hierarchical database vs Relational?
Lets store this part of the data in an hierarchical database and this part in a relational.
I've seen project managers concentrate on what they know to the exclusion of real work:
One project that needed a decision on the programming language to use (Java or C++), instead he spent the two hour meeting discussing the *layout* and *typeface* of the specification.
It quickly became clear he didn't know what a compiler was. But he did know how to format a mean Word 6 document!
You're in a no win situation, find another project.
The obvious question is why? As a developer who became a project manager by default/accident one day, I'm still trying to find my way back. Anyone know how to do this apart from the obvious one of screwing up a project and getting myself fired?
When the leader is killed, everyone moves up.
But you can read the live text comentary at http://news.bbc.co.uk/sport3/worldcup2002/hi/match es_wallchart/germany_v_usa/default.stm though.
Germany 1 - 0 up on the 38th minute. 43 minutes.
The one thing I've missed so far in this thread is what a Project Manager (PM) can bring to the table to help their technical staff.
Frequently, at least on smaller projects, the PM is the Team Lead. Realizing then PM's often do not have technical knowledge what can they do? Simply put: define a schedule of milestones with clearly defined short-term goals. By clearly defined I mean is either done or not-done; a 1 or 0 if you will. Track these goals. Revise the schedule and keep it visible to the team (put it in version control!).
Also, estimates while necessary are usually meaningless; at least I have seen very few accurate project estimates. Reason being that they are only based on experience (if lucky) or wild assed guesses. Until you have tracking in place for prior timelines on that project or other similar projects, where you can then use empirical data to make your estimates, making them good is black magic at best.
Tracking then is where a PM also adds the most value for a technical team. Many times I have seen the "schedule" issued as if it were the 10 Commandments given to Moses by God, only to see it abandoned because no tracking, or God forbid, revisions were done along the way.
So to recap for PMs out there to help their technical staff:
I think developers (or DBA's :-) ) make better project managers than MBA's, *provided they understand business*. That means a) speaking to business managers in their own language and understanding their problems and perspectives and b) understanding what execution is. Honeywell's CIO defines it as. "aligning strategy with reality, goals with people." Take that philosphy as a project manager and, if you have any people skills at all, you will be a raging success. And on't forget to sweat the details!
a set which your technical skills may add to or subtract from... Maybe you should actually find a decent project manager, better yet a genius PM, and get yourself assigned to his/her projects and use him/her as a mentor. It is not the same skill as programming by yourself or even running a small team of "buddies".
Where I work there are three project managers. One is really good... one is decent... and the third just sucks. The good one is not technical. The other two are.
The reason why she's good is because she knows how to be a MANAGER. Good managers realize their strengths and their limitations and rely on the people they are managing to fill in the gaps. She is extremely good at listening to client requirements and when a developer tells her that something is impossible or unrealistic, she is not afraid to tell that to the client. Because there's no BS on her projects, the client almost always (unless they are unrealistic people) comes away happy with the finished project because they weren't lied to and their expectations were MANAGED to be realistic.
It takes a certain type of personality to be a manager... most engineers don't have it.
--
"What do you want me to do? Whack a guy? Off a guy? Whack off a guy? Cause I'm married."
My Boss is a lousy developer. He's often nagging about "wouldn't just a threeliner workaround do the job?" and stuff like that.
But when things get tight and I'm willing to stand a fight, he shuts up and listens and usally keeps the customers of our back - our argues with them. The other side is of course that if he hadn't promised "the blue from the sky" - as we say in germany - we wouldn't have gotten into the corner in the first place.
Bosses are that way. Their sellers, and if they stay fair with me and pay my roll, I'm the last one complaining about them being lousy developers.
A PM has to be a bit of bouth. Pushy to the devdept., but ready to listen to a well prepared (not only the PMs and CEOs doing rubbish, mind you...) argument from R&D - if marketing and R&D work the slightest bit together in that way, things usually turn out well in the end.
If not, companys usually go belly up when VC runs out the latest.
Think about what category yours belongs to (and what category of developer you are!!!) and act acordingly.
We suffer more in our imagination than in reality. - Seneca
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...
what you need to do in a situation like this is show management and the PM the downstream effects of their decisions.
First step is to document the SDLC process, including how to handle Change of Requirements.
Whenever PM requests changes to process, simply send email to PM "I understand that you want us to skip testing phase for project..."
When things explode further down the track, you will have the data to go back and explain why things have turned to custard. Schedule a project review meeting, and make this info (internally) public
Over time, you should be able to demonstrate significant difference in outcomes between projects executed according to process, and those where process steps were missed (not just testing, but perhaps time to redesign given change in requirements, or even just to design at all)
Once the value of the process is proven, you can then make it very difficult for PM to force a project to step outside of the process.
How cute.
I heard there is another company with that problem, the uri: is here.
The teacher was a moonlighter, having a day job for the political police as a senior project manager. First of all, the class had three times the ordinary number of people, so we wasted three weeks splitting the group in three.
Then we had to work on our projects in teams of 10 people, which made managing the meetings as much work as doing the project itself.
Then I was canned, because when you're 38 years old, you just cannot learn by heart a 50 paragraph text like a 18 year old can (and then the teacher said that there was plenty of erroneous information in the text). I was canned despite our group project ending at second place when it was evaluated by the second in command of the political police...
So, if you like bullshit and nonsense stuff, go for project management.
A large part of the problem employers have with putting programmers into project management roles is that though programmers do have more experience directly with the types of projects they'd be managing, they don't necessarily have a good familiarity with the responsibilities of managing a project.
Rather then simply suggesting to senior management that it might be a good idea, you need to familiarize yourself with project management skills and requirements. That way, when you approach senior management, you aren't just the employee looking to control his own destiny...you're a guy who took some initiative to prepare himself to take on more responsibility (sounds a lot better, doesn't it?).
Since you mentioned that you're a web developer, I'll give you a place to start. Kelly Goto (http://www.gotomedia.com) is an expert in the field of Web Development project management. Her book, Web Design: Workflow that Works is an excellent starting point and reference for web developers looking to get into project management. I have read her book, and seen her speak at several conferences, she is clearly a person who has made the transition from web developer to project manager.
Hopefully, this info will help you get started on the path to managing your own projects! Good luck!
Holy crap. You just spelled out my daily reccuring nightmare with my project. I am not however an IT prof. I am an Electrical Engineer. But here is the jist, if you take a project management job, and know nothing about your product, or the technology behind it, you better learn FAST. And if you use any excuse as to why you don't need to know that much, you are only hurting yourself and the company. You can only help yourself by staying educated about your product. I think it would also keep your customer happy if you know what you are talking about!
This is not a magic answer, and it doesn't always work, but: if you want your boss to understand why you come to the conclusions you come to, make sure your boss has the same information you have.
This won't work if, for example, your boss does not WANT the information. It also won't work in a basically dishonest situation (one where your boss is not levelling with you.)
Still, there ARE many situations where communications can help.
In the case of a nontechnical manager, for example, gradually feed him technical information at a level he can understand and use. Most nontechnical managers DO want to understand something about what they are doing. Cynically, one might say they want to LOOK as if they understand, but the most effective way to look as if they understand is to ACTUALLY understand...
Don't challenge his authority ("you're nontechnical, ergo I don't accept your authority,") help him to do his job better.
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.
I study in Cumputer Sciences in a North American University, and most of the professors here don't know what an e-mail client is. Then, they tell their graduates students to code stuff they couldn't do themselves. And some most of the graduate students don't really know how to code. Then, these people become project managers. As an undergraduate and employee, I'm afraid about the day I will work for one of these persons...
I know where you are coming from. I have dealt with inept project managers in the past. There really isnt much you can do, unless your project manager will listen to you and your suggestions. And that is a 50/50 shot at best. The only thing you may be able to do, depending on your corporate environment is talk to the project manager's superior and see if they can help. If that is not an option, the project team can appoint a "shadow" project manager that does understand how things get done and have the "shadow" try to work with the real project manager. Its just a thought. All else fails, do what most of us do, grin and bear it.
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.
Before you apply for project manager, read up on project management. To me, it sounds like the entire company is fundamentally flawed, and becoming more senior will only worsen your day-to-day life. This book will help you figure out if there's hope. Carefully assess the situation before you make a dangerous leap.
Stop the brainwash
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!
---
"Don't anthropomorphize computers. They hate that."
Once upon a time ...
... there was a great king who desired to give a State Dinner for a few thousand of his closest friends. He called in his Chief Artisan and informed him of the dinner plans. The king described how he wanted the finest table settings, all in gold and encrusted with intricately carved jewels. The Chief Artisan did some sketches and agreed with the king on what the settings would be like. They agreed to meet again in a few weeks and look at the schedule for production of the table settings.
A few weeks went by, and the Chief Artisan came to report. He showed the king a time schedule showing creation of prototype settings, review by the king, and production of the final table settings. The schedule showed that the settings would be finished in November, but the king preferred to have the party in October, when the weather would still be fine. The Chief Artisan agreed to adjust things for completion by October before the next meeting.
On schedule, the Chief Artisan appeared with prototypes, and a revised schedule for production, showing completion by October. The Chief Artisan also recommended that they meet at regular intervals to check progress. The king reviewed the prototypes, which the Artisan had simplified because of the shorter deadline. The king requested more cherubs on the plates, more beautiful carving on the embedded jewels, and more complex scrollwork on the knives and forks. The Chief Artisan protested that these new features would jeopardize the schedule, but the king reminded him who was king and who wasn't. The Chief Artisan withdrew.
At the next project review, things were measurably behind. There were too few jewels ready, so that the plates were not complete, and there were far too few knives and forks done. The king demanded that the artisans work harder. The Chief Artisan protested, but the king again reminded him of their relative positions. The king demanded additional reviews, even more frequently than already agreed to.
At the next review, not much more was done. The king insisted on visiting the shop to see what was being done. The next day he arrived. The artisans were a bit nervous, but they knew their arts and mostly continued with their normal efforts.
"What is that man doing?" asked the king, pointing out an obvious slacker.
"He is resting his eyes and hands, O King," replied the Chief Artisan.
"An egregious and insulting waste of Our time," declaimed the king. "They should rest at night, not while working."
"It shall be as you say, O King," answered the Chief Artisan.
"And that man over there," asked the king, "what is he doing?"
"He is sharpening his tools, O King."
"Again a waste of Our time. No wonder you are accomplishing so little. Henceforth, tools are to be sharpened at night, not on the job."
"As you wish, O King," sighed the Chief Artisan. They parted until the next review.
Halfway to the next review, the Chief Artisan sent to the Chief Steward, requesting some new apprentices to help with the work, specifically with sharpening the tools. The Steward, mindful of the King's budget, solved the problem in the age-old way of Stewards, by not replying to the request.
At the next review, more work was in fact completed. The king inspected the pile of completed plates and utensils. At first he smiled in satisfaction, but as he looked more closely his smile turned to a frown. "These plates," he growled, "the cherubs are rough, not fine, as were the earlier plates. Our guests will not be suitably impressed if this is the best you can do."
"The work is rough, O King, due to the use of dull tools, as you commanded."
"We did not command you to do poor work, Artisan, We commanded you not to waste time!"
"O King," the Artisan explained, "just as Your Majesty cannot have a good party without good food and settings, my artisans cannot create good art with dull tools."
"Must We tell you everything?" screamed the king. "Have someone else sharpen the tools!"
"I have requested new apprentices for just that purpose, O King, but the Steward has not responded to my request."
The king roared, "Do not bother Us with these internal matters, Artisan. We are the king. Allow the artisans to sharpen their tools as needed: but they must make up the time by working overtime."
"It shall be as you say, O King," responded the Chief Artisan glumly.
The king returned to the inspection. Soon, he was again enraged. "These plates, many of them do not yet have their carved jewels. What is wrong here?"
"There has been increased spoilage of jewels, O King," replied the Chief.
"What is causing this," boomed the king, "Are your people so completely incompetent?"
"With all due respect, O King, jewel carving is a delicate task. Without frequent rest periods, the carvers eyes tire and their hands shake, resulting in spoiled work."
"You tiny fool," boomed the king. "you must punish the workers who spoil my precious jewels. Clearly they are not being careful enough."
"It shall be so," bowed the Chief Artisan.
At the next inspection, the king swept into the area filled with suspicion and with a visible air of challenge. When he saw that quality was improved in the carving he calmed a little, and when he saw that most of the plates had their jewels, he became almost happy. Then, however, he counted the stacks of completed work and found that while quality was up, not as much work was completed.
"What are you doing wrong now, Artisan? Must you yourself be punished?"
"O King," replied the Chief, "several of my key artisans have become ill from the punishments You ordered and cannot work. As well, a few have left the kingdom and gone to the neighboring kingdom, saying that their work will be more appreciated there. As a result, we have fewer workers and can produce less work."
"We ordered that your artisans work overtime," roared the king, "has there been no improvement from this?"
"In fact the reverse has happened, O King. Again, there have been those who have left the kingdom in search of a place where they will be more appreciated. Those who remain are mostly from the lower ranks, and while they are energetic, they lack the experience to do the work you require. And as they tire from overtime, again there has been spoilage and lost work."
"This is unacceptable! We are most disappointed in you, Artisan. Return to your quarters and await our decision as to your fate." The Chief Artisan withdrew, certain that his days were at an end.
The king was mightily concerned. The Chief Artisan had failed him, and surely must die. Yet the State Dinner was important and the settings must be completed. And, though the king hated to admit it, the Artisan had tried mightily to do as he was commanded. The king decided to consult his Wizard, who had been his mentor and sounding board since his youth.
Before he could summon a messenger, a loud explosion and a cloud of smoke announced the arrival of the Wizard. It was said that the Wizard always knew when people thought upon him.
After jumping a bit, the king wasted no time. He described the events surrounding the dinner, then stated his concern. "Wizard, it seems to me that the Chief Artisan has disobeyed me and must die. And yet, do not We bear some of the blame for the problem through Our inability to advise him properly? And in any case, without the Chief, how can Our artisans possibly prepare for the dinner?"
The Wizard reached up and plucked a pigeon from thin air. Drawing his dagger he contemplated viewing the pigeon's entrails for insight, only just in time remembering that he was in the throne room. Stuffing the pigeon into one of his capacious pockets, he instead snapped his fingers, producing a brief flash of flame followed by a plume of smoke. He observed the smoke as it dissipated, discerning patterns that only he could see. At last he turned back to the king.
"Majesty, I have long studied these problems and can offer some insights. There are four, and only four, Aspects of work which we must consider. And these I call Resources, Scope, Quality, and Time. Immutable laws of nature relate these Aspects. Let us consider them and how they are related."
The Wizard went on: "I call the work Your Majesty demands, the sum of all tasks, Scope."
"A curious name, Wizard, but I am familiar with your arcane ways. Go on," said the king.
"Consider now the Resources: the number of artisans Your Majesty has. If an artisan be lost, shall the work, or Scope, increase or decrease?"
"It depends on whether the lost artisan be good or bad, and what responsibility he has been given," answered the king.
"You are wise, O King. Yet Your artisans are quite capable, as You justly require, and surely they divide responsibilities generally wisely. That being so, what then shall be the result of reducing the Resources?"
"We still demand what We demand. And the work must be of the highest Quality. Then it must take more Time," answered the king thoughtfully.
The Wizard nodded. "Just so, O King. If Scope and Quality change not, and Resource is reduced, then Time will stretch out. Wise you are."
The Wizard continued: "Now, O King, consider what must happen if we hold the Resource constant and demand that the artisans produce the same work in less time. What will then occur?"
"They will labor harder so as to please Our Majesty?" the king asked hopefully.
"This has been Your Majesty's experience?" asked the Wizard slyly.
"No," the king admitted, "although they tried. At first it appeared to be working, but overall they got less done, and when We demanded more output, the work itself was poor. Working them harder only resulted in poor results, and some key artisans actually fled the kingdom."
"Can you put this in terms of Scope and Quality, O King?"
"Let me think, Wizard. Ah, I see it ... if Resource
and Scope remain the same and Time is reduced, then Quality must inevitably be
reduced."
"Yes, O King," agreed the Wizard.
"But this is unacceptable," cried the king. "The goods we receive must be of the highest Quality!"
"Then, Majesty, what can be done?" asked the Wizard.
Thinking, the king gazed out upon his kingdom. "Your questions are challenging, Wizard. But let me think, I can see through this maze of yours. Wait, I have it! You would have me realize that even I, your king, cannot dictate all four of these Aspects. If I hold Resource, Time, and Quality to myself, then Nature controls Scope. And yet if I hold Resource, Quality and Scope, then Nature must control Time. Is this your lesson?"
The Wizard replied, "You speak wisely, O King. It is as you say. Your artisans are serving you well within the limitations given. They will apply their skills to their best ability at all times, but they cannot change this law of nature."
"Can I then do nothing, can I have no idea what will be accomplished, or when?" cried the king.
"Not so, O King. In his work, Your Artisan well understands the relationship between the Aspects. If You will tell him Your wishes regarding three, he can estimate the value of the fourth. And though events may change the results in detail, he can keep You informed of progress against his estimate, in time for You to prepare for the outcome. If You work with him on the Aspects, he can progress most effectively, and You can guide him effectively to the best result."
"Well done, Wizard. You have assisted Your king, and in the doing saved the life of the Chief Artisan."
With this, the king turned to dismiss the Wizard, only to find that he was already gone. Shrugging, the king summoned the Chief Artisan.
The Chief Artisan entered the room expecting the worst, yet knowing in his heart that he and his workers had been doing their best. Trembling but erect, he awaited the king's word.
"Fear not, Artisan," the king began. "I now see what you have been trying to tell me. I rely now upon you to tell me how best to prepare for the dinner I have in mind. Be aware, however, that the invitations are out and I cannot bend on the date. Would more artisans help?"
The Chief thought briefly, then produced his answer. "We might improve by adding a small number of artisans, but this will have little effect in the time left, or may even slow us down as we teach them our methods."
The king began to glower, then remembered what he had learned. "What, then, do you recommend, Artisan. I know that you desire only to serve as best you can."
"It is so, O King. Here is my solution. We cannot much change our Resources, and the Time is given. Your Majesty must have the highest Quality, which leaves us with only Scope to vary."
"You use terms which I have only today learned, Artisan," remarked the king. "Have you been speaking with my Wizard?"
"Indeed, O King, he advises us often in how we do our tasks, which he calls Work Process. He is strange, yet his ideas have worked a powerful effect."
"Strange he is, Artisan, strange indeed. But go on, what of Scope?" said the king.
"Here is what we can do. We can produce all the place settings you need, of the highest quality, by reducing scope in any of these ways: we can return to the simpler design of plates which we showed you, removing the cherubs; we can provide simpler utensils, though still of the highest quality; or we can produce fewer plates or utensils. Among these, Your Majesty may choose."
His Majesty thought, then pronounced his decision. "We will have the appetizers during the tour of the Royal Zoo. I will have the cook produce food that can be eaten in one bite, from the fingers. This food shall be served by the loveliest maidens, who shall circulate through the guests with trays. Thus we will need fewer dishes and utensils."
"It is good, O King," said the Artisan. "Yet still the time will be tight. There remains a risk that we might not complete our task, hard though we will try." The Artisan made to leave.
"Hold, Artisan, hast thou learned nothing? We have not as yet done Our Royal Part, if there remains risk. We shall say further."
The Artisan waited.
The king continued, "Yes, We have it. You will carry out all three of your suggestions, ensuring the best possible result for the State Dinner. You will make fewer plates and utensils as We have already commanded. Those which you make, you will make simpler, yet still as high in Quality as We deserve. Can this be done?"
"Of course, O King," said the Artisan, now almost calm. "If I may suggest, we might lavish the bulk of our effort on the dinner plates, leaving the other dishes simpler, as a frame for the main course. And similarly we will keep the utensils simple, again setting off the beauty of the dinner plates."
"Yes, Artisan, this will suffice," said the King. "Is there anything else?"
"If I may, O King, two things. First, should anything go wrong, I crave permission to change the details of the designs to ensure delivery. I will of course inform Your Majesty immediately to be sure you agree."
"Good, Artisan. But more: you must call upon Us for further creative reduction of your effort if it is needed. Just as We can change the appetizers, We can change the desserts if need be."
"You are wise and powerful, O King. It shall be as you say."
"And the second thing, Artisan?"
"It is too soon to be certain, O King, but it may be that we shall exceed these goals rather than barely meet them. Should this be the case, would you prefer that we enhance the designs accordingly, or perhaps you would wish some small gifts for your guests?"
The king beamed. "Now you sound like Our true Chief Artisan, supporting Us in every way. We see now that by releasing you from undue pressure We free you to do more, not less, to please Us. But let Us not speculate now. When you find that you can do more ... wait, as the Wizard would say, when you find that Scope
can be increased ... see Us then and together we will decide what to do. Perhaps we
will even give your people some time off ... no, this is, after all, only the 10th
century. I am ahead of myself. Workers' rights are centuries away. In any case see
Us, and together we shall decide what to do."
"As you wish, O King," said the Artisan. "I am now certain that we can serve Your Majesty as You deserve." He bowed and withdrew, happy to have his head still on his shoulders, and confident that his artisans could perform as the King required.
The dinner was a great success, and the Chief Artisan even struck up a lively friendship with one of the serving wenches. As it turned out, they all lived happily ever after.
Although it may not only apply to the new media industry, it seems allot of the project managers and indeed a majority of the designers/middle management seem to come from a paper based designing background - or at least the experience ive had points to this. In this sort of enviroment, the only functionality they need is that the page of a magazine turns over, the rest is all asthetics. This, to a couple of the companys I've worked for at least, is a a huge down fall, they know of the techincal background work, they're just to the opinion that it supports the foreground design work, which leads to little designing and poor to no testing beyond the scope of the developer testing it himself. Inevitably of course the company quickly realises that perhaps they should of been listening to the developers constant dribbles of moaning, but by this time, both the companys I've worked for realised this far to late.
...the real f*cking world. Scope creep, no budget, bare minimum of resources provided (if that), and nothing but blame when you can't deliver the near-impossible on time. Solution? Become a manager yourself. Kind of like sleeping with the enemy, but you need to be out of programming and into managemen in your early thirties anyway, or else you become a fossil no one wants to dig up.
Haven't you seen the TV commercials man!?!
Fred, what's the matter? We're only asking the impossible.
CDW's television commercials suggest that they can solve these impossible problems and make everything in your organization work like it should!
I'll see your senator, and I'll raise you two judges.
I've been a developer for almost 20 years now and it always amuses me to see complaints like these.
Developers are funny creatures. I once did a talk where I asked the audience, all developers, to think about their favorite project. Then I asked for a show of hands from those whose favorite project had been a "success". I'd say only about half the audience raised their hands.
We do not always define success the same way that others do. I know of plenty of developers who simple chase the latest "kewl" technology and couldn't care less if the product eventually released.
Business requirements ARE important. Sometimes deadlines ARE hard dates. Sometimes is IS better to release a partially functional first release and improve it later.
These are also issues that developers have a hard time accepting, but are true nonetheless.
If the project manager says "I need this by this date" and you do not believe it is possible, then you have to negotiate. "I can do this by this date, or I can do this by that date, or we can drop this requirement and do what you want". Let the pm make the business decision but don't act like you are some sort of inert object which simply experiences bad management. A lot of times bad management occurs because developers aren't getting involved in the decision process.
http://fifaworldcup.yahoo.com/en
bp
I started going to the local comm college to pursue a programming degree. This knowledge is extremely helpful. I have also read tons of case studies on projects to gain PM experience that way.
In all I am becoming an effective PM with decent tech knowledge. Even if you only take a few programming classes it is very valuable. Other skills to pick up are:
"I don't think it's selfish, to eat defenseless shellfish." -NOFX
Have a read on that and some other articles in the archive. I am sure you it will help you put your thoughts in some order. You can then give it a try (diplomatic one) and move the waters a bit.
Just my $0.01
Marcos
I get stuff that actually cannot logically work that I can prove cannot logically work all the time.
I have found even if the manager has a teck. background thouse unatainable requirments with no testing still happen. I see 3 posible reasons for this. 1. The manager just pretended to be a teche to get a managment job. 2. The higher income causes half the brain to shutdown. 3. They have come under the control of the dark side. (Marking)
I belive that real tecke have no desire to be managment. If a true tecke has visions of managment inorder to control the stupidity; Think again. In the last year I have seen 4 teckes cross over to the dark side only to discover they had even less control of the project and were only supporting the evil empire. Lucky once this was discovered they returned to the light. This left upper managment in a delima. The pratice of promoting from within was not working. The current management came from ouside the group as a fake tecke and a non tecke.
Teckes don't worrie there is ------------ Lets just say it involves a 386 and fake skin and hair.
'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?"
You stated that previous suggestions of getting a PM who knows something about the technical issues have been dismissed.
I've been in this exact situation - same job titles, etc. Worse, I was actually the one who kept the PM looking good enough to get up the chain into that job. I paid for my mistake, let me tell you.
Regardless, any job which involves liason between two areas (general management, and technical project details, in this case) REQUIRES a degree of experience in both areas. This is no different.
If you company doesn't understand something as basic as that, then start looking around for a better company. They probably won't last so long, anyway.
Been there, done that. Depending on the political climate, you have have screwed yourself because you spoke out. Done that too. :(
In my case the following occured when I realized we were lead by the unititiated, and for YEARS tried to make change:
Essentially, by speaking my mind, and giving my opinion what which way the IT area should be headed, I got labeled Anti-Microsoft (when in reality, the guy in charge would want anything MS even if it didn't really fit the need. An NBM-er.) What they really wanted was lackeys. I left within 6 months of receiving a 'Dedication to Excellence' (or something) award.
My suggestion is to write down all the positives and negatives of your current boss, and if you were boss. If it seems to make sense, and management's decisions fly in the face of logic, just leave.
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
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.
i firmly believe that if you are a manager and higher up than me, that you should be smarter than me and someone I could come to with questions. however that is not how it works in the real world.
Managers do just that: manage. they manage a project and make sure that deadlines are being met and that the staff has what they need in order to meet those deadlines. They are not there to answer your technical questions. Managers aren't experts in the area that they are managing and not required to be. Hell I've worked with some that haven't even turned on a computer before. All they need to be is very organized, communicate good with their staff and get people to follow their leads.
It's hard for us as IT people to have follow people tha we deem less intelligent than us. In this game we are playing, the smarter you are, the more successfull and praise you get. We don't close deals or catch the winning pass, we program and figure crap out. So for us to answer to someone who isn't on the same level as we are, is kinda a smack in the face.
Just remember that this is a hacking club where the smartest person is the leader. This is a job and in some jobs the dumbest person leads the crew.
Never mind, evidently that was just live stats. And part of it wasn't working.
bp
Our department (part of a large company) has a lot of project managers. The main way those people got to be project managers was by either screwing up when they weren't PMs: when you screw up, no one wants to use you on projects, so your only move is to become a PM.
.forward file. That seems to be their only purpose: forwarding email.
Since our company has no method of firing people unless they kill someone on the job (and even then, you could probably talk your way out of it), you get a lot of people with technical know-how, basically stuck doing all the implementation (since they are the only ones who can consistently do their job), with PMs who are, for lack of a better word, useless.
We suffer the same maladies as the poster: PMs who don't understand how to schedule, who don't know what requirements are, care only about the look of the site, and who never follow any sort of logical process. Our quality control is basically done adhoc (and sucks), but no one cares.
Much of the problem is the culture, which seems to reward spending more time and money on a project, rather than getting it done quickly and effectively. We let customers run the process, and the PM will allow the customer to make whatever changes they want, regardless of the impact on the schedule/budget, then basically blame everyone else when the project fails/goes over budget.
Technical people as PMs are actually no better: they tend to see the inefficiencies, but no one wants to change their methods, so frustration settles in.
I could easily replace 90% of the project managers in our department with a
My advice would be to work on your resume.
The biggest worry I'd have at a job like that is the incorrect evaluation of my procifiency and progress based on inaccurate or incorrect standards. I don't want to be fired/promoted because of how my apps look, I'd want to be recognized for building solid, stable, functional apps.
In this situation, you're being judged on purely arbitrary parameters that have little relation to what technology's true business goals should be.
Another disconcerting problem with this scenario is the likelyhood that they would promote from within to management is rather low, if they do not value technical expertise. You can't expect to make it into a managerial tech position from within further down the road if tech expertise isn't one of the primary prerequisites for attaining that position.
I'd move on as soon as a bigger and brighter opportunity presented itself if I didn't have a TRUE tech manager.
Well, if there's money in the budget, you could always do like we had to do on one of my previous teams. We had the developers talk to the middle-man, and the middle-man spoke with the managers. The middle-man had some programming experience, and some management experience.
;)
He also knew well enough that a project that needed 6 months to complete couldn't be done in 6 weeks, and he made sure to tell the clients/managers that. He also had to translate coder talk to manager talk, a very impressive feat to say the least.
After he arrived, the projects went much smoother, and we even let him code once in a while
Glen
Track your fuel economy
You lucky you have A Project Manager. That's a non-existant position at our company. We are developers, we are project managers.
As usual, the whole point has been missed here. The current model and theory of project management, obsessively beloved of MBAs, and originating in the early 1900s, mostly from the work of Frederick Taylor has been proved time and time again to be unable to deliver projects. This is a top-down process which concentrates on metrics and inevitably decays into senseless beaurocracy, and obsession with irrelevancies.
In effect it doesn't matter if your PM is technically savvy or a professional manager (god save me); the theoretic framework they follow is flawed, and the chances of the project succeeding on budget, on time, and to the satisfaction of the end-user are about the same: virtually nil.
(How many projects have you worked on that have satisfied the above 3 criteria? Er...none, per chance?)
Upto 35 people died in London recently due to the failure of the new software controlling the ambulances. As the engineering structures whether they be physical or in software get increasingly complex, then we desperately need better form of PM.
Again this kind of question is not just applicable to IT, but like many of the issues facing us in IT, is applicable to the whole of society).
Personally I would like to see a lot more research into evolutionary construction methods, or more research into complexity theory, and emergent behaviours and not this continual shoving of a square peg of anally, hierarchical, inflexible, failing methodologies into a round hole.
But firstly we should wake up to the fact, that the current model is crap.
Of course in my case, the problem was due to a lack of competence, coupled with an egotistical and very selfish attitude. (the stereotypical golfing buddies syndrome) Horrible decisions were made on a regular basis, lies were spread like PB on the other side of the Jelly sandwich, and the upper management did not only allow it to happen, but in the long term it was obvious that such behavior was encouraged.
This is to say that the technical, or lack thereof, knowledge was NOT the problem. The leader does NOT need to know everything about every part of your systems. Neither does a manager. (PM's are less leaders and more coordinators, even though in many poorly run companies they are paid and treated like emperors).
Most technological companies these days have project managers that are in fact from a technical background. One of my goals is to be one such project manager possibly, and so I'm taking my computer engineering undergraduate degree off to graduate school so that I can get a masters in business administration. Companies that wish to be successful will hire people with similar backgrounds, whether it be from work experience or education. I don't know what to do about your company, but I know hiring engineering managers who've never attended a math course over the 200 level is bad, bad policy.
~ now you know
Any developer striving for a PM type job needs to read a basic SDLC book, because if you think that your superior programming skills and technical knowledge alone are going to make you a wonderful PM, think again. SDLC is a very extensive and time proven process, and indeed as has been said.. developers tend to lack perspective on certain levels, and work best when given specific guidelines and dates. PM's *should* know much more about the SD life cycle, but developers have a point also... Any good system's analyst needs to have basic programming skills. The argument can go either way. However, I would choose a system's analyst with no programming skills, over a developer with no SDLC experience any day. Just my 2 cents.
They decided that project managers really didn't do anything except give them project schedules that were too long. So my company now has no project managers.
The tech leads are responsible for all the project management associated with any project as well as the majority of the design and implmentation.
Weekends, late nights, chaos, fustration, are all common here.
God, I love my job.
You seem like an ordinaery engineer to me, that care about how it works, but not how it looks.
Remember, its actually how it looks and feels that matters, not how it work. Provided that your customer ofcourse can do what they need with it. Usability/Look is probably the most important. First of all, customers wont buy your software of it looks bad, or just damn hard to use, _how_ things works matter jacks to them as long as it actually works.
I've learned that the hard way, you will probably do that to if you only care about how well engineered the piece is, but forget about look/feel/usability.
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
I was lucky enough to be in a company that was happy to move me from a Tech Lead position to a Project Manager position.
Surprise #1: I hated being a PM, and I suspect most good engineers would too. What fun is it to nail down requirement details for other people to build, specify milestones for other people to meet, and set deadlines for other people to follow... especially if you're more capable than the people you're managing. As glamorous as "Project Manager" sounds, it just ain't that great of a job.
Surprise #2: I sucked at it. I found you have to be good at slogging through mundane tasks, and extremely detail-oriented, to succeed at project management. I thought I'd be good at it because I fancied myself good at "seeing the big picture", turns out that was only the first 10% of the job.
I've long since gone back to being "just" a software engineer and I couldn't be happier. Don't know if that will always be the case, but for now they couldn't "promote" me to PM if they doubled my salary.
--
flounder
I don't like
I currently act as our senior programmer and serve the function of project manager when necessary. Unfortunately, management still ask for the impossible to be implemented and worry more about form than function. However, I am in a position to make sure certain things that are really important get done. Same song, just a different tune.
The teacher was a moonlighter, having a day job for the political police as a senior project manager. First of all, the class had three times the ordinary number of people, so we wasted three weeks splitting the group in three.
Then we had to work on our projects in teams of 10 people, which made managing the meetings as much work as doing the project itself.
Then I was canned, because when you're 38 years old, you just cannot learn by heart a 50 paragraph text like a 18 year old can (and then the teacher said that there was plenty of erroneous information in the text). I was canned despite our group project ending at second place when it was evaluated by the second in command of the political police...
So, if you like bullshit and nonsense stuff, go for project management.
(Reposted, account being moderated into oblivion)
Whether a project manager trusts the estimates given by the programming staff, and whether the project manager's management trusts the project manager's estimates, matters more than the technical qualifications of the project manager. If the project manager doesn't trust the programming staff's estimates, then the project manager will feed management what they would like to hear -- that it can be done instantaneously for zero cost. If management doesn't trust the project manager's estimates, then management will ask the project manager for the project to be done instantaneously for zero cost. Companies where either of these conditions exist usually are not good places to work :(.
"Display some adaptability" -- Doug Shaftoe, _Cryptonomicon_
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 ...
I'm an engineer and recently had the dubious honor of managing a system implementation and integration project. It wasn't a completely positive experience though it did have its rewards.
My biggest warning to you is to not expect the impossible deadlines and ridiculous requests to magically disappear. You'll just be the one passing them on to the engineers. The only difference will be that they'll know that you know how ridiculous they are.
--john
If you just hook the website up so it emails you and your boss whenever someone hits a glitch (database error, whatever) on your website, you'll get a lot more support for adequate testing. I did this inadvertently at one point and believe me, it gets a lot of attention but my bosses definitely appreciate testing more.
They'll come demanding an explanation and you tell em that to prevent that in the future, it is a common rule of thumb at Microsoft (and they're the best in the industry from your bosses' perspective, right?) that they spend at least one person testing for every person programming. So half the time developing is debugging. (i.e. its not just your incompetence... even the smart people do loads of testing.) Then step back and let management decide what to do.
If they're stupid at that point, do you really want to be there?
That said, fixing every bug no matter how big or small is a luxury your company may not have. Stay levelheaded yourself.
--LP
The IEEE Computer Society publishes "The Software Project Manager's Handbook", by Dwayne Phillips, available at http://www.computer.org/cspress/CATALOG/bp08300.ht m. It's essentially a cookbook on how to run a software project that not only explains in non-academic terms what should be done, but how and why it should be done. It's an excellent guide for developers who want to break into management and for helping inexperienced PMs to not mess things up. We've been using it on the task I manage and life is a lot easier for all of us. I recommend it to everyone in our field.
Where I work, they don't even care if it looks good!
"Hmm, the interface looks good, but I've god a few changes... it shouldn't take too long... but if you can just change the colorscheme and the layout... You've got a two days 'til we ship, so you should be okay. Oh, and there are some features that need to be added too. I forgot to mention them earlier..."
And of course, when it has bugs and a kludgy design after the last minute overhaul... "I can see you're having trouble handling your level of responsibility. You need to get organized and get on the ball! Everyone here works pretty hard to get things done and you seem to be the weak point."
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.
The company I work for doesn't have a project manager. We have this guy who calls himself one though -- but he doesn't manage anything but his own department, our content production team.
Our 'managers' -- two twentysomethings who worked at a financial company for a year, so they think they know how to do things professionally -- are the ones that demand the impossible. Or micromanage tech-side solutions so they are inefficient. Or simple don't spec things out, and then add requirements on the last day before a deadline.
My opinion is that a good project manager, tech knowledge or no, would keep this kind of stuff in check. He or she would have a clear idea of what's really necessary for our product to get off the ground, and listen to the right people. Technical knowledge might help. It might help a lot. But not as much as common sense. And not as much as a clear idea of what the project really needs.
It sounds like you've been dealing with BAD project managers. The tech stuff might be hurting them, but it's definitely possible to be a decent manager without tech knowledge. Just harder.
The worst scenario is when the managment doesn't know enough about the technology they work with so they miss out on opportunities because the are so short sighted. Typical case is consultant companies that are so tuned into making money so they don't want to improve code reusability because that would give them "less" hours to bill the client. Instead they could improve the product so it can be reused, sell it cheaper, get more clients and cash in later!! That's stupid and shortsighted. Anyway programmers are way fanatical about the things they make. For gods sake: if a client pays for a Lada don't try to make a Ferrari.
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
Look at the tomato! Isn't it sad? He can't dance! Poor tomato!
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 have over 29 years experience working in the electronics industry and as a system developer/implementer. The most recent 10 years were spent as a professional project or program manager on government system acquisitions.
A project/program manager is hired to control three factors of a project, scope, schedule, and budget. In most projects, the PM that was around for contract negotiations has been canned by upper management along with several of his or her successors before the project is completed. The reason is that no matter how savvy the manager is, contracts are captured by proposal teams based on delivering the cheapest bid based on a proposal promising pie in the sky technology. The promises in many cases can never be fulfilled regardless of how much money or time is sprinkled on the resulting development effort.
True project schedules capture reality, but they are built by capturing and carefully analyzing all of the tasks and assets required to deliver a product. This includes personnel, materials, time, and monetary resources required for completing those tasks. After all of the info is captured and the critical path through tasks is plotted, a scientific risk assessment must be accomplished to determine the probability of task completion. Usually working with an 80% probability of completion gives a reasonable calendar date for accomplishign a task.
Unfortunately, contracted milestone dates are usually on paper before this type of assessment is ever accomplished. The result is that virtually all projects/programs are badly over budget, under scoped, or don't have a realistic schedule until the project is almost complete.
I can't defend dolts that end up in project or program management with no concept of the technology they are delivering. However, I will say that a PM is the buffer zone between marketing and engineering that tries to deliver the goods. Being a PM requires a set of skills that are not the same as those required in a developer. Most developers do not make good project managers because they are too close to the details of a technology. Likewise, most project managers would not be competent to take over for their developers. However, a good PM does have to be savvy enough to know when technology or the laws of physics are being exceeded.
fucking stand up for yourself. tell your fucking project managers that they don't know shit and they should shut the fuck up.
Our PM is a former history teacher, with no technical experience whatsoever!
Look at my karma - I'm bad, just like Michael Jackson!
PMs are over priced middle man monkeys. Personally wouldnt have any desire to be one. That aside rest assured than when your Project managers loose their job, and they will, that they will be unemployed for many months because the rest of the world does require project managers to not have their head in their collective asses during the interviews.
Going with the MBTI, and Keirsey's viewpoint, I had an ESTP boss, who hired and ESTJ manager, for our group of programmers.
The programmers consisted of one INFP, one ISTP, one (probably two) INTP, one INTJ, and one other guy that I haven't typed yet. Probably and N though.
The SP boss loved the SJ manager. As any Artisan loves having a Guardian clean up after him, and Guardians, especially Ts, love disseminating orders from above.
To us, however, he was not as well liked.
The INFP, thought him to be an idiot, but got along with him.
The INTPs worked with him, though one did it so he could shift the blame on him.
The ISTP liked him, for making order.
The INTJ got into fights with him in what he saw as idiocy, quick decisions, and uneeded control.
Overall, he added control to the project, but at a great cost. Productivity slowed because people either fought him, or did *only* what he requested, and nothing more. He was eventually let go with the first round of layoffs that also got rid of IT, and left only the INFP and ISTP.
The moral of the story, well I don't know. But if this happens again, I will probably give up. If the manager has *any* control, as opposed to just reporting, he *must* be technical, or the project, and possibly the people, are doomed.
Have you read my journal today?
The formal project management session at CHECK (sorry, the sessions aren't online yet) did outline the structure for the people involved in a project. The thing I remember most is that the structure that was presented to us (and endorsed by the State) had Project Managers in an organizational role *only*. They didn't make technical decisions. They drove home the process of managing a project. They generated reports for the suits, kept everyone on track with timelines (decided on by the group), documented the process, ran project meetings, and kept things neat and orderly. They didn't make technical decisions. The presentation giver did say that it would be ideal if the Project Manager was someone of a technically minded person so they could write documentation correctly, not give out false information, and would simply understand to a certain degree what all the technical people were saying. That doesn't mean they have to understand the ins and outs of BGP but they should be able to understand enough of what it is after an explanation to get the point across in writing.
IIRC I also heard one of the other (larger) Unvs say that they are considering highering a full-time Project Manager for their dept. Project management can easily become a full-time job.
Hopefully your state endorses some sort of PMM. I would try to convince the suits to let your team leaders take a class or two. If nothing else it will help the actual Project Manager out if the majority of the people that person works with understands the PMM process.
It is almost impossible to create a rule that all project managers be coders - or not be coders. At one time everyone was inexperienced, and it is true that most of us don't seem to improve much, but the challenge of managing a project of any kind requires strengths, as others here have noted, that don't have prerequisites. Flexibility, the willingness to listen to alternative approaches, to adjust expectations, and to defend the work of the team to management. These are all human qualitites, though rarely seen. Would programming experience be beneficial? In most cases, yes, but not in all. I've seen some sucky managers and some good ones and none of them knew what they were doing - and these weren't software projects.
I work at a company with a similar situation. We have spent the past couple months, at my insistance, on reworking our process.
Here is what we've done:
Most importantly, use a process that makes sense for both the project and the task. If something is high-risk, consider a spiral-model. If something is complex, use iterations or the (related) Unified Process. From an organizational perspective, you should lay out templates for all of these.
Find someone that knows something about Software Engineering, not just Computer Science. Programmers know some great stuff but there is much more to acceptable-software than elegant functional code.
My company has a guy with a Theater degree managing electrical engineers. (Not my group, thank God.) I've never had to deal with him, but we get a steady flow of his underlings walking into our area bitching, "It's like explaining things to my mom!"
Have them read this book:
Modern Systems Analysis and Design (3rd Edition)
It seems to me these people don't know the basic system development lifecycle that every decent project manager should know..
I worked for a mid-sized (now quite small), fairly notorious .com. The people running the show knew NOTHING about technology (let alone simple macroeconomics), and damn near killed the company.
So after losting my job thanks to poor business decisions, I find myself subcontracting for a "consulting" company. Current project: build an online accounting webapp for a client whose clients wish to keep track of outstanding invoices and purchase orders online. Simple stuff. Too bad it's taken six months to reach beta. Why? BECAUSE THE PROJECT MANAGER DOESN'T KNOW JACK SCHITT ABOUT TECHNOLOGY.
My point? Sadly, this seems to be the norm, and I have yet to find a way around it.
Now get back to work or I'll keep you here Saturday.
If you look at project management then you see three sides of the "coin".
.... except if the manager was an "old fox" in programming and experianced in architectures AND had enough energy and patience to LEAD youngsters and enough bones to do not step back if upper management wanted BS from the team.
a) The client relation.
b) The technical challange.
c) The administration of man power, tasks and budgets.
Regardless how good you manage the technical challange, that means how good you "drive the software process", the other two aspects are equal important for success.
The a) is a typical responsibility for a typical project manager. Discussing with the customer to get inputs what to do and make agreements about when to deliever.
With c) the project manager basicly tries to accomplish the in a) agreed goals and time lines.
Without in depth knowledge how a technical project is to be managed, that means how software is crafted or should be crafted this is impossible.
The only way to lead a software project with out software skills (mainly architecture and software project management, like: milestone planning, release planning, quality assurance, version and configuration control) is to have a very good communication skill and very communicative lead developers.
If the project manager TRUSTS the estimations of the lead developers and TRUSTS their explanations why certain taks have to be done in a certain order, he still can manage with out to deep technical knowledge.
In reality a team is rarely build up with high skilled and high communicative people at once.
So the only true solution is to evolve form a programmer to an architect and from an architect into a project managing role.
I was for a long time, as long as I had no project scheduling skills, of the opinion that a technical product/technical project can only be managed by in depth knowledge of the involved technologies. Meanwhile I think it works without also, as explained above. But still I did not found a project witch was managed perfectly
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The course was from claremont consulting, out of LA, (though Sun paid for it for a group of us engineer types), and the book was used as a textbook to the class. It's called "Everything an Engineer should know about Project Management". It's not specific to the Software industry, but definately approaches PM in a way that's compatible with software engineers' mindsets.
Also consider joining the Project Management Institute. They have special interest groups around many professional categories, including Software Engineering.
i - This sig provided by
It would be very difficult for a non-technical person to be a project manager. How would they, then, mediate technical disputes between technical people? Often, during the course of a project, people come to technical logger heads. Often, the only way to resolve this is by the project manager facilitating a solution. I've done is hundreds of times over the last 10 years.
A lot of project management is mundane stuff (tracking schedules, informing people of changes, etc), but a lot of it is making informed decisions about what to do. By this, I mean, there are always bumps in the road to getting out any product. If there isn't one person smoothing over the bumps, then the design will drift.
"...how things look rather than how well things actually work..."
I understand your pain. I do.
But in your comments you don't once mention the needs of the business you work for -- you are only concerned with "how well things work". Please note: I offer no defense for your being told to "skip testing". That is indefensible. But you must know that technical elegance and the needs of a business do not always meet at the same spot; and project managers sometimes find themselves in the necessary but unfortunate position of matching up the two.
Programming experience as a PM is helpful (I have it) but if you think it changes anything, you are mistaken. You've still got to make the projects work on time and budget. And if you've worked as a programmer you know that programmers never finish, they just stop.
This is not meant to be discouraging, just a little view of reality. I will promise you this, though. Programming is a lot more fun!
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.
-- Those of you who think you know it all are very annoying to those of us who do.
Programmers should try and have at least a basic view on business issues both inside and outside the company.
It's quite simple a question of self-defense. No mater how briliant a programmer you are, siting in your corner concentrating solely on programming you will:
- Get a lousy salary because you don't know other people's salaries or you don't know-how/have-the-courage to get a beter salary.
- Be overworked because your manager keeps piling things in your plate.
- Sudenly discovering that you got laid of or your company went bankrupt.
- Get blamed once again for a project that blew-up (and probably you won't even know about it)
Need an example?
Look no further that the pile of once "innocent and happy geeks" that sudenly found themselfs unemployed when their companies went bust with the tech-bubble colapsed (and they didn't even saw it coming)
1)It's not going to be a lot of fun moving from frustrated programmer to PM if you're interested in technical work. are you ready to be the point of communication for a development team, answering phones, writing timelines, etc ? It is a full-time job, and you won't get to do the "cool" stuff any more.
2)Likewise, PMs exist because programmers don't have time to answer phones and emails all day. A lot of us programmers don't have the skills or desire to be effective communicators anyway.
3)I suggest trying to make the system work for you. If PM is an entry-level job at your shop, it could be that you know more about industry practices than the PM does (QA testing, version control, builds, what makes a good SOW). If something's missing from your process, explain it in depth and put it in terms that will make sense outside of the IT department. Usually, this means money and time.If you say, "that's impossible" too many times, you may end up looking like the boy who cried wolf.
Har!
I'm the type of person that fixes the key problem whatever it may be. I've learned many new technologies because we were "weak" in those areas. Gradually others learn them and I move on to other problem areas. The situation that you have described, having clueless project managers, unfortunately seems fairly common in this industry.
I started studying Project Management and found a great resource at http://www.pmi.org. PMI is an international professional organization dedicated to the advancement of Project Management as a profession. I would highly recommend their Project Management Body of Knowledge (PMBOK) and related material from their bookstore.
I have certified as a PMP and it has greatly helped our organization. PMI has a pretty general focus, but they do have a IS Special Interest Group that you would probably find more helpful.
HTH.
There was a great thread on this subject on Usenet about 5 years ago in the newsgroup comp.software-eng entitled Do I Really Need a Supervisor?. An individual involved in designing and implementing real-time avionics systems came to the conclusion that his middle management were wastes of space doing negative work and that he felt he could probably do the entire project, including scheduling and budgeting, without them.
The consensus of the followups was that a good manager is one that gets you the resources you need, shields you from the bureaucratic BS from higher-ups and the customers, and allows you get the work done. A bad manager is one that interferes with the work, doesn't defend your side of things to upper management, and/or doesn't know the limits of his expertise. Even worse, a bad manager may only care about personal empire-building, wasting the organization's energy to further his own political agendas. There is also a meaningful distinction between "manager" and "technical leader," and most projects need some of both.
If you work for a company that fosters bad management, becoming a project manager will simply switch you from being responsible to your current set of bad managers to another set of bad managers.
He was a regional manager in a large construction company and he always tells me (one day, maybe, i'll be in a management position) that you never delegate a task to anyone that you can't do yourself. Now i know the tech industry is somewhat different than the construction industry, but i believe the principle still sticks.
After my junior year of high school my younger brother, one of his friends, and I were given a job putting our small town's factory online(custom home furnishings, would have required databases and loooooong calculations and lots of time). My older sister was given the position of project manager, due to the fact that she was a student at Harvard. I was the only person on the project with any programming experience. The owner of the factory was technologically challenged.
We suffered from many problems, but the key problem was that neither the factory owner nor my sister had any clue what was possible for us to do, and neither of them would listen to me when I attempted to explain things to them. Often when it seemed like they were listening, it turned out that they had merely nodded and smiled and continued believing what they wanted.
While I agree that it is important for project managers to have some applicable form of technical knowledge, I think the main problem is convincing upper management of that fact, as seems to be the point of this article. Is it possible to tell upper management that there needs to be someone knowledgeable about this stuff in charge when upper management has no clue themselves?
Let the universe of discourse be wombats...
I am a consulting project manager for process and discrete manufacturing. I could not agree with you more. The gulf created unknowledgeable decisions (by management or project management) is always deleterious to the product (and the vision behind the product). It is often a futile battle, from my entreprenrial perspective, to get upper management to understand that it is easier to produce timely results with a better product by working with their employees (programmers, in your case) than having "outsiders" with no understanding pushing a product/project to completion that carries the burden of unforseen costs of warranty and bad feelings from customers plaguing the misbegotten product.
Good luck with the resolution of this problem, but be warned that project management has its own dark corners of untested and untenable assumptions, and since the ruling elite usually have no comprehension of being experientially relevant to the products/projects they manage, you are likely to come face to face with "holier than thou" attitude amongst your teachers.
The solution I devised to circumvent the unthinking and unknowing above me was to be dutiful in appearances (attend meetings, create meaningless reports, etc.) and proceed in a manner that I thought best. When producing the final results (end of project/inception of product) I stood back while the supposed managers tried to explain to upper management/sales department/stockholders what this product was, how it worked, etc. and then stepped in and demonstrated how it worked, why this approach was taken, and make appropriately direct comments on how irrelevant the project managers were to the outcome, also offering why their scheme would not work as elegantly and what that meant to the bottom line.
An excellent book for new technical project managers is Steve McConnell's Rapid Development. I'd recommend it highly. Easy read, excellent advice.
Please, for the love of Pete, read Rapid Development . If you read, understandd and apply that book, you'll be head and shoulders above most project managers.
A project manager must above all, know what it doenst know and when to ask. A good team member is one who can explain to a manager what the weights and risks of certain paths of action are such that the manager can make an informed decision with the customer AND the bottom line in mind.
Let your architects report to the CTO in stead of the project manager.
Pre-condition is that the architects must have a good sense of what's going on in the market and be able to prioritize not only on code pureness but also be able to implement pragmatism beneficial for the target market's demands (time for features in stead of perfect code).
it is easy to see who works for companies with a respectable business process and who are just arrogant butts. Im not sure if it speaks more of the company or the person, but I feel it must be indicative of each - to some degree...
I wonder, if I know the companies everyone worked for, if it would affect my investment strategies.
hmmmm....
...is to leave the company. Upper management isnt listening to reason, the project managers got hired with "no previous experience of anything" so the hiring practices are suspect, and you are being told to produce crappy software. This is not the place to learn about project management. This is the place to learn where exactly on the wall it hurts the most when you bang your head against it. Find some place that is interested in quality people. (and when you do, let all of us know about it so we can apply there too 8^)
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.
There's a (fairly) new CNET site with an entire section dedicated to developers handling managment responsibilities. One of the featured articles today is Making the transition from developer to manager. Here's the link: Builder.com Manage.
In my experience (7 years) as a programmer and now (3 years) as an architect I've come to believe that my job is to NEVER tell a PM or an executive that a project is impossible. My job is to tell the PM or the executive that the project will take X amount of time and will cost X amount of dollars.
A good way to handle the less technical PM or executive is to talk in language that makes sense to them. If a project is initially termed as "impossible" chances are the better terminology is "unreasonable cost benefit." Anything can be done, inventors have been proving physicists wrong for years.
Learn Java, learn C++ and learn ExecuSpeak. With that skill set you'll be more likely to make your point with your PM (who has to turn around and make the same point to his boss) than not.
[_-+ S3VYN +-_]
Most programmers I know think managemers are clueless PHBs and act accordingly. That's the root cause of most of the project mgmt problems I've seen in the industry.
However, seeing the PM as someone to fend off all the "noise" of the organisation - meetings, budgets, change requests etc. gives a healthy perspective that is mutually beneficial.
I've recently worked with a great PM, Anders. He is great at eliminating disctractions.
Here's what he does:
- handles all calls from customers etc. This means the developers get a batch of change requests every now and then instead of an unending, uncoordinated mess of interruptions and changes.
- keeps everyone posted on progress, all the time (and if we're behind schedule, he lets everyone know early and immediately notifies the customer and starts renegotiating the timeline, resources or requirements). The customers respect him even when budgets slip - because they know early, they know why it happens and are able to influence how it is resolved.
- keeps colleagues from the company interrupting, for example, when the CTO wanted people to go to a demo of a new version of the content management server he stopped it since it was not relevant to current project and everyone on the team saved a few hours of glorified Powerpoint slides with little technical content. He also made sure to go there himself so that if anything relevant came up with the new version he could have the team check up on it.
- fences off other PMs trying to steal his resources - so, if you work on his project you don't get dragged to irrelevant meetings or to play fireman on someone elses burning project.
- he keeps you focused. This is a bit of a bitch since most programmers have their pet features but it really speeds up project completion a lot. He will say "focus on this", "cut that feature", "this is good enough" etc. even when you would prefer spending another day gold plating a particular feature. Gradually, however, most people realise the benefit of this approach - even though some people enjoy firefighting working on projects were problems don't grow big is a great experience. And you get to go home from work on time.
- finally, he handles all the red tape and suits of the organisation. That means - reporting, budgets, meetings, strategies, gantt charts etc. He handles that and let the developers focus on developing.
Quite easy, really, but it takes a lot of modesty to be a great project manager. I think many PMs have too big of an ego to be really successful - Anders, on the other hand, would always admit when he was clueless and ask experts (developers) for advice as needed.
How this helps. If you would like to go into PM make sure to read Steve McConnell's classic book, "Rapid Development". It's a gold mine of best practises and cases show how to - and not to - run a project.
Also, a book like Bill Jensen's "Simplicity" is highly recommended - it is a simple yet valuable treatise on how to make it simple to do the important things.
Cheers,
Martin
Sometimes hjaving project managers without development experience can be a good thing. They tend to look at things from the view of the customer more and don't focus on what the technology can and cannot do.
It should be up to the the developers to tell the project manager what can and cannot be done with the technology because that is their specialty. Of course, the PM has to listen to what the developers say and the developers have to actually be honest about what the technology can do. I have seen a few projects where the developer said that the technology couldn't do something because they didn't want to do that amount of work and the PM wasn't really listening anyway...who do you think won that argument?
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.
All PMs can write code, all managers are former developers, no cubicles, senior developers all have window offices... ;-)
Same thing at my company here.. I am the lead developer, and my boss knows nothing.. He wants to always jump on the newest and latest fads without considering all the technical aspects of a project. Many times it has happened where he quotes a development time of 2 weeks to a client, but because of the scale and complexity of the aplication we're building, that turns into 2 months. Needless to say, clients aren't happy.. There's only 2 techs here, it's a small company, and we are always pulling our hair out because our boss told a client they could get something that just isn't possible.. I would like to know how to get him out of the loop, he needs to stick to just running the company.. Let someone who knows my job sit down with the client and discuss their wants/needs and what is possible or not..
When I started as a programmer, I figured a good, reasonably intelligent manager would be able to manage anything, since management skills include knowing when you need to defer to a resident expert, and so on. After participating in various projects under various managers, I revised my opinion that a manager of a tech project would have to be 'tech literate', with a background that included at least a little engineering of some kind.
Years have passed, and now I've (reluctantly) concluded that software engineering needs to be managed by a software engineer/manager (can't be one and not the other--needs to be both). Ultimately the manager will make the decisions about what valuable elements have to be cut to save time, and what schedules will have to be extended to include important features, and so on. They also have to assess risks about what to try and what might prove to be too difficult. Most importantly they have to listen to their engineering team and decide which intelligent, well informed opinion to listen to when they disagree (and they will...managing engineers == herding cats).
That takes actual software engineering skill and experience, and actual management skill and experience. Small, obvious projects will succeed without suitable management, but not to the extent they could have, and large ones will run on and on or produce half-assed results. I've seen successes and failures, and I've seen successes turned to failure due to changes in management, and this was the common theme.
This carries through all the way up to the top (a tech company without tech & management trained leadership at the top level will have serious problems). The CEO doesn't have to be an engineer, but you need an engineer/manager high enough in the hierarchy to be able to say "we have to do this" and make it stick.
So I would suggest if you're on a tech project without tech management is to polish up your resume and start looking.
I toiled for a real-estate/snake-oil salesman who had made a killing in the Calofornia land rush and bought a software firm.
His total lack of perceptiveness consisted in
- handing me "The Five Minute Manager," a not-so-fine book that he'd obviously never read,
- having erraticly scheduled alleged weekly "rah rah" meeting to inspire the troops (we always met afterwards and griped that he was an idiot and the company was doomed, never mind the project,)
- asking for estimates, which I delivered based on the growing amount of work (he kept adding "fee-tchurs") to be done and the wall of the delivery date which my team and I were hurtling towards,
- and then he'd cut my small team by putting somebody on another project.
It was acidosis vs. Tums, headaches vs. Aspirins, desperation vs. alcohol medication.
I NEVER want to be a middle manager again. Specially not graftin' for an idiot. I'd rather sell shoes or groom dogs, cats and turtles (they have claws that need trimming.)
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Unfortunatly, we like in a new world where there is too much knowledge for the PM to know everything. This is where the term "knowledge worker" comes from; you have knowledge that your boss does not have. This is perfectly OK. Managing is an art that does not require the specifi technical expertise required to get the job done. "If you want the job done right, find the right person to do the job".
Jamey
Jamey Kirby
You can't really compare engineering to PM. They are two completely, vastly different things. One takes years of hard work and dedication and learning in widely disparate areas, while the other takes -- from what I can tell -- good hair, at least a passing knowledge of golf, a subscription to Details magazine, and the ability to "network" without resorting to using CAT5, fibre, or 802.11b.
Can you hire a PM with no preivous PM experience and expect products/projects to get managed? Maybe, even probably. In fact, the submitter is trying to bail water out of that particular boat so we know it not only happens, but is common. Can you hire a software engineer with no previous experience and expect any software to get written? Not even the slimmest chance in hell.
Not to put too fine a point on it, but most people could do PM if forced and very few can be programmers. So the converse of the submitter's problem doesn't even begin to hold water. "I'm a senior admin clerk in an aerospace firm where the engineers have no experience making copies and restocking the supply room..."
It just doesn't work, man.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Would you ever hire a chef who couldn't cook? A foreman who never built anything? A colonel who never fired a gun?
Perhaps it's good to think about this from other perspectives. The building construction industry is a good analogy to software. The people with the money have rediculous demands. Architects and engineers design it and then the project manager has works with them to estimate its cost and time. He has to know the business side, the engineering side, and the construction side.
Construction is chock full of suprises, delays, and inconveniences just like software development. If you want to be a good software development project manager, take a look at one of those guys and see what skills they have and try to mimic that.
I'd bet they have experience in business, design, and construction, but mostly in construction.
I don't think you'll find many people fresh out of college with a business degree go into the project management business without having some practical experience with construction or design.
However, this is unfortunately the case in software development.
The teacher was a moonlighter, having a day job for the political police as a senior project manager. First of all, the class had three times the ordinary number of people, so we wasted three weeks splitting the group in three.
Then we had to work on our projects in teams of 10 people, which made managing the meetings as much work as doing the project itself.
Then I was canned, because when you're 38 years old, you just cannot learn by heart a 50 paragraph text like a 18 year old can (and then the teacher said that there was plenty of erroneous information in the text). I was canned despite our group project ending at second place when it was evaluated by the second in command of the political police...
So, if you like bullshit and nonsense stuff, go for project management.
(Reposted, account being moderated into oblivion)
Communication! Communication! Communication!
That's both ways, open, honest, direct, active, check the ego at the door and be thicked skinned.
A quick look at this thread just re-emphasized that for me.
I find effective communications lacking on most projects (i.e most people) and it is my responsiblity no matter what role I play (Developer, Architect, P.M, Line Mgr.) to foster it. It's my best tool. Technical acumen is a plus but doesn't do any good if the P.M. is a poor communicator.
It may mean working in your own time, but having delivered something management needed and did not realise they needed covers up at management level your other blunders, past and future, that your peers are/will be aware of.
Avoid being on someones project management software if at all possible. Become a trouble shooter, work on high profile special project teams, such as performance improvement. Get another job if necessary.
Be Free: Free Software Tuition
However, I think you might need a Product Manager, someone who is a developer who can manage how the product is produced, how the development works, how QA works with the development, etc. A Product/Project Manager rolled into one is great, but seldom found in today's industry in my experience.
"It's here, but no one wants it." - The Sugar Speaker
Is not wanted, but seems to be a neccessary evil, a least he does the damn status
Telepathically understands exactly what I do
Is a great developer but knows I am better
Withstands searing heat from upper management, and will sacrifice himself for the good of the developers
Always takes the developers side in an arguement
And of course always delivers the food on time
Sorry could help myself....
You sound like me. "Tell me when to have it done, cause I can't estimate." That isn't his problem.
Your project manager doens't employ the best programmer in the world. He doesn't employ the worst programmer in the world. He doesn't employ an average programmer. He employs you.
Even if he knew how long it would take him, that doesn't corolate to how long it will take you. He needs you to develop the skill of guesstimation. You may have a calendar deadline that is out of your control, and then he might give you a deadline, but otherwise he needs your needs in order to manage everything else.
And if you told him 1 week, because you didn't understand the complexities of how to integrate the DB with the palm when you said 1 week, and he then asks you why you are late, the correct answer isn't that it is hard to impliment. Of course it is hard to impliment, if it wsn't the cutomer would do it themselves. The correct answer is "Because I failed in my guesstimation."
In other words communication. He will start to learn your weaknesses, and help protect the project from them. Next time you say 1 week, and he knows you haven't dealt with the tech before, he will take it with a grain of salt, and won't arrange for testers until closer to the due date, or whatever.
My manager automatically doubles my estimates for new stuff, and things tend to flow pretty smoothly. I am geting better, and our trust is getting better. I am learning what things "can't be done" versus "need more time" versus "you need to tell the customer they are wrong, and they probably want this".
your manager doens't need to know programming in Palm. If he did, you probably wouldn't have a job. He just needs to know you, your strengths, your weaknesses, and how much he can expect to get out of you. And the only way to get there efficiently isn't to try to teach him programming, but answer his question.
It wasn't what took so long, it was why are you late.
Our development company has just been aquired by a larger company that provides Project Managment and Project Managment certification. Our new company is called PM Solutions, and the president of our company use to be the president of PMI (Project Mangment Institute. PM Solutions has just partnered with Carnegie Mellon University to provide a 'PM Collge Masters Certifitation' process for individuals wishing to master Project managment. To ba good employee, I thought I would peddle the companies wares. You can check it out at: www.pmsolutions.com Cool stuff, I'm signing up for my PM classes as soon as I get done with my current project. Hope this helps. Larry
I find it ironic that most of the postings here validate the military structure:
(1) A generalist (PM = officer) to oversee policy, manage the schedule and resources, and buffer the doers from meddling from above.
(2) A tech expert (programmer = senior enlisted) to manage the tech details and be a tech knowledge source.
Who'd think the military has had it right all along? Of course, when know-nothing political (i.e. office politics) hacks get put in positions, it all falls apart no matter where you are.
For some reason PMs at my company get paid more. They should be fucking smarter.
specifically for web projects, this one discussion has taught me more about how I need to shape my choices in classes than anything I've learned in school so far. Thanks.
Project managers must have better technical knowledge of the subject than those implementing the project. This prerequisite is critical to the project's success!
When it comes to software, folks tend to think the rules are different when compared to other technical jobs. For example, when a bridge is built, no manager would dream of giving the job to someone without a thorough understanding of physics (and more specifically, of bridge-building). But in software, folks tend to think they can hire some geek out of high school and have them implement God's universe within six days.
Unfortunately, it doesn't work that way. Software is no less complicated or serious a discipline than building bridges. If bridges fail, people can die . Likewise, if software fails, people can die just as well, and billions of dollars in damages can occur. Even if you're only implementing a text editor. (Imagine if a text editor corrupts someone's file when they're configuring a satellite computer or something. This is not a joke.) And infinitely more so if you're implementing an operating system, for crying out loud.
Contrary to popular misperceptions, software is a serious matter, not some colorful graphics and icons you click on. To manage a software project, you can't just understand project management. You have to understand what happens when both bits of a XOR gate are high, and you must understand this better than the programmers you manage! Even if they program in Visual Basic. To be a good project manager, who can give reasonable estimates (not just to shut up management, but to tell the honest truth about when something can be implemented with reasonable quality), who can deliver something that's actually worth the resources spent in development, you must be so experienced that you have forgotten 99% of what your programmers haven't yet learned, and they better be pretty damn good programmers.
For software to be truly successful in the coming years of ever-increasing dependency on computers, computer education simply must change. Programmers should become proficient in electronics as a prerequisite to any programming class. Project managers should have been programmers, and damn good ones, for 20 years prior to becoming project managers.
While it's not necessary for project managers to have technical experience or skills, it is essential for them to *listen* to the developers' needs and pushback. In a properly run company, project managers and developers work as equals to solve a problem. If developers are merely mindless slave labor to project managers' whims, the project (and the company) are destined to fail.
"Has anyone else found the barrier to project management is their technical knowledge. How did you get past it?"
:-)
Yes, that's exactely how things where at my previous job. I found a good solution, I quit my job and found a new one where management actually has some technical know-how and things are much better now
When I was in this situation, she had a nice rack, which was enough to smooze the customers when she extended customer expectations beyond reality. Maybe that there should be some kinda minimal equipment set if the tech knowledge is not there.
Wow - lots of interesting comments posted here, and some things to think about.
I'm starting to come to the conclusion that perhaps the most valuable thing about a project manager is the way they act as the "shield", protecting a group from becoming the direct pawn of an upper-level management person (CEO, VP, or what-have-you).
I can recall a situation with a previous employer where the software development dept. used to be pretty much directly controlled by the company president. Eventually, some things got restructured, and a person was assigned as a project manager over their department.
They didn't really like this, because they felt like the guy was technically clueless and just more middle-management wastefulness. (In fact, both of these things were arguably true, to an extent.) The interesting thing, though, is the department started becoming more focused on completing the development tasks that the *users* wanted, vs. only working on the "pet projects" the company president envisioned.
I've been tempted to get into project management before. (Especially after talking with a few of my buddies who came from tech. backgrounds, and now swear that project management is such a great career move for them. Better pay, more respect, etc.) Honestly, I think it requires a completely different skillset - and it's too bad so many places treat it like a "promotion" from a tech. position. IMHO, there's no reason at all to pay these guys *more* than your tech. workers.
People with good technical skills should try to continue to work where they can put those skills to the best use. Trying to become a "technical project manager" is only going to make you slowly lose your technical edge, and spend half your time doing things you don't enjoy - like building time-management charts and sitting in boring meetings.
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.
Currently hooked on AMP
I'd rather have a PM who knows absolutely nothing technical and instead relies on the lead programmer/solution developer to lead the team. The PM in this case would interface with the client and keep the pressure/politics off the programmers, plus keep everyone on task/make sure everyone behaves.
I can't think of anything worse than a PM who has a little technical experience because it can get to their heads, and they think they don't need to rely on the decisions of their programmers.
"Teachers leave us kids alone
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.
Holy Christ - THIS SOUNDS ALMOST EXACTLY LIKE MY COMPANY!!!!! I can understand managers not having technical backgrounds - but I agree "Project" managers should not (or is it "can not") be managing "Projects" if the project is technical with out some understanding of the technology behind it.
Management is the same as programming, at the highest level of abstraction there is. The manager's job is significantly more difficult than that of a programmer because while the programmer usually deals with quantifiable, or at least qualifiable, problems, the manager deals with ambiguous conditions all the time.
A programmer may run into an uninitialized variable for example. This is an easy fix. The manager runs into uninitialized programmers, and this is considerably more difficult to remedy.
A programmer knows the capabilities of all the objects he arranges into a piece of software, and he also knows the effciency and parameters of the algorithms that get the job done.
A manager does not have full insight into the capabilities, attitudes, and personal lives of the resources he uses to build his project. He may outline, dictate and enforce certain policies, practices and processes, but can not be assured 100% that these will not be circumvented at every turn.
So, while the programmer (such as myself) does their little thing, and when it breaks, reaches for the manual and the debugger; the manager is, at best, dealing with uncertain conditions, on a slippery slope, sans manual, with only conversation and limited metrics to serve as his debugger.
The average manager is just as qualified to manage as the average programmer is qualified to program. Any time anyone bitches and moans about how lousy and clueless their manager is, they should start fixing things by taking a good, long look in the mirror.
As a programmer, how effective an object are you? This is not meant to dehumanize - managers don't mean to treat coders as cogs, but they do have to consider that perspective. As one building block of which the project is constructed, do you provide adequate reflection for your manager to make use of your abilities intelligently? Are you doing too much information hiding? Are you a bottleneck in a good process? Are you under-utilized, or over-extended? Should you NOT be reading Slashdot from work?
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
What I try to do, but for unexplained reasons is resisted, is to have management or the PM *rank* the requested features, and then knock them off one at a time.
That should tend to soften any deadline because there is no "line", per se. You have high-priority features, and lower priority features. It is rare that all of them are show-stoppers. If their is a date line, then you go with the features you have finished at that point, giving enuf time for final testing. (Some of them are integrated, so it is not always this clear-cut, but it helps.)
New requests will get added as time goes on, and the list will probably change.
However, some managers seem like they just don't want to commit to priorities. Is it because then they can't blame the developers?
Table-ized A.I.
On large software projects there are two core issues: determining what needs to be built and then building it. Being technical is very helpful in addressing the second point, but it isn't required or debilitating any more than having an exceptional understanding of the business side when writing requirements. A good tech mgr may know when to challenge developers' answers or estimations but might not have a clue about the soundness of the requirements. Non-tech mgrs from business can create better requirements docs that aren't as likely to change because they understand and anticipate future needs.
There's no silver bullet single answer: PMs are good or not based on how well they work with others, how well they make use of the resources at their disposal, how little time and money they waste and so on. It isn't because they are or are not technical as much as it is if they are or are not competent. And companies that do not believe in sound project management are only going to succeed in spite of that, not because of it.
The problem with sales people is that in their business, if the project ... err, prospect ... is "impossible", then you didn't tell a big enough lie so go back and tell a bigger lie.
now we need to go OSS in diesel cars
Impossible is coding 100000 different values into a 16 bit field. That is where "cheap" isn't one of the choices as you have to expand the field ... and that may mean recompiling and maybe even recoding everything else that expected to use just 16 bits.
Impossibility depends on how you state the problem. If the manager says "use a 16 bit field to code the 100000 values" then it is impossible. Tell them so and they might not believe you (in part because they may have come from a background where they are drilled with concepts like "nothing is impossible if you try hard enough", even though we know that is not true). Tell them 100000 requires at least 17 bits, and that its quicker to just use 32 bits, and then at least they haven't heard the word "impossible".
If you really do have to tell them it is impossible, maybe if you relate it to something they can understand, they can get the message. "That's like running a one minute mile". "A car can do that". "A car is a 32 bit field".
now we need to go OSS in diesel cars
If you've only been working for a year and come to these conclusions you're way ahead of half the blow-hards running around here.
Some things that people haven't mentioned...
/.) many people who work writing software get the sh*t end of the stick. If this is the case from your direct management, and you get the feeling that other higher people in the company don't want to know either, then you have two options: change company, or wait for a change of senior management. It is very difficult for one person to change how things work - attitudes come from the top down. That's whether you are a PM or not. (I've seen the good and the bad)
A lot of the things mentioned very much depend on what company structure you work in.
In my company, the people who can make life difficult or easier for the engineers and the project manager are the directors and marketing guys, and the person who runs the technical department. It is the PEOPLE in those types of positions who make the difference - are they strong, realistic, but also with a drive to succeed and deliver for their customers?
Quite often (or so it appears in
Without all these people working AS A TEAM with everyone and being realistic (if tough), then things just fall to bits, good project managers or not.
Secondly, even with technical project managers you may or may not get people in your exact field. And people who think they know what their engineers should be doing can be just as bad - especially if they are in the same field. Again, it is the people, and their personalities that effect the feeling of good boss/bad boss the most.
Also, don't underestimate how much work project managering is, and how much further your stress levels go up. The money (if you get any increase) will not compensate you. I thought it was stressful being a senior engineer! And you will probably get a LOT less time to do anything technical.
However, technical people CAN be good managers. They need to learn how to get things done by others. The good ones (as viewed from above) get things done. The good ones (as viewed from below) get things done - without a stick and in cooperation.
Project management in particular is a bit of a balancing act, things constantly move (and get added), and keeping it all together requires a cool head and support from *everyone* else - both engineers, other departments and senior management.
Some opinions - although I haven't got all of the answers.
Regards,
Rob
Development Manager/Project Manager/Snr Software Engineer/Overworked
I have had some great project managers that weren't engineers.
what we used to do on a new PMs first day was:
1. sit them down and explain to them in finite detail what we did, and how it worked.
2. explain to them the problems they would be dealing with, and give them the technical training to understand those problems. They didn't have to become software engineers, but writing a simple web-based email address collection script can teach somebody alot about client-server interactions, security, etc.
and then, we made sure that time estimation was always done with a (trusted, senior) engineer (and they sure didn't write specs). like this guy said, it was always a matter of negotiation between people who respect eachother to achieve a common goal.
finally, resource allocation was not handled by project managers. a person's time was owned by a resource manager, and all PMs had to go to that central person to ask for it. so, the moment something changed on your project, you had somebody other than that PM whose responsibility it was to check on whether it was time well spent.
All that stuff about skipping testing, etc. that's not the PM's fault, but the fault of whoever is in charge of them.
As for becoming a project manager, being an engineer helps a lot, but make sure you learn from the other project managers, the way you wished that they had learned from you.
After all, why should you care? When upper management asked you where Feature X was, you'd never heard of it either. But you weren't about to sacrifice any all-important face in the meeting. You turned on your tech team like the traitor you are and stabbed them in the back. Oh, they'll figure it out when review time comes around, but that's a few months away. And you might have a different job by then, after you've collected your bonus. Just because you're a treacherous little git doesn't mean you don't have some smarts.
Don't do these things. Be good.
Jack
Either the department or the company is headed for a collision with reality, and you can get hurt in one of these. Departments can be eliminated and companies can be bought (usually at fire-sale prices) as a result of this sort of thing. These people are practicing very-short-term management and usually get caought by reality at some point. Try not to be there when the inevitable happens.
Yup, find a new job. That is correct. Would a physician work for a chief physician who knew no medicine, or an engineer for a chief engineer who knew no engineering?
It is a recipe for disaster and they will turn on the developers whenever it suits them. Knowing this gives you time to find new shoes so to speak.
Just learn to say no! "NO" I do not want your job nor your money: "NO", I want to work in a professional shop that appreciates technical people.
In closing I use to hear this bullshit idea (always from non-technical people) 20+ years ago. Without exception it was a DISASTER that they created.
I just typed up a huge response, and I'm have yet to see any of my posts displayed! :(
Long story short, check out our web site,
it has great PM info, the #1 Source.
http://www.pmsolutions.com
Larry
I apologize for the length but I have something to say about this topic:
.tif images and Oracle databases. Nope, they hadn't fleshed out the design before I arrived; we went from requirements gathering to design to customer sign off to finished GUI in 4 months. Yes I made it, but I almost landed in prison. The problem? A somewhat competent but HUGELY arrogant buttwipe of a PM. This guy's picture is next to the word "hubris" in the dictionary. His favorite thing was unannounced "dog & pony" shows where he would routinely berate people for not showing any progress. This PM also suffered from the trait of liking a$$sholes. His favorite boy was a devout Iranian muslim who drank heavily, fondled women, and lied lied lied. Muslim boy made one mistake though; he tried to get me in trouble with the arrogant PM. You see, muslim boy had written the coding standards document. I was standing in the room when muslim boy told the PM I was not writing code to his standard, to which I replied: "I am writing the code as close to your standard as I can, but my code interfaces with your code and your code is not written to your standard. If you would like to spend a moment I can go print out a sample of your code and we can review it in front of the PM." Muslim boy shut up after that day. But anyway, the PM was an a$$ and he always listened to Muslim boy's advice. As a footnote there was a position open a few weeks ago on dice.com at this company for an MFC Visual Studio v5.0 person who "could fix things". Hubris is a ver bad thing to have when you work in software...
.NET work in the future - and I will most likely want to come back and help out.
Well let's see, I've been doing this C++/Oracle/SQl Server thing every day for 11+ years now, sooo:
First Job: Manager was highly technical. Great gig for me because he let me play and play; I learned alot. After 4 years of bonuses and pats on the back, the job ended in a rapid 3 month assault on my work habits. For example my
"tardiness" was not an issue for 4 years - then suddenly it was a BIG issue {this from the boss who said "I don't care when you come and go I just need it done"}. Why and how did this happen? Because I refused to hand edit a report to change numbers so they were more like what the customer expected. The hand edit was needed after I discovered a nasty "off by one" bug that caused miscounts of dozens at the territor level, hundreds at the region level, and tens of thousands at the national level. My manager acknowledged the bug, told me to fix it, and then had me rerun the reports --> the reports were hugely different from the previous quarter's reports and so some "fixing" was needed to make the data more like what the customer wanted. The incidental fact that these "numbers" dictated salary and bonuses for a sales force of hundreds mattered not - the customer expected numbers that looked like the previous quarter and that's what they got. Nope, I don't think that the company that hired me out of college exists anymore...
Second Job: Two highly technical Manager(s) - they fought over me endlessly; it was fun. Why was it fun? It was fun because 1) Those guys both ran interferance - my job was to write tight code, their job was to make sure I had adequate time to do it, 2) They were TECHNICAL. Result: a very stable product that everybody liked {no really it does happen}. In general it was a Fabulous workplace with a really hot receptionist. Then the phone rang for more money...
Third Job: Maybe you've heard of them --> www.wsj.com. Yepp I helped the Wall Street Journal build their web site. Semi-technical manager whose favorite quote was "the day you see me writing code is the day we're all screwed". Okay workplace, with 2 hot babes in daily view. But there was one problem: my manager - who I did and still do like - had the horrible trait of liking incompetent a$$holes. I had a good run at Dow Jones but I have heard that my ex-manager's career has taken a nose dive --> it's hard to soar with eagles when your goto people are turkeys. The most important thing I learned at Dow Jones was that consultants make twice as much money for doing the same work as I do. Soooo, on a whim, I packed up my beamer and my babe and we moved out to CA where I would become a consultant...
Contract #1: 4 months to write a multi threaded MFC GUI that worked with
Contract #2: Signed a 6 month contract and rode the gravy train for 1.5 years before I couldn't take the stupidity anymore. Highlights of the gig were the time that the developers decided that the best database choice would be Object Store, but Marketing over rode developers and so we found ourselves writing an object-relational wrapper on top of SQL Server. The NON TECHNICAL PM didn't know the difference and we were unable to convince him that he should push back on this decision. Then there was the great "transaction controversy" where me with 8 years of databasing experience was over ruled by someone with {I'm not kidding} 3 weeks of database experience. The decision was made that MS transaction server, and transactions in general, would be too expensive and so they would not be used when transferring data across a wireless connection from a hand held to a SQL Server box. I was unable to convince the completely NON technical PM of the seriouseness of this situation. I finally couldn't take it anymore so I left. It has been 1.5+ years since I left and this product is currently installed at 1 user site and they are having "database problems"...
Contract #3: Best PM I ever worked for. The problem was that a staff of 220+ ADA programmers was making their first attempt at an OOP C++ application. The bigger problem was that project management {way high above PM level} forced an arrogant trash talkin OOP mentor onto the PM {trash talker: one who sounds great to high management but who is otherwise incompetent}. The mentor was supposed to know something about OOP and architecture. The mentor took a combat system which could have been as simple as "ship, sensor, track, doctrine, weapon" and he turned it into an unmitigated disaster of more than 8,000 classes that featured such classes as "TransitionFromStandbyToSafeNotComplete" and "ChecksumCalculator" - the latter being a class with one method --> calculateChecksum. But in every high level meeting that I attended there was my PM, who was quietly sitting in the back of the room rolling his eyes at the sh$t that was excruding from the OOP mentor's mouth. During one particularly bad sh$t storm with many high {I mean real high way above PM} level people in the room the mentor was arguing for the inclusion of another half dozen classes {with one method each} into the project. Well, I had a helluva gin hangover that morning and I wasn't in the mood for a sh$t bath and so I blurted out "yeah, yeah, yeah, and 8,000 classes later you have a system". The mentor didn't know what to do or say so he walked out of the meeting. My PM was beaming from ear to ear. Within 1 month the mentor was gone. Did I mention that my PM was both TECHNICAL and POLITICAL? Best PM I ever worked with and I will be working with him again, hopefully soon, in the future.
Contract #4: Short term biotech embedded. As I type this I am waiting for a meeting to end so that I can be tasked. I was going to play golf this summer while waiting for the economy to come back and rates to improve. But the phone rang. So I talked to these people. I'm here for 1.5 months. The work is good so far and my PM has had a large hand in writing the code - he's TECHNICAL. This contract will most likely lead to
Anyway, sorry about the length but IMHO being technical DOES matter. But the best PM I ever had was both technical and political...
--Richard
http://www.gel.ulaval.ca/~dumais01/genu
I am surprised to hear you are experiencing a barrier to project management on the basis of technical knowledge. It may be more likely you are being dismissed on the basis of not demonstrating an adequate base knowledge set for this occupation. Having been an IT systems engineer, IT manager, IT Director and IT Senior Project Manager over the years - I feel qualified to state the following: In my opinion, individuals often underestimate the degree of difficulty involved in good project management, and I'm not talking about the challenges of understanding the technical components of whats contained within the project scope. I'm referring to the ability to identify and/or source out project sponsorship, define deliverables, assess and assign the correct resources, lead by consenus versus direct authority, build good and easily understood projects plans, and conduct a meeting and update process that is actually constructive throughout the project. There are a lot of soft "social services" types of skills to make a project close on time. Hence why MBA types are mostly preferred in this role - management usually figures its easier to teach them the technical than the techies the people skills. Anyways, I would highly recommend that anyone still driven to this role start out at http://www.pmi.org . This is "the" certification and education path to good project management.
In my experience the manager has primarily been a founding partner in the business. He knows his technical stuff because he had respect enough for his developers to learn their language before asking for anything business related to be created. The ony problem has been that technology has moved faster than the managers' ability to grasp new paradigms so they often insist on methods older or less suitable for handling certain tasks. Like snapshots of a competent manager several years ago that did not grow with the times. Not only is it bad for interpersonal cohesion, but more importantly it is bad for business.
Get tech savvy managers or make it a company policy to have tech savvy managers I say. There has to be a line drawn where internal neoptism (of sorts) comes into the picture.
Inadequate knowledge is the downfall of the integrity of any service or product.
The reality is that for any project of substantial size, it's impossible for a single person to manage it. From my experience, it's best to have one person be ultimately responsible for the project, and let them focus on the overall schedule and budget. Then have a Technical Lead (who works for or with the PM) interact with the engineers and translate for them. But don't rule out a PM because they were never an engineer. A successful PM will have a good BS detector and will know when to believe an engineer, and when to question them further. It's a give and take process. But overall, if you can't pick your PM, educate them, don't work against them.
its spelled savant, you fucking retard.
Provide feedback, do not do the impossible, but be grateful that somebody is watching out about how things look and keep the lid on your runaway creative power and does not impose his personal technical preferences on you.
P.S. no, I am not a manager. Would not want to - I will be bogged down with my technical preferences and would not pay attention to the sugar on the top. Which customers like.
<^>_<(ô ô)>_<^>
Short of that, it looks like your company is due to go down, oh say about.... (looks at watch) now. If management can't listen to its people and make changes, it needs to be overthrown, ousted, cleaned, deleted, etc. Go to the TOP. If the CTO does not listen to your suggestion, its probably because he knows everything about everything and does not need help from lowly Engineers. The truth is, the only code he has written is rotting on IBM punch cards from his university days. Look for a new JOB. These people are ruining your career.
I've seen dozens of projects fail. Only projects with engineers acting as project managers have succeeded. The concept of "management specialists" is fatally flawed, and actually quite insane if you think about it for awhile. Managers have to be able to make decisions based on personal experience and domain knowledge. Traditionally, engineering project managers were very senior managers with advanced degrees. Project management was a field that you would work your way up to after several years as a junior engineer, then senior engineer, then team leader. This is another fad notion being followed with no substantiation or logic, probably as a result of the deficit of qualified project managers during the dotcom boom. It turns out that the projects probably were not all that important, however, so, in the long run (like everything else) I suppose it doesn't really matter.
But don't think you're going to get it to work.
If your org is typical, you may actually be being saddled with this "project management" in order to collect productivity metrics. In this notion engineering development is treated as a Production process rather than as a Design process. Engineering, of course, is a Design process, so to manage it you have to look at how engineering design has traditionally been managed -- what has succeeded and what has failed. Production processes are good for managing things like building a tract of houses.
When I was a kid I spent several years working as a building contractor and a project manager of building construction. For the last 20 years I have been an engineer and recently a manager of software development. They are not at all the same thing and the models should not be confused.
I prefer to give them such an outrageous time estimate that they either give up on the idea or let me do things how I want them so that it will "get done faster". They usually like the end result better than their original idea, anyway. When they want me to do something, impossible I will say that it will take me a while to figure it out but that I will try my best and just write enough code to prove that it won't work. One other thing I do is say that I don't understand and have them explain it in so many different ways that they forget what they were wanting done in the first place and come up with a new idea that is actually possible (things of the sort are not documented where I work).
http://www.accountkiller.com/removal-requested
Just because it was an anomaly of epic proportions, here's my favorite PM's background:
She was nearing 50, had a degree in Sociology, and had been managing I/T projects for a decade or more. A lot of her projects were cobol and RPG for banks, and we were a Java house. She was remarkably good at PM. She was also seriously not technical.
Her best moments:
-- She once doubled a bid to a client based on his being unprepared and an a$$. Her explanation was life was too short and she'd rather not have to deal with him, but if he paid a vicious premium, we were there for him...
-- She liked to keep status meetings short, group-wide, and effective. Gant charts or checklists of milestone items would get a quick review, we'd respond on change in status since the previous meeting, and we were gone.
-- She knew she didn't know code. She didn't revel in it, but she would look for an effective analogy on critical issues so she could understand them well enough to do initial communications with clients (to shelter us). If it exceeded her ability, she'd arrange a call/meeting with all three of us, and she'd quietly listen and learn while we worked with the client to find a workable solution. She was willing to learn, in other words, and wasn't intimidated or put off when we would contradict or correct her on technical items.
-- She *did* know people, project management issues and methodologies, political tricks, and everything else, thanks to her adapting her sociology training over to the topic.
-- She'd rarely play us politically. If something was hot, we'd get a warning. If it was a lame issue, she'd say it was likely to fade away if ignored.
Going the other direction, I've seen technical types that were the epitome of the Peter Principle... great techies that had been handed a budget and a project without a lick of training or ability to handle the project. This scares me *more* than a non-tech PM, because they often suck at delegating, politics, shielding the techies from distractions, etc.
Having started as a design-build engineer on Semiconductor Fabs, I've got to say the software field is pretty full of rank amateurs in Project Management, in general. The people I worked with in construction PM were trained experts and had field experience and an awareness that careful design, scheduling and bidding/estimating were necessary specialties, not off-the-cuff afterthoughts, and that these were necessary costs in any large project. Anything less is like building a house without a blueprint!
I'd also argue that poor I/T Project Management training is reflected in the poor overall quality of software compared to any other engineering discipline. But that's a whole other can of worms.
I've noticed a subtle character trait that is important here. Some leaders/teachers don't mind being corrected. Let's call them wise. Other people feel it undermines their authority if you prove them wrong or ask them a question they can't answer. Many will punish you politically for showing them up, even if that wasn't your intent. Yup... not wise at all.
This knack/flaw alone doesn't make someone a good PM, but it sure does make for a crappy one, if the PM isn't a genius at both PM and any tech roles they fill.
Why wisdom? Well, I was told once that wisdom was learning that you can't know everything.
The first thing I tell the customer / client as a PM is that although I'm not a geek, I do speek geek. Running interference to allow the programmer to work his/her art is critical. They need to be freed from the morass of a 40 minute hallway meeting with the customer, resulting in my two sentence deliverable to the programmer. And I read /. after work 1:00 F@#$#* in the morning. Why, because it gives me exposure to the "other" side. I've read about 95% of all the messages here, but this one prompted me to write. I think the best definition of the PM programmer relationship is symbiotic. Like the bird that picks meat from the teeth of the aligator. Both need each other. I highly recommend mutual outide activities, shoot pool during lunch, or drink beer after work, whatever,
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?"
The man who never alters his opinion is like the stagnant water and breeds Reptiles of the Mind -- William Blake
To be a programmer, you need to be able to understand and solve technical problems. To be a project manager, you need to be able to understand resourcing, management and in some sense, sales problems. Project managers are stuck between the techs, who want to do things technically as well as they can, and managers who need to do things cheaply and make the best profit, and sales types who need a project that is sellable.
You need to compromise your desire for technical perfection to be able to relate to all the concerned parties. You need to see it from their point of view as well as from the tech's point of view. Just like it's sub-optimal having a non-technical project manager (at least, from the tech's point of view), it's also sub-optimal to have a purely techo project manager...
rr
Quidquid latine dictum sit, altum videtur.
I think a project manager can do a great job despite not having the technical background of his programmers under him/her.
I've done web programming and website project management, and I would have to say, as a programmer I trust a tech skilled project manager more; and as a project manager, I feel I'm a better manager knowing the basics of what my programmers are working with/on.
But still, if a project manager is simply a great leader and listens to his programmers' suggestions, then any lack of background skills can be forgotten.
Like I said, it all depends on the situation and the people involved.
We are often faced with immovable deadlines and limited resources; we nearly always end up negotiating about the scope of what we can deliver within those constraints.
Of course, this is not in a consulting/outsourcing environment - we're an internal team, so our clients are allegedly on the same side (hah). Nevertheless, we agree with the PM what's in scope for the current phase, and what they need to do to increase the scope if they're not happy with that. We can do this because we have a habit of meeting those commitments - sure, we screw up, but never without letting the PM know as soon as we know what the situation is.
A lot of responses to this thread seem to indicate a lack of trust and respect between the techies and the project managers. I don't care how "technical" the PM is, if that basic trust and respect is lacking, you will never fix the problem. Of course, trust and respect need to be earnt, and sometimes, we techies have to take the first step....
N
It's all very well in practice, but it will never work in theory.
Maybe they are.
Brains != Techie knowlege
Give me the time or the money and it will get done.
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.
Actually, you are saying he's not a good PM... that's what "mutually exclusive" means.. that the two items cannot co-exist...
You pose a good question. Been PM'ing for 12 yrs. And I think tech knowledge IS an asset. And here's why: PM work requires, more than anything else, GREAT COMMUNICATION. Your dev background will actually help you IF you realize that dev knowledge is only a small (but possibly very valuable)component of the job. PM'ing (well done) is basically project COLLABORATION with you as the communication nexus (and planner, and work coordinator and supervisor and advocate for dev and advocate for mgmt/S&M). In other words, you need to have: - Great communication skills - excellent business analysis - reasonable technical analysis skills - intimate knowledge of the SDLC - infinite patience with everyone - balls of iron (because you often have to say no to a variety of folks - nicely, but firmly) - good knowledge of development best practices - how to listen more than talk - basic PM skills (plans, resource mgmt, pm methodologies and best practices) In that context, your dev background is a huge benefit - not an encumbrance. As long as you are willing to leave the developers mindset behind and assume your new mental role: as a support resource for your dev team AND the business players. Now, how many PM's have all that knowledge overall or do their work in a way that serves the dev team well and the business well? Only a small handful that I have ever known. The secret ingredient: you must become an intelligent and attentive facilitator of a huge dialogue which, ideally, includes almost everyone from customer support to sales to exec to dev and QA (and customers, if you have the access. The more you involve the whole team, respect and use whatever input you can AND provide frequent reality checks for everyone, the better the productivity and the better the product. This is why you often work with PM duds: mgmt does not understand project management and therefore often does not know who to hire - so they pick someone with 'pm' on their resume. There is a lot more to (really good) pm than technical or development background, but your dev background is not a liability - it's an asset, as long as you remember it is only a small part of your skillset as a PM. BTW, my background includes: UNIX/Network sys admin, Oracle DBA, Web Dev, Perl/CGI (only a little), a little PL/SQL, shell scripting, business analysis, technical analysis plus I am a hobby programmer, having played in assembler, C, Perl, Java. So I am pretty sympathetic to where you are coming from. don't be discouraged period (no 'but'). Just remember the big picture of great PM'ing is going to use a lot more than your dev skills. Hang in.