Or:
Critical chain management methodology for animation production.
I have mentioned before the data on the % of projects that are considered a failure or that go over budget for various reasons (32% success rate, 44% over budget and 24%failure, source) I feel that part of the issue is the way that we create schedules and budgets. That is not to say that these are inherently un-achievable. Nor are those that create these not doing a proper job. The true challenge is how to create a schedule and budget that can take into account the cost and time to do it versus all the things that can go wrong. Experience of course plays a big role in this but is not a guarantee of success. There is no real guarantee only an ability to quantify a higher or lower probability of success.
This should not be misconstrued in giving excuse for a projects failure nor of abdication of an individual’s responsibility to get something done. Sometimes sh*t happens. Sometimes there are too many cooks or not enough of this or that but I digress. That isn’t the point I am trying to make.
The big point? How does one anticipate all of the possible things that can go wrong in a project? You can’t and I have yet to see proof to the contrary. But there are ways to significantly increase your chance of success. Ignoring for the moment some of the other points I have made as far as the pitfalls to look out for let’s look at the theory of constraints or more specifically Critical Chain Project Management.
The theory proposes that there are a limited number of constraints that always exist within a given structure or process and that there is always at least one constraint. A constraint is anything that prevents the system from achieving more of its goal. This can be in the form of, but not limited to, equipment, people or policy. Examples could be not enough computers or not fast enough machines, lack of skilled staff or company/government policies that limit the structure from achieving its goal such as you must hire only residents from a certain province. It is likely that some constraints cannot be removed but recognizing that fact is important to furthering your process.
Any series of processes can only move as fast as its biggest constraint. Once identified you can build around it. Here are some steps to use in discovering constraints for a project:
1. Identify the constraint (the resource or policy the limits your ability to achieve your goal)
2. Decide how to exploit the constraint. Buy more machines, add more people, decrease expectations.
3. Subordinate all other processes to the above decision. In other words find ways to support or organize your system to deal with the decision made.
4. Elevate the constraint.
5. If as a result the constraint is removed or reduced, return to step one. Don’t become complacent. There will always be some constraint in the way!
Fairly heavy I know.
Another key aspect to this process is the creation of buffers during steps 2 and 3. Buffers can be in the form of time or budget and should not be confused with inventory or what is in the queue from one process to the next. Buffers allow for the variation in processing time within a given process. For instance you decide that you have enough staff to output 2 minutes of animation a week but one of your constraints is a high % of inexperienced animators. The 2 minutes is based on what? Your fastest animator or your slowest? Taking the time to assess the differences between these two extremes will help you come up with your 2-best/worse case timelines. Based on that plus the constraint of the number of inexperienced artists you then find the mean value or “good enough” value. Not the best but also not the worst. Maybe the number you come up with is 1.3 minutes per week. Is this an acceptable constraint? If not then the constraint becomes elevated and you need to get rid of it. Is the constraint now too much cost? Then the whole process starts again. In this way you are trying to find ways to pull material through the system not push it through. Pushing material through a system means that you are always going to be reacting to a problem instead of identifying the problem and finding ways to overcome it before you get there.
Essentially do not get caught in making a schedule that adheres to your optimum expectations but to your acceptable expectations. The acceptable being the least possible throughput that you can live with, keeping in mind the other aspects that will connect to this. Using the above methodology to constantly try to increase your throughput. In this way you stand a better chance of actually achieving or even surpassing your established goals.
In many cases the “good enough” approach will win over. This usually happens when it becomes apparent that there is no way of finding the “optimum” approach to a system or the uncertainty between your optimum and near optimum solutions becomes too great. Something will have to give be it quality, quantity, time or money.
What is imperative with this system is to never stop. If you stop doing this on a daily or weekly basis then Parkinson’s Law and Inertia will set in. Just because you have 2 weeks to do something doesn’t mean it should take the 2 weeks to do it if you think you can do it faster. This is where rewards come in and should be thought of when building your process. If you stop you will become stuck in reaction mode as opposed to proactive mode. Always be vigilant. Never assume, as you know what that can lead to!
No comments:
Post a Comment