I could write a nice narrative detailing my interaction with a mid-level manager and how she wanted a new web site for her program pretty much NOW, and how, once we built it, took three weeks to even look at it for fixes, and after giving us fixes, is only now setting up an 18-person (yikes!) meeting discussing what should be on the web page… but I will spare you. Mostly I’ll spare you because you have your own stories of people who think the cart goes before the horse and pick out wallpaper before finishing the architectural designs.As I learned a long time ago (and have had to teach many people since then), the web is in such a unique position in most firms because it is a program without a country. It does work for all divisions. As such, it is one of the few things that can reach every nook and cranny of an organization. It is one of the few ways to affect enterprise-wide change (I mean, is your financial department or purchasing program shape the way programs do things?).
Most people think, “I have a problem. I have devised a solution. Now I will create a web-version of that solution. This is what it will do. This is what it will look like. Now, let’s talk to the web guy…”
Maybe other web-people think that makes sense. Maybe they are happy to accept the assignment and do the work whether or not they see issues with the solution.
But I’m not that guy. I want to be there meeting 1 and help someone discover the solution (and how it is web-able will be discussed in turn, but by having me at the table early on, the web-solution will be obvious as it was thought about during first-level meetings). Â I think the the web is a tool that invites conversations about the process. not the process of design or development, but the process the client is trying to take to the web.