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

A book I thought was good

[stoolpigeon]

I recommend Making Things Happen: Mastering Project Management (Theory in Practice) [amazon.com] by Scott Berkun. Berkun has quite a bit of experience working on and managing teams. You can check out his blog [scottberkun.com] 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 [oreilly.com] 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.

Re:ITIL

[mc1138]

ITIL is great and all, but might be a bit monolithic for a first time project manager, especially working solo. Your other recommendations are right on track though.

PMI

[rodrigoandrade]

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.

Project Management

[Anonymous Coward]

You're going to get a lot of answers here pointing to specific methodologies like Agile, but for someone just starting out I think it helps to understand what project management is and isn't.

The Project Management Institute (the ones that run the PMP certification program - pmi.org) is sort of the world repository of project management theory. They publish "A Guide to the Project Management Body of Knowledge" or PMBOK. Most practicing PMPs take everything in the PMBOK with a grain of salt, because it is an ideal vs. what happens in reality, but I think their definition of Project Management is a good one:

"Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements."

There are some good nuggets in there that I think can help a new project manager.

First is to understand that the whole point of a project is to meet some set of requirements. So you probably better know what those are before you start, and more importantly, you should know how to measure whether you've met them or not.

Next is to realize that you are managing project activities, or tasks. You need to have some idea of what things need to be done in order to meet a requirement, what resources (people/skills, money, time, etc.) are needed, and some idea of how long it's going to take.

Lastly, project management involves applying tools (like scheduling software, or gap analysis templates), techniques (like change control) and skills (like leadership) to tie it all together.

It doesn't particularly matter what your process is (agile, six sigma, etc.), but it is very important that you have one. Every professional PM I know adapts their corporate methodology to fit their style and the nature of the particular project. That's part of the "skills" in the PMI definition.

Project Management can really make your life easier and doesn't have to be an overly onerous process.

Good luck!

Re:Agile Software Development and Planning

[mysidia]

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

Re:Only as much as you need

[myvirtualid]

Mod parent up. With all due respect to other posters, sending the submitter to ITIL is overkill. Talk about drinking from the firehose.

I use to run a number of development teams in a systems integration and custom development shop: We took our employer's base products and toolkits and integrated them into customer environments. We did a lot of "1.0's" - typical projects were 2 to 6 weeks in length and if we ever saw them again, we lost money. We could afford one or two moderate bugs (sev 3 - functionality impaired); more than that, we lost money. We could not afford major bugs (sev 1 - all is borked; sev 2 - most is borked). And given the tight timelines, we had to be very sure that what we were developing was what the customer asked for and what the customer asked for was what the customer wanted.

We almost always made money and our customers were almost always very satisfied. We very rarely lost money, and it was usually on strategic projects (spend integration money to make more license money).

Here's what we did:

1. Write a high level design document describing the major components and data flows. A mix of diagrams and text. Nothing too technical, because the customer has to understand it. But it has to be enough for a senior dev to either start coding (2 week project) or write an internal-use mid-level design doc (6 week project).
2. Developer, tester, and writer estimate how long to do their bits based on high-level design. Project management adds some buffer (10% to 50% based on complexity).
3. Customer reviews design, expected ship date, signs off. (Because the design has to be fit for the customer, no UML diagrams or fancy methodologies that the customer doesn't understand. These things have their place, to be sure. But if you cannot describe it in pictures and words, it may be too complicated for you and your organization's current level of development methodology.)
4. Based on the high-level design document, start three simultaneous streams:
   1. Development: Either start coding or write that mid-level design document.
   2. Test: Write the test plan. Not the test cases. Start with the acceptance test plan. Have this signed off by the customer.
   3. Documentation: Start putting together the major structure of the documentation. (ToC, section headings, text where necessary, etc.).
5. Checkpoint: The developer, tester, and writer meet to ensure that they agree that what they are each working on aligns with the others and with the high-level design. This can be a 30 minute meeting or a three hour meeting, depending on scope, etc. Most important things:
   1. Do we align with the design?
   2. Will we ship on time?
6. Add detail. The developer codes, the tester writes test cases or test scripts, the writer writes documentation.
7. Checkpoint: The developer, tester, and writer meet to ensure alignment.
   1. Do we align with the design?
   2. Will we ship on time?
