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
Now that I’m back from vacation, I’m catching up on my reading. I enjoyed David Anderson’s Management versus Leadership on ‘The Apprentice’ which prompted me to think about what I would have done in Kwame’s place. It took me a long time to learn, but a manager always has the option of firing people who
I publish a monthly (most of the time) email newsletter, The Pragmatic Manager. The last two issues have dealt with decreasing project time, before and during the project. Clearly, I don’t remember to post notices of the emails every month, so feel free to subscribe yourself.
You’re a project manager. You have too much work to fit into a project (scope) and not enough time to do it. What do you do? Timebox. Timeboxing is a technique to fit what you can accomplish (some of the scope) into the time you have allotted. Timeboxing works when you have fixed schedule
Because I work for myself, I frequently miss things like Secretary’s Day or Boss’s Day. This year I almost missed Take Our Daughters And Sons To Work day. When the Ms. Foundation started Take Our Daughters to Work day, many colleagues poo-poohed it. “Who needs such a thing?” But a funny thing happened. Girls started
Read Bret Pettichord’s How Did the Blackout Happen? to see how cutting yourself off from data can damage your ability to perform your job.
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,
Oh dear. I was not sufficiently articulate in my last post. Both Frank and David in their comments asked about capacity, the output of the organization over time. That will teach me to post when I’m tired. (Maybe.) Let me try this again. In each of these projects, senior management wanted more features than