This was a suite of six Web applications to view, edit, and maintain enterprise meta data. The suite is a proprietary design. Please ask to see a scrubbed screenshot.
When the project first began, we were looking at adding new functionality to the existing system. But once the system designer got into the code, and talked to the SMEs about performance issues, it quickly because clear that the entire system had to be rewritten.
While this added to the scope, time and budget of the project, approval came quickly as all stakeholders understood the issue well. They’d been using the system for a year and everyone hated it.
Since everything had to be rewritten (the UI, the midtier as well as the logical and physical structure of the database), I took the opportunity to propose a total redesign of the UI. Initially they were planning on just rewriting the code and adding pages for the new functionality. I talked with them about the information architecture of the site, the fact that it looked awful from an aesthetic perspective, and that embedding presentation code within each page was not the best way to manage it.
On all counts the team agreed. I met with the sponsors and the project manager and received their approval as well. I didn’t talk about Information Architecture; I talked about the overall organization of the features. For example, putting the management of Admin users and regular users on two different pages wasn’t necessary. I didn’t talk about the ugliness of the site; I talked about being able to easily match the site’s look and feel to the company’s branding standards. And I didn’t talk about CSS (except to the developers); I talked about easily managing the look and feel from one file instead of making changes on each HTML page on the site (which when we got done was a 70 page app).
I found early on that talking about user-centered design (UCD), IA, CSS, etc., tend to put most project members to sleep. But when I put it into terms of work flows, ease-of-use, branding, and ease of managing the site I meet with success. Understanding and speaking the language of your audience, while still following the fundamentals of UCD is the best path to success – personally and for the product.
Knowing that I have many levels of customer from Sponsor (and sursequently (it’s a word now!) the company) to the project team, to the end user and knowing what each customer needs makes me more successful as well. A PM doesn’t want to read a function allocation table, but a business analyst does. An end user doesn’t care about how tight the CSS file is, but the developer does.
Things That Could Have Gone Better
Analysis and Design took longer than expected. This was due to two things: turn over in resources and the requirements for a major part of the application were not as well defined as the business partners has portrayed.
The first part is always an issue. People get moved around from project to project midstream all the time. However, out of 40+ projects I had not seen so much resource switching before. It slows things down due to the new person having to get up to speed with everyone else.
The second part was the biggest factor to the hit to the timeline. The business partners and the SMEs really thought they understood the requirements. They did, but they each had their own individual understanding. Requirements were written down, but not well detailed and there was disparity in meaning.
So I spent a large portion of my time helping them flesh out the requirements. This is not in my job description per se, but I find that I spend more and more time doing it because business analysts don’t seem to have a refined understanding on how to find requirements, let alone define them. Because of my background in finding and defining user requirements, I naturally fell into the role of BA for a time.
The other major factor that inhibited the project was the use of off-shore development. I have been on projects were off-shore use was helpful, and I have been on some where it is horrible. This time it was horrible. Documentation is the make-or-break factor in off-shore development. We had a lot of trouble with the data models, and a lot of confusion ensued. The UI specifications I created worked well enough, but then a large part of UI specs is describing the presentation and since I developed a CSS file there really wasn’t an issue.
What I did miss out on was acceptance testing. This was partially due to off-shore development, but was primarily a factor of the project world. I was moved on to another project by the time the team got to acceptance testing. The app is now in production and from what I have seen they got it mostly right. It looks as though they changed some things in the CSS file and whoever did it doesn’t fully understand CSS. In the end it is not a problem. The app functions very well. Feedback from the field has been very good. The search function returns results in less than 3 seconds (it was over 15 seconds before we started).
What I Will Do Differently Next Time
I have already had a couple of next times. The lessons learned on the project I described here fall under the double-edged sword category.
Due to the nature of the development methodology, it is difficult to invest an in-depth effort into each project. But I am finding that my work is overall much easier if I do invest. Well, actually my work gets harder, but there are less headaches and surprises.
I look now to get allocated to an effort even before it kicks off. I get to know the developers better, even in off-shore situations. I find that knowing them, and letting them get to know me makes the entire process go much more smoothly. I help write requirements, even beyond user requirements. It is drilled into my head to focus first on the what’s then go on to the how’s. This isn’t true of most of the other roles I work with. I help keep them focused on the what’s during requirements analysis and have received many compliments for doing so.