Another Toe Tagged Project
I was recently asked to go take a look at a web site project. Ordinarily, my answer to requests for a critique like this is, “Are you willing to pay my ‘I don’t want to do this,’ rate?” This person, however, I owed. Big. I almost asked, “Would you be willing to take an internal organ instead? I have a spare kidney!” I don’t think she would’ve taken it. She wanted the web site reviewed. And so I began my foray into a text book case of all that can go wrong in web development.
This person I was helping out — let’s call her the Customer, because she was — had retained the services of her university’s IT department to develop a web site for her organization. She provided what she believed was a very complete set of requirements for exactly what needed to be built, yet the project was well over deadline and didn’t look right to her. She wanted me to provide a sanity check. Was this the best that could be done with the web? Were her expectations too high? Was this a fundamental limit of the technology? Was there something she could have done to prevent this or could do to rectify it?
Customer, Requirements, and a Chorus of Angels
It turned out this was the simplest kind of site imaginable. No database backing. No server side scripts. No site search function. No Java widgets. No Javascript. Absolutely nothing but good ol’ fashioned static content. She provided a Word document with every bit of the content to be put on the page: text, images, sidebars, navigation, and a first cut at styling and layout. I say first cut because she wasn’t given any guidance on the width to which she should lay out - and not for lack of asking - or formatting conventions like leaving link text blue and underlined. (Yes there’s irony here given that the style sheet for this site messes with the link style — I just haven’t gotten around to correcting that yet.) She wasn’t rigidly inflexible about the requirements either, and actively solicited their input where they felt something wouldn’t display well or adhere to the usability conventions of web sites. Print documents she knows; the Intarwebs she doesn’t.
I know it sounds like I’m describing the Platonic Ideal of a Customer - she had her requirements in order and left room for flexibility of implementation. I promise I am not exaggerating. And yes, I believe the cloud cover over my house did break to allow a single beam of golden radiance to illuminate my screen when I read her specification — okay, that part I’m exaggerating. But it’s true nonetheless that this project did not suffer from an indecisive Customer with poorly conceived notions for a grandiose ball of scripts and database hacks.
The Site, Or Shall We Call It “Ground Zero”
Then I looked at the results. I expected to spend a half hour poking through and giving her an overview. Soon I had a notebook out frantically scrawling notes. I think I wrote “Here Be Dragons,” a handful of times, and I remember using enough exclamation points to populate a fanboi forum post. But these were not light-hearted exclamation points; they were laden with foreboding, a lightning strike arcing down to the point at the bottom.
The gripe list is summarized below. Note that this isn’t meant to be a set of guidelines universally applicable to all web sites (although some probably are) — they’re meaningful in the context of the particular look, feel, and set of information she was trying to portray.
- There was a logo on the top left of the page suggesting a way to navigate back to the home page, but it wasn’t linked.
- There was a bread crumb trail (list of links followed to get to the present page), but not all the text links in the trail were actually links, meaning you couldn’t reliably navigate using the trail.
- There was some extraneous formatting, borders and boxes around paragraphs in the side columns, that didn’t really look intentional. I guess you had to be there and see it, but it looked off
- Across several pages and within a single page, several different color and formatting conventions were followed for href links, making it impossible to consistently and easily identify links. And none of these styles were the usual blue with underline. Moreover, some non-link text was formatted in ways that suggested links that could be followed.
- Some of the foreground and background color choices made the text difficult to read
- Many of the images had been stretched or compressed without regard to their aspect ratio. Given that many of these were photographs of people, it gave the whole site a fun house mirror effect.
- URLs for other sites were listed on some of the pages without being linked to those other sites.
- Some of the link names and titles of pages didn’t match their contents. For example, a link to a statement from a person went to a page with a matching title but contents that read more like a third person biography. The link to that person’s biography went to their statement about the site and its purpose.
- Some of the links pointed to missing anchors within pages.
- The navigation was confusing in places. On a product list page, you might click on “Order Now” only to be taken to a product description page with its own “Order Now” button. Recall above that I said this side had no scripting. This is still true, clicking the second “Order Now” button downloads a PDF order form.
- Several pages present on the server file system had no links from the anywhere on the live site. These were intended to be part of the site and omitted accidentally.
- Overall, there was a general lack of consistency to the site. Content that is in boxes on one page floats without a border around it on the next. Text that’s styled like the links on one page aren’t links on another. All in all, it gave the impression of being shoddy workmanship.
All in all, this is pretty amateurish stuff. Any competent developer would catch this stuff with a quick once over of the site. Not only did the developer not catch it, but when pointed out on a page as an example of a problem with the whole site, he fixed only that page and not everywhere else the problem occurred.
Rewarding the Guilty and Blaming the Innocent
Customer’s point of contact for this project was, well, I’ll call him Irving Thomasso Guy. IT Guy was the directly assigned labor on the project. He built the site. From her first description of him, I thought him well-meaning but incompetent. I reasoned that since he had no talent with graphic design, layout, or site usability, he must be a pretty good database and scripting developer.
This seemed plausible, as IT Guy was assigned to the project at the first meeting where it was discussed. No one took the time to analyze the kind of site being built to recognize that good aesthetics were all that mattered in the complete absence of any actual coding work. There was no project manager of any kind for the project; where a good project manager spending even 5% time overseeing this trivial job would’ve quickly picked up that the wrong person had been assigned. In fact, Customer described to me that another developer clearly had the right skills and ideas, because in walking past IT Guy’s desk, he would make suggestions that resulted in significant improvements to the site. Too bad he was just passing by and not given the job.
It became apparent, however, that the problem ran deeper. IT Guy had a sign over his desk reading, “Clock In, Clock Out.” Apparently these are the watchwords of his work ethic. On several occasions he committed to several days of development work knowing he’d be out of the office for training the rest of the week. At one point, he told Customer that if he had designed the site, he might take pride in its development, but as it was her design, he was just there to mechanically do what she told him to get the thing online. I think I actually take more pride in folding laundry than this guy does in his… you know… career.
Bottom Line, and Digging Ever Downward
Bottom line, this was a failed project. Months overdue. Customer provided a list of changes required before the site would meet its initial requirements, and it was returned with fewer than half of them made. I guess IT Guy thought she wasn’t going to check, or something. If her organization’s IT department had been operating as an independent contractor or firm, prompt payment would be the least of their worries. A court date might well be in their future.
This is something that frustrates me about IT departments; the desire to not make waves in one’s own organization tends to shield them from the results of incompetence. I’m not saying that all large organization IT departments are necessarily incompetent, just that it seems easier for them to get away with it.
Ultimately, I suggested Customer cut her losses. The site is static HTML with some CSS for formatting. There’s no real scripting work to speak of, so there’d be little learning curve for someone else to come up to speed on the site. She knows exactly what changes need to be made and where. I suggested she get a CD with the files on it from IT Guy and take it elsewhere. Of course, he lied to her again and said that wasn’t possible. I hope I don’t end up having to fly out there…








