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.
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?
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
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...
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.
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
I understand your frustration that you see things going badly and want to do a better job, but knowing the details of developers' work is not the answer.
The best project manager I ever worked with knew nothing about the details. It was in the early days of the Web, building a very complex Web site for a client, and he barely knew how to write HTML. But here's why he was a great PM: He trusted his team, including the technical lead, he understood the people and knew how to get them to work well together, and he knew the importance of high level issues like testing, clear specifications and change control. He was a good *manager*.
And here's another key to success: strong sales people. Good sales people will get the right cost estimates from the developers/consultants, and then won't buckle under pressure when they present those to the client. Then you actually have time to do the testing which was factored into the proposal.
I was a very technical project manager, not quite a developer, but I like to think I understood the tech details very well and got on well with my various teams. But I would regularly get bogged down in the details simply because I enjoyed them, and as a result would spend less time on the strategic issues like persuading the client that they should reconsider their latest idea. I think I did well, but I know I could have done better.
My advice to you is this: talk to your project managers and sales people, and get them to understand the importance of the various stages of work. Show them that a slip early on can lead to more costly slips later. Advise them, and get them to trust you, so that when you say "We need to spend two weeks testing" they make sure you get that two weeks and don't think "Oh, but I'm sure we can get away with a couple of days".
As for progress in your career, project management is a lot about people and little about knowing obscure technical details. If it's people you want to focus on, then great. Otherwise perhaps you should aim for being a senior architect. And then your company can charge more for your time, and they'll have even more budget to spend on testing!
I used to work for a IT company with a creative vent, as a result they hired project managers with ZERO understanding of the tech side, and knew more about making things purty.
We got by because the project managers knew that they didn't know anything, so they would ask about everything, but that did put a major strain on the tech department as we ended up being consulted about EVERYTHING.
I am a strong believer that project managers should understand the area that the project is in, they don't have to be a guru but it makes sense that they should at least understand whats going on.
However I also know that a project manager needs to understand more than 'joe programmer', as business(tm) (as in harvard business school) comes more into there jobs. And of corse they should be able to buffer the programmers from the clients, I know a lot of hackers who cannot comunicate with each other, let alone a suit.
c.
This is part of the problem with PM's not being technical (and most management of tech areas). The wrong question for a PM to ask is, "Can XYZ be done". The wonderful thing about technology is that the same goal can be approached many ways, and technologies combined in unique ways. While lots of things are possible, how many are worth the money and man hours it would take, both in development and support?
"Can it be done?" should be replaced by "Should it be done?". When the work is done and we step back and start supporting, living with and working with the result of the effort, will be truly get what we say we want?
More things can be done than should be done. This is where not having fundamental tech knowledge on the part of a PM leads to trouble.
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.
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.
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.
When my current manager informed me, a month before the project deadline, that oh-by-the-way, the program would have to be distributed on separate systems *on segregated networks*, and I took a deep breath and tried to meet him half way, he put held up his finger to silence me. He turned to the whiteboard and wrote the word NEGOTIATION on it. Then he turned back to me and said, "This is NOT THAT. I am the manager. I do not negotiate."
That's why, with a week to the deadline, I've been on slashdot all day. Treat me like shit when I'm trying to help you out? Fine, OK, you don't respect me, I won't respect you, and guess what? You're not going to really motivate me to do my best work. And if you obsessively time my daily arrival/departure times TO THE MINUTE, I don't think I'm going to be volunteering to work many more unpaid weekends of overtime.
Anyone looking for a Perl/Linux/security geek in the London area?
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.
That's the thing - we don't have to suffer. We should know the technology well enough to ensure we can keep our asses covered.
:-) If your managers are good (as mine are at my current job) then there's no need.
;-) bcos we take pride in what we do. I know I could move to a job 20 miles down the road for 5-10K more, but frankly I don't want to.
Of course, there's no need to be defensive unless your management really are a bunch of unscrupulous weasels!
My current place is pretty much a classic *good* example. Medium-size company (200-250 employees), flat management structure. You can trust the managers, right up to board level, not to stiff the employees - many of them have worked up from engineering positions so they know the score, and if you say "the customer's wrong, it'll actually take this long" then they'll fight your corner as far as it takes. And it gets real loyalty and real benefits for the company - we'll work longer hours and put ourselves out to meet a release (up to a limit, of course!
Grab.
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.
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.