Project Management For Programmers?

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

Comments

help your PM help ypu

[chongo]

I found that it was easier to sit down with my PM and asked then the one thing they needed to make their job easier. If it was half way reasonable I went out of my way to give that to them ... in turn they seemed more willing to listen to reason and help form a project timeline that was 1/2-way based on reality.

Stop whining, start doing.

[smoon]

As a developer I've found that most management-types don't give a hoot about technical details, or much of anything else that a heads-down developer might care about.

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

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

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

If that doesn't work, then get a job with a company that has a clue. They're out there.

Don't mix management and architecture

[rsmah]

The problem your firm seems to be facing is that you are mixing project management with system design/architecture. What's the difference you ask? Project management is the process of resource allocation, scheduling, budgeting and task tracking. System design/architecture is the process of figuring out what should be built and how it should be structured internally.

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

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

In a nutshell.

[Fross]

One thing both you and the project manager need to understand is:

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

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

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

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

Fross

(a technical architect working as a project manager!)

Only bad managers demand the impossible

[Skapare]

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

Re:Only bad managers demand the impossible

[Surak]

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

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

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

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

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

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

Re:Only bad managers demand the impossible

[Surak]

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

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

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

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

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

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

[PinglePongle]

Until recently, I was the development manager at a fairly large internet company; we had project managers who knew very little about software development, database design or how to run software projects. Do you know why ? because that was my job.

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

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

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

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

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

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

The attitude of most of the posts in this subject has been "huh, we're 200 times smarter than those idiots running the project, they're so stupid they couldn't blah blah blah". Hey, if you're so smart, it's your job to use that intellgence to move the project forward, not whine about how what a bad job everyone else is doing.

It's not as easy as it looks

[James Youngman]

There's much more to successful project management than there appears, particularly when the PM is also managing the relationship with an external client. It's the PM's job to make the client happy and (usually) deliver a profit. In a software context, this normally means delivering some software that works (see the Properly Testing Your Code thread).

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

• Understanding the business context and business drivers
• Managing client relationships (even for internal clients)
• Estimating and planning skills
• Tracking progress against plan - and taking appropriate action (pay attention to this one!)
• An understanding of what timescales are realistic. For example, is it realistic to estimate design:code:test in the ratio 3:2:1? (answer: no).
• Understand that you need to make it possible for the client to change their mind half-way through
• Delegation skills (you can't do it all yourself, you know!) and motivational skills (i.e. understand the kinds of things you can / can't ask of people).
• Risk analysis/mitigation
• Personal organisation and time management
• (In some shops) Project accounting skills

Also, don't underestimate how much work this is. If you are team leading (i.e. working for a PM) then you can expect to lead a team of up to 8 and have the interaction with those staff and the PM take up 100% of your time (i.e. no time left for coding anything yourself). If you are a PM, you won't be able to directly supervise that many staff, because you have the added responsibility of steering the ship. Techies-turned-PMs are frequently tempted to take on the odd technical task - but resign yourself to the fact that you will have to delegate it to one of your staff in order for it to get done on time.

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

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

Who writes the specifications?

[geoswan]

"...the project managers have no programming experience of any sort. I'm of the opinion that project managers should understand the projects... As a result we are routinely told to skip testing or to implement the impossible, with an emphasis on how things look rather than how well things actually work. Has anyone else found the barrier to project management is their technical knowledge. How did you get past it?"

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

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

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

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

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

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

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

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

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

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

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

[DNS-and-BIND]

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

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

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

Not Quite

[BoBaBrain]

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

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

If you are relying on one team member to have *all* the necessary skills, then you do not have a real "team".

Nothing beats a good PM

[hagbard5235]

I know that there are a lot of rotten PMs out there, but if you ever have the good fortune to work on a project with a good PM you will never willingly work on a project without one again.

I miss my PM. Her job was basically:

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

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

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

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

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

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

Re:Oh Please!

[Fnkmaster]

This is pure trash. The fact is that most programmers don't and don't really care to understand much about the business. That's exactly the reason that you need technical leads or TPMs who understand both the business requirements and enough of technology to make reasonable trade-off decisions, and either work closely with a business-oriented PM/requirements person, or have excellent rapport with upper-management (i.e. have their trust - not be perceived as a lying technology person).

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

[James Youngman]

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

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

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

• Programme Manager - these are the guys the Project Managers work for
• System Architect - career progression here is measured in terms of the criticality or size of the project you run/work on
• Principal Consultant - your job here is to be your organisation's main expert on some specific thing (deep skills rather than the wider skillset which is more usual for a system architect)

We do have some career positions above those, but they're mainly line-of-business and divisional management, Managing Directors of various business units, and so on. We have a dozen or so members of technical staff who are more senior than the System Architects for large programmes and the principal consultantts, but they don't really have specific job titles (as you might expect at that level, people know them by their name and reputation alone).

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