I’m particular about two things: calling a prose plan a project plan and calling a Gantt chart (or yellow stickies) a schedule. One of my colleagues emailed me last week, explaining he’d spent a week developing a project plan and was hoping I could take a look at it. “Sure,” I said. “Send it along.” […]
The Projects@Work folks have posted another excerpt from Manage It! See Roll With It to read a bit about rolling wave scheduling.
Glen Alleman in What’s Wrong With This Picture says this: dentifying, sequencing, and assigning durations to tasks is NOT the role of the Project Scheduler, it is the role of the project team, along with the Project Scheduler. The Work Package Manager, the Customer, the entire team that is accountable for delivering the business
I’m writing my project management book. I have no idea how far along I am. (Wait, I promise to explain.) When I write, I have several phases: the exploratory phase, where I write articles, the write-it-down phase, where I write the whole thing down (in chunks, of course), and the editing phase. I’m in the
One of the scheduling tips I discuss in my project management workshops is “Plan to refactor.” I explain that if you’re using a lifecycle other than Agile, where the integration and testing is built into every iteration, you’re going to have to refactor at the end, when you do integrate and test. At one
I had a discussion recently with a manager who was concerned about his developers meeting their milestones. “We have “Code Complete” as a milestone. The developers say they meet it, but that just means they wrote code until the milestone date. The code isn’t complete. I can’t even tell how complete it is.” Ah,
I gave a talk entitled “Predicting Project Completion” at the Central Mass chapter of the PMI last night. I had some suggestions about techniques to generate and discuss schedule estimates. Then, to practice a little, I asked the audience to become participants and practice a simulation. The simulation is to first estimate how long
If you’re managing a project longer than a few weeks, you may realize that the project’s progress is not quite where you think it should be. It can seem impossible to change course. But choosing to continue what you’re doing is a choice. So you can choose to do something different. I started thinking
I’ve been thinking a lot about impossible schedules. I’m talking about the project schedules that no matter how you organize the project, it’s not possible for this group of people to cram that set of features into this much time. At least, the developers don’t think so. If people are up against impossible schedules,
Caveat: I just started thinking about this, so I don’t feel particularly articulate. After reading Roy’s post of Kent Beck’s discussion “Invest in the design of the system every day”, I realized that’s what I do for project planning. Every day, I’ll adapt the work I’ve planned to do, to meet the needs of