Slashdot Log In
The Principles of Project Management
Posted by
samzenpus
on Mon Jun 23, 2008 01:26 PM
from the read-all-about-it dept.
from the read-all-about-it dept.
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.
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.
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.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Also on this topic (Score:5, Informative)
Re:Also on this topic (Score:5, Funny)
Parent
Is this (Score:3, Interesting)
like the Cliffs Notes for the PMBOK [wikipedia.org]?
Re: (Score:2)
Cliffs Notes are for literary works that people can't be bothered to actually read. They don't have them for technical documents like the PMBOK. The technical equivalent is known as a "textbook".
Book version of a meeting? (Score:5, Funny)
Thank god we've gotten that out of the way. I guess now that we've adequately defined work, I can go get some work done. See ya'll at the next meeting.
project management is more like "time accounting" (Score:4, Insightful)
Only Project Managers have completely different names for those things, but the better ones do a lot of time reporting and time budgeting.
Re: (Score:2, Insightful)
Re:project management is more like "time accountin (Score:5, Insightful)
Not really.
I'd say that Project Management involves juggling three things - Schedule, Scope and Budget (think of it as a triangle).
Usually, any change in project direction, requirements, resources or funding affects one of the 3, and you need to juggle between the 3 to find an optimal state.
Parent
Re: (Score:2)
Time accounting for a project is data collection, that's it. Technically, all accounting is just data collection.
It's the analysis and resultant actions that set apart good financial managers (and project managers) from the dreck.
In my experience, time accounting by PMs is used primarily for budgeting and budget allocation -- more as reporting to their superiors than anything else. I have had the pleasure of working u
Re:project management is more like "time accountin (Score:3, Insightful)
Though project fiscal performance is important I think the most important aspect of a 'qualified' project managers job is knowing what to do when things do not go as planned. I think the best example of a project manager would be
General Leslie Groves
http://en.wikipedia.org/wiki/Leslie_Groves [wikipedia.org]
who's responsibility it was to keep everyone on task and on schedule. By taking on planning and logistics he allowed the scientists to focus on what they do best.
Which is the mark of a good project manager. The ability t
Actually... (Score:3, Insightful)
I'm pretty certain that many people with a 'coder's background' will be all too familiar with some of that terminology, after they've been in the workforce a year or two.
I bought Microsoft Project a while back (Score:5, Funny)
Worst investment I ever made. My memory is hazy, but I seem to recall it set me back five hundred bucks.
So with the manual open, I created a new project, and then the manual said "Enter your tasks".
Well, Hell, if I knew what my tasks were, I wouldn't need a project management tool. I gave up on it completely.
Re:I bought Microsoft Project a while back (Score:5, Funny)
Yeah, I had the same problem with Microsoft Word. I bought it to write a novel. But it turns out you have to supply your own words!
That title is very misleading.
Parent
Re: (Score:2)
Clippy was useless. He wanted to know the "genre" of my novel. How can they call their software "user friendly" if you have to learn technical jargon that?
Re: (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 g
Re: (Score:2)
It's also the sound my toilet makes when I flush.
How long each deliverable will take (Score:3, Insightful)
The top 12 techniques that are used in real life:
Re:I bought Microsoft Project a while back (Score:4, Insightful)
MS Project paves the way to waterfall projects, mainly because most managers don't understand iterative development.
Parent
Re:I bought Microsoft Project a while back (Score:5, Insightful)
MS Project paves the way to waterfall projects, mainly because most managers don't understand iterative development.
I'd say the problem is more general: most business people don't understand iterative development. They want hard deadlines and schedules and guarantees, even though software development doesn't really work that way.
Essentially, they stick their heads in the sand and want software development to be just like manufacturing.
Give most businesses a choice between a waterfall development PM and an iterative development PM, and they're going to pick the waterfall guy because he's willing to give them a (probably very inaccurate) deadline of when the whole giant project will be done.
Parent
Re: (Score:3, Insightful)
Iterative development does not exclude deadlines. The main ideia is that you have to constantly review your plans, adjust to new information, and incrementally build your understanding of the product as well as the product per se. Of course some managers prefer to just lay the plan down and shout at you until you make it happen: it is easier for them not to have to think and replan all the way. I like to emphasize the point that your understanding of the problem at hand evolves along with the project. Build
Re: (Score:3, Insightful)
I don't know why iterative development excludes deadlines.
It doesn't. Depending on your implementation, of course.
Some approaches to iterative development have features but no deadline. The project is done when all the features are done, and no sooner. Tools give you projections on when that will be.
Other approaches to iterative development have deadlines but no features. Or rather, no guarantees of what features will be available by that deadline. This is sometimes called "time-boxed development." Yo
Re: (Score:3, Insightful)
No; managers who do not understand iterative development pave the way to waterfall projects. Sometimes those managers use MS Project.
Re: (Score:3, Insightful)
If your knowledge is incipient and your tool provides an inadequate abstraction, you will veer towards bad habits. If you're good at OO, you can do it even in Perl. But if you're not, you will probably get some nasty habits.
Re: (Score:2, Insightful)
Yeah. One time I bought QuickBooks, and it wanted me to create a bunch of accounts and set up transactions and everything. Hell, if I knew anything about accounting, I wouldn't need accounting software.
Tools are sometimes designed to be used by professionals, as a means of them doing their job; not as a substitute for professionals with a 95% accurate wizard.
Re: (Score:2)
Agreed, because it's very easy to throw around project managment buzzwords and terms, but at the end of the day project management is real work requiring real skills.
Many people have low opinions of PMs, but once you work with a skilled one the difference is obvious.
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.
M
Re: (Score:2, Insightful)
"Project manager" and "Architect" are mutually exclusive. You can't be an expert in both, let alone have the time for both.
Regards,
Re: (Score:2)
I am a project manager employed at an architecture firm who is also a licensed architect. I guess if you wanted to be anal about it, and it would seem so i would be a project architect.
Many companies are based on different team members all functioning at different levels. On any project it is possible to have licensed architects acting as designers, project managers, construction administrators, specification writers, you name it. It's a matter of what the project calls for and what your specific expertise
Re: (Score:2)
Yes. As a Solution Architect that is responsible for the success of my projects I can.
Regards,
Re: (Score:3, Insightful)
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.
Ok, change the job titles to any you like and you have defined the (IMO) basic problem of a project manager. Technical politician == project manager?
Succinctly well stated.
Re: (Score:3, Insightful)
I'm a couple years into my architecture career, and I've been working at a firm where there's basically zero organization. What that means is that everyone gets put in charge of their own projects and is basically left to fend for themselves (even the summer interns.) It's a very inefficient and strange way to run things, but somehow the guy running the firm has run it that way for decades and still manages to get tons of work, so he'll probably never change.
But I'm not going to refute your point, my experi
Sad but so true (Score:2)
The sad part of my exposure to project management as it applies to Software development is that any project large enough to require use of a project management approach is destined to fail simply because of its size.
Re: (Score:2)
Re: (Score:3, Insightful)
Large software projects can succeed but they require
1) A PM experienced in software development
2) Good communication and trust between the PM, the developers and the client
3) Support from management, especially in making the correct resources available to the project at the correct time
In my experience the two most common factors that contribute significantly to the failure of a project is poor specification and constraints exerted by the rest of the business on key resources.
Something they rarely teach managers (Score:5, Insightful)
Know when to cut your losses if you can. I used to work for a team that managed a component used by several projects at a large client, and one of those projects was run by a real textbook case of a nearly psychotic bully. After a while, my management decided that the pay wasn't worth the damage he was doing, and pulled our people off the contract.
Our management was smart because they actually gauged the cost-benefit ratio of keeping our people on that contract and realized that yes, numbers might go up for a quarter or two, but employees would start leaving, and that would be worse for business than dropping the contract.
Re: (Score:3, Informative)
Re:Something they rarely teach managers (Score:4, Insightful)
Parent
Project Management is..... (Score:5, Funny)
Re:Project Management is..... (Score:5, Funny)
Parent
Re: (Score:2)
Most of the readers don't know what to do with a single woman, let alone 9 of them at the same time!!!
Re: (Score:2)
The downside to this methodology is that you have all the fun at the beginning and then you are REALLY screwed.
Re: (Score:2)
No, those are the accountants/bean counters. Project managers are the ones who try to actually GET 9 women to make one baby in a month, because their PHB said do it.
The Two Key Project Management Thingys (Score:5, Informative)
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...
The term "Project Manager" has has been corrupted (Score:3)
There are (at least) two definitions for "Project Manager". One definition is what we would like the term to mean. The other definition is how most others use the term. The term "Project Manager" has has been corrupted, like "Engineer" and "Hacker".
In the non-slashdot world....
1. An engineer could be a person to cleans toilets (building engineer or sanitation engineer).
2. A hacker is a person who engages in fraud and who uses a computer.
3. A project manager is an administrative assistant who distributes schedules, meeting minutes, and status reports.
I've only worked in one company that did not use definition #3. All other corporations where I've worked have used definition #3. There was even one company that asked that a new hire have a PMP. But the actual work they did was definition #3. They only managed paper, not people or money.
Re: (Score:2)
Re:first post (Score:5, Funny)
Phase 1: Uncritical acceptance.
Phase 2: Wild enthusiasm.
Phase 3: Dejected disillusionment.
Phase 4: Total confusion.
Phase 5: Search for the guilty.
Phase 6: Punishment of the innocent.
Phase 7: Promotion of nonparticipants.
Parent
Re: (Score:2)
On the PM note, our CIO likes to think of himself as a PM, what with his MBA and all, but I wouldn't put him in charge of taking care o
Re: (Score:3, Funny)
"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."
Of course that happens only when you use Vi. Try Emacs instead.
Re: (Score:2)
On my current project they have picked zero.