Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Project Management For Beginners?

timothy posted more than 4 years ago | from the what-one-ought-know dept.

Programming 168

lawpoop writes "At my current workplace, I'm tasked with creating a rather complicated and metastasizing web-database application. I've mostly been the sole 'IT guy' at my workplaces in the past, so I've never had to, nor taken the time, to learn proper project management routines — code comments mostly got me through it. Now for this project, it's getting somewhat hairy and I'm sensing that I need to start doing things in a more organized manner. What resources would you direct me to? Books? (I wouldn't mind buying one good one.) Websites? What do proper 'specs' look like? Must I use UML (seems complicated and unintuitive) or a simpler ER diagram? For this job, I just need to provide better estimates for completing features, but what will I need if/when I would be working with a team?"

cancel ×


Sorry! There are no comments related to the filter you selected.

A book I thought was good (4, Informative)

stoolpigeon (454276) | more than 4 years ago | (#27673381)

I recommend Making Things Happen: Mastering Project Management (Theory in Practice) [] by Scott Berkun. Berkun has quite a bit of experience working on and managing teams. You can check out his blog [] for more info. and to get a taste of what his writing is like.
There are a ton of books out there - his blog has a sample chapter to read so you can see if this will work for you. I thought it was easy to read and covered quite a bit without getting bogged down. The table of contents [] breaks things down to a pretty low level - so that is another good way to see if it hits on what you need or if it might cover a lot of stuff you don't care about. I know I wish some of the people I've worked for had read it and took it to heart - especially the stuff about how not to annoy people.

Re:A book I thought was good (2, Informative)

kchrist (938224) | more than 4 years ago | (#27674559)

Another great book is The Art of Project Management [] , written by Scott Berkun and published by O'Reilly. The author was a PM at Microsoft on IE and Windows teams but don't let that deter you. The book is full of great information, especially for someone new to managing development projects.

An excerpt from the book [] was posted here on Slashdot back in 2005.

Re:A book I thought was good (4, Informative)

stoolpigeon (454276) | more than 4 years ago | (#27674637)

Making Things Happen is the second edition of The Art of Project Management. They cleaned some things up and I think added in some practical exercises - and changed the title. (I'm not sure about the exact differences because I never read the first edition) I think Berkun explains why they changed the name in the forward but my copy is at home and I can't remember for sure. It is unfortunately confusing.

Re:A book I thought was good (1)

kchrist (938224) | more than 4 years ago | (#27674729)

Oh, I didn't realize that. I completely missed Scott Berkun's name in your comment. Thanks for clarifying.

Re:A book I thought was good (1)

Erie Ed (1254426) | more than 4 years ago | (#27676335)

I know my PIMPS are out there 3C3's represent in dis mutha fucka!!!!!!!!!!

Agile Software Development and Planning (1, Funny)

jeroen8 (1463273) | more than 4 years ago | (#27673411)

I would suggest to look at Agile Software Development and planning tools. These are lightweight and highly effective, especially in constant changing environments (read requirements).

Re:Agile Software Development and Planning (2, Informative)

mysidia (191772) | more than 4 years ago | (#27673709)

Do you have a web link to specific tools?

'Agile Software Development' is a 21st century buzzword, just like XML, LAMP, OO, and eXtreme Programming were some buzzwords of the 20th century.

A multitude of vendors claim their tools are for or support 'agile' development, whether they're really useful or not, is another matter....

Re:Agile Software Development and Planning (2, Informative)

TheSpinningBrain (998202) | more than 4 years ago | (#27673907)

'Agile' is a class of software methodologies. A popular Agile methodology is called Scrum. An excellent resource on how to conduct a Scrum shop is 'Agile Project Management with Scrum,' by Ken Schwaber. A good place to get started is [] .

Re:Agile Software Development and Planning (2, Informative)

TheSpinningBrain (998202) | more than 4 years ago | (#27673937)

There's also 'Agile Software Development with Scrum,' same author. There are people who consider it to be the Scrum bible.

Re:Agile Software Development and Planning (1)

jeroen8 (1463273) | more than 4 years ago | (#27674023)

I have good experience with Scrumworks [] for planning the development work using Scrum, Trac [] for PR/CR management and Subversion [] for source control.

ITIL (4, Insightful)

NeutronCowboy (896098) | more than 4 years ago | (#27673419)

Start there. There's a ton of stuff online. If you can get your work to spring for certification, great. If it doesn't, no worries. Project Management is easy. Just keep in mind a few things:
- You need a project schedule with milestones. Live by it. Make others live by it.
- Understand GANTT charts. Don't necessarily use them, but the principles behind are solid.
- Google is your friend. The wikipedia article is actually a good start.
- Above all, understand that this is a team effort. You won't succeed without others. Time to start honing those social skills.

Re:ITIL (3, Informative)

mc1138 (718275) | more than 4 years ago | (#27673455)

ITIL is great and all, but might be a bit monolithic for a first time project manager, especially working solo. Your other recommendations are right on track though.

Re:ITIL (1, Funny)

Anonymous Coward | more than 4 years ago | (#27673517)

There's no I in TEAM but there is a ME!

Re:ITIL (2, Funny)

Anonymous Coward | more than 4 years ago | (#27673821)

and there's no u in "winning team"

Re:ITIL (1, Funny)

Anonymous Coward | more than 4 years ago | (#27674249)

and there's no u in "winning team"

No, but there is "me".

Re:ITIL (3, Insightful)

Anonymous Coward | more than 4 years ago | (#27673539)

Be careful with ITIL as it can massively overcomplicate things for people trying to do the bare minimum that works. We used ITIL based software at our company for release and service management and talk about overhead.

My recommendation is to do a lot of reading to familiarize yourself with the topics.
    - Start with a basic analysis and design book (which will walk through requirements). From there you'll get ideas of other books you need to read.
    - Many of your questions are asking about how to be a development lead. Read "Ship It" by Richardson and Gwaltney. That is the best software book I've ever read

Re:ITIL (2, Interesting)

NeutronCowboy (896098) | more than 4 years ago | (#27673881)

Spot on. ITIL is not for the faint of heart, and should be applied appropriately. That said, it provides a ton of useful information about how things should be done. Compare that with what you need, use what makes sense, and move on.

And yes, it sounds more like he's moving on from being a code monkey to actually being responsible for the development lifecycle of a piece of software, so development lead stuff is a good place to start.

Re:ITIL (1)

Maxo-Texas (864189) | more than 4 years ago | (#27674497)

I want to highlight the team effort aspect.

The major failures that I see in projects by new project managers often turn on not asking for availability by secondary and tertiary teams such as testing, documentation, and installation teams.


I like RUP methodology a lot. It uses agile concepts and has a high focus on identifying "risks" early.

This is a wonderful concept that has helped me many times. Break the project into pieces that are easy to crank out and those which are unproven ("risks"). Resolve all unproven aspects of the project before beginning the easy parts of the project.

Are you depending on MySQL working under Windows Happy Clown edition? Then make sure of that early.
Do you need to code a bunch of transaction classes and services for data? Do that later.

Starting the easy parts (so you can show progress) results in $100 million dollar canceled projects.

Agile/Rup/etc. type management (vs Waterfall) assumes you can't capture 100% of the requirements in advance so you have frequent iterations.

It's also true that debugging big O time is exponential. The sooner you let the testing team start testing, the more effective their testing will be. Bugs will be found sooner and be easier to fix.

If you want a recipe for missing your deadlines, do a lot of coding up front- never show the users until it is 99% complete- and give it to testers when all unit testing is finished and the project is 100% done.

Good Luck!

Re:ITIL (4, Informative)

Tiger4 (840741) | more than 4 years ago | (#27674675)

In addition, be be careful with your requirements, specifications, and testing.

Your users and customers (two related but often slightly different groups) are supposed to come up with the requirements, but often they are clueless on what they need. So you will often need to help them with suggested feasible solutions. However, the ultimate decision on what is REQUIRED is theirs. Just be sure to help them with the difference between required vs nice to have vs "you have got to be dreaming". The budget and time estimate is based on the requirement.

ONCE THE REQUIREMENTS ARE LOCKED DOWN you do not accept changes to them. Any changes go into a NEW requirement that will be harmonized with the old one at a later date. Think of it like a train leaving the station. No new passengers get on, none of the old ones jump off, except under controlled conditions. If the users want to change the requirement, tell them to get on the next train. As the PM, you decide when the new stuff can be included into the old AND HOW MUCH IT WILL COST TO DO IT. Never let them think it will be "free".

Getting a good estimate from the written requirement is tough. Trying to determine Function Points and lines of code and complexity and speed of development is a serious art form. Get good people and go over it a lot, from different angles. If you are lucky, this project is similar enough to past projects that you won't plant the seeds of destruction at this stage. You need to be sure you can really live with the cost and time estimate you give them. DO NOT ASSUME BEST CASE just because it look "easy". Too many people do. DON'T JUST DOUBLE EVERYTHING unknown. that is just wasteful. If you have serious unknowns, do some risk reduction explorations to be sure you do know what you are talking about (or at least plan to do them so you will know when the time comes).

The best specifications are testable. And the Tests should be written at about the time the specs are written. A Requirement might say "full color display". A Specification might say, "display in at least six colors, including white, black, red, green, blue, cyan, magenta, and yellow". Guess what the acceptance test is going to look for? It should be as Unambiguous as possible. This is where team work is good. Don't let the designer write the specs and the tests. Too much chance for hidden assumptions to creep in.

Which reminds me, be sure to explicitly lay out the overall software design, all the modules, all the interfaces, and subject them all to thorough rigorous Reviews. Too many otherwise good projects die from unstated assumptions that lurk under the surface. The coders are so anxious to get started they forget to examine where they are and where they are going vs the tools and skills available. They never see the iceberg until too late.

Please do your best not to become another "out of control software project".

Re:ITIL (1)

odoketa (1040340) | more than 4 years ago | (#27676273)

It can't be emphasized often enough that once you have a plan, you need to stick to it, and therefore you need to have a very good plan.

Of course, you never -actually- stick to the plan, but emphasizing that every change means delays of X helps to stem the tide of changes people come up with.

Re:ITIL (1)

NeoSkandranon (515696) | more than 4 years ago | (#27676315)

"ONCE THE REQUIREMENTS ARE LOCKED DOWN you do not accept changes to them"

You forgot: Until Sales pitches a fit and leans on your regional manager, who will lean on you to "work it out" with your team, because this is a very important customer who you can't afford to offend in any way.

Re:ITIL (2, Insightful)

gosand (234100) | more than 4 years ago | (#27677213)

"ONCE THE REQUIREMENTS ARE LOCKED DOWN you do not accept changes to them. "

Unless, of course, you are using an iterative or agile methodology.

I am not sure the original poster is asking about project management... It sounded to me more like "development project management". Because full-blown project management involves everything for a project - initial stages, getting the line of business engaged, development, testing, user acceptance, implementation, support, overall budget, training, etc etc etc. It's a much bigger animal that managing just the development piece.

Granted, you can use many of the principles... like creating a plan, tracking to the plan, re-planning when necessary, tracking to milestones, status reporting, tollgates, communication planning, etc.

And I have a general rule - when in doubt, draw a picture.

PSP (3, Insightful)

Walterk (124748) | more than 4 years ago | (#27673433)

Something that may be of interest to you is the Personal Software Process, see []

Re:PSP (1)

Walterk (124748) | more than 4 years ago | (#27673461)

In very bad style, replying to my own post, but the PSP ties in nicely with the Team Software Process (TSP).

You will probably see many people here advocating agile, but you can use many of the things in both PSP and TSP in Agile. Just as long as you remember that having no process is worse than having a bad one. At least when you have a bad process, you can impove it.

That useless piece of s*** (2, Insightful)

wiredog (43288) | more than 4 years ago | (#27673797)

It is useful for getting in the way of getting work done. Or if what you're doing is something you've done before, in exactly the same way. In which case, why don't you just use what you've already done?

God help you if some PM makes you use it when you're wringing out a new API on a new platform.

PMI (3, Informative)

rodrigoandrade (713371) | more than 4 years ago | (#27673477)

I suggest using the PMI methodology, as it is the industry standard, it'll add a lot of credibility to your resume, and make life much easier for those who follow your work (co-workers, or the guy replacing you once you brush up that resume with a PMI cert).

Now go research about it, as a good PM needs to be able to do the legwork, too, not just shout orders around.

Re:PMI (1)

mysidia (191772) | more than 4 years ago | (#27673735)

So do you have any suggestions about what books or sources to look at for information about PMI methodology?

Posting a question on slashdot is a form of research; after all, it takes some effort to send someone a question in an article-suitable fashion, and actually get it posted.

Re:PMI (0)

Anonymous Coward | more than 4 years ago | (#27673793)

Posting a story on /. is researching?? REALLY???!!!!

You can get any story on /.'s front page, provided you use the right buzzwords.

Re:PMI (2, Informative)

Maxo-Texas (864189) | more than 4 years ago | (#27674513)

Shameless plug (0)

Anonymous Coward | more than 4 years ago | (#27673485)

Might be slight overkill if you're just working on this alone, but if you need to communicate/collaborate with others, you might take a gander at the product I work on:

A few pointers (1)

nyvalbanat (1393403) | more than 4 years ago | (#27673489)

My general approach so far has been:
- Write a design document pretending that someone else of your skill level is supposed to implement the solution based on that document. It helps reveal holes in your design, or at least strengthens your confidence.
- Figure out the toughest/trickiest parts and prototype them first. That way you reduce the amount of last-minute surprises and can make a better estimate.
- UML or pseudo-UML can definitely help. Get a whiteboard and keep it updated. It helps you keep the big picture when you're deep in low-level code.

Test driven development (2, Insightful)

tjwhaynes (114792) | more than 4 years ago | (#27674145)

When it comes to writing a good design document, use whatever you feel most comfortable. Yes - UML is a highly expressive way of describing the life cycle of a system but if it isn't familiar to you, you'll be better off with a list of things that it is supposed to do. Ideally, the design document should be readable by every one who has some requirement from the design. This does sometimes mean that you need to split your design into externals (what the customer sees) and internals.

One technique that I have found to be particularly effective is "test-driven development". That's another buzz-wordy phrase for your resume. However, this one carries significant benefits.

If at the time you write your design you also write a ready-to-run test suite to test your design, you will write a better, more complete design because you will have been forced to think about the scenarios your design must cope with. Further more, you also have a great way to assess your progress as the design is implemented. If you were thorough in writing your test suite, then you can gauge the functional completeness of your project by simply seeing how many of your tests are running successfully.

Oddly enough, this approach leads to faster development cycles because you always have a clear picture of what is working, what needs to be implemented still and what is not behaving as expected. It is also pretty motivating to write a couple of hundred lines of code and to be able to quickly run some tests to validate its function and see another two tests click through successfully.

Toby Haynes

Re:Test driven development (2, Interesting)

TheRaven64 (641858) | more than 4 years ago | (#27677033)

I also like test-driven development. It seems difficult, but the code I've produced using it has generally been better (and, in the end, taken less time) than code I've produced with other techniques. That said, I wonder if anyone has tried combining test-driven development and literate programming. By first writing the documentation, then the tests, then the code, I imagine you would have very few surprises and a polished end product.

Only as much as you need (5, Interesting)

Jawn98685 (687784) | more than 4 years ago | (#27673515)

My advice is to adopt only the project management tools and methods that you need to get the job done effectively. It is all too easy to become mired in learning a complex discipline (project management) when all you really need is a well thought out flow chart and a good ER diagram. In other words, do not spend your valuable time trying to learn MS Project or any of the several readily available alternatives. They are tools for someone well-schooled in the techniques in managing complex projects. Your flow chart could easily expand into groups of related tasks, one grouping for each element in the chart. To manage that, a simple task list manager will do.

Re:Only as much as you need (4, Insightful)

D3 (31029) | more than 4 years ago | (#27673775)

This is what PMI says to do, cherry pick what you need out of the vast standardized body of knowledge (PMBOK in PMI terms). However, if you don't have a good grip on the BOK, how do you know what to cherry pick and what to ignore? I'm not saying you need complete mastery of the PMBOK, but a course in the groundings of it helps immensely. I'm working on my SANS GIAC certification in PM and would be lost just picking up the PMBOK without the background of the class. The work project I'm doing right now is small and so some things like Budget Management and HR Management don't apply, but that might not be the case for the submitter.

Re:Only as much as you need (1)

rtb61 (674572) | more than 4 years ago | (#27674361)

From a experienced project management viewpoint, anyone who is asking these questions prior to starting a complex project where it has been stipulated that they have to provide 'better' estimates for completing features, is in real trouble. Attempting to learn project management whilst winging it in on a hope and a prayer on a current project is not the most sensible thing to do.

My advice would be to admit the limits of of experience to management, hire in a reputable consultant and pay attention to what they do for the next project, either that or start looking for another job now. It is not to bad learning to apply project management techniques on small simple jobs but you really don't want to be learning whilst attempting large complex jobs. Small jobs with large stuff ups, still don't hurt that much but, major jobs even with small stuffs ups can be hugely expensive. Good project management is all about experience and learning from your mistakes and being quick enough to correct them before they get out of control.

Re:Only as much as you need (5, Informative)

myvirtualid (851756) | more than 4 years ago | (#27673871)

Mod parent up. With all due respect to other posters, sending the submitter to ITIL is overkill. Talk about drinking from the firehose.

I use to run a number of development teams in a systems integration and custom development shop: We took our employer's base products and toolkits and integrated them into customer environments. We did a lot of "1.0's" - typical projects were 2 to 6 weeks in length and if we ever saw them again, we lost money. We could afford one or two moderate bugs (sev 3 - functionality impaired); more than that, we lost money. We could not afford major bugs (sev 1 - all is borked; sev 2 - most is borked). And given the tight timelines, we had to be very sure that what we were developing was what the customer asked for and what the customer asked for was what the customer wanted.

We almost always made money and our customers were almost always very satisfied. We very rarely lost money, and it was usually on strategic projects (spend integration money to make more license money).

Here's what we did:

  1. Write a high level design document describing the major components and data flows. A mix of diagrams and text. Nothing too technical, because the customer has to understand it. But it has to be enough for a senior dev to either start coding (2 week project) or write an internal-use mid-level design doc (6 week project).
  2. Developer, tester, and writer estimate how long to do their bits based on high-level design. Project management adds some buffer (10% to 50% based on complexity).
  3. Customer reviews design, expected ship date, signs off. (Because the design has to be fit for the customer, no UML diagrams or fancy methodologies that the customer doesn't understand. These things have their place, to be sure. But if you cannot describe it in pictures and words, it may be too complicated for you and your organization's current level of development methodology.)
  4. Based on the high-level design document, start three simultaneous streams:
    1. Development: Either start coding or write that mid-level design document.
    2. Test: Write the test plan. Not the test cases. Start with the acceptance test plan. Have this signed off by the customer.
    3. Documentation: Start putting together the major structure of the documentation. (ToC, section headings, text where necessary, etc.).
  5. Checkpoint: The developer, tester, and writer meet to ensure that they agree that what they are each working on aligns with the others and with the high-level design. This can be a 30 minute meeting or a three hour meeting, depending on scope, etc. Most important things:
    1. Do we align with the design?
    2. Will we ship on time?
  6. Add detail. The developer codes, the tester writes test cases or test scripts, the writer writes documentation.
  7. Checkpoint: The developer, tester, and writer meet to ensure alignment.
    1. Do we align with the design?
    2. Will we ship on time?
  8. Repeat "add detail" and "checkpoint" steps as necessary. Stop adding detailing when done (e.g., often the writer will finish first, then the tester, then the dev - and it's nice when it goes this way, because the tester can review the docs and make sure test plans and docs really align).
  9. Test.
  10. Ship.
  11. Profit.

Handling exceptions. If at any point things start to drift out of alignment, stop. Figure it out. If the problem was the high-level design, go back to the customer. Otherwise, it's an internal issue you have to identify and correct.

VIP: Acceptance test plan. Having the acceptance test plan signed off by the customer is crucial. If they sign it off and everyone codes to it and it aligns with the high-level design and the deliverable passes acceptance, then you are done.

One thing I've left out: Change requests. They are the bane of every project under development. You need to dig in your heels and manage them properly. Work collaboratively with the customer and developer to determine whether the change request:

  • Can be integrated at no/little cost.
  • Can be integrated at the cost of more time, money, and shipping delay.
  • Should be punted to a 2.0 or another project.

Always assume the latter and try to involve your developers as little as possible, they are busy developing. Interruptions delay shipping.

IMHO you cannot make do with less than the above. If your management does not accept the need for this level of process, I strongly recommend seeking a change of management or employment. If you do not have this minimal process - and it really is minimal - then in all likelihood, your project will go way over budget, you will never ship, and the customer - whoever they are - will never come back for more. This isn't a slight, this is the reality of most software projects: Over budget and shelved, with 0% satisfaction.

Process, properly managed, is your friend.

Process, out of control, is your second worst nightmare.

No process at all will results in flashbacks, nightmares and a need for therapy for years to come.

More or less. AFAIK. YMMV.

Re:Only as much as you need (1)

EricWright (16803) | more than 4 years ago | (#27675929)

This is one of the first posts I've ever wanted to mod to +6.

In my experience, the parent is spot on, even for "internal" projects where IT is building business applications for another department.

Re:Only as much as you need (1)

Beezlebub33 (1220368) | more than 4 years ago | (#27676125)

Customer reviews design, expected ship date, signs off. (Because the design has to be fit for the customer, no UML diagrams or fancy methodologies that the customer doesn't understand. These things have their place, to be sure. But if you cannot describe it in pictures and words, it may be too complicated for you and your organization's current level of development methodology.)

Pretty good post, but my quibbles would be:

o Use Case diagrams are UML. The convey, quickly and clearly, who can do things with the system and what they can do. And it's really important that if you are unable to do something, you have a Use Case that shows a person doing something with a 'You Can't Do This!' on it (or, preferably, "you will be able to do this in version 2.0"). It's largely about 'managing expections' by the customer.

o Design must mean something different to you than it does to me, and I think maybe you meant architecture. The customer won't understand the high-level design. They will be able to understand the architecture, especially how the architecture will be able to allow the Use Cases to happen, which is the important thing.

Re:Only as much as you need (3, Insightful)

digsbo (1292334) | more than 4 years ago | (#27674201)

Jawn is right, but remember that You Will Fail. Accept that. Experienced project managers fail most of the time. When I say fail, I mean you will be late and over budget. "Managing" expectations is what the learning experience is about your first time around. Good luck.

Re:Only as much as you need (1, Insightful)

Anonymous Coward | more than 4 years ago | (#27674673)

Have to quibble with this just a little bit.

Experienced project managers will "fail" from time to time, but if anyone is failing "most of the time" then they are not doing a very good job. It's okay to fail - as long as you learn from your mistakes.

Now, I'm not saying a project will always come in at the same cost, schedule and scope as the original charter. But a good project manager deals with changes and communicates these back to the stakeholders. It's not a failure to be over the original budget and 3 weeks late if there was a requirements change that was accepted by the project stakeholder, so long as the impact was clearly communicated and everyone signs off on it.

Re:Only as much as you need (1)

IcyHando'Death (239387) | more than 4 years ago | (#27674285)

I agree with the parent. In your case, while you are taking on a bigger project, you are not being called upon to manage multiple resources, multiple dependencies etc. That's a large part of what project management is. It sounds like you're more after something that can act as a guide to software development. A nice, short, practical book is "UML Distilled" by Martin Fowler. While it is geared towards teaching the application of UML, it does so by describing it's various diagrams in context and showing how to use them yourself.

The book starts out with a description of the software development process advocated by Fowler, which is an iterative approach. My favorite nugget is in a section headed "When to Use Iterative Development" which begins, "You should use iterative development only on projects that you want to succeed." :)

There's a breakdown of the project phases and the book deals with requirements, risk management, planning and lots of other issues, and at the end there's a nice simple example.

If you already feel like your project is in a bit of trouble, time may be of the essence. At just 166 pages, "UML Distilled" is a quick read and takes a very pragmatic approach that should get you going in the right direction quickly.

Re:Only as much as you need (2, Insightful)

sjanich (431789) | more than 4 years ago | (#27676237)

Right. Being a good project manager is NOT about being good at MS Project and other PM tools. Being a good PM is about being a good communicator and a good organizer (including for contingencies). Being a good PM is about getting people to do what you want and need without having direct authority over them. Bing a PM means having responsibility but only some authority.

Re:Only as much as you need (1)

realsablewing (742065) | more than 4 years ago | (#27677201)

Agree with the parent, as a technical person it's very easy to get caught up in finding 'the perfect tool' that will do all of those nasty management tasks for us.

The reality is that management consists of working with the people on the team, coordinating tasks, finding out about problems in time to solve them, work around them or get relief in schedule or budget in performing the problem tasks. A lot of communication, a lot of time with people not necessarily as much time with the technical work as you might prefer.

I currently work with someone who likes managing people, in a positive way, is interested in finding problems and fixing them before the release date and in getting schedule or cost relief before the customer gets ticked. He does this using two things, 1) an spreadsheet for documenting the tasks and tracking how much people work and 2) a lot of communication with the team. For keeping projects running smoothly he was laid off from his last job because his work was obviously 'too simple' since there weren't any crisis to take care of all the time.

If you aren't interested in the people part of the management find someone to buddy up with who does like that part, it is a huge help and keeps the stress level down a bit.

Consider the Library (0)

Anonymous Coward | more than 4 years ago | (#27673525)

May I suggest your public library? More libraries have taken to stocking books for professional development as a way to increase readership.

Back to basics (1)

JamesP (688957) | more than 4 years ago | (#27673551)

1 - Start with PM basis: the book "Head First PMP" seems like a good start (and yes I read it)

2 - Go learn about Scrum/XP/etc that's what (I and a lot of people) to be the realistic approach for sw pm today, stay away from RUP/Waterfall, etc

Otherwise, a book I found nice is "Software project Survival Guide" [] even though it's a bit on the side of waterfall.

You could go directly to Scrum/XP but it's nice to learn about 'classic PM' first, it helps with vocabulary and the general idea.

Re:Back to basics (1)

Walterk (124748) | more than 4 years ago | (#27673647)

Go learn about Scrum/XP/etc that's what (I and a lot of people) to be the realistic approach for sw pm today, stay away from RUP/Waterfall

I would have to disagree with you there. While Scrum and XP are very much on the rise due to the whole "agile" buzzwordyness, RUP and Waterfall are still very much used today by a majority of companies. Neither of those are actually bad processes, it's usually how they're implemented or managed. A bad implementation of Scrum can kick you in the nuts just as much as a bad implementation of Waterfall.

It's all about how you manage your process and improve it to cut out the bits you don't need. This is the case for all development processes. Take Kanban* as example, where Agile can be used on a Waterfall process. Continual improvement.

*: []

Re:Back to basics (1)

heck (609097) | more than 4 years ago | (#27673997)

learn about Scrum/XP/etc that's what (I and a lot of people) to be the realistic approach for sw pm today, stay away from RUP/Waterfall, etc

That's like saying "Go learn Java (or C# or Ruby or...) only because that's what I and a lot of people say is the realistic approach." THEY'RE ALL TOOLS FOR THE ARSENAL, AND YOU SHOULD BE FAMILIAR WITH ALL OF THEM.

Just as what language you use is a choice depending on the skills of the team, the hardware at the company, and the project at hand; the project management style depends on the team, the company, the requirements, etc. Based on my 20 years of experience, WHAT PM approach you do doesn't matter as much as a good team. I do insist that you have SOME sort of plan/process/framework for requirements management, task analysis, timelines, etc... But I will state that what matters is the team. Once you have the right people, apply the project management framework that works for the team and for the project. And adapt it as needed as things evolve.

As many have said, go to PMI. Take what they say with a grain of salt. (Even though I am a coder, I've taken several of their courses and always gotten value out of them, which is more than I can say of many courses) Because we on slashdot do bring joel spolsky up frequently, I will say Joel has some though provoking posts about project management among many other things ( Not saying I always agree with him - take what he says with a grain of salt...

god fucking dammit (0)

Anonymous Coward | more than 4 years ago | (#27673563)

Software development is turning into a branch of sociology rather than an application of computer science. All these bloody "methodologies". No wonder software gets ever more complex and slow, and there's little in the way of innovation - it's all just implementing old theory.

And now for the selfless answer you won't like: the economy is fairly shit today. There are many highly skilled individuals who would have more experience doing what you're trying to do, but who are out of a job. The best way forward for the company is to offer them your job in return for a proportion of their first year's salary. You work together for a month or two, teaching him about the firm.

I'm not looking, but I'm sure other /. readers are.

PMI and ITIL (2, Insightful)

ErichTheRed (39327) | more than 4 years ago | (#27673585)

I'd recommend starting out with the PMI body of knowledge...start here: PMI [] . ITIL is a very good framework for designing an ideal operational environment, but it's huge and very bureaucracy-centric if you're not careful. The ITIL content is not free, but you can take training courses or buy it yourself.

All that said, don't underestimate what you're getting into. Project management is not IT work. The job you do as a PM is totally different from anything you're going to do in your IT job. For one, you can't do any of the work yourself. A PM's job (in my estimation) seems to be begging and pleading workers and their managers to get things done on time.

Also, project management, like people management is a skill. You can either do it or you can't. I've seen IT guys promoted to project managers who fail horribly at it. Remember that you're not the "doer" anymore, all you do is keep records, hold meetings and yell at people who miss their dates. On the flip side, a truly good PM with IT skills is a godsend. Being able to understand that an IT project is NOT a construction project is a key skill. Traditional PMs will tell you that a project is a project. However, you know EXACTLY how long it takes a carpentry crew to frame a house, a plumber to lay pipe, and a drywall crew to put up walls. You sometimes have no idea how long it will take to find $obscure_bug[n]. Construction projects have at least a chance of coming in on time, and IT projects really don't unless they're totally simplistic. Keep that in mind and you'll do well!

Critical Chain Project Management (0)

Anonymous Coward | more than 4 years ago | (#27673615)

I've seen good results when applied (and bad results when applied poorly, but that goes for any methodology).

Not enough information (3, Insightful)

MikeRT (947531) | more than 4 years ago | (#27673639)

You didn't state whether or not you were on a team or not, but if you aren't, then just document the hell out of everything.

If you are become a project manager over a team, here are some helpful hints that someone should have told a boss I know at a different site from mine:

1) Learn the difference between delegation and dereliction.

2) Defend your team against outsiders unless your team is behaving indefensibly.

3) Your biggest job is to remove hurdles from your team's path. These may be helping them on technical decisions, but more commonly will be you marching into someone's office demanding their cooperation with your team when your subordinates cannot get any information or cooperation from them.

4) Don't take on more work than your team can handle unless you are willing to double up on helping them AND your management role.

Re:Not enough information (1)

cowscows (103644) | more than 4 years ago | (#27673753)

#4 leads to a pretty key point. An issue that I've seen on some bigger projects is when the project manager has a hard time accepting the fact that their job isn't as much to "do the work" as it is to manage the people who are doing the work. There's something to be said for leading by example, staying involved, and not losing touch with the grunt work, but it's important to realize that on a project that's continually progressing, project management is a full-time job.

If the project manager is putting 20 hours of their work-week into grunt work, it might feel to them that they're making their best contribution to the team, but that's not necessarily the case. That time might have been better spent helping the other members of the project team get their work done more efficiently, or making sure that the proper communication takes place to avoid mistakes, or keeping outside forces at bay.

Sometimes you just want to sit at your desk, put headphones on, tune out the world, and just do some work. But that's a luxury that project managers often don't have, and it's one that's sometimes hard to give up.

Sorry (0)

Anonymous Coward | more than 4 years ago | (#27673685)

I thought this was my weekly team meeting.

Project Management (1, Informative)

Anonymous Coward | more than 4 years ago | (#27673687)

You're going to get a lot of answers here pointing to specific methodologies like Agile, but for someone just starting out I think it helps to understand what project management is and isn't.

The Project Management Institute (the ones that run the PMP certification program - is sort of the world repository of project management theory. They publish "A Guide to the Project Management Body of Knowledge" or PMBOK. Most practicing PMPs take everything in the PMBOK with a grain of salt, because it is an ideal vs. what happens in reality, but I think their definition of Project Management is a good one:

"Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements."

There are some good nuggets in there that I think can help a new project manager.

First is to understand that the whole point of a project is to meet some set of requirements. So you probably better know what those are before you start, and more importantly, you should know how to measure whether you've met them or not.

Next is to realize that you are managing project activities, or tasks. You need to have some idea of what things need to be done in order to meet a requirement, what resources (people/skills, money, time, etc.) are needed, and some idea of how long it's going to take.

Lastly, project management involves applying tools (like scheduling software, or gap analysis templates), techniques (like change control) and skills (like leadership) to tie it all together.

It doesn't particularly matter what your process is (agile, six sigma, etc.), but it is very important that you have one. Every professional PM I know adapts their corporate methodology to fit their style and the nature of the particular project. That's part of the "skills" in the PMI definition.

Project Management can really make your life easier and doesn't have to be an overly onerous process.

Good luck!

just say no (1, Funny)

pr100 (653298) | more than 4 years ago | (#27673699)

Project management is a way for middle management who know nothing about programming to make themselves feel useful and screw up your programming project....

Re:just say no (3, Insightful)

thoughtspace (1444717) | more than 4 years ago | (#27674245)

Your statement is an example why we have Project (and other) Managers. The 'programming project' is only part of the objectives of the business. As you have a hostile view towards management, it would be correct for the Project Manager (and Software Manager) to isolate you from the upper management so you can work how you like with your view. There is nothing wrong with your view. A Project Manager would just have a tougher job ensuring everything gets done and getting status from you as you would feel they are interfering and incompetent. As a Project Manager, you just accommodate the different personalities. The trick is to get everything required out of the team without them knowing I am doing it.

Re:just say no (1)

pr100 (653298) | more than 4 years ago | (#27674391)

I don't have a hostile attitude to management - I've been a manager of teams of programmers.

I have a sceptical attitude to a lot of the guff that comes under the umbrella of Project Management these days - especially as it's applied to programming.

Everything needs managing in some sense (although for small software projects often this management is best done by the people doing the programming too). But that doesn't mean that a gannt chart helps you in the slightest.

Re:just say no (0)

Anonymous Coward | more than 4 years ago | (#27674695)

Says the unemployed "PHP" web developer.

Don't do it!! (1)

Wyllyam73 (1303287) | more than 4 years ago | (#27673783)

Don't fall into that trap.. I did. Here is what I learned: 1) There is no complete answer to how to document a project. anyone that tells you otherwise probably doesn't code or support someone else's work. 2) Learning project management takes time and experience. A book won't help.. I have several and all are equally useless. 3) Project management doesn't sound like what you are looking for (like the other person above said, PM is for Middle Management). what you need to do is look at it from the outside. if you had to come in to support someone else's website/database, what would you need to be able to support it successfully? inputs, outputs, timings, schedule jobs, maintenance jobs, etc. Document what those are and how they run. Then create some basic flows to describe how the system integrates together. Being the only IT developer will make the documentation more difficult and you aren't going to get it right the first time (or first dozen times). Just be ready to add or remove information from your documentation as you go. Also, every time you have to research something, create a document that defines what the problem was and how you fixed it.. you or someone that follows you may need it to resolve future problems. And don't trust what I tell you to be true or final. You will find a better way as you go through it.

Talk to someone in person (2, Insightful)

daffmeister (602502) | more than 4 years ago | (#27673791)

This is a big topic, and there are lots of different "right" answers. The best one for you depends a lot on you, your project, your workplace, and your future team.

Try to find someone that you can talk to face-to-face for 30 minutes over a coffee or beer. You'll learn a lot more from their experience in that time than any amount of reading and you'll then have a better idea of which way to direct your energies and further research.

Ideally someone with a similar project to yours, but really, anyone with a bit of experience (the more the better, as they would have seen more methodologies) can help.

Bare Bones Project Managment (2, Interesting)

jeffshoaf (611794) | more than 4 years ago | (#27673831)

It sounds like you're primarily looking for advice on managing your application design and development, which isn't quite the same as traditional "project managament" - you're looking for help with part of the application lifecycle. But, just in case I'm mistaken and you are looking for help with project management, I recommend Bob Lewis's "Bare Bones Project Management" (Details here). []

It's pretty cheap ($8.95 + S&H) and bypasses a lot of the fluff that's not needed for anything except huge projects.

Use crowdsourcing! (1)

140Mandak262Jamuna (970587) | more than 4 years ago | (#27673833)

Post all the details of your project requirements, benchmarks, test cases, unit test modules and everything in Slashdot and ask for advice. You see, most slashdotters are jobless fellows who salivate at the idea of working their tails off to solve other peoples' problems. When you reap all the benefit of the contributions and laugh all the way to the bank, make sure your minions do not waste their time reading slashdot. Great Idea, Fellah.

All my management skills I learned (2, Funny)

wiredog (43288) | more than 4 years ago | (#27673837)

in Army Basic Training.

Which is why I'm not in management...

Re:All my management skills I learned (2, Funny)

Lumpy (12016) | more than 4 years ago | (#27674419)

Because you cant lob a grenade in the direction of the problem to make it go away.

Corporate America frowns on that.

Re:All my management skills I learned (2, Funny)

geminidomino (614729) | more than 4 years ago | (#27675479)

Because you cant lob a grenade in the direction of the problem to make it go away.

Corporate America frowns on that.


Use trac for guiding you (1)

chthon (580889) | more than 4 years ago | (#27673879)

The project roadmap feature of trac is nice to help you set up your project.

First define the partitioning of your project as trac components, so that it is easier to assign tasks, features, bug tracking, etc. Then define your roadmap. Enter features on components as different tickets and assign them accordingly to your roadmap. Maybe you know other systems, but having a good central database for assigning and completing tasks and being able to track progress with it is invaluable. trac is really good and with relatively low overhead compared with other systems to start with.

PMP Credential (0)

Anonymous Coward | more than 4 years ago | (#27673931)

Project Management is a profession in itself. Contrary to what many have stated here, it is not easy and that is because it encompasses far more than just schedules and budget. If you have a local chapter of PMI near you I recommend you join and pursue a PMP credential. Not only has it made my life easier, it has increased the success rate of my projects by a factor of three.

Rules of Thumb (3, Interesting)

mseeger (40923) | more than 4 years ago | (#27673953)

Some rules of thumb:
  • If someone gives you a time estimate: multiply with two, add one and go to the next bigger unit. E.g. if another developers says he needs one hour, take 3 days. Proceed similar with costs others tell you (unless you have a binding offer).
  • If you give someone else a task: Ask him/her about the current status, tell him what to do, let him repeat it, repeat last two steps until bot descriptions match, repeat all steps the next day.
  • Try to keep meetings smalls, the effectiveness of meetings is inversely proportional to the number of participants. Typical error of beginners is trying to get everyone at one table and to clarify everything there. Usually that burns a lot of time and achieves nothing.
  • Plan for tests, fixing and documentation... Costs typically the same or more time and money as all code development.
  • Be aware of Murphys Law... You can't plan for it, but you can grant it some room in your plans.

Re:Rules of Thumb (1)

analogkid76 (1224880) | more than 4 years ago | (#27675513)

"If someone gives you a time estimate: multiply with two, add one and go to the next bigger unit. E.g. if another developers says he needs one hour, take 3 days. Proceed similar with costs others tell you (unless you have a binding offer)."


When I tell my manager that something will take approximately 2 weeks, he's NOT going to schedule 5 months. What good is an estimate at all if you're going to give yourself a +/- 1000% margin?

Where I work, we are asked at a minimum to provide a Class D estimate, which is a ballpark estimate, -25% to +75%.

My management, in particular, expects that I will have at least a vague clue about how much work is involved in a given activity, and having done similar work before would at least be able to hit it somewhere in the ballpark.

I like to use PERT estimates, or something similar:
estimate = (optimistic + (4 * likely) + pessimistic) / 6
So my 2 weeks (likely) becomes: (1wks + (4 * 2wks) + 6wks) / 6 = 2.5 weeks


The Cathedral and the Bazaar (1)

Ron_Fitzgerald (1101005) | more than 4 years ago | (#27673967)

The Cathedral and the Bazaar by Eric S. Raymond []
This may be an odd choice for some but I found it a great read for team leaders and project coordinators.

Eric tends to compare himself and his achievements of fetchmail to that of Linus Torvalds and Linux which I personally found distracting topic.

Re:The Cathedral and the Bazaar (1)

u38cg (607297) | more than 4 years ago | (#27674335)

You obviously haven't found the bit where he talks about chanelling Pan in bed, then. *That* put me off my food for a number of days.

Basecamp... (2, Interesting)

TofuMatt (1105351) | more than 4 years ago | (#27673987)

Basecamp has been the only thing ever that made me not hate doing PM. []

Triple constraint (3, Insightful)

93,000 (150453) | more than 4 years ago | (#27673999)

Understand the triple constraint, and more importantly, make sure those above you understand it as well. Much like the old adage 'you can have it cheap, fast, or good. pick any two.' Cost, time, and scope. A change to any one affects the others.

- Due date got moved up? Project just got more expensive or lost a feature or two.
- Scope increased? It's going to take longer or cost more.
- funding decreased? Lose features or increase project duration.

Leave it to the sponsor to determine how to deal, but be certain that they understand how things affect one another.

Practical Project Management by Michael Dobson is a good intro*. It's clear and uses good examples, without digging too much into the PMBOKish stuff that can be overwhelming when starting out.

*disclaimer -- I didn't read it all (dove into the PMBOK to prep for the test), but very much liked what I read. Plan to go back to it someday.

Process and execution (2, Insightful)

torington (1191747) | more than 4 years ago | (#27674027)

You could go anywhere on this topic. I had a similar experience a couple years ago when I took up some leadership roles. I suppose one big thing for me was to recognize a distinction between process & technique. As you probably know, practically every software project is guided by fundamental process milestones: requirements, design, development, testing, documentation, release. You shouldn't deviate from this, but its up to you how you execute/implement this process ("technique"). That said, random thoughts:
1. Are you guys using SVN, CVS, VSS, PVCS, etc?
2. Get the requirements on paper. It'll save your *ss if something wasn't built to expectation. (This is more important if you work directly with clients.)
3. I agree with above posts: Your goal is to let the developers do their thing. And, perhaps even at this early stage, you probably need them more than they need you.
4. One hard thing is to say no to your peers/superiors if they infringe your team's priorities or "rights".
5. Most people don't like regular meetings, but I like status meetings (called with proper frequency) to keep everyone in tune and on schedule. Remember to show them the timelines, and repeat the priorities so that they understand the big picture.
6. Agile, Waterfall, RUP are formal processes. Google/Wiki it. Scrums are regular stand-up meetings.


Metastasizing?! (4, Funny)

MaerD (954222) | more than 4 years ago | (#27674119)

At my current workplace, I'm tasked with creating a rather complicated and metastasizing web-database application.

I don't think that word means what you think it means, unless the "web-database application" moves to new hosts on it's own..

a. the transference of disease-producing organisms or of malignant or cancerous cells to other parts of the body by way of the blood or lymphatic vessels or membranous surface.
b. the condition produced by this.

Wait, you're trying to tell us you work for skynet, aren't you? Carry on, then.

Project Management is simple (0)

Anonymous Coward | more than 4 years ago | (#27674231)

The most important part of project management is whipping programmers so they can make an artificial date. Its important to do this so the code quality can turn to crap and then the project can be cancelled or a new project can be created to redo the first one. What would we do without project management?

Check out FogBugz! (2, Interesting)

fran (132829) | more than 4 years ago | (#27674293)

Check out FogBugz - they even give away a free "startup edition" for 1 or 2 people to use. It's either something you install on your own server, or use the on-demand "hosted" version. I use the latter, and it's great.

The Zachman Framework (0)

Anonymous Coward | more than 4 years ago | (#27674569)

The Zachman Framework [] is a great tool for organizing all the information you collect about a project and provides ways to interrelate that information. It's free-form enough to be scalable to all problems (document what you need to, store extra emphasis on things that are important) and it tries hard to not inflict more harm than good (not so rigid that every project can't be implemented in an entirely different if the problem demands so).

PMBOK (2, Informative)

crimsonshdw (1070988) | more than 4 years ago | (#27674639)

Having had to go this exact route, I started to take business analysis courses through a local college to compliment the IT knowledge and work through two fields. An excellent resource books is PMBOK [] . The book is really straight forward in general concepts and will give you a good fundamental understanding of project management. If you wish to follow through, there is a designation certification as well. A lot of project management just comes down to being really good at making flow charts and having a general concept of lengths of 'reasonable' work to complete projects. You have to be really detailed oriented and have good common sense.

Bare Bones Project Management (2, Informative)

pjrobar (947609) | more than 4 years ago | (#27674709)

Bob Lewis's Bare Bones Project Management: What You Can't Not Do [] would be a good place to start. He writes an IT and project management related column for Infoworld.

UML Reference Martin Fowler (2, Interesting)

woodsrunner (746751) | more than 4 years ago | (#27674723)

Martin Fowler's UML Distilled is a great read. Roughly 200 pages it offers a concise introduction to UML which is a handy way to visualize software design and share ideas in a common and easy to use visual language.

7 years experience tells me... (0)

Anonymous Coward | more than 4 years ago | (#27674755)

1. write a COMPLETE spec with deliverables, don't deviate from it.
2. have your team review, note milestones and blocking issues
3. add up all the required time inputs from each team member.
4. Multiple time required by 2 (and budget) and ultimately you will be +-20% of the 2x estimated time and budget.

good luck young warrior.

Another way to look at it... (5, Insightful)

Alpha830RulZ (939527) | more than 4 years ago | (#27674815)

A lot of good suggestions above. I'll add the following: Project management is the art of creating lists of tasks and getting them done. It's really as simple as that, and it's also more complex.

You need a list of your requirements. What are the things your system needs to do?

You need a list of things you'll develop to meet the requirements. These include the pages, the back end modules, the database schema/tables, etc.

You need a list of the tests you're going to perform.

You need a list of the steps to move into production.

The act of creating these lists will force you through the process of thinking through your project. Assigning elements from these lists to other people is how you get the project done. Understanding the dependencies between the items on the list identifies your path through the project. Watching how items get added to these lists lets you know whether your project is under control (high addition/change rate is bad).

The process of formal project management just codifies certain documentation approaches to the above. You can do everything you need in Excel/word, or use tools like MS-Project. The fancy tools are overkill for a small team/project.

Many of the disciples of project management lose sight of the fact that a project plan is not the end goal, it's a visualization of the work to be done. When you have enough detail in the plan so you can understand the work to be done well enough to estimate it, assign it, understand the dependencies you need to manage, and report your status to yourself and interested parties, you're done.

That's my take. I have 20+ years of project management experience, sometimes while being called a project manager.

Process and Book Suggestions (3, Interesting)

Laoping (398603) | more than 4 years ago | (#27674859)

First I want to say that several of the comments that came before are very good. There is a wide variety of experience and can help you get started.

I would say start as small as you can and expect to not get it right. Take your big project and break in into a few smaller easier to digest sections. You are going to make mistakes, but as you practice and you get you company more used the process will evolve and work better.

I won't give you specific examples of process, because I am not familiar with your organization and the process will have to be tailored for you company to work well. I will give you two books I feel are good to help. I read a lot of books on project management and I think these two are very good starter book.

Information Technology Project Management , Kathy Schwalbe


Managing Software Development Projects: Formula for Success , Neal Whitten


This one is always useful... (0)

Anonymous Coward | more than 4 years ago | (#27675163)

The Fast Forward MBA in Project Management (2, Informative)

no haters (714135) | more than 4 years ago | (#27675275) []

We used this book for my project management class in grad school. It's very easy to use and seek out specific information. The methodologies it explains are straightforward and easy to implement as well.

Some recommended reading (3, Insightful)

Stop+A (301523) | more than 4 years ago | (#27675609)

I've been a project manager for a couple of years now. Still have lots to learn. The basics:
- Scope: Define the project and what it's going to deliver.
- Requirements: Define the finish line, what's the product or service your project is going to deliver.
- ONE BUSINESS OWNER/SPONSER: Who has the purse-strings and will sign off on the completion of the project.
- Activities and Milestones: Define what needs to be done and pick off some deliverables on the way to completion, so you can show everyone (and yourself) you're making progress.
- Schedule: Put the activities and milestones on the calendar. Do you have people who can complete those activities and deliver the milestones? (Have you factored in vacation time...?)

Some recommended reading:
Head First PMP--the PMBOK is dry, Head First made it very accessible.
The Art of Project Management, by Scott Berkun--Learned a lot from this book. I come back to it time and again for ideas.
Managing Humans, by Michael Lopp--Enjoyable read, got some good ideas. A lot of the chapters in the book can be found at

Another recommendation: Get a mentor. Check out the local PMI chapter ( and see if they have a mentoring program.

Good luck!

Do something radical... (3, Interesting)

stonewolf (234392) | more than 4 years ago | (#27675701)

Hire an experienced person on contract to get you started and mentor/teach your team how to do a professional job of software development.


Re:Do something radical... (0)

Anonymous Coward | more than 4 years ago | (#27677027)

Hire an experienced person on contract to get you started and mentor/teach your team how to do a professional job of software development.

If you can get the funding, this is by far the best advice posted. Spending time working with a good, experienced mentor, even if only for the initial stages of a project, is fantastically beneficial, much more beneficial than reading dozens of books, attending a bunch of training classes and spending hour upon hour perusing websites.

Do It Like My Project Manager (1)

aquatone282 (905179) | more than 4 years ago | (#27675703)

Refer to yourself as "The Architect," then hire a couple of people to clean-up after you're done "architecting."

ONE book? (1)

DigitalCrackPipe (626884) | more than 4 years ago | (#27675713)

I understand that you don't want to read 5000 pages right now to get up to speed, but I suggest that you're aiming low if you think you're going to get all of your management knowledge from one book. Consider one book now to get you on track for your current effort, but to really get good at it you will probably need to absorb (and process) information from several sources to come up with all of the detail you need in your unique environment.

Is it an actual project (1)

geekoid (135745) | more than 4 years ago | (#27675729)

with many people, or is it just you?

If it is people, pmbok. Most college offer some sort of basic class geared towards pmbok. Take some.

If it is just you, then create and archetecture, modularize it, then break all the moduals down into code(pseudo) chucnks, then break the chunks into bit.
Then start programming.

Naturally every step requires communication with stake holders. Identify them immediatly.
Look up what a stake holder is, most people don't actual know how to identify stake holders.

Your Doomed (0)

Anonymous Coward | more than 4 years ago | (#27675773)

If you are asking at the stage where things "are starting to get hairy" then it is too late. All is lost. It is time to open the third envelope. Your only hope is to hire a mean program manager to save you. Just stay behind them and do what ever they say!

Want to say thanks to everyone's input (3, Interesting)

smooth wombat (796938) | more than 4 years ago | (#27675883)

I'm glad this question was posted because I have come to the conclusion that no matter how good I am at my current job, I'm bored and need to continue to advance myself. Unfortunately, because I work in a government environment, upgrading your skills is somewhat difficult due to union regulations about who does what as well as the whole "who you know" nonsense.

As a result, I've taken stock of what skills I do have and have realized the "Those who can't, teach" rule applies to me and will (hopefully) be shifting gears in the (very) near future. Specifically, project management.

If all goes well, I'll be heading back to school in the fall (while still working) to get a degree in IT Project Management using both credits I've earned in other computer classes as well as life experiences. I'm still waiting on word from the school as to how many credits I can transfer so we have an idea of what classes I need to take.

The information provided here, some of which I already knew about, is invaluable and while I'm one of those who will bitch about the cruft you folks sometimes write when responding, the responses so far are probably the most informative I've seen in a long time.

Thanks again and keep those suggestions coming.

P.S. If anyone has an opening for a low level PM, drop me a note. Organization and the ability to see the entire project, and in what order things need to be done, are my forté.

A good book... (1)

iso-cop (555637) | more than 4 years ago | (#27676849)

Managing Software Development Projects by Neal Whitten is approachable and has been very helpful to me.

paperwork (0)

Anonymous Coward | more than 4 years ago | (#27677029)

As far as I can tell from how the last project I was on at my current employer, there are 2 things to keep in mind:

1. If you need someone on another team to support your project and they tell you that they already have stuff to do and you need to get in line behind other folks with important needs who had the foresight to plan and schedule the work, call up everyone you know at the next level up and argue until you get what you want NOW.
2. Never EVER allow timesheets to be late. If a team member is late in submitting a timesheet, call them in for a 1:1 to tell them how serious this issue is and could result in disciplinary action.

Those two should get you to the point where the software is in production. You can then take vacation while the rest of the team (that just finished working 24/7 for nearly a week) spends the next couple of weeks patching up all the holes in the system.

Are you an ACM member? (1)

richardkelleher (1184251) | more than 4 years ago | (#27677051)

ACM offers many online courses in project management. Most of these are free to members.

Website reference (0)

Anonymous Coward | more than 4 years ago | (#27677071)

Also take a look at

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?