Bill Brantley has clarified what he means by "microprojects," What makes microprojects different from traditional projects? Basically, these are projects that don't have enough time and too many requirements. And probably not enough money either. What do you do?
Bill describes three key aspects of these kinds of projects that he seems to see frequently - that create havoc for him.
- Path dependency. Choices made in the first days greatly impact how the rest of the project will go. And with compressed time lines, this can kill.
- Negative feedback loops. Changes have ramifications everywhere that tend to spawn more changes and impact the project path.
- Client dithering (my term). Clients change their minds in all projects, but with short time-frames, the discussions and changes have an outsized impact.
As I read through this list and Bill's discussion of the issues, I can't help but think that the core issue is that changes impact the project almost instantly, whereas with longer projects the changes can be absorbed into the remaining activities (or "buffered" if you are a TOC person). However, I have been in many "normal" projects environments where every change / upset seems to be critical because there is no mechanism to determine the real impact on the project.
My thought is that there isn't a real difference between these projects and projects that run for months or years. The project team and the client need to know the impact of changes. They need to know the impact of delays and rework. And they need to know the impact of mid-project scope-changes. From my perspective, it looks like the team needs to take the 1/2 day to plan out this project: what are the stages, hand-offs, critical inputs.... And then do it - don't worry about task due dates, worry about remaining durations once things have started.