I just finished updating all my email newsletter (Pragmatic Manager) pages. I hadn’t announced my most recent newsletter, Making Waterfall (a Serial Lifecycle) Work For You, Part 1 (Vol 4, #1). I’ve reorganized the pages, so go here to read all the previous articles.
I reported on my progress cleaning up my office Cleaning Up the Office, Round 2. I hadn’t let it get that bad since that round of organizing, but I did ask for help from Daughter #2 in May, to buy some bins and drawers to continue my never-ending attempts to stay organized. The past 8
Kevin says in his comment: Business analysis is how you figure out what done means. Project management is how you figure out how to get to done. I disagree. Business analysis is the elicitation and definition of what everyone else wants to have in the product. Project management is understanding what’s driving the project,
Via Raven’s Think you know what a project is?, there’s a pointer to What is a Project? Think Again!. Garry, the author likes David Allen’s definition of a project: < blockquote>A project is any outcome you
I don’t have much use for Gantt charts; if you’ve determined the tasks in enough detail and far enough out to really see the critical path, you’ll be wrong in 24-48 hours. If you don’t put in that much detail, it’s a pretty picture, but not enough information to manage the project. (Of course,
While teaching a management class recently, one participant came up to me at a break, and said, “Why are you teaching us project management with this portfolio stuff? This is supposed to be a management workshop.” Portfolio management, determining which projects to fund and when, is management work. The best managers actively manage the
I’ve taught several workshops where people wanted to learn how to start adopting some agile approaches. They knew about timeboxing, but didn’t quite see how to make it work. The part they were missing was having working valuable product at the end of each timebox. I explain that to the participants, and they nod sagely.
I taught a workshop about transitioning to Agile earlier this week. One of the things that’s difficult for many project managers to recognize is that milestones must be deliverables–otherwise, it’s too hard to know when something is done. One of the participants had a slightly puzzled look on his face when I said that,
If you haven’t read Duane Nathaniel’s thoughtful comment on What Happens When You Can’t Finish What You Wanted in an Iteration?, do so now. Duane makes some great points. RUP has iterations; they’re not timeboxed–they’re deliverable-based. (Take a look at the link that Duane points to.) In the RUP, an iteration results in a deliverable.
I’ve encountered a number of projects where people didn’t know the context of their work. As developers, they were working on the thing they had to develop or fix today. They might remember what they had done yesterday, but there was no sense that they knew what they needed to do tomorrow, or that they