Seth Godin has a great entry, Saying ‘no’. No is the essence of project portfolio management, no matter who you are. If you don’t say No, your yes’s don’t mean anything. As Seth says, Saying no to loud people gives you the resources to say yes to important opportunities.
There’s a discussion on a mailing list about a partially committed-to project: there aren’t enough people on the project, the people don’t have the time to do the work because they are interrupted all the time by support of previously released applications. The only people available are part-time people who are not available when the
I’m trying to clean up the project portfolio management book for technical review, and I realized the other night (well, morning, when I woke up), that I’d missed explaining a key idea. We all work on several kinds of projects: Projects that maintain the organization, the kind we need to run. These projects “keep the
The project portfolio book is in Beta! For those of you who have not heard of a Pragmatic Bookshelf Beta book, here are the limitations: It’s not laid out correctly Although I’ve looked for typos, I have not discovered and fixed them all The bibliography is not yet included (it will be on later betas,
I’m editing the project portfolio book. Yes, I’m trying to get ready for beta. No, I have no idea when I will be ready. I’ll have more information before Wednesday, if you want to know. I realized that when managers don’t make ranking decisions about the project portfolio, when they don’t fully commit to a
Chris asked in his comment, how about using the word ‘abandoned’ for projects that are “finished”? I just don’t think of completed projects as abandoned. Let’s separate the product from the project. Projects complete. Products may never be done, but projects do finish, sometimes whether we want them to or not. I was working as
John Cook, wrote a lovely post, Peter Drucker and abandoning projects, explaining how Drucker talks about abandoning projects. (John, thanks, I will definitely be referencing Drucker in the PPM book.) I haven’t been using the word “abandon” when I describe stopping projects. I’ve been using the word “Kill” and the concepts of permanently stopping projects
I had coffee with a friend Saturday night. She said, “Our family has a tradition of starting many projects to see what we can stick with. If you don’t start a project, you can’t finish it.” She’s right. You certainly can’t finish something you don’t start. But the real question for all of is: Should
I was reading Ralph’s post, Whose Fault Is It?, and I realized that if you don’t know enough about management, you can misunderstand the root cause. Ralph’s example is of defects in an iteration and how they were not detected early enough because the acceptance criteria were missing. The criteria were missing because the testers
I’ve been reading Jeffrey Kaplan’s book, Strategic IT Portfolio Management, as part of my research for my project portfolio book. He says something astounding (I’m paraphrasing a sentence on p.73): Managers intuitively know when their projects are not delivering sufficient value. Wow, that has not been my experience at all. My experience is that managers