James Robertson has written a thought provoking article on workflow and takes a gutsy stance that says that workflow doesn't work. I would have to agree with his points about the origin of the percieved need for workflow to improve quality control and workflow's failure.
My view is that workflow has two (usually conflicting) purposes: to speed things up or to slow things down. James is talking about the latter case where you put in controls to prevent undesirable content from getting published. By adding steps to this process you are deliberatly adding more bottlenecks to publishing. Pretty soon, the sysem is unusable. The other case (speeding things up) is about division of labor. Your process becomes an assembly line where people work efficiently because they are specializing. This only works if people want to specialize and are able to become more efficient by doing one thing (for example, graphics designers and writers). But most knowledge workers don't think of themselves or like to work in this way.
Another accelerating tactic is creating resource pools and workflow can also help with that. The concept here is that you have variable demand for throughput. When you need to produce more, you can draw resources from a shared pool and distribute the load more. Workflows designed to work in this way are role (rather than individual) based so that people share a queue of work. When you bring in extra people, the queue can be worked down faster. This is sort of how call centers work.
So, when designing workflows, think about whether you are trying to speed things up or slow things down. If you are slowing things down, keep things as simple as possible. As yourself if a simple approval would do. If you are trying to speed things up, as yourself an assembly line mentality works in your organization.