The Principles of Project Management 125
zedguy writes "Ask someone what 'project management' is and you're liable to get a few blank stares — it's one of those fields people have heard of, but probably have problems pinning down a definition. So that is what the first section of the book does: provides a definition that can be summed up as applying tools and skills to complete a project. That then leads to what exactly is a "project": a set of tasks with a time-frame and goal of somehow adding value. So yes, the introduction does involve a fair bit of terminology that isn't going to be familiar to many readers coming from a coder's background, but there's a helpful appendix that lays out many of the terms. Just as important, the introduction explains what project management is not, some of the misconceptions and why it's good to know." Keep reading for the rest of Zoltan's review.
With the definitions out of the way, readers then get into the start-up tasks. First, there's looking for projects (find opportunities), deciding is it's a good opportunity (this is a bit of office politics — you want to know soon if the your project has the necessary support from management) and even if the task warrants a project — one of the key points is that a project is not on-going maintenance — it has a goal and a completion date.| The Principles of Project Management | |
| author | Meri Williams |
| pages | 204 |
| publisher | SitePoint / O'Reilly |
| rating | 8 |
| reviewer | Zoltan Hunt |
| ISBN | 0-9802858-6-0 |
| summary | A practical introduction to project management |
Once you have decided to undertake a project, the next steps involve a proposal, identifying stakeholders, setting up an organizational chart and establishing communication protocols. This is the soft skill side of project management — a lot of the work is keeping the people the project is for interested and informed on where the project is heading. Much of the advice is practical — including dealing with the stakeholders who just aren't that interested in your project and picking a good project board — the less the better. Finally, once this is established it's time to make sure everyone is on the same page and agreed on the deliverables (the specific things the project will achieve).
By chapter three ("Getting the Job Done") we're into the actual material many readers (including myself) think of as project management — setting schedules, breaking deliverables into discrete tasks. For that, there's a lot of practical advice here — especially around making estimates and communicating them to stakeholders and team-members so they are not mis-interpreted as wild guesses or hard dates. Particularly good was the advice on refining estimates from a general size (is it a small, large or extra-large task), then, as the date got closer, change it to a more accurate estimate. As well as measuring performance, some management tools like work-flow and Gantt charts and issue lists are introduced in this chapter.
The last two chapters look at managing your team and completing the project. The "Keeping it smooth" chapter gives a good overview of the people management skills you will need working with team members. There's a fair bit of overage of team building (forming, storming, performing and adjourning) and a bit of coverage of collaboration over distances. Having done some small group management in the past, I think it covers all the bases well and it's applicable outside of project management as well.
Like many of the new SitePoint books this book explains a complex topic with a few illustrations and a clean layout. They're using that humorous information schema (light-bulb, bicycle horn, hand grenade) to good effect. One example of this is in Getting Started chapter: There is a section talking about what goes in a Project Initiation Document (PID), and there are break-out boxes on what it is not meant to take the place of.
For an example of the layout, the "Keeping it Smooth" chapter is a good example of how this book is organized; Topics are broken up by headings with points arranged as lists of short paragraphs, which makes it easy to skim. While it's a small book — 200 pages, about 25x20 cm — it's still good to be able to skim.
The glossary covers the particular usage of words in the project management domain.
Appendixes A-C list some tools,other resources (books and blogs) and C provides a list of qualifications and associations.
For a topic I was quite unfamiliar with when I started, I'd recommend this book as a good overview to the topic. The chapters follow a chronological order through a project — from picking a project — including those to avoid — planning and executing, managing the staff and stakeholders and finally, finishing your project and handing it off.
The author, Meri Williams, writes two blogs: GeekManager and Meriblog which readers might want to check out for further material. While each field has it's jargon, project management has a number to learn — and this book does a good job explain it.
You can purchase The Principles of Project Management from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Also on this topic (Score:5, Informative)
I'm a Project Manager .. (Score:2, Informative)
Well thus my job title (Project Manager, Architecture). Now I know typically most /. topics are technology based, however I think there are similarities.
In my experience a Project Manager is someone with enough experience, resources to oversea the successful completion of a given project. Quick note green MBA's need not apply.
I think having a clear understanding of the product, the process, and the expectations is essential. In addition the ability to make assertive critical decisions based on experience.
Most importantly realizing the Project is No.1
Probably one of the most interesting projects I've worked on to date is Overseeing design consultants for an FAA funded Residential Sound Insulation Project. What made this a challenge was having to work with Airport Technocrats, Acoustic Engineers, General Contractors, Mechanical Engineers, Architects all in the same room at the same time. None of which having the desire to understand what the other did, and all believing his or her aspect of the project was most important. Insert politically motivated agenda's and viola a nightmare to oversee.
Re:I bought Microsoft Project a while back (Score:3, Informative)
You missed the point of the tool.
The point of the tool is to allow you build your list, assign resources, time estimates, dependencies, track deadlines, etc.
Start simple:
Task 1: Write outline of application goals (X days)
Task 2: Create block diagram of expected modules and functions (X days)
Task 3: Code skeleton structure (X days)
Task 4: Write code for modules (X months)
No, I'm not a developer - and it's just an example. Once you have that in place, you start doing real work. And you realize, "Hey, I'm going to need to do these 12 things before I can do that one." Perfect, you go back and add those in, making them prerequisites. Little by little, you end up with a useful plan that lets you track your progress and estimate completion dates, etc.
Microsoft Project isn't a project manager. It's a tool for a project manager to use.
Definitions of PM and project (Score:1, Informative)
As a working PM, I can attest that even in our own field there is a flexibility to the terms "project manager" and "project". Consider it a holy war of sorts. So when someone applies for a position as a PM, it often helps if they have a PMP certification so its clear what their definitions look like.
http://www.pmi.org/CareerDevelopment/Pages/Certification-and-the-Job-Market.aspx [pmi.org]
Re:I bought Microsoft Project a while back (Score:1, Informative)
Let me put it in a different light. To do a project you need to answer the following;
1. What do I need to deliver to consider the project complete
2. Who will do the work for each deliverable
3. How long each deliverable will take
4. What is the flow of my deliverables (what happens first, second, third, etc)
So if you can answer What, who, and how long each activitity you need to do takes, then you have a project plan. Checkout the guys at Merlin2Users google group [google.com].
Re:Something they rarely teach managers (Score:3, Informative)
The Two Key Project Management Thingys (Score:5, Informative)
Re:I'm a Project Manager .. (Score:2, Informative)
Obviously it didn't occur to you that Architecture has meanings other than what you do.
Another PMs Perspective (Score:5, Informative)
1) While delegating out tasks and keeping track of time and budget are part of what a PM does, it's been my experience that the above is the minimum for a good PM. I've found that companies value not only someone who is going to manage the tasks, but also work with the business to help finalize the definition of the project and realize all the various business scenarios they will face before the project ever starts. This helps prevent scope creep and gives the architect a clearer picture of what is wanted. From my experience, I've never managed a project solely on tasks alone. If I don't understand the entire business aspect, I don't do the project.
2) There is certainly a need for a PM and a Technical Architect. The distinction I've experienced is as a PM, it is my job to define how the system should work from an operational perspective and outline all business rules. It is the architect's responsibility to design the systems in a manner that will be reliable to meet the above directives.
3) Waterfall vs. Iterative Development. My personal thoughts on this, and this is up for interpretation by anyone, is that the best method is a hybrid of the two. There's no reason I can't go through an intensive definition and design exercise prior to starting the project and outline all the business rules/operations. However, a good PM knows how to manage the business' (read executives) expectations on when the project will be completed. Always build in a buffer. Once the Project Plan is complete, iterative development can begin, working on chunks of functionality broken down into short term goals.
4) Good PMs should be honest and stick up for the technical team as much as the business. They should know when to push back on which side.
Now open for complaints...