Berkun reading group discussion
MakingThingsHappen
>
Chapter 1: Discussion and Questions
date
newest »
newest »
message 1:
by
Scott
(new)
Mar 07, 2015 11:11AM
Mod
reply
|
flag
When I first read The Art of Project Management (which tells you how long ago it was, before it was Making Things Happen) I remember being so relieved because you were saying that project management could be different. It could be about more than tools and arbitrary schedules.Do folks feel that things have changed in the intervening decades? Are corporations more thoughtful about project management than they used to be?
Mod
I still think the human element is too often disregarded, in favor of tools and methods, but that perhaps reflects culture at large.
I still like much of chapter 1. The sections on history and the balancing act are my favorites. Do you folks think those ideas have held up?
I have reread chapter 1 yesterday and I also loved it all over again :) Yes, those ideas are still essential -- I am a BA now and I can see, when I am in a project managed by someone else, how all those aspects are still sadly disregarded most of the time. Makes me want to go back to project management :)
Mod
I found it entertaining that I referenced the pyramids as we're *still* not sure how they built them, nor how that project was managed.
I have two questions: 1) do you have any experience of differences in PM attitude in the public vs the private sector? (I know it's unlikely for you but I work in higher education and anecdotally I have seen a lot of difference). 2) What are the pros and cons of having resident PMs vs contractors? (another sore point where I work)
Mod
1) The public sector is generally more process oriented and bureaucratic. There is also more respect for tradition - that because things were done one way in the past they should always be done that way. But the public sector is often more willing to invest long term. The private sector is the opposite - more room to try new things, less fondness for tradition, and far worse at investing long term.
Those are sweeping generalizations of course - every industry is different - but that's what comes to mind.
2) Contractors always have less political power. The upside is they can be hired to focus on a tactical thing and work independently. The downside is when they are used on strategic work (often because they are cheaper) they don't have the authority and support to make that strategy happen. You can end have an endless revolving door of contractors continually failing because they really need to have a staff role to do the job. Of course a great manager hiring a PM contractor can make sure they have the influence and power they need to do the job well.
The key lessons from history, especially #2, really resonated with my experience in IT:1. PM and software dev are not sacred arts.
2. The simpler your view of what you do, the more power and focus you will have in doing it.
3. Simple doesn't mean easy.
Anyone that works with PMs (team members and sponsors/clients) should have more appreciation for how tough the role is after reading the balance/paradox section.
My big starred quote from this chapter is: "Confusing processes with the goals is one of the great sins of PM." It's echoed throughout the rest of the chapter. Shiny tools and methodologies always tempt us with panacea marketing, but as the next chapter brilliantly states, "the belief that what really matters is the technology..." worsens the team's culture.
As a gadget and software person, it is disheartening to read this, but I know it is true based on time with many different teams. I wish our tools were better. I wish all team members came to projects with an understanding of how to participate in projects. But that's all wishful thinking for some far-off future time. To accomplish progress today, the team has to be *led* by someone that understands the project, the people involved and can act to bring all the disparities to the surface to be ironed out.
Mod
The sacred thing still drives me crazy. I can't stand pretense: yet management and engineering have an abundance of it. I love people who let their work speak loudest and can laugh about themselves and their profession. They're more likely to be open to new ideas and to admit when they've made a mistake: two huge assets for teams and projects.
Process vs. goals is a core part of most of the Agile processes. Do you have experience with them? On average I think they're better, but any idea can be beaten to death by a suitably moronic manager.
Gerald Weinberg was a big influence on me. He's one of the few voices in this whole domain that emphasized it's really about relationships, not processes and not tools. Peopleware by Demarco is another rare voice of sane human centricity.
I loved Peopleware too and I didn't know of Gerald Weinberg... which of his books would you recommend?
Also, would you or others like to share an example of when their project team / single team members were reluctant to accept you as PM or even openly hostile, and what you did in that situation?
Mod
On Weinberg:
if you do any kind of spec or requirement writing:
http://www.amazon.com/Exploring-Requi...
If you're interested in being a better thinker / decision maker:
http://www.amazon.com/Are-Your-Lights...
If you work with technical people and want to understand their psychology: http://www.amazon.com/The-Psychology-...
Thanks for this. The first two sound great and the third one might actually make me understand better why I failed to become a great software developer :)
Finished re-reading Chapter 1 on a flight on Sunday. So many dichotomies to keep track of, yet they all ring true. I'm glad to be reminded that it's all about people - without humans, the projects simply don't happen. No level of PM-software-goodness will overcome that fact, and I'll take a cohesive team with a clear goal and no Gantt charts over an overmanaged team of misfits with plans-a-plenty and no direction.
Mod
Mod
Howdy,Two parts of Chapter one stood out for me.
Like Kye the "processes vs goals" grabbed my attention. While I agree with Scott that Agile methodologies have made this less painful I think it's still a problem. People in our world get fixated on our approaches, like you and your todo lists (and me with task tracking systems). I think this one is easily coached if a good leader/boss is paying attention. Sadly I think that's rare.
The second was the balancing act section. *Loved it.* A bunch of times I've been coaching a new leader and tried to communicate this. Poorly. There are many reasons the transition from an individual contributor to a leader is tough and you've nailed a bunch of them here.
I enjoyed the section on creating an environment that can discuss and confront failure openly, instead of denying and hiding from it. I loved what Boeing did - create a black book of design and engineering failures for future generations.What's an effective way to hold a meeting to discuss project failures? I think you would need to have a leader that can break the ice by saying the mistakes that he made on the project.
Scott wrote: "I still like much of chapter 1. The sections on history and the balancing act are my favorites. Do you folks think those ideas have held up?"..."
Yes, the ideas in chapter 1 have held up. The balancing act section reminds me of the wheel of life. Sometimes you need to take a look from 10,000 feet, so that you can bring things back into balance. I'm going to try to take a step back and look at my last several projects and assess what's off balance.
Hi Scott. Thanks so much for doing this. I think this is a great idea and am looking forward to seeing what comes out of this.One of the things that stood out for me was that you referred to Atul Gawande (Page 7) who wrote "The Checklist Manifesto" (Although, not at the time this book was published) and later on in the chapter you speak against having too many checklists.
What are your thoughts on this dichotomy? Has your thoughts around checklists changed? Do you feel that a certain amount of checklists are helpful, but too many creates diminishing returns? Have you found a mental model around checklist this helps you identify when you should have one and when it is really necessary?
I ask because checklists are supposed to help us deal with complexity, and provide a system where we can incorporate the lessons we have learnt from our mistakes. But I this the warning here is against becoming a "checklist manager" as opposed to a "project manager".
So admittedly, I have never worked in any field that has actually used the PM framework, but like many people I have found myself as a project manager in numerous environments. I really appreciated your discussion of Tom Peter's dichotomies that are often part of the PM process. Further, I think that you make some important points about learning from those in other fields about how they function without explicitly pushing that point.
Another nugget that stuck out to me in this first chapter was the reality that great workers, don't always make good managers - too often we promote people out of their area of specialty and effectively hamper a team or organization in multiple unexpected ways.
Mod
Mod
On bad managers - Automattic, where I worked for a year to write The Year Without Pants, doesn't pay team leads any more than individuals. They wanted to remove the financial incentive so that only people truly interested in leading take on the role. It's an interesting idea:
http://scottberkun.com/2014/what-if-m...
Scott:That is a great concept that frees us up to be specialists or generalists based on our skillset, not a simple monetary platform.
As always, your thinking is greatly appreciated!
TG
Ravi asked what's an effective way to have a meeting about project failure?Taking the Agile stance, ideally we are having retrospectives so often that we don't wait until after the failure has occurred before turning our attention to the causes of failure.
It's also where we need to follow Scott's examples of good leadership -- having a leader who can create a safe place for the team to discuss and learn from the failure.
Lisa wrote: "It's also where we need to follow Scott's examples of good leadership -- having a leader who can create a safe place for the team to discuss and learn from the failure." Thanks Lisa! I think you nailed it on the head. I haven't interacted or worked with many leaders that have created that safe place for teams to discuss failure
Mod
The ideas in this chapter seem to have mostly held up though I'm not sure that having a single Program Manager running a project is the recommended approach these days. Given the difficulty of finding people capable of all the skills and with the capacity to balance them, as stated by Tom Peters, there are lots of organisations now that put two people in place to lead a team. To borrow the lingo from Agile one role could be considered a "ScrumMaster" focused on the efficiency of the team and the other a "Product Owner" focused on the market/business opportunity. They sit together with the team and collaborate very closely while holding the two distinct viewpoints.
I enjoyed the reminder if the careful balancing a PM needs to do to be successful. And after a recently poorly advised project, the reminder to be positive was an added plus!
Mod
