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
I have a column this week on Stickyminds, Multiprojecting: The Illusion of Progress. Thank you Frank Patrick, for naming this kind of multi-tasking (and for reviewing the work-in-progress). Feel free to comment on Stickyminds, unless you want to comment here.
About 15 months ago, Denise Robitaille and I met for lunch. Denise was explaining how she helped her clients implement a reasonable corrective action program. I explained how I’d helped some of my clients figure out what was really wrong when they had problems. We were struck by the similarities of our approaches. So,
Program management is the art of managing an effort of multiple projects with multiple deliverables. If you google “Program Management,” you’ll see a bunch of interesting posts, including Chris Pratley’s Program Management. To me, Chris is describing project management, albeit of a large project. When Chris talks about his “program” management, he’s discussing the coordination