Doug was concerned. He was the project manager for a brand new product. After a few specific features, the product manager wasn’t quite sure what needed to be in the first release. The developers were working in a new language. The testers had never seen this new database. And, his management wanted the first release […]
Glen Alleman has a post about program management, Managing Multiple Projects is Called Program Management which got me thinking. (I’ve written about program management in the past also: Program Management: Multiple Projects With Multiple Deliverables.) But in the portfolio management book, I defined a few ways to think about your projects as programs: You, and
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
I ran into Dan North at the Agile conference today, and explained a little about the project portfolio book. I’m writing it because I have a number of clients who are having trouble breaking the multitasking habit (working on more than one project at one time.) Dan said, “Oh, you want them to commit to
A reminder: I’m teaching a public project management workshop in Waltham, MA, Sept 22-24, 2008. If you would like to: Understand different lifecycles and when (and how) to use them Practice pragmatic approaches to organizing and estimating a project Learn a variety of ways to steer a project to success Learn how to develop and
I’ve published a podcast: How Many Emergency Projects Do You Have? Enjoy!
Feature Article: 90% Done Is Not Almost Done Back when I was a new developer, my boss asked me how long it would take to complete a specific task. I looked at it for about 20 seconds, and said “Four weeks.” “Great,” he said. At the end of the first week, I was 25% done—that’s
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,
Refocusing: Emerging from the Split Focus Schedule Game You see your manager bounding down the hall towards your office. You know what’s going to happen before he gets there–he’s going to ask you to take on yet another project in addition to the three you’re trying to juggle now. You want to run and hide.
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