What do you think?
Rate this book
Guerrilla Project Management
A Fast, Flexible Approach to Managing Any Project — Right Here, Right Now!
To manage effectively in today's complex project environment, you need a framework of project management (PM) competencies, processes, and tools that can be put to use immediately and that flexes and scales to meet the needs of any project.
In Guerrilla Project Management, Ken Hanley emphasizes key project management competencies, including managing stakeholders effectively, assessing risk accurately, and getting agreement on the objective measures of project success. Focusing on these and other competencies as well as effective PM processes and tools, Hanley presents an alternative approach to project management that is light, fast, and flexible — and adapts readily to the many changes every project manager faces.
Offering tips and techniques on topics ranging from communication and reporting practices to risk mitigation, this practical book is organized to allow readers to work through all aspects of a project or quickly find answers to specific problems.
This is the go-to guide for today's nimble project manager!
To manage effectively in today's complex project environment, you need a framework of project management (PM) competencies, processes, and tools that can be put to use immediately and that flexes and scales to meet the needs of any project.
In Guerrilla Project Management, Ken Hanley emphasizes key project management competencies, including managing stakeholders effectively, assessing risk accurately, and getting agreement on the objective measures of project success. Focusing on these and other competencies as well as effective PM processes and tools, Hanley presents an alternative approach to project management that is light, fast, and flexible — and adapts readily to the many changes every project manager faces.
Offering tips and techniques on topics ranging from communication and reporting practices to risk mitigation, this practical book is organized to allow readers to work through all aspects of a project or quickly find answers to specific problems.
This is the go-to guide for today's nimble project manager!
236 pages, Kindle Edition
First published December 28, 2010
2 people are currently reading
9 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
Read
June 8, 2011Guerrilla Project Management by Kenneth T. Hanley
love deadlines. I like the whooshing sound they make as they fly by.
Douglas Adams
Yes, I know that your sponsor has an end date in mind already. And yes, I have worked on projects for which the end dates just couldn’t move. Sometimes they’re legislated, sometimes they just “are.” For example, the Winter Olympics were scheduled to begin in Vancouver on February 12, 2010, and that date would not be moved under any circumstances. But just because you have a date doesn’t mean that the implications of that date have been thoroughly thought through. Accepting a date before figuring out the implications for project performance (scope and quality) and budget borders on the irresponsible. Sure, there are times when you’ll have to back into a project date, but that date should never be a part of your first-cut or original plan. Working to a date before anything else has been looked at leads to outrageous optimism.
I saw it in spades a couple of years back with a group of my students at the University of Calgary. It was late April, and the term was almost done. The class? A very bright group all in all: 24 students, all with solid PM backgrounds, half of them working on graduate degrees. I broke them up into three groups of eight, then pulled the first group of eight aside and handed them a fairly detailed statement of work (SOW) for a fictitious project. I also gave them their resource load, detailing how many of each type of person was available to work on their project.
“It’s late April,” I said to the first group, “and I’d really like to see this project wrapped up by the end of September, if possible. Build me a schedule for class next week, using the resources I’ve laid out, that shows me how to get the thing done by the end of September.” Then I paused. “Keep in mind that I’m a reasonable man, and if you think it can’t be done by the end of September with the scope as defined in the SOW and the resources I’ve laid out, let me know. As my old prof used to say, “‘If you have to eat crow, eat it when it’s young and tender.’” And I sent them on their way.
Then I huddled with the second group of eight. What they didn’t know was that I was giving them exactly the same statement of work and exactly the same resource load that I’d given the first group. “It’s late April,” I said, trying to keep things as similar as possible, “and I’d really like to see this project wrapped up by the end of November.” Same assignment as before: “If you can, build me a schedule for class next week, using the resources I’ve laid out.” I also gave them the same “I’m a reasonable man” line, and the “eat your crow when it’s young and tender” line, and I sent them on their way, too.
Then, over to the third group of eight—you see where I was going with this, don’t you—where I gave the same statement of work and the same resource load. But I gave this group the requirement of finishing by the end of January the following yearand thesame “I’m a reasonable man, and let me know if the requirement is unreasonable” speech.
So what do you think I got back from those three teams the next week in class?
The end of January group: “We looked at it really closely,” they said, as they handed me their Gantt. “It’s going to be tough, but we think we can just make it by the end of January—nine months—with this plan.”
And then the end of November group: “It’ll be really tight,” they said, “but we figure we can just make it with this plan.” And they handed in their Gantt.
The end of September group?: “It’ll be tough, but we think we can just it squeeze it in.”
And that’s the outrageous optimism of forward-based planning in its full lack-of-glory. With an arbitrary end date, it’s amazing how unrealistically optimistic people can really be.
There’s something really powerful about taking a piece of paper with a set (that is, set before anyone has done any planning) end date written on it and then crumpling it up and throwing it over your shoulder with the entire project team— and your sponsor—in the room watching. This isn’t meant to be disrespectful of a required end date (and you may want to be a little less dramatic), but it is intended to demonstrate a key element in the thinking of the best PMs: The first cut at a project plan should never be end-date constrained. Instead, it should be about:
What needs to be done
How we’ll measure success when we’re done
What resources we have available to get it all done.
Then—and only then, because making decisions about these three elements takes quite a bit of time and thinking—will we try to determine if what we need to do and the resources we’ll have to do it with are compatible with the end date we’ve been given. And if it doesn’t fit, then we can take a disciplined—not outrageously optimistic—view of what needs to change to allow us to make the necessary end date.
What adjustments can we make to resourcing (and, therefore, budgets) to speed us up?
Which of our “done” or “won” conditions (see Chapter 9) can we pull off the table or out of the project to help us make the required end date?
Are there performance compromises (a reduction in scope, quality, or both, perhaps) we can make that’ll allow us to hit the required date?
Sure, end dates are important, and they’re sometimes established before you know what you’ve really got to do to make the dates. But they’re very often arbitrary and badly misused, and thinking PMs never start their planning from them.
<< Previous Top of page
love deadlines. I like the whooshing sound they make as they fly by.
Douglas Adams
Yes, I know that your sponsor has an end date in mind already. And yes, I have worked on projects for which the end dates just couldn’t move. Sometimes they’re legislated, sometimes they just “are.” For example, the Winter Olympics were scheduled to begin in Vancouver on February 12, 2010, and that date would not be moved under any circumstances. But just because you have a date doesn’t mean that the implications of that date have been thoroughly thought through. Accepting a date before figuring out the implications for project performance (scope and quality) and budget borders on the irresponsible. Sure, there are times when you’ll have to back into a project date, but that date should never be a part of your first-cut or original plan. Working to a date before anything else has been looked at leads to outrageous optimism.
I saw it in spades a couple of years back with a group of my students at the University of Calgary. It was late April, and the term was almost done. The class? A very bright group all in all: 24 students, all with solid PM backgrounds, half of them working on graduate degrees. I broke them up into three groups of eight, then pulled the first group of eight aside and handed them a fairly detailed statement of work (SOW) for a fictitious project. I also gave them their resource load, detailing how many of each type of person was available to work on their project.
“It’s late April,” I said to the first group, “and I’d really like to see this project wrapped up by the end of September, if possible. Build me a schedule for class next week, using the resources I’ve laid out, that shows me how to get the thing done by the end of September.” Then I paused. “Keep in mind that I’m a reasonable man, and if you think it can’t be done by the end of September with the scope as defined in the SOW and the resources I’ve laid out, let me know. As my old prof used to say, “‘If you have to eat crow, eat it when it’s young and tender.’” And I sent them on their way.
Then I huddled with the second group of eight. What they didn’t know was that I was giving them exactly the same statement of work and exactly the same resource load that I’d given the first group. “It’s late April,” I said, trying to keep things as similar as possible, “and I’d really like to see this project wrapped up by the end of November.” Same assignment as before: “If you can, build me a schedule for class next week, using the resources I’ve laid out.” I also gave them the same “I’m a reasonable man” line, and the “eat your crow when it’s young and tender” line, and I sent them on their way, too.
Then, over to the third group of eight—you see where I was going with this, don’t you—where I gave the same statement of work and the same resource load. But I gave this group the requirement of finishing by the end of January the following yearand thesame “I’m a reasonable man, and let me know if the requirement is unreasonable” speech.
So what do you think I got back from those three teams the next week in class?
The end of January group: “We looked at it really closely,” they said, as they handed me their Gantt. “It’s going to be tough, but we think we can just make it by the end of January—nine months—with this plan.”
And then the end of November group: “It’ll be really tight,” they said, “but we figure we can just make it with this plan.” And they handed in their Gantt.
The end of September group?: “It’ll be tough, but we think we can just it squeeze it in.”
And that’s the outrageous optimism of forward-based planning in its full lack-of-glory. With an arbitrary end date, it’s amazing how unrealistically optimistic people can really be.
There’s something really powerful about taking a piece of paper with a set (that is, set before anyone has done any planning) end date written on it and then crumpling it up and throwing it over your shoulder with the entire project team— and your sponsor—in the room watching. This isn’t meant to be disrespectful of a required end date (and you may want to be a little less dramatic), but it is intended to demonstrate a key element in the thinking of the best PMs: The first cut at a project plan should never be end-date constrained. Instead, it should be about:
What needs to be done
How we’ll measure success when we’re done
What resources we have available to get it all done.
Then—and only then, because making decisions about these three elements takes quite a bit of time and thinking—will we try to determine if what we need to do and the resources we’ll have to do it with are compatible with the end date we’ve been given. And if it doesn’t fit, then we can take a disciplined—not outrageously optimistic—view of what needs to change to allow us to make the necessary end date.
What adjustments can we make to resourcing (and, therefore, budgets) to speed us up?
Which of our “done” or “won” conditions (see Chapter 9) can we pull off the table or out of the project to help us make the required end date?
Are there performance compromises (a reduction in scope, quality, or both, perhaps) we can make that’ll allow us to hit the required date?
Sure, end dates are important, and they’re sometimes established before you know what you’ve really got to do to make the dates. But they’re very often arbitrary and badly misused, and thinking PMs never start their planning from them.
<< Previous Top of page
Displaying 1 of 1 review