The Project Process

It seems to be an accepted fact that many technical projects fail, over run and generally fall short. Despite this people still apply the same business processes time and time again.Lets consider the average web project.

You gather a set of requirements in an hard to read document, you pass the document around via various involved groups who poke at it and take it into dark corners for a grumble, maybe add some corporate graffiti in a manner not un-akin to a stoat peeing on a found sandwich to mark his property (I’m assuming a male stoat). At some point someone writes out an LOE (Level of Effort: A set of fictitious number that represent how much a person actually wants to work on a project. The higher the number the more they want to put everyone else off doing the project).

While this lackluster analysis is happening, someone else will be employing a design company to create an interface containing functionality never previously considered by a sane person. The design company happy in the knowledge that they won’t have to build the project will include things like scratch and sniff images, and a “hug me to purchase” cart functionality. They will suggest paths to non existent information, which they will represent with the words “Lorem Ipsum”. They make up all of this fantasy whilst naked from the waist down, wearing hats made out of burning money. They sacrifice many goats and manatees, in return for Satan’s help in creating a very beautiful PSD of a website that cannot be built in the human world.

Now it is build time. The ratified requirements document, and the impossible design are laid on the altar of the chief technical Hoo-Waller. He studies these artifacts and then, with a whoop from his warrior clan of disinterested teenagers and assorted OAPs (Old Age Programmers), he wipes his nose on the documents and proceeds to invent his own system that is both easier to make, and ignorant of the artistic-contenty-fiddle-faddle that limits the foolish mere mottles he is forced to pander to.

Then the stew begins. For a number of months and weeks people hide in their offices and “do the project”. No one group really knows what any other one group is doing. Oh there is reporting, and mile stones, and issues to be resolved, but ultimately everyone is separately involved in making there own individual  project. There own interpretation of the design and the requirements…

…see here’s the thing (and where this whole pointless rant comes from). I don’t think anyone in this process ever really gets to talk about the actual “thing” that is being built. The technical people see a technical thing with properties and behaviours that match the properties and behaviours outlined to them. The Design people see a design thing, the content people see a content thing. The managers see a time schedule and a budget, the marketing people see other attractive marketing people. All of them are involved in creating things that match the loose description of what was promised, but achieving it from the point of view of their world.

No one wants to stray into the other groups domain and really get to grips with what anyone else is creating, because we’re all obsessed with our own little worlds. We all think our bit is most important, and never subordinate to someone else’s views. And here’s the kicker, we’re all making the same thing, aren’t we? A thing is a thing. 1 = 1 doesn’t it. A thing can’t be one thing to him, and another thing to her, and another thing to me. We described it, and we decided what it was before we built it.

I recently described the project requirements as the shadow on the wall. Everyone agrees on what shape the shadow on the wall is meant to be, but the project is to building the thing that casts the shadow, which is a very different thing from the shadow itself. It can be made in so many different ways, and re-imagined by so many schools of thought. So of course projects slip. Of course everyone’s disappointed, it’s the only logical outcome of many people pouring there hearts into something only to discover that everyone else working on it is not interested.

It’s the reason why we all declare that everyone else on the project is an idiot. Can’t they see? What planet are they on?

If  I’m right (maybe I’m not,  maybe this is just a rant), then the solution lies in aligning the minds of those involved. I don’t know how you do that, not least because language is subjective and loose, and common understanding is prerequisite on common experience. You cannot expect to simplistically align all peoples points of view, and not everyone can know everything that everyone else does.

Part of the solution is surely to make sure that all people on a project are involved, and interested, and communicating. Not just in there little groups, but across all the groups involved. There must be empathy, which can be helped with good communication. And good communication shouldn’t demand that those involved make boring effort. Good communication invites interest by being interesting, and by doing much of the work for the reader.

I also don’t think you can buy in interested people. If you discard work to a group of people because you don’t care to involve yourself in its complexity, then you have no empathy, and you can’t expect those parties to try to make you interested, they’re not paid to do that. They will find there own fun in the work you have set them. Most likely they will build what they have to in the easiest way possible and deliver exactly the line items that were demanded of them.

Finally I think you can’t care about something that is too easy. It’s the same principal as the discarding of work to a third party. If you’re involvement in a process is a predefined selection of a button, then you are not involved. If you always just enter the address in the sat-nav and get taken where you want to go, then you will never be interested in the process of map reading, you’ll only ever be angry when it doesn’t work. With understanding of complexity comes empathy, that’s why electricians tend to not thump their TV sets. If you’re involved in a process, not just a slave to it, you’re likely to care about it more. That isn’t just a comment on technical involvement. You need to also appreciate the difficult of sculpting a great piece of content, or the agony of balancing the aesthetics of a web page. Or even the effort involved in articulating a clear set of requirements.

Back to shadow boxing…


Posted in Collaboration, Projects | 2 Comments

2 Responses to The Project Process

  1. Brewing Bard says:

    Here, here. Need to take a more unified software development approach. Which of course no one there, at least none in charge, no how or want to do.

  2. mordechai swamp fox the original says:

    I don’t even know how to make a damn website… i just thought they appeared if you wished three times and farted on the screen…. i’d really like one actually i’m sure they could be useful…. not like toilet paper is, but then that’s why you can scratch and sniff toilet paper and not websites

Leave a Reply

Your email address will not be published. Required fields are marked *