The problem with managing an approval process involving idiots

May 19, 2006

One of the biggest problems with working with idiots in the internet industry is the amount of valuable time wasted trying to follow and enforce a process for change requests to put changes live on websites.

Let's take the following example. Marketing woman (MW) from big corporate client (CC) has a 20mb powerpoint presentation she wants put on the corporate website. As this site was built by a rubbish company in the first place, getting it from marketing woman's hands onto the website involves the following process:

1. MW calls marketing company
2. Marketing company send request to us
3. We upload to staging server for approval
4. Marketing company check and approve
5. Marketing company contact Marketing Woman to approve
6. Marketing company give us approval to go live
7. Developer connects to to VPN, copies files across, HTML, etc.
8. Marketing company reviews and confirms approval
9. Marketing woman reviews and confirms approval

Then… the f*cking dumbass marketing company call up. "There's a typo on slide 18". WTF. That's why we have the staging server and a f*cking approval process.

Don't these idiots understand that the file they view on the website is the same f*cking file they supplied?! No, instead, they blindly review it at each stage of the process until it goes to production, and then finally look at the damn thing and realise there are typo's.

So, a new powerpoint is supplied, and the poor developer has to drop what they're doing and repeat this whole tedious process.

The rumours are true. People who work in marketing are stupid. F*cking stupid.

Here's a diagram to illustrate the process:

A dev's life

(Click for a larger version) 

Advertisements

One Response to “The problem with managing an approval process involving idiots”

  1. Sounds like you get it easy to me. Here’s the change process I have to regularly deal with.

    1. Develop new bits (inc code, test plans, deployment plans etc)
    2. While doing 1 above, but once deployment and test plans are finished, submit change request inc above mentioned plans. (At least 2 weeks in advance, change board only meets once a week, and once they approve it, it then has to be submitted to clients change board for approval)
    3. Finish code, deploy to Test Environment for assembly test. Run test scripts, get them signed off by client, update deployment plan to take account of any hiccups along the way.
    4. Wait for change request to be approved for controlled/monitored environments.
    5. Deploy to QA/UAT environment, run test scripts, let client run UAT test scripts, update deployment plan to take account of any hiccups along the way.
    6. Lock in a time for change to go into production.
    7. Do production change.
    8. Monitor for ‘n’ days to ensure change was successful.

    Given that these changes are software changes, not document updates, and any mistakes affect thousands of people using critical business systems. The process is long and arduous, but works and has saved arses many of times.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: