Slashdot Mirror
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?"
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.
Those who can, do. Those who can't, sue.
Something that may be of interest to you is the Personal Software Process, see http://www.sei.cmu.edu/publications/books/process/psp-self-improvement.html
"If anyone needs me, I'm in the angry dome."
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.
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.
Do really dense people warp space more than others?
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.
Sweet informative mod.
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.
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.
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 was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
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 www.randsinrepose.com
Another recommendation: Get a mentor. Check out the local PMI chapter (www.pmi.org) and see if they have a mentoring program.
Good luck!
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.