Slashdot Mirror
Advice for a New Software Project Manager?
Tom O'Neill asks: "I have recently been promoted to 'Manager of Software Development' at the small business I work for. I have been developing web-based software professionally for about 6 years. I have seen the software development cycle work and I have seen it fail. Are there any project managers out there with some advice for a green horn like myself? Are there any books or other reading material that I could read in order to manage a software project effectively?"
Pay attention to history ... It's bound to repeat itself.
Are there any books or other reading material that I could read in order to manage a software project effectively?
No.
(Semi-serious. The evidence suggests to me that either you can do it (presumably with some practice) or you can't. If there is a group of people who can learn it from books, they are lost in the noise. Nor does there seem to be a way of knowing in advance whether you can. Like I said, semi-serious; I don't fully mean this but it's not fully a joke either.)
In all groups, there are offical, and un-official designations. I, for example, am an Infastructure Software Developer. But, I am also the team's go-to guy. I have no long term projects, only short ones, so people bring me things to work on, on the side. There are the guru's who everyone goes to and the loners or the popular people. If the boss knows the groups working, they can interact more effectivly. Also, don't be afraid to let the programmers have a little extra room to develop and imagine. If you become a slave driver, your project will fall behind and mabey even fail.
If you want to be the best, think back to when you were in the team and what your first boss (or first good boss) were like... if they sucked, do the total opposite. If they did things well, and you remember having a good time, do what they did.
I will leave you with a quote from futurama. "If you've done your job right, it won't seem like you've done anything at all." - God
while(1) { fork(); };
Well, for one, creating a good environment for the coders can help (meaning no tiny cubicles without a door)!
"Are there any books or other reading material that I could read in order to manage a software project effectively?"
Complete Code.
Seriously you already know something about one aspect, by wearing a particular hat*. Now you need to work on the "How do I manage people" aspect? Compared to that, code managment is easier.
*By that I mean that you know one, or two jobs. What about documentation? What about interfaces? Fill in as needed, just remember there are holes.
Your chief weapon is surprise...surprise and fear...fear and surprise.... Your two weapons are fear and surprise...and ruthless efficiency.... Your *three* weapons are fear, surprise, and ruthless efficiency...and an almost fanatical devotion to the penguin.... Your *four*...no... *Amongst* your weapons.... Amongst your weaponry...are such elements as fear, surprise....
-- I have monkeys in my pants.
My advice to you is to get the hell out now while you still can.
All joking aside, get yourself certified; that will give you a base of knowledge that will help you understand what you're doing.
The following a Must Reads:
- The Mythical Man-Month
- Code Complete
- Rapid Development
I personally don't jive with RD, but the book is an excellent source of knowledge and is applicable outside of RD. Also, get yourself educated in risk management and estimations (work breakdowns). I haven't seen any good books on either -- maybe I need to write oneGood luck.
Yeah, right.
Many people have been where you are now; tap their experience and avoid the pitfalls they got to live through.
You can find a bunch at the local PMI Chapter.
Yeah, right.
Welcome our new green-horned overlords.
Best regards, A.C.
My personal tips, based on that projects are executed by people:
- Know the people you work with, understand the way they communicate progress/problems. Everyone is different
- Create an atmosphere where delays are acceptable, but only when pre-announced. This avoids surprices just before a deadline and allows you to take actions in time.
- When assigning a task, let the receiver make a time plan and commit to it. You'll find out they are in general too optimistic but highly motivated to make it because they made this promise towards you. Never push a deadline on them if you can avoid it.
- Don't ask for too many progress reports, talk with your people and ask once in a while a snapshot of the current task. Non-performers can be identified in an early stage this way.
All items I mentioned are human related. Why? Because my experience is that in most cases that is the only area where one can (is allowed to) make a difference.
I have seen the term "project manager" applied to a full spectrum of job duties. I think most people will agree that a project manager is responsible for insureing that a project is completed on time and on budget. (Although that should be the responsibility of everyone.) Beyond that one goal there may be many secondary duties. Part of the confussion may be that a project manager is also tasked with other duties such as designer, lead developer, or HR management. Responsibilities will also depend on the size of the project. So the first step should be to talk with management to determine your exact responsibilities, and to talk with other project managers within your organization. Once you have an understanding of you role then you can start looking at reading material.
There are some basic management skills you will want to work on. When leading technical people you need to convince them the project is good ("buy in"). Lots is written about this and most of it can be summed up with "Treat people with respect." You need to know how to critise properly by asking the right kinds of questions. In general don't ask questions that can be answered with a yes or no. It is harder then you think. Budgeting time is very important. Gant charts (ala MS project) are usefull.
Management Speak: You needed to be more proactive.
Translation: You should have protected me from myself.
Management Speak: I'd like your buy-in on this.
Translation: I want someone else to blame when this thing bombs.
Management Speak: We want you to be the executive champion of this project.
Translation: I want to be able to blame you for my mistakes.
Management Speak: We need to syndicate this decision.
Translation: We need to spread the blame if it backfires.
Management Speak: We have to put on our marketing hats.
Translation: We have to put ethics aside.
Management Speak: I see you involved your peers in developing your proposal.
Translation: One person couldn't possibly come up with something this stupid.
Management Speak: There are larger issues at stake.
Translation: I've made up my mind so don't bother me with the facts.
Management Speak: I'll never lie to you.
Translation: The truth will change frequently.
Management Speak: Our business is going through a paradigm shift.
Translation: We have no idea what we've been doing, but in the future we shall do something completely different.
Management Speak: Value-added.
Translation: Expensive.
Management Speak: Human Resources.
Translation: A bulk commodity, like lentils or cinder blocks.
Management Speak: The upcoming reductions will benefit the vast majority of employees.
Translation: The upcoming reductions will benefit me.
The friendliest digital photography forums on the net!
As a manager your duty is to ensure your developers don't do things that waste time or money. You need to do at least these things:
1. Figure out what the real requirements are. Don't simply believe that customer's (in house or not) know what they need. Don't treat customer's like idiots: they are the most valuable resource you have to ensure the software you deliver is actually useful.
2. Get the business folks to prioritize the requirements so that you can reduce scope effectively. You will have to reduce scope--better to be ready for it than to be surprised when the time comes.
3. Ensure that *everything* your developers do can be traced back to a requirement. If someone is doing something that can't be traced back to a requirement they are wasting time and introducing unnecessary complexity.
4. Never forget that your job is to bring value to the business. Don't rule out non-software options when you see them.
These ideas ultimately lead to or from, depending on how you look at it, to "build only what you need".
You really need to read the following books, as you move up the chain:
1. The Pragmatic Programmer
By Andrew Hunt and David Thomas
2. Pragmatic Version Control
By Andrew Hunt and David Thomas
3. Pragmatic Unit Testing
By Andrew Hunt and David Thomas
4. Pragmatic Project Automation
By Mike Clark
5. Code Complete, 2nd Edition
By Steve McConnell
6. Debugging The Development Process
By Steve Maguire
7. Joel on Software
By Joel Spolsky
8. Testing Computer Software
By Cem Kaner, Jack Falk, Hung Quoc Nguyen
9.Managing the Testing Process
By Rex Black
10. Lessons Learned in Software Testing
By Cem Kaner, James Bach, and Bret Pettichord
11. Peopleware: Product Projects and Teams
By Tom DeMarco & Timothy Lister
I also second, The Mythical Man Month by Brooks.
Some said that you can't learn anything from books. I just don't buy it. You can learn a lot from the mistakes and successes of others. Just like a great coach looks at films of other teams (learning from their mistakes and successes), you can do the same.
Take time to read books written by those who have been in the trenches and apply the lessons learned.
Yours,
Jordan
c'mon mod it up, it is funny
P.S. I am not the author of the parent
"Shit rolls downhill" is a common misconception. Your new role is to prevent this. Protect (but do not isolate) the people below you from those above.
Not much of a secret since I talk about them regularly, but still, these are the secret rules of TQM, Six Sigma, and most other successful projects:
(1) know what you want
(2) know how to tell if you got it
(3) tell everyone (1) and (2)
(4) allow the front-line people the autonomy (and safety) they need to make changes, and
(5) reward them for achieving (1)
I've seen projects and programs and processes fail for missing any of these steps, but its pretty amazing how often people fail either (4) or (5).
There are two methodologies I like.
1) Extreme programming - this is good if you have a kick ass team and clients that are receptive to the idea of working with your development team. However, if you are in that situation, chances are any methodology would work anyway, since this methodology assumes best practice for everything.
2) Rational Unified Process - this is good if you can afford it. Its more adaptive to situations where your developers are not as stellar and clients are a bit more unreceptive. But the nice part is that it adapts. Note: you don't need to use the Rational tool set in order to use this methodology, but its nice to have anyway.
Archie - CIO-for-hire
I'm surprised that nobody mentioned the Quality Software Management series by Gerald Weinberg. There are 4 volumes; you want to start with the first one. This is a great series, if you can take the time to properly digest the contents.
This series is concerned with the management process rather than any specific techniques. It won't make you a great manager by itself, but I found it helpful for knowing when I was heading in the right direction.
Play it cool, play it cool, 50-50 fire and ice.
Two books: Fred Brooks' famous "The Mythical Man-Month" and Tracy Kidder's "Soul of a New Machine". The former is all about managing large, heck, gigantic software projects. The latter is about managing small, highly motivated teams effectively.
get rid of 'em. everyone will love you
vodka, straight up, thank you!
/usr/src/linux/Documentation/ManagementStyle
Hit yourself in the head with a hammer. Notice how itt feels good when you stop!
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
Don't forget, they look to YOU for leadership.
Frink: Nice try floyd, but you were designed for scrubbing, and scrubbing is what you shall do.
I've heard too much about Extreme Programming stifling and frustrating good developers to want to use it with a "kick ass team", and I have yet to see a client able to field a Customer Representative that can do what XP demands of them. I would consider it if I had a large inexperienced team, or a team already used to XP. I'd especially consider it if I had a client who couldn't be nailed down on a project scope, and who could be thus tricked into not nailing me down on what gets delivered by the deadline.
Most of the time in my experience (both in and out of software) a project manager is handed the scope, manpower, budget and deadline, already decided by pointy haired people, and told "make it so". I really can't see how this can be done with any confidence with XP.
I'm less familiar with "Rational Unified Process", but a quick glance looks more makes it look more like expensive and flexible project management software than methodology for managing anything. Software can be a useful tool, but it cannot be the management itself.
----
Open mind, insert foot.
Good luck, you will need it.
There is no god; get over it already! Never exchange a walk on part in the war, for a lead role in a cage.
You've been a developer, so remember what it's like. You'll be working with a lot of people who probably don't understand software development and software developers. You're the developer's advocate, so don't forget how to think like one.
Ceci n'est pas une signature.
Always always always be helpful. Make it so your people can do their work. Provide and get out of the way. The worst managers, IMHO, are those who look for failures and a place to hang blame. Anyone, I mean anyone, who is berated or belittled will never want to do their best for you and company. But if you help them and teach them, they will always give their best.
(and the breakdown thereof)...
I have seen some other suggestions here re books that are standard software dev. fodder at Barnes and Noble but I have found these to be more insightful about the process dynamics:
Beyond Chaos Chapter 7 is a PM Primer, which should be helpful.
If It's Broken, You Can Fix It: Overcoming Dysfunction in the Workplace
and finally, read the Appendix of The Dilbert Principle about his management principle - OA5 which is unimplementable in any company which you don't own, because the first bullet point "Get rid of all the assholes" is impossible.
Take heart in the fact no matter what you do, in the end, you will be a reviled peon from the POV of those above you and the incompetent tool of oppression from the POV of those below you and bitter, sullen, spiteful and venomous towards both groups. Later when the project is a smoldering crater, you might get to RIF most of your team.
Project Management is a snowmobile racing across the tundra and then suddenly it flips over, pinning you... At night, the ice weasels come. - Apologies to Matt.
Thats freaky. I also have about 13 years experience developing and some 5 - 8 years of PMing and managing other PMS.
I did read all three books and recommend them. I particularly recommend 'Rapid Deveopment' - though the name is a misnomer.
Finally my 'sagely' piece of advice is there is no one type of project, project manager or project methodology. The hard part is to match all of those to the culture, the task at hand and the clients.
For those about to die...we salute you.
Make sure there is some level of monoculture in your .. culture. You want everyone to be comfortable and to some degree, even a small one, interchangable. You want skill level to be similar, style to be similar, documentation to be similar. Heck, even the same for some things. Of course, there needs to be some level of difference to allow freedom, to allow people to be people and not cookie cutters.
-
ping -f 255.255.255.255 # if only
There are a number of books by Capers Jones which are non-trivial reads, but are very evidence-based (i.e., what really works and what doesn't, based on studied outcomes rather than theory).
Also, here is a very succinct guide to a few, mostly non-technical topics which I've found to be very helpful in the real world.
I'm not talking about a manual for your product, I'm talking about keeping track of what you do, what your staff does and what the results are. It may be laborious to do so, but there will be times that you'll be glad you did. Also, you may wonder why something was done a certain way a few years ago; having some kind of knowledge base written down will be invaluable.
Document the code. Make sure that people adopt javadoc-type conventions. Check out Doxygen if you're not doing Java development, and make it a policy that people need to comment their code in places that are not painfully obvious. Programmers can be quite fat headed at times about this, because "hey, I know this, and if you can't read this then you aren't good" or whatever. What is obvious to them might not be obvious to others, and if you want to do a quick scan over some code, its easier to read a comment defining a block than figuring out their "spark of genius du jour" (sometimes people write things overly clever thinking that its more efficient when in reality its not and only making things harder to maintain).
The point of this is that:
- Your staff will not be the same forever; people move to other projects or other jobs.
- You will forget details.
- You will find it difficult to recall exactly what you and your staff did several months ago, especially if the project is large and fast moving.
I'm not saying that the above points are absolute, but in case you do find yourself in any of those positions...By keeping documentation, you will always be able to back up, defend, promote and prove (or disprove) your ability to manage. Now you just need to make sure you make the right decisions; nothing can help that except experience and good judgment.
Never hit your grandmother with a shovel, for it leaves a bad impression on her mind...
The Deadline is silly, but it's a good read and has excellent information and might be the first one you read. Peopleware is the most important book. Read Slack last, as it's least connected to specific software projects, and more on management, in general.
" Well, for one, creating a good environment for the coders can help (meaning no tiny cubicles without a door)!"
Or we could start doing what companies did in the Dot.Com era.
A lot of what's been said above can be reduced to this:
Management is a service to your coworkers: those people are under your care, not in your power.
There was also a remark about having some degree of "monoculture" in your group. What that person wanted to say was that your group needs an ethos, a group identity, a sense of common cause even when goals are ill-defined.
There's one piece of excellent reading about the early days of WinNT... and its not the one at winsupersite... I found via slashdot over a year ago and can't find now. It was an account as told by someone on the team or it might've been Lucovsky or Cutler. In any event, it went deeper into what was different from the early OS development at Microsoft about the early NT effort, discusses "ethos" briefly, and touches on how difficult that ethos was to maintain as the project grew. That last part was a bit heart-breaking to read...
1. Remember, you are a professional working with other professionals. Your team consists of Software Engineers, not hackers/coders/programmers. Getting in that mindset helps a great deal, because you're not slapping together some product, you're engineering it.
2. Look into any project management methodology that uses iterative development. You want to do iterative development as much as possible.
3. Get as much detail as possible in a "written" spec up-front. It doesn't have to be a formal document, an email will do as long as you have something you can show the customer that they wrote when the requirements change.
4. Put in a formal change request proceedure, and make sure that the person actually making the change gives a time estimate for it before you agree to do it. Come back to management with the actual cost of the change in terms of missed deadlines, lost functionality, etc. This is where iterative development can save your ass, because you can push some functionality off to the next iteration with minimal effect on your current development.
4a. Require that the person requesting the change go over a minor "speed bump" in order to request a change, something on the scale of sending an email or filling out a web form on your intranet. You'd be suprised how many change requests disappear when the person requesting it has to do more than ask for it when you happen to pass by them in the hall.
As for books, your biggest problem is going to be putting in some sort of software development process. Almost every company out there still does seat-of-the-pants development, with lousy results. I'm a big fan of the Rational Unified Process, just be sure to customize it down to the parts you actually need. As another poster said, you don't need any of Rational's software in order to use RUP, just read their books about it.
Once you have some sort of process in place, the rest of the job becomes relatively easy, because you have the information you need to actually manage the process.
Are there any books or other reading material that I could read in order to manage a software project effectively?
... specifically the Book of Revelation. Given what line of work you're entering you simply must understand the parts about the horsemen. Got it?
Start with the Bible
Sun Tzu's The Art of War is another one that will come in handy.
I'd also strongly recommend Bret Ellis' American Psycho.
Oh, and it would also be wise to at least skim through absolutely anything you can find about Adolf Hitler.
As a long-time software project manager with Microsoft, I'm offering all of this from personal experience. Hope it helps. And as you enter this exciting new management position, don't forget to have some fun once in a while!
Whoever designed level 61 in Frozen Bubble is a sadistic bastard.
You have a sick, twisted mind. Please subscribe me to your newsletter.
The one thing that will go the furthest in keeping a project from turning into a disorganized disaster is to establish and vigorously enforce a formal change control program.
Form a change control board with all of the critical stakeholders (that's projectum managerese for "people with major influence over or siognificantly affected by the results of the project.) as members. Be vigilant about enforcing the process. Yes, there will be emergencies, but those can be dealt with via conference call, net meeting, or whatever other techno-gizmos your organization uses.
At the beginning, document the requirements so you will have a baseline to control. If someone wants a change, they have to propose a change to the requirements. Do the same thing during analysis and design, and finally during coding and testing. Manage the defect resolutions as changes as well.
When a change is submitted, perform a risk analysis (what are the chances of what is being requested in the change working correctly without breaking other things?), impact analysis (how much work is this going to be? One programmer for two hours or the entire project staff for 3 months?), and finally what are the benefits derived from the request and is it worth it given the risk and impact analysis.
The change management process isn't so much of a control process, but rather a communications process. You want to force the stakeholders to actually talk with one another about the project, so that everyone knows what is going on and no one suddenly discovers a nasty surprise and now has an excuse to sidetrack the project until their 'issue' is addressed.
RUP is a methodology, but just happens to have tool support. However, you're not forced to use the tools and you're not forced to use all of it. Only richer companies can really afford to use them. For example, I still use CVS as the version control repository not ClearCase and in other projects I use JIRA not ClearQuest.
I am not sure about disagreement with XP, I said you need good team and good client. I would like to consider it on projects but like you said, real-life(tm) kicks in. I still like that ideas from it though, one of the nice parts about RUP is it is customizable and you can customize it to have concepts from XP (pair programming, test first development) integrated with it as well.
Archie - CIO-for-hire