In my project management class today, one of the students asked about how to schedule interdependent sub-projects. The scheduling tool he uses doesn’t deal well with pieces of one sub-project having dependencies of other sub-projects. It’s difficult to see the critical path, and to know what’s really going on. (It’s too easy to have […]
I’m not a fan of project scheduling tools. I have trouble making the tools create the schedule the way I think, and I can never quite see the whole schedule when it’s in electronic form. Other people, especially senior managers, tend to believe the project schedule once it’s in electronic form, no matter how
I’ve noticed a common theme among the projects in trouble I’ve encountered over the past few months: functional milestones without deliverable milestones as a part of the functional milestone. Here are examples of functional milestones: “requirements complete,” “code complete.” These milestones raise these questions for me: How can you know something is complete when
James’ comment and Eric’s comment asked good questions about why I differentiate between milestones and handoffs. Milestones can be a collection of events (handoffs) that culminate in one milestone. Let’s take the milestone “code freeze” or “code complete.” The code doesn’t magically all become complete on one day; some of the code is completed
In the last couple of years, I’ve worked with some project managers who thought the reason they made schedules was to know when the milestones would be met. They thought if they knew when “design complete” or “feature freeze” or “code complete” occurred, they could track the schedule. I’ve never been comfortable with that,
I’m developing a syllabus at the graduate level to teach high tech (if that matters) project management to people without a lot of PM experience. I’m supposed to teach MS Project as the tool project managers schedule the work. I’ve been rejecting the idea that a scheduling tool can teach a new PM how
From the “I wish I’d said that” list: Via Frank Patrick’s blog, Mike Cohn, in his User Stories Applied for Agile Software Development. Chapter 10, Why Plans Go Wrong in pdf, explains buffers and padding and scheduling: “A Buffer Isn’t Padding — A buffer isn’t padding. Padding is extra time added to a schedule that
I talked to a project manager recently who was so busy fussing with the schedule (WBS) that he didn’t have time to make decisions on the project. He was a project administrator, not a project manager. If you’re working on a difficult and complex project, spend time on the schedule. You need to review