Slashdot Mirror
The Principles of Project Management
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.
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
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.
See also: The Mythical Man-Month by Fred Brooks.
like the Cliffs Notes for the PMBOK?
That then leads to what exactly is a "project": a set of tasks with a time-frame and goal of somehow adding value.
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.
ZuluPad, the wiki notepad on crack
It seems to make more sense to me when I think of project managers as time accountants. They have time budgets and scopes and reports and things that relate along the lines of a financial manager running a business.
Only Project Managers have completely different names for those things, but the better ones do a lot of time reporting and time budgeting.
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.
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.
Request your free CD of my piano music.
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.
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.
Sig Battery depleted. Reverting to safe mode.
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.
the technical discipline that tells us that nine women can make a baby in one month.
None of them can see the clouds; The polished wings don't care.
Obligatory Dilbert:
http://books.google.ca/books?id=0qmO19BnQk8C&pg=PA73&lpg=PA73&dq=dilbert+project+management+zombie&source=web&ots=xdbnRLJusA&sig=kZuXH1Iq6zqTRyNHzF4w0vkniqs&hl=en&sa=X&oi=book_result&resnum=1&ct=result
Seriously, been to some training. Project Management Center of Excellence and Body of Knowledge and PMBOK sound a lot like the "Montgomery Burns Award for Outstanding Achievement in the Field of Excellence award"
Sad thing is if I want to make more money it seems pretty much a necessity.
Remember when using a shovel aim for the head!
I forgot if I am talking about the Zombie or myself.
Focusing on time alone can lead you in the wrong direction. PMI offers some free information on their website on Project Management (pmi.org) that can help you get some hand on PM from a general overview perspective. It's about managing all resources, not just time or money and ultimately PM is about efficiency. Time is just one piece of the puzzle. One project can be closed ahead of schedule and be crap at the same time.
I'm a program manager, so that's like totally different.~
Invenio via vel creo
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
PROJECT PHASES:
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.
You may have your project completed (pick two):
1. on time;
2. on spec;
3. within budget.
"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."
With a comment like that, I would hate to see the kinds of projects you've worked on. They must have been total chaos. Tell me, did they ever ship? If so, how bad was the quality? How far over budget was it?
Everyone in my company knows what a Project Manager does. I can't imagine running a project without one.
...you mean PM's do more than ask "Are you done yet? How about now? Now?"
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.
From long experience, I can say that there are two things to do which get products out on time: 1) Pare requirements to the absolute minimum. Decide which features are required, and which are nice to have. And forget about the latter. (The engineers will stick some of those in on their own, according to their passions). 2) Keep everyone working in parallel. Ferret out any situations where someone is waiting for something, and eliminate those. And you'll see that in many cases those "waiting" scenarios indicate more serious misunderstandings about who is doing what.
I'm a Comm project manager for the air force (3C351) and let me tell ya with the way the military operates we are the unnecessary middle man in the process...truly truly a shitty job
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 under and side-by-side project managers who use the time data well. These have tended to be with managers who really understood what their staff were working on, and would step in to improve performance when tasks began looking like they would run over budget.
Sometimes this meant coaching (and/or training) staff, sometimes it meant reassigning tasks, sometimes it meant replacing incompetent resources.
I'd just like to add to your point about time reporting and time budgeting -- this only works well if the time budgeting is done well. Someone who cannot budget well will never be able to use time reporting well. Without good milestones/goalposts/need assessments/whatever, it is impossible to use reporting to assess progress.
To sum up, it's not just competent budgeting & reporting that are necessary, but also a good understanding of how to interpret the numbers and apply fixes. I believe this is something very hard to learn other than by experience (both working under a good PM and getting a chance to make your own mistakes as a new PM).
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
Please replace Phase 5: Search for the Guilty, with Witch Hunt. I've always found that title more appropriate.
A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort.
The triple constraint is Time/Cost/Scope. Any one of them alone means little in formal project management.
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
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 to take away useless task and decisions allowing you to do what you do best as a team member.
"The Nemesis function used to be handled informally. Now it's a profession, kind of like Project Management."
http://dilbert.com/strips/comic/2006-08-12/
Really...there are not literally tons of books about this subject. Really...there are not numerous certifications for Project Management. Blank stares from some maybe, but really...this is presented as a topic that is breaking ground? Really.
In the modern uber large multinational large cap corporations, project management is actually done by a bunch of people. 1 guy manages the workers. 1 guy manages the schedules. 1 guy sells it to the customer. Insecure guys at the top hire more & more mediocre managers to pass the blame on to so it is more finely broken up over time.
So I've read through many of the comments and have a few thoughts regarding them. My background comes from being a BA transitioning into a PM. I also have the PMI certification.
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...
Time accounting for a project is data collection, that's it. Technically, all accounting is just data collection.
That's not been my experience. As a former PM for a construction management firm, specializing in IT buildouts, I found that dealing with time frames were more about site-adjustment to new and unexpected things.
For example, the contractors labor who is putting in all the ethernet drops all decide at once to take off without telling their boss to Mexico to be with their families for some reason. Or there's a bad storm, and the person who is supposed to install the racks doesn't show up, so when the hardware vendor comes in the next day, he has nothing to put the machines in.
Stuff like that. (Countless other things). The PM has to deal with all this crap, and still try to figure out how to get everything done on time, which often is impossible.
You can yell and scream at the contractors/vendors all you want, but it won't change anything. You can deal with change orders which are so vague as to grant the vendors license to bill you up the ass, and when you balk and demand specifics they delay things even more, you can do all of that and it still doesn't change the fact that ultimatly your job is to explain to your client that it's not going to be on budget, on time, and to their specifications. At this point, the PM has to sit back and give the owner at least something that works.
Then again, I was never a very good PM.
The Internet is generally stupid
In my experience, Phase 7 all too often depends on the success or failure of the project.
If the project Succeeds: Promotion of nonparticipants.
If the project fails: Promotion of the responsible parties.
Odd, that...
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.
Ok the time management side of project management is like computer science 101. The important part is communication, communication, communication and a little more communication. The other part of project managers job is process. Make sure that there is a process and that it is well understood by all involved with the project.
Alot of the communication goes along the lines of
- Dealing with difficult customers.
- Dealing with difficult developers.
- Dealing with difficult line managers.
- Dealing with difficult subject matter experts.
- Dealing with difficult testers.
In my experience the major tasks involved with "time accounting" can and maybe should be delegated.
Counting beans (time or money) isn't that hard. It's the people skills or lack thereof that seem to make or break most projects. Thus "Wheel Greaser" is the way I've come to think of the good project managers I've worked with. "Keeping It Smooth" shouldn't be a chapter. It's a fundamental aspect of every part of a well run project. Projects are just that, projects, it's the people that need management, they're usually from many departments, don't get paid based on the project, and are usually putting up with the project manager as a "second boss".
It's unfortunate, but the accountant types usually run miserable projects while the diplomat types actually get people to come together and get real work done.
Operator, give me the number for 911!
Followed by: "Yeh, I dropped of school/college because there was nothing they could teach me about programming".
Yup, the software world is special - Big Yellow Bus Special.
Yes I realise this is a broad brush and some pax have read Brooks etc. But then we still get fundemental project management and systems engineering niches reinvented every few years as "Xtreme" or "Agile" or some other crap.
-- Butlerian Jihad NOW!
I see where you're coming from... but time accounting is what I was referring to... which doesn't have much to do with putting out fires :)
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
Action Item!!! - Professional Superhero!
That is all.
Well, that criterion rules out 99% of the projects I've ever worked on then.
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.
Um.Sorry to say this, but this should probably be moderated +5 insightful.
Recent bad experience, you see....
Completely different approach to project management, genius-level guy at thinking through business processes from fundamental principals.
"Critical Chain" is written as a novel, there is a technical book behind it, I believe. He sold 2M copies of his first novel, the one about "Theory of Constraints".
These are important books, I learned a lot about OS scheduling problems from TOC.
I'm there right now. You just have to find the right leverage points to move things along and accomplish the goals while letting the various Lords Of Creation do their thing and have their ego games. For instance my immediate Celestial Being Above Me doesn't even want to think about the budgets, so I do all of that and can make quite a lot happen by skillfully pointing out salient financial facts as they relate to goals and timelines. You have to swallow your ego on that kind of project, but it is possible to guide it all the same.
I'd say that Project Management involves juggling three things - Schedule, Scope and Budget (think of it as a triangle).
It is common to include a fourth factor, quality - thus making it a pyramid.
I'd say that Project Management involves juggling three things - Schedule, Scope and Budget (think of it as a triangle).
Actually, you also have to factor in blame so it really becomes a time cube (original seems to be offline).It is common to include a fourth factor, quality - thus making it a pyramid.
May contain traces of nut.
Made from the freshest electrons.
Quality, for all intents and purposes, falls under scope.
Increased quality implies increased diligence, increased QA and consequently, more to do.
This would need more money, more time etc.
The top 12 techniques that are used in real life:
The things all these have in common are:
So what happens is everyone attempts to "negotiate" the length of time something will take, rather than realizing that it's not something that is negotiable. If it takes X time, it takes X time, all things remaining equal.
That old saw - "price | quality | speed - pick any 2" was optimistic. Going too fast inevitably results in both lower quality and higher costs down the road, as bugs that aren't fixed at an earlier stage end up being either more expensive to fix, or show-stoppers. Planning for quality initially takes more time that *seems* unproductive to *cough* "certain types of people" *cough* but it's also, in the end, cheaper, and quicker. Problem is that too many people think that development is just "throwing code together, finding and fixing the bugs, and deploying".
"Price, quality, speed" - either expend the time to get high quality, or you'll waste money and any speed gains are temporary at best. Instead of cutting quality, cut feature scope, and kill off any attempts at feature creep - that's where the biggest problems are. If whoever is managing the project hasn't got the backbone to do that, they deserve yet another death march.
(Ted Kozman was the PM for the Texas Superconducting Supercollider, as well as a few NASA projects, before I ran into him as a Project Management professor in grad school)
"There has never been a successful project."
His point was that once the real world has intruded on the schedule/scope/budget, then the project has failed. Finished too fast? Your schedule was bad.
Mujadaddy's Corollary to Kozman's Rule:
"...except the second Death Star."
Populus vult decipi, ergo decipiatur...
"Force shits upon Reason's back." - Poor Richard's Almanac
Good, fast, or cheap- pick any two.
Working for both small and large companies over the last 20 years, I've noticed that the first victim of any project is proper project management (the second being proper QA). As a coder who frequently finds them self in this situation, I marked down the 12 steps that *every* software project will go through one way or the other. The difference between a successful project and a clusterfuck - usually boils down to doing them in the correct order the first time. They *will* be done in this order eventually; but you can save a lot of time and aggravation by doing them in this order to begin with.
Consider this the "cheat sheet" for projects with inadequate management:
1. Define the purpose of the application.
2. Define the functions a features of the application.
3. Develop a top level plan for developing it.
4. Create the database schema for storing the necessary data.
5. Create detailed mock-ups of the finished application.
6. Have those mock-ups approved by the people who will be using it.
7. Develop the exact interfaces that will be needed for all objects used in the application.
8. *Then* code the classes for the objects (this is the part we always like to start with)
9. Code the classes into the GUI.
10. Test and debug.
11. Have your QA process approved and signed off on by the client/users.
12. Deploy.
I know this seems simple, but seriously, try to think of any scenario where you could switch *any* two of these steps around and not risk wasting time and effort. It can't be done. I know - I seen very, very talented people try. Look at any successful project you've ever been on, and you'll see that - while there may have been valient attempts to do these things in different orders, or skip steps - in the end a successful project will have gone through all these steps, in this exact order. Even if things steps had to be repeated because they were taken prematurely.
BTW, this is a very, very boring way of approaching development. Nothing exciting happens until step 7, and by that point it's so obvious what should be done that there's no sense of adventure left. I rarely concede this fact myself unless I have a mission critical project with an unmovable deadline.
A good project manager knows how to get a client to focus and communicate (when they'd rather talk about their "vision"), limit the scope of each phase of development, work with clients to help them fully understand their options and the ramifications of each one, and to keep moral and enthusiasm high during the boring or tedious bits. But follow these steps even without proper management, and you will at least be assured of not wasting time in any aspect of the development process.
Enjoy.
My company doesn't want clients without a corrupted definition of project manager to think that I will go above and beyond distributing schedules, meeting minutes, and status reports so my job title is now Project Coordinator.