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
A client was optimizing for what they thought was the bottleneck in their software development: the testers. In the assessment, I gathered some quantitative data about how long the testers took to test and how long it took for the other groups to perform their work. (They used a phased lifecycle.) The testers were
David Anderson has an intriguing post, Lawyers, Unit Tests and Performance Reviews. David says “Individual team members can be set specific goals and behavior objectives…” and gives examples. I prefer that team members set their own goals with input from their managers. But the key here is that a technical person should be looking to