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

Comments

ITIL

[NeutronCowboy]

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

[anonymous_wombat]

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.

Re:Only as much as you need

[D3]

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.

Another way to look at it...

[Alpha830RulZ]

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.