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?"
ITIL (Score:5, Insightful)
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.
PSP (Score:3, Insightful)
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 [cmu.edu]
Re:ITIL (Score:3, Insightful)
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
PMI and ITIL (Score:3, Insightful)
I'd recommend starting out with the PMI body of knowledge...start here: PMI [pmi.org]. 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!
Comment removed (Score:4, Insightful)
Re:Only as much as you need (Score:5, Insightful)
Talk to someone in person (Score:3, Insightful)
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.
That useless piece of s*** (Score:3, Insightful)
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.
Triple constraint (Score:4, Insightful)
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 (Score:2, Insightful)
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.
Test driven development (Score:3, Insightful)
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.
Cheers,
Toby Haynes
Re:Only as much as you need (Score:3, Insightful)
Comment removed (Score:3, Insightful)
Re:Only as much as you need (Score:1, Insightful)
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.
Another way to look at it... (Score:5, Insightful)
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.
Some recommended reading (Score:3, Insightful)
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!
Re:Only as much as you need (Score:3, Insightful)
Re:ITIL (Score:3, Insightful)
"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.
Re:ITIL (Score:5, Insightful)
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: Making things happen (Score:1, Insightful)
Here's my 3 steps for getting started before buying a book or doing anything else:
1) I'd recommend talking to your team, individually, about what things on the project are most frustrating or could be improved.
2) In each conversation ask for their advice on what you can do, and also what they are willing to do or try
3) Based on your conversations, propose one simple change that has the best odds of both being accepted, and improving things. If the team has lots of conflicts, pick something very small. If there is too much dissension, pick something you can do with just one or two others.
4) Then make the change.
5) If things go poorly go back to #1.
6) If things go well, propose the next thing from #3.
But without talking to your team, and without establishing credibility and leadership, no book, degree, or IQ, will be of any use to you as a project manager. Start with your team first and earn their trust.
P.S. The book was originally called The art of project management. Making things happen is the 2nd edition, and heavily revised, version of the book.
- Scott Berkun [scottberkun.com], Author of Making Things Happen [amazon.com]
Re:A book I thought was good (Score:4, Insightful)
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 [scottberkun.com]). 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 [amazon.com], by Mike Cohn, who also has a good blog [mountaingoatsoftware.com]. 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 [xkcd.com]? 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.
Re:ITIL (Score:2, Insightful)
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 order to get on with the job) he accused me of trying to "hide something" from him.
That was an extreme case, but the lesson is - treat process as a contract, as much as the functional requirements. If they ask for more, just say "no"