Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Programming IT Technology

Project Management For Beginners? 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?"
This discussion has been archived. No new comments can be posted.

Project Management For Beginners?

Comments Filter:
  • by stoolpigeon ( 454276 ) * <bittercode@gmail> on Wednesday April 22, 2009 @08:34AM (#27673381) Homepage Journal

    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: (Score:3, Informative)

      by kchrist ( 938224 )

      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.

      • by stoolpigeon ( 454276 ) * <bittercode@gmail> on Wednesday April 22, 2009 @10:40AM (#27674637) Homepage Journal

        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.

        • by kchrist ( 938224 )

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

      • by Jay L ( 74152 ) * <{mf.yaj} {ta} {hsals+yaj}> on Wednesday April 22, 2009 @06:13PM (#27680123) Homepage

        After a long spell away from project management, I bought a few books to catch up on what I'd missed. I did read the Art of Project Management, but I wasn't that mesmerized by it (though I did start following Scott Berkun's blog []). It felt too sterile and academic as a starting point. Maybe it's better if you're already in the thick of it, and maybe the new edition is cleaner.

        What did mesmerize me was Agile Estimating and Planning [], by Mike Cohn, who also has a good blog []. It's quick reading, in an appropriately lightweight style, and it introduces all the concepts of agile planning (independent of Scrum, XP, etc) in a way that... that...

        Well, remember that one professor you had, who taught you biology by deriving it from chemistry from physics from mathematics []? Cohn explains agile planning from first principles, in a way that made me wonder how we spent two decades not realizing how obvious it was. My forehead hurt from all the slapping. Of course! Why are we forcing humans to estimate time and to calibrate their estimates? All we know is "hard" and "easy"; estimate in points, track your velocity, and let a smart computer figure out what that means in weeks. Of course! We don't need to plan hour-by-hour for dates 18 months away; we don't even know what we'll consider important than.

        If you're considering agile methodologies, you must buy this book. If you're considering traditional top-down/waterfall planning, do yourself a favor - just slap your forehead every day. It'll build up calluses for when you buy the book later.

    • I think lawpoop is confused. He keeps calling it "project management", but if you RTFA (I know...) he's actually asking about software engineering.

      I'm currently taking a software engineering class and our assigned text is Software Engineering: A Practitioner's Approach []. However, we've never opened it. My instructor says it's a "good reference", but he doesn't agree with everything in there. He teaches his own method, which he's developed while working as a software engineer for a large defense contractor fo

  • ITIL (Score:5, Insightful)

    by NeutronCowboy ( 896098 ) on Wednesday April 22, 2009 @08:38AM (#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 (Score:4, Informative)

      by mc1138 ( 718275 ) on Wednesday April 22, 2009 @08:42AM (#27673455) Homepage
      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: (Score:3, Insightful)

      by Anonymous Coward

      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 ask

      • Re: (Score:3, Interesting)

        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.

    • 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 a

    • Re:ITIL (Score:5, Informative)

      by Tiger4 ( 840741 ) on Wednesday April 22, 2009 @10:45AM (#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: (Score:3, Insightful)

        by gosand ( 234100 )

        "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

        • by Tiger4 ( 840741 )

          Agile is great for quickly verifying your project is moving in the right direction. I'm just wary of it being use as a substitute for a robust system design. Users might be happy with the basic functionality they see, but they may not be in a good position to see the big picture of long term maintenance or system architecture. If adding a new function turns into a massive hack to get it to work, you aren't doing them a favor by being highly responsive up front.

          But by no means are the two mutually exclusi

          • by gosand ( 234100 )

            Agile is great for quickly verifying your project is moving in the right direction. I'm just wary of it being use as a substitute for a robust system design. Users might be happy with the basic functionality they see, but they may not be in a good position to see the big picture of long term maintenance or system architecture. If adding a new function turns into a massive hack to get it to work, you aren't doing them a favor by being highly responsive up front.

            Actually, you ARE doing them a big favor by fi

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

          Especially if you're doing iterative development. What did you think the next train was?

      • Re:ITIL (Score:5, Insightful)

        by anonymous_wombat ( 532191 ) on Wednesday April 22, 2009 @02:36PM (#27677315)
        The above post implies that you are going to use a waterfall type development methodology. A more light weight alternative is to do iterative development. Deliver a release to the customer every 4 - 6 weeks, and ask if that is what they want. After each one, if they like what they see, ask what they want to see in the next iteration. Negotiate the scope of each iteration, but not the customers priorities.

        Of course, if they don't like what they see, you have a different problem. Figure out how to get on the right track.

        • by Tiger4 ( 840741 )

          It isn't about waterfall methodology vs anything else at all. It is more about Hitting the target, and trying to keep the target from moving more than absolutely necessary.

          I would personally prefer that all requirements be firm and well known in advance. Then have a firm spec developed, then have a fixed and approved design, etc. It probably is not going to be possible or practical to do business that way, but it would be nice.

          But what IS possible is to avoid having a new and unvetted requirement suddenly

      • Re: (Score:2, Insightful)

        by Javaman59 ( 524434 )

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

        I would add.. do not let the customer increase the process overhead either

        This is unusual, but I once had a customer who was actually more interested in the process than product! As I got stuck into the project, he'd frequently drop by and demand a "process" item, such as a plan, a demo, a design document, etc. Initially I responded positively, but that just increased his demands, until it was seriously interferring with the project, and, incredibly, he knew it! When I started resisting the demands (in orde

        • When I started resisting the demands (in order to get on with the job) he accused me of trying to "hide something" from him. [...] the lesson is - treat process as a contract, as much as the functional requirements. If they ask for more, just say "no"

          Another lesson could be that when your client feels uncertainty and doubt, actively make this a topic and ask how that feeling can be alleviated. The problem should probably be fixed by the client himself, for instance by paying an external auditing party, by paying for extra deliveries and so on.

      • There is a lot more to managing a software development project than project management. Gantt charts are great for the time management aspect of a software development project but what the client is paying for isn't effective use of the team. It is a quality application delivered on time and on target. That means relevant and well articulated requirements, good analysis, accurate estimates, flexible and relevant architectures (both software and information), well written code, and consistent testing covera

  • PSP (Score:3, Insightful)

    by Walterk ( 124748 ) <[dublet] [at] []> on Wednesday April 22, 2009 @08:39AM (#27673433) Homepage Journal

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

    • 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 (Score:4, Informative)

    by rodrigoandrade ( 713371 ) on Wednesday April 22, 2009 @08:44AM (#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.
  • by Jawn98685 ( 687784 ) on Wednesday April 22, 2009 @08:47AM (#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.
    • by D3 ( 31029 ) <daviddhenning@[ ] ['gma' in gap]> on Wednesday April 22, 2009 @09:14AM (#27673775) Journal
      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.
      • by rtb61 ( 674572 )

        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

    • by myvirtualid ( 851756 ) <> on Wednesday April 22, 2009 @09:23AM (#27673871) Journal

      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

      • 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.

        • It's too bad Slashdot is still stuck in 1997, and doesn't have ways to flag posts as favorites... I have to do a shitload of cut and paste whenever I find something worth saving.
        • This is one of the first posts I've ever wanted to mod to +6.

          Quick, let's grab the slashcode and make it go to 11!

          Of course, that will mean converting it to use base 5, but that might be cool. Today would be the 43rd day of the 4th month of the 31014th year, for example.

          Seriously, thanks - I've got a little glow of slashpride right now!

      • 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

        • Use Case diagrams are UML

          Excellent point - as are all of your "quibbles" (which I think you use to mean "pithy and accurate observation" - at least that's the sense I get from your post :->).

          I poorly expressed the point I was trying to make when I wrote "no UML". I meant something more along the lines of "no jargon", no specialized terminology or diagrams that are unfamiliar to a non-technical audience. For example, "actors" and "agents" have specific meanings in various contexts, and while developers

    • Re: (Score:3, Insightful)

      by digsbo ( 1292334 )
      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.
    • 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

    • Re: (Score:3, Insightful)

      by sjanich ( 431789 )
      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: (Score:2, Interesting)

      by high_rolla ( 1068540 )

      This is a great post. Just to add my bit on top of this. I forget who said it but one quote I quite like is:

      "The most important thing is to keep the most important thing the most important thing."

      At the end of the day your task is to get a job done and a large part of that is going to be managing information flow and keeping it flowing as freely as possible between yourself and everyone else involved (management, end users, you, other developers etc). Simple things such as a big whiteboard, a properl

  • 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' f

    • by heck ( 609097 )
      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 manageme

    • by Tarwn ( 458323 )

      As others have already commented, Agile is one option but unless you want to be the guy in the corner pounding on screws with a hammer, I'd suggest reading a little about several methodologies and then dig deeper into one methodology when you have a situation that fits.
      Remember, the OP is in a single person environment, that alone is going to make daily team meetings a little challenging (or at least a little odd to watch).
      Other options include Critical Path, which can be executed with a waterfall model but

  • PMI and ITIL (Score:3, Insightful)

    by ErichTheRed ( 39327 ) on Wednesday April 22, 2009 @08:55AM (#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!

  • by MikeRT ( 947531 ) on Wednesday April 22, 2009 @09:00AM (#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.

    • #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 h

  • Here is one site I found yesterday with templates, white papers, articles, etc. []
  • by daffmeister ( 602502 ) on Wednesday April 22, 2009 @09:17AM (#27673791) Homepage

    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.

  • 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.
  • 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.
  • by wiredog ( 43288 ) on Wednesday April 22, 2009 @09:20AM (#27673837) Journal

    in Army Basic Training.

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

    • Re: (Score:3, Funny)

      by Lumpy ( 12016 )

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

      Corporate America frowns on that.

      • Re: (Score:3, Funny)

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

        Corporate America frowns on that.


  • 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 w

  • Rules of Thumb (Score:4, Interesting)

    by mseeger ( 40923 ) on Wednesday April 22, 2009 @09:30AM (#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.
  • 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.
    • by u38cg ( 607297 )
      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... (Score:2, Interesting)

    by TofuMatt ( 1105351 )
    Basecamp has been the only thing ever that made me not hate doing PM. []
  • Triple constraint (Score:4, Insightful)

    by 93,000 ( 150453 ) on Wednesday April 22, 2009 @09:35AM (#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.

  • 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
  • by MaerD ( 954222 ) on Wednesday April 22, 2009 @09:47AM (#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.

    • by clodney ( 778910 )

      I thought metastasizing was a perfect word to describe a project where scope creep has been replaced by scope gallop. One where new requirements seem to come from everywhere, sprouting from what was once a tightly defined product.

      • ``I thought metastasizing was a perfect word to describe a project where scope creep has been replaced by scope gallop. One where new requirements seem to come from everywhere, sprouting from what was once a tightly defined product.''

        My experience is that web applications tend to be like this. The barrier to entry is low and there is often a lot of competition. Once a competitor implements a good idea, there is a lot of pressure to duplicate that idea in your own product. If you opt to go this way, many tra

  • Check out FogBugz! (Score:2, Interesting)

    by fran ( 132829 )

    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.

  • PMBOK (Score:2, Informative)

    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
  • 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.
  • by woodsrunner ( 746751 ) on Wednesday April 22, 2009 @10:48AM (#27674723) Journal
    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.
  • by Alpha830RulZ ( 939527 ) on Wednesday April 22, 2009 @10:58AM (#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.

    • I have 20+ years of project management experience, sometimes while being called a project manager.

      Just curious... What were you being called other times?

      Names? Liar? Scapegoat? Catbert, Destoyer-of-Marriages? Head slave-driver?

      • Bastard, Shithead, God of Delivery... Slave Driver was in there, as well. A couple of the folks called me "The Best Manager I ever had". They were the same folks who called me "Slave Driver".

        Seriously, I have been variously labeled Manager of IT, Engagement Manager, Product Manager, Program Manager, Business Systems Architect, and Lead Developer.

  • by Laoping ( 398603 ) on Wednesday April 22, 2009 @11:03AM (#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


  • by no haters ( 714135 ) on Wednesday April 22, 2009 @11:42AM (#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.
  • by Stop+A ( 301523 ) on Wednesday April 22, 2009 @12:12PM (#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!

  • by stonewolf ( 234392 ) on Wednesday April 22, 2009 @12:21PM (#27675701) Homepage

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


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

  • 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.
  • 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.

    • <quote>
      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.

      I'll give you a hint. Users are not usually stakeholders. And stakeholders are not usually users. Oh how obtuse was that? Lol.
  • by smooth wombat ( 796938 ) on Wednesday April 22, 2009 @12:35PM (#27675883) Journal

    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é.

  • Mary Poppendieck does a good job of translating the manufacturing paragdigm of Just-In-Time manufacturing to the software development process...

    I personally really related to these, as I'm a software guy with a Mechanical Engineering degree...

  • This guy [] wrote an amusing piece on Agile methodolgy.

    I like this bit: "If you plan on using Agile to get out of writing proper documentation, then get ready to agile your sphincter for the angry client."
  • Steve McConnell []
  • like, if you are doing Agile-style work. As long as you define your goals properly (which, in essence, equals a definition of your project), then you can use your management tool to keep track of what is done, what needs doing, priorities, estimated times for completion, actual times used, etc.
  • First thing is: forget about milestones. Milestones have 2 problems: first they put a fixed date for delivery, that means a fixed amount of time. Second they assume a fixed amount of work done until that Milestone. And finally they assume the work aka code is "finished", "polished" and tested.

    Currently you say that you want to do better estimates ... with no experience and likely no reference data this is nearly impossible to do with milestones.

    The most important thing is to get an idea about your "speed" o

  • I think these books are a great starting place to learn how a good manager operates.
    • The Career Programmer [] is written mostly from the programmer's perspective, but gives a lot of advice on how managers and programmers can work together to achieve the project's goals.
    • Software Project Survival Guide [] has a lot of good information on how to run a successful project.
    • The Mythical Man-Month [] has been around for a long time, and has a lot of good management advice.
  • by zmooc ( 33175 )

    You've lost focus already before you started. Project management is not about reading books, using uml or not or whatever. Project management is about knowing what needs to be done and ensuring it gets done in time. So, instead of reading a book, what you should do is:

    1. Ensure you know what needs to be done (this involves things like requirements, customers, deadlines, versions, quality assurance etc.)
    2. Make a plan on how to get that done (this involves things like requirements engineers, software enginee

"I prefer the blunted cudgels of the followers of the Serpent God." -- Sean Doran the Younger