Project Management For Beginners?

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?"

Only as much as you need

[Jawn98685]

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.

Bare Bones Project Managment

[jeffshoaf]

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). [issurvivor.com]

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

Re:ITIL

[NeutronCowboy]

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.

Rules of Thumb

[mseeger]

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.

Basecamp...

[TofuMatt]

Basecamp has been the only thing ever that made me not hate doing PM. http://basecamphq.com/ [basecamphq.com]

Check out FogBugz!

[fran]

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.

http://www.fogbugz.com

UML Reference Martin Fowler

[woodsrunner]

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.

Process and Book Suggestions

[Laoping]

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

and

Managing Software Development Projects: Formula for Success , Neal Whitten

 

Do something radical...

[stonewolf]

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

Stonewolf

Want to say thanks to everyone's input

[smooth wombat]

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

Re:Test driven development

[TheRaven64]

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.

Re:Only as much as you need

[high_rolla]

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 properly laid out intranet and just walking around talking to people can be a huge asset in achieving this.