From Digg:
digg - The Perils of Project Planning
The Perils of Project PlanningThe single biggest mistake I see planners make it to assume some aspect of “perfection” in their conversion of an estimate into a plan. Our estimates are not perfect; they need to encompass uncertainty. People are not peripherals: their performance is uneven and they can be distracted by many kinds of unplanned events.
Come an interesting article.
Opinion: The Perils of Project Planning
Opinion: The Perils of Project Planning
By John ParkinsonWhat’s the best way to plan for complex software development projects? Dynamically, if you can. But that doesn’t make it any easier.
In my last column, I wrote about the challenges we face when trying to create a useful estimate of the effort required to complete a software development project and the methods available to do so. As challenging as this is, it’s just the start of our journey to a predictable project outcome. Now we have to take that estimate and turn it into a plan that will allow us to “manage” (from a root word that meant “keep a hand on”) the work.
Let me start with a couple of important observations:
First, for small projects, and experienced, self-organized teams, a formal plan may not be necessary. Such teams have a good sense of how long it will take them to finish and are good at assessing what they can commit to. In these circumstances, formal plans may serve other roles (perhaps as a framework for collecting information about what actually happens or as a template for reporting progress). But they won’t enhance the project team’s work. That doesn’t mean that smaller projects don’t need to be planned for. More… »

I also am not happy that I can’t have an internal schedule separate than an external schedule. I want to tell my developer that his part needs to be by the end of this week, so I can check it next week, but tell the client that this task will be done next week. How do I hide a task from the client? 