8. Repeat "add detail" and "checkpoint" steps as necessary. Stop adding detailing when done (e.g., often the writer will finish first, then the tester, then the dev - and it's nice when it goes this way, because the tester can review the docs and make sure test plans and docs really align).
9. Test.
10. Ship.
11. Profit.

Handling exceptions. If at any point things start to drift out of alignment, stop. Figure it out. If the problem was the high-level design, go back to the customer. Otherwise, it's an internal issue you have to identify and correct.

VIP: Acceptance test plan. Having the acceptance test plan signed off by the customer is crucial. If they sign it off and everyone codes to it and it aligns with the high-level design and the deliverable passes acceptance, then you are done.

One thing I've left out: Change requests. They are the bane of every project under development. You need to dig in your heels and manage them properly. Work collaboratively with the

Re:Agile Software Development and Planning

[TheSpinningBrain]

'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/ [mountaingoatsoftware.com].

Re:Agile Software Development and Planning

[TheSpinningBrain]

There's also 'Agile Software Development with Scrum,' same author. There are people who consider it to be the Scrum bible.

Re:PMI

[Maxo-Texas]

www.pmi.org

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:A book I thought was good

[stoolpigeon]

Making Things Happen is the second edition of The Art of Project Management. They cleaned some things up and I think added in some practical exercises - and changed the title. (I'm not sure about the exact differences because I never read the first edition) I think Berkun explains why they changed the name in the forward but my copy is at home and I can't remember for sure. It is unfortunately confusing.

PMBOK

[crimsonshdw]

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 [amazon.ca]. 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.

Re:ITIL

[Tiger4]

In addition, be be careful with your requirements, specifications, and testing.

Your users and customers (two related but often slightly different groups) are supposed to come up with the requirements, but often they are clueless on what they need. So you will often need to help them with suggested feasible solutions. However, the ultimate decision on what is REQUIRED is theirs. Just be sure to help them with the difference between required vs nice to have vs "you have got to be dreaming". The budget and time estimate is based on the requirement.

ONCE THE REQUIREMENTS ARE LOCKED DOWN you do not accept changes to them. Any changes go into a NEW requirement that will be harmonized with the old one at a later date. Think of it like a train leaving the station. No new passengers get on, none of the old ones jump off, except under controlled conditions. If the users want to change the requirement, tell them to get on the next train. As the PM, you decide when the new stuff can be included into the old AND HOW MUCH IT WILL COST TO DO IT. Never let them think it will be "free".

Getting a good estimate from the written requirement is tough. Trying to determine Function Points and lines of code and complexity and speed of development is a serious art form. Get good people and go over it a lot, from different angles. If you are lucky, this project is similar enough to past projects that you won't plant the seeds of destruction at this stage. You need to be sure you can really live with the cost and time estimate you give them. DO NOT ASSUME BEST CASE just because it look "easy". Too many people do. DON'T JUST DOUBLE EVERYTHING unknown. that is just wasteful. If you have serious unknowns, do some risk reduction explorations to be sure you do know what you are talking about (or at least plan to do them so you will know when the time comes).

The best specifications are testable. And the Tests should be written at about the time the specs are written. A Requirement might say "full color display". A Specification might say, "display in at least six colors, including white, black, red, green, blue, cyan, magenta, and yellow". Guess what the acceptance test is going to look for? It should be as Unambiguous as possible. This is where team work is good. Don't let the designer write the specs and the tests. Too much chance for hidden assumptions to creep in.

Which reminds me, be sure to explicitly lay out the overall software design, all the modules, all the interfaces, and subject them all to thorough rigorous Reviews. Too many otherwise good projects die from unstated assumptions that lurk under the surface. The coders are so anxious to get started they forget to examine where they are and where they are going vs the tools and skills available. They never see the iceberg until too late.

Please do your best not to become another "out of control software project".

Bare Bones Project Management

[pjrobar]

Bob Lewis's Bare Bones Project Management: What You Can't Not Do [issurvivor.com] would be a good place to start. He writes an IT and project management related column for Infoworld.

The Fast Forward MBA in Project Management

[no haters]

http://www.amazon.com/Fast-Forward-Project-Management-Portable/dp/0470247894 [amazon.com]

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.