May 5th, 2008 at 2:30 pm
There are so many scary parts about this. One of my favorites is “months overdue.” How could a project like this take months to begin with? We all like telling clueless customer stories. It makes us squirm a bit more when it is clueless/uncaring IT folks. There are organizations in which I have been that would call Mr. Guy ROAD - Retired On Active Duty.
I do think one of the challenges was identified right up front: her UNIVERSITY’S IT department. I have been in IT for a while (about 18 years) and have seen 3 kinds of people in University IT departments: ROADies, as above; students who are varyingly bright, but have no experience or intention to be there in 6 months; and people who are really good at what they do and work for the University for reasons other than a competitive salary. Universities are generally resource constrained (that is the polite term, right?) and like to use slave labor ^D^D^D^D^D^D^D^D work-study programs for as much as possible. Many of the students are competent, or even better, but lack oversight, experience and long-term commitment. There are far too few people in the last category.
The security industry is accused, with good reason, of forgetting occasionally that IT systems exist to allow people to do work. I have been guilty of that myself on occasion. Right now my job is to try to translate business requirements into technical solutions, and vice versa. It is hard enough when the 2 sides just don’t understand each other, in this case it appears that IT is not even trying to provide a service. It reminds me of the “service” part of “civil service”. If you work in IT you are overhead. In any company you should be making money, helping the people who make money, or working on your resume.