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?"
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.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
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."
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.
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.
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!
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.
Do you have a web link to specific tools?
'Agile Software Development' is a 21st century buzzword, just like XML, LAMP, OO, and eXtreme Programming were some buzzwords of the 20th century.
A multitude of vendors claim their tools are for or support 'agile' development, whether they're really useful or not, is another matter....
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 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.
Best Slashdot Co
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.
Putting the "anal" back into "analyst"...
in Army Basic Training.
Which is why I'm not in management...
Best Slashdot Co
'Agile' is a class of software methodologies. A popular Agile methodology is called Scrum. An excellent resource on how to conduct a Scrum shop is 'Agile Project Management with Scrum,' by Ken Schwaber. A good place to get started is http://www.mountaingoatsoftware.com/scrum/.
There's also 'Agile Software Development with Scrum,' same author. There are people who consider it to be the Scrum bible.
Basecamp has been the only thing ever that made me not hate doing PM. http://basecamphq.com/
-Matthew Riley "TofuMatt" MacPherson
I have a website
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.
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 thoughts:
...etc...etc...
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.
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..
Metastasis
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.
I put on my robe and wizard hat..
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
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
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.
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
Yours, Francis Rath
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 http://www.amazon.ca/Guide-Project-Management-Body-Knowledge/dp/193069945X/ref=sr_1_1/190-4122478-2675606?ie=UTF8&s=books&qid=1240410769&sr=1-1. 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 through, there is a designation certification as well. A lot of project management just comes down to being really good at making flow charts and having a general concept of lengths of 'reasonable' work to complete projects. You have to be really detailed oriented and have good common sense.
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.
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.
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.
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
http://www.amazon.com/Fast-Forward-Project-Management-Portable/dp/0470247894
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.
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!
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
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é.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower