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.
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(); };
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.
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.
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".
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).
The evidence suggests to me that either you can do it (presumably with some practice) or you can't.
I'm going to have to disagree with this one. Project Management in general is a pretty mature field. I deal with project managers from the oil, gas and chemical fields every day and these guys and gals are well trained at what they do. There is very little "hey, we're just good at it." Most project managers work their way up the system during their careers, learning different aspects of a project from the bottom of the project team on up. Plus, companies will send project managers to either outside PM training, or for the larger companies will have their own, interior colleges.
The reason all this time and money is spent training project managers is because a good project manager (in those fields) can literally save billions in capital costs, hundreds of millions in lost opportunity costs and workers lives. Project systems are pretty well defined and they usually require proper front-end-loading to make sure the project team knows exactly what they're supposed to be doing it before they actually start execution. Plus, there are formal risk analysis steps performed so the team knows what might come back to bite them in the ass so they can be prepared with the appropriate contingencies.
Now, with respect to software, from what I have seen anecdotally there's just not the same kind of rigor placed on most software projects, even large, very expensive software projects. The upfront definition tends to lack the type of detail you see in other (physical) capital projects. I don't know if its the idea that "Hey, its only software, its no problem if we change crap halfway through implementation" that causes this or something else, but its a killer when it comes to controlling cost and schedule, not to mention the ramifications that has on the project team (low moral, work crunches, throwing bodies at the problem, etc.).
The moral of the story (I'll stop rambling here) is that project management is very much a learned skill. Although its not as mature in the software field and software specific project management training may not be as available as more PM training specific to more traditional industries, its still worth looking to get as much training as possible. It will pay back in spades. Also, as someone above mentioned, network your butt off with other IT PMs. Learn from others what works and what doesn't work. Also, start formulating a company-wide project system with you colleagues. And go read up on the successful IT PM jobs. From what I understand Boeing did an awesome job with the software development associated with the 777. See if there are any case studies about how they did it floating around.
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.
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.