Reducing rework and approval phases

| | Comments (0) | TrackBacks (0)
The new way of developing anything - be it software, or creatives or even documents seems to be - create a quick prototype, then get people's opinion on it - i.e. get them to mark it up, then create changes to accomodate all these opinions, and review it. This review then suggests further changes - perhaps because someone who hadn't given too much input before decided to do so the second time around. These changes are again incorporated for a final approval phase when the work is signed off by everyone.

Does this sound familiar? Yes.
Does this work? Absolutely.
Is this slow? Sure, but other methods are slower.
Is this the best we can do? Certainly not..
So what do we do then?

Reduce rework

In the previous example, we saw that the same "document" was "rewritten or modified" 4 times. By itself it's bad. Repeated modifications don't really add too much value to the document. Conventional wisdom suggests that the last 10% take 90% of the effort, and most documents are obsolete by the time they're ready. So why the urge to produce perfect documents? I can see how that's important if you're writing up a contract, but most documents are internal documents written to get people on the same page. People in general scan documents. They don't read them. Here's a suggestion. Tell people that the document will be written in this form
  • 2 people will write the prototype document.
  • This will be reviewed once to get other opinions. This is preferably done by using track changes and done serially. One person reviews, and then passes it on to the next guy, who reviews it again. By the time the third guy has reviewed it, most errors are out. The remaining folks will just read the document. :-)
  • Once this is done, get people together again to approve it. If there are any changes to be made, the one who suggests the first modification collects the other requests for modification, updates the document and sends the document around. That's all

Reducing approval phases

It's a good idea to get approvals ;-) They save you when things go wrong. But the approval process begins to take a life of its own if too much attention is paid to it. I'd suggest that you don't need more than 2 levels of approval anyway.
  • The first level of approval should be the folks that manage you.
  • The second level of approval should be the folks that control the budget.
  • If those two sets of people are the same, well, you don't need the second approval.
Another issue is that people who need to approve things typically don't have time. Which means that if you wait for approval, you may need to wait a week. Multiply that by a few documents, or decisions, and hey, suddenly you're waiting a pretty long time. Nothing consequential seems to get done, there's lower motivation and things start to go downhill.

Fix a certain period every week - say Thursday afternoon for a couple of hours to go through several approval decisions at a stretch. (Fridays are bad for this activity. Most people want to get things done before the weekend, and have no time on a Friday.) This would mean that if something wasn't approved this week, because of a delay, then it would get approved the next week. On the average, people would have to wait half a week for any approval.

These two common sense suggestions can shave at least 30% - 40% off the time involved in a process.

Tags: , , , ,

0 TrackBacks

Listed below are links to blogs that reference this entry: Reducing rework and approval phases.

TrackBack URL for this entry: http://arunconsulting.com/blog-mt4/mt-tb.cgi/51

Leave a comment

About this Entry

This page contains a single entry by Arun Sadhashivan published on May 1, 2006 10:26 PM.

Lies by engineers.. was the previous entry in this blog.

Guy Kawasaki on entrepreneurship is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.01