I’ve been sick for weeks, and am finally coming out of it to be close to healthy. (I was still coughing in the 8-degree Fahrenheit cold leaving the gym. Oh well.) One of the problems is that my work doesn’t stop if I’m sick. I bet yours doesn’t either. Daughter #2 asked last night if […]
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 was trying to address the issue of ROI (Return on Investment) in the project portfolio book. I don’t buy project ROI. First, the idea of a project for software is an artificial construct—our consumers buy running tested features, that we happen to package in a project to release as a product. But the idea
Jim, in his comment on Intuition is Not Enough for Knowing About the Project Portfolio, said: I am having trouble with the definition of the word “value” in this context. Do you mean showing progress, as in earned value, or value to the customer, such as in ROI or payback period? Value has become a
One of the big problems in organizations is how to fund projects. ROI does not work. I learned how to lie with ROI back in 1988—I can make the numbers be anything you want. But if you don’t have ROI, how do you know what projects to fund? One set of projects is the set
I’ve been working with several clients on their transitions to agile–or at least, more agile approaches to their projects. In each case, the managers decided to move towards agile because the technical staff were in their words, “naive” about the project goals. To be fair, none of the projects had a vision or release criteria,
I recently spoke with a project manager. He was concerned about the product managers handing off the requirements to the development staff. He was right to be concerned. Handoffs don’t work. The more people think they are done with “their” part, the less likely you are to receive/finish a great product. That’s because no one
I’ve been writing pieces of the project portfolio book, and was wondering how to explain how managers get caught in the trap of having too many projects. Then I read Joe Ely’s Minimizing Work-in-Process for Knowledge Workers, and had an “aha” moment. (Well, I think I did. You let me know.) For many managers (and
One of the problems I see in projects is that there is not a sufficient definition of done. For agile teams, it’s not clear what done means for a timebox. For non-agile projects, the team may not agree on what done means for a milestone or for a release. For an agile team, do you
I taught my project dashboard workshop today. One of the things most people want to measure is progress towards project completion. But you can’t measure project completion progress unless you have completed features: developed, integrated, and tested features. A completed feature is done enough for someone to use. Implementing by architecture leaves all the