— 12 August 2004 —

Portfolio – Enterprise Metadata

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.

Project History

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).

Success Factors

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.

Respond Eloquently Below

April 2008 March 2008 February 2008 January 2008 December 2007 November 2007 October 2007 September 2007 August 2007 July 2007 June 2007 April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 April 2006 March 2006 February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 January 2003 December 2002 November 2002 October 2002 September 2002
Snook Approved!