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?"
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
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!
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.
You've had a much better experience with this than I have. I've only had one instance so far where I've had to tell the PM that it was impossible but the problem was that he didn't believe me. His reply was "So, you don't know how to do this?" so I gave him a mathematical proof as to why it was possible. This PM has a Masters in Strcutural Engineering from a well-respected university, so I thought that should be enough, however he simply crumpled it up and told me that he would write the code since I obviously didn't understand what he wanted. A couple of months later he raises the issue with me again and tells me that he is having trouble implementing it. Knowing that he is going to ignore my proof if I show it to him again I came up with the most basic and realistic data set that I could that would be unsolvable. I then asked him to try solving this data set by hand. Two days later when he came to me and told me that he didn't think it was possible I had to fight very hard to hold back the "I told you so" because I was hoping that this incident would convince him that in the future if I say "impossible" then he should consider the possibility of something really being impossible. Unfortunately nothing has changed and I am now looking to change jobs.
Anyone know a company that doesn't treat its developers like morons and that is hiring?
I think you're right in this. A project manager should, in my opinion, be responsible for planning and control, and not for any tech-stuff. In my company, there is a group of persons that discusses with the customers about what they want, and what is possible. THAT's a point where tech-expertise is needen. When the specs are settled, it is handed over to a PM to make sure it gets implemented.
A project manager has a set of skills that are distinct from by complementary to the skills of an engineer. A project manager who starts their career as a project manager often has great skills for, budgeting, say, and understands the administrative details as a role. The reason that these people fail is that, lacking an engineering background, when creating plans they are unable to accurately estimate time and resource requirement, and even worse they are unable to identify critical paths, dependencies and opportunites for parallelism.
The ideal structure is to have a project manager to take care of the details, and a system architect to see the "big picture" and have overall responsibility for planning and executing the project. If the project manager is in charge, then that individual should have at leat 5 years experience "in the trenches" on similar projects, and should have the authority to set priorities and trim the feature set if necessary.
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
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).
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.
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
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
Thats trick to getting a techie to work 20 extra hours a week for the manager's benefit - make 'em feel just enough like owners to try and "save" the project. You set up an impossible situation and tell one of that they're "lead programmer" and watch that one self-destruct. Works every time.
This post expresses my opinion, not that of my employer. And yes, IAAL.
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.