I was so excited after reading Goldratt’s second book, Critical Chain, that I wrote the blog post below. It’s still actual, I still stand by what I said… But after the difficulties I encountered in my latest project when trying to apply some TOC principles, I felt the need to emphasize the fact that theory is not reality. Sounds pretty trivial, I know, but we all dream big and think that a carefully planned project will go smoothly.
Just remember that the human factor, the unpredictability of the client or the miscommunication between team members can make all your planning useless. It’s not bad, but it is normal and you should expect it and adapt quickly.
So read the post below, but remember that all these books and rules are meant to give us more insights and advice. They are not the PM Bible and should be “read with a license” – meaning that you should take all these infos through your personal filter and apply only the things you feel comfortable with…and also expect that some things won’t work. Hope this helps ;).
As I was mentioning in one of my previous posts, I am a big fan of Goldratt’s books. I recently finished the second one, Critical Chain, which explains how TOC can be applied to projects, and not just manufacturing. It is quite an interesting read.
It’s not just about the ideas it brings, but also the manner in which he explains them. It’s motivational and actually induces you in a “thinking, problem-solving state”. The book really tries to show how other project managers are understanding and applying TOC, and what difficulties it brings, and what solutions they find. I totally recommend it!
My bullet points from the book are:
- Focus on the resources: on their skills and available time, their multi-tasking abilities (if they are involved in other projects as well), their need to know in advance when things come their way — “A Critical Chain project network will tend to keep the resources levelly loaded, but will require them to be flexible in their start times and to quickly switch between tasks and task chains to keep the whole project on schedule.”
- Insert buffers along the way, not just at the end of the project: wireframing, design, development, they all need a time buffer, just in case things don’t go as planned and their delivery is delayed. Strictly related to this is the point below – because no matter how many buffers we introduce, projects are always late, right?
- Don’t set strict deadlines, because an estimate becomes a “self-fulfilling prophecy”: if a designer tells you that a task will take 16-20 hours and will be ready in 1 week according to his/her schedule, they will definitely do your task in the last 2 days, and even deliver 1 date later! It’s called the “student syndrome”, and we’ve all experienced the need to delay things until they turn critical (see also my post about the “latte phase”). Instead, explain to the designer why finishing this task faster is in the best interest of the client, and hence the studio, and offer positive rewards for quick deliveries.
- Monitor and adjust: monitor the time sheets and see where the buffers are gone – they will most likely predict the delays. Be prepared to recover the time lost, or notify your client about the delay.
For more details, read this nice article also…and of course, the book :), and draw your own conclusions. It’s not a perfect or life-changing theory, but it will open your eyes and make you think on how you can manage your projects better.