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

Only as much as you need

[Jawn98685]

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.

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

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.