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.
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.
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.
Re:I'm a Project Manager .. (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:I'm a Project Manager .. (Score:3, Insightful)
Succinctly well stated.
Comment removed (Score:5, Insightful)
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.
Re:I bought Microsoft Project a while back (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: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.
Re:I bought Microsoft Project a while back (Score:3, Insightful)
No; managers who do not understand iterative development pave the way to waterfall projects. Sometimes those managers use MS Project.
Re:project management is more like "time accountin (Score:2, Insightful)
Re:I bought Microsoft Project a while back (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: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.
Re:I bought Microsoft Project a while back (Score:1, Insightful)
Re:Sad but so true (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.
Re:Is this (Score:2, Insightful)
like the Cliffs Notes for the PMBOK [wikipedia.org]?
Re:I'm a Project Manager .. (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 experiences actually reinforce it. The first project that I was in charge of (started less than 6 months into my architectural career)was an absolute nightmare for me. The biggest problem that I had was in terms of understanding the process. That's something that you can't just sit down and figure out, no matter how many hours you put into it, it's something that can only really be learned through experience. I think it's even more of an issue for architecture than it is for something like your average software project, because there are a lot of very specific hoops that a building design has to go through in terms of government regulations/building codes/etc. Lots of little things that aren't necessarily hard to deal with, but if you don't know that they're an issue and don't deal with them at the appropriate time, you're going to have some serious headaches somewhere down the line.
It was a ridiculously stressful experience for me, and while I learned a lot, I feel like I learned more about how not to do things, instead of how to do things. That's bad, because while there might only be a few or even one right way to do something, there's usually thousands of wrong ways to do it. So I'll just make a bunch of different mistakes next time.
The other thing that you're spot on about is the ability to make assertive decisions based on experience. Lacking in experience, I was very reluctant to make decisions on many issues, and you can be sure that the contractor could tell I didn't know what I was doing. Many more headaches resulted from that.
I've read articles and interviews of college kids where they say that they were hoping to get a job as a consultant. I can't imagine why anyone would want to consult with someone who just got out of college.
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 to take away useless task and decisions allowing you to do what you do best as a team member.
Re:I bought Microsoft Project a while back (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. Building software is a creative process all the way, so it makes no sense to make all your plans upfront. Nobody tells an architect when to have the design for the doors, and then when to have the designs for the windows, then the bathroom, etc, etc.
Re:Something they rarely teach managers (Score:4, Insightful)
Re:I bought Microsoft Project a while back (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." You say, "Ok, we will definitely spend the next three months working on that. We will give you a release on exactly that day. What will be in the release is whatever we managed to get done in those three months."
What iterative development does not give, when done properly, is both a committed list of features and a hard deadline. Why not? Simple: because in the vast majority of cases, a team will fail to deliver on these promises. This is largely due to a lack of process control (features changing during development, making the release an impossible-to-estimate moving target), misestimation, and discoveries (now that we have written this exactly to spec, we can clearly see why it utterly sucks, and why we need to change it all around right now).
I have had many conversations with executives/managers who say, "ok, this time, let's make sure not to change the requirements once we get started, and to put a lot of effort into our estimates to make them accurate. If we do that, we can have commitments on both features and deadlines, right?" And then, despite these promises, the requirements change anyway, the estimates turn out to be inaccurate, and the deadlines are missed, and everyone is upset.
If you are in an environment like this, it is better to not make promises, than to make promises and break them. Sell up the adaptability of your design process (sure, we can throw in your new idea right now!) as the benefit that justifies the lack of hard-and-fast promises of both features and delivery dates.
How long each deliverable will take (Score:3, Insightful)
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.