Instead, let’s inject a critical chain technique into how you manage this project. Estimates on tasks are usually inflated to allow for slack time in the eye of the estimator. Let’s take the CC method of removing slack and creating a buffer, and apply it to only the lower levels, either on individual tasks or series of tasks. Take the scheduled time and chop off the last 20% of it. (I wouldn’t bother with anything less than 40 hours in duration) This is now your deadline, and the time afterwards until the “official” deadline is the management buffer. Keep communication with the team open and honest, let them know what you are doing. Their goal now is to get the task done by the new due date. If they are done by then, they can spend some time doing “Google-ish” creative brainstorming and experimentation. If not, that’s when the project manager becomes more heavily involved than normal, helping to remove roadblocks and provide more resources. Of course, the PM should be doing this all along, but now is the time to redouble your efforts. It’s important to let the team know that if they go over this deadline, it’s not the end of the world. It shouldn’t even be a negative thing. It’s just an early alert system, and everyone should know ahead of time that there’s just as much chance of going over this deadline as their is hitting it on time or early. Keep the critical path in mind with your decisions, you may have to let a non-critical path task slide to address a critical one.
By managing the tasks this way, resources are compelled to knock out the things that lead to a specified deliverable first, and add the most value. It doesn’t require adjusting the official schedules, or introduce paperwork overhead. This is simply a management technique.
As a solo developer or on a team, I think it would be great to “eat our frogs first” and then either start the next task early, or have a few days to brainstorm about what we can do to add even more value. Working with a team for a short time with a blank canvas, you can pool the skills and do some great team building while generating some really creative stuff. You could also do additional testing and debugging, or start looking at the next task early and brainstorm about the best way to go about it. Or, a little of everything. Let the ones who like engineering do things to fix bugs, enhance the documentation, and make it scale better. Let the prototypers do their thing.
- Understand CC buffer management and the benefits of it (links below)
- Get your team on board by showing them the WIIFM (what’s in it for me?)
- Keep the critical path tasks in mind for decision making
- For tasks 40 hours or longer:
- Create a CC deadline by chopping off the last 20% of time from a scheduled task
- The last 20% is now a management buffer
- Check status at the CC deadline
- Not complete: Focus support efforts on the task
- Complete: Start the next task early, or have a “Google day”!
For some background on Critical Chain and it’s benefits, here are some references for you. Specifically, you need to understand why you’re doing this well enough to get your team to believe in it too. This probably won’t work well with totalitarian rule.
About the author
Josh Nankivel is a Project Planning & Controls Control Account Manager and contractor for the ground system of the Landsat Data Continuity Mission, a joint project between the USGS and NASA. His academic background includes a BS in Project Management, summa cum laude. He can be found writing and contributing in many places within the project management community, and his primary project management website is located at pmstudent.com.