Comments on Enterprise IA Methodologies:

Evan Smith — Sat, 09 Aug 2008 02:44:43 GMT

Thank you, James. This is my first read on ‘boxesandarrows’ as well as my first post. I am an emerging IA within my company and self-taught (and still learning). Your article has hit on some very key issues that reinforce some ideas I’ve had about Requirements Gathering and Needs Analysis. I look forward to learning a lot more with you and everyone else here, as well as sharing our experiences. Thank you again for a great post and an interesting read. -Evan

Marianna Samara — Mon, 18 Feb 2008 11:53:20 GMT

Nice approach of user needs. In my opinion, these two steps are also neccesary in web or design projects too.Throughout each project development the main focus should be on users needs (by users I mean the people working inside the company that i.e. need a redesign of their web site) as they will actually interact with the system once it is finished. Before starting to develop a draft IA, much time and thought should be spent on how you’ll identify user needs and developing an overall stategy by indicating the objectives and scope of the system.

Stephen Ruiz — Fri, 01 Feb 2008 20:21:16 GMT

This is a great article. Thank you.

Alexander Wilms — Sun, 18 Nov 2007 20:11:09 GMT

Interesting read. Even beeing “insiders” we need to spend large amounts of time to understand the business processes of our own departments.
Creating a new service or changing an existing service might be easy if you have to deal with simple business tasks (as the call center operation you descibed), but gets very difficult if business stuctures are unstructured or differ by location or country. In a simple case like the one described, with stable operational processes it might be sufficient to visit a department for some time to get a good understanding. But how do you handle a situation where you deal with departments in several countries, with different national legal regulations, different ways of “how we do it over here” and all the political issues that will come up when you start to change people’s workspace?
I am also wondering whether the sequential approach you descibe is the right way here? If business processes cannot be made transparent (despite thorough analysis) and you need the stakeholder’s “buy in”, a rapid approach with frequent feedback to and involvement of the stakeholders might be more appropriate.
What is your experience?

Richard Dalton — Wed, 16 May 2007 07:35:04 GMT

Juan – in many cases it does all come down to some kind of contact with external users. We’ve been successful at doing the kind of things James highlights with external users – see a presentation myself and a colleague gave at the 2005 IA Summit: A Foray across Boundaries: Applying IA to Business Strategy and Planning (http://www.iasummit.org/2005/finalpapers/104_Presentation…) – the Capability Discovery Map in the first case study was a way to bring together external user and internal stakeholder goals/needs/points of pain.

Juan Ruiz — Mon, 30 Apr 2007 03:40:37 GMT

James, this is a very good article outlining what needs to be done before tackling the problem already defined by our clients, especially for internal applications (ie. intranet projects). As you mention, many times, the real problem is not well understood by the client and they tend to focus on common and/or popular solutions rather that understanding the real problem and finding the proper solution.

I would like to mention though, that ‘needs analysis’ is successful if performed inside the organization because we have direct contact with staff and other workers within the organization. As for building external web applications or websites, where the general internet user will use the application, I find it hard to incorporate a ‘needs analysis’ approach since I don’t have direct contact with external users. Putting together a ‘Business Analysis’, ‘Project Requirements’ on the organization side of things, and a ‘User research’, ‘User tasks and goals’ on the user side on things, help identify what the ‘needs analysis’ achieves for the internal projects. Or, do you have an example on how to use this approach on external web applications?

Michael Beavers — Fri, 27 Apr 2007 13:50:19 GMT

James, thanks for writing this. I think that one of the easiest mistakes IAs can slip into is to dive in to start working a problem that a client hands to them, rather than investigating to see whether the problem a client thinks they have is the real challenge.

Anita Salem — Mon, 30 Apr 2007 03:21:44 GMT

James, thanks for bringing up the more strategic aspects of the work we do. I do think that many IA/usability/UCD people can be overly focused on the tactical “problem solving” aspect of our work. Good architects should always be looking for underlying business and user needs to provide value. Like Ray said, though, we are really not doing structurally anything different than has been traditionally done in product development. What I think we do very differently is apply design practices (prototyping, iterations for example)to business problems. We also uncover issues through a bottom up approach (interviewing, field studies, etc.). The iterative, empirical, user centered processes we use are what differentiate us from the other traditional processes.

Patrick C. Walsh — Fri, 20 Apr 2007 13:20:19 GMT

I totally agree with your approach. In my experience the data required for a really effective EIA is rarely available unless you go out and get it. On many occasions when I have conducted research amongst staff members (for both quality and IA issues) they have commented that it had been the first time that anyone in the organisation had asked what they thought of anything.
Regarding ‘ethnography’, I’ve been doing it for years and didn’t know. That will look good on my CV!

Paul Sherman — Thu, 05 Jul 2007 16:06:00 GMT

Thanks for a good read James. A couple of comments: You said of user needs research:

“Rather than support the design process, this research helps the IA understand the nature of the problem.”

Maybe I’m picking at semantic nits, but it seems to me that because a “design” in our world is a functional description of a problem-solving tool, there is very little – maybe no – difference between understanding the nature of the problem and the early stage design process.

My last comment is on your “strategy and scope” section: for anyone interested in a structured approach to negotiating strategy and scope, I HIGHLY recommend Adam Polansky’s chapter in “Usability Success Stories.” Full disclosure: I edited the book. But I’m propping Adam, not me.

I find I just keep returning to Adam’s case study for bite-sized nuggets of smartness.

Glen Wallis — Thu, 26 Apr 2007 21:12:33 GMT

Excellent article James. I will pin Diagram 2 on my office wall.

I don’t think the methodology you suggest is confined only to the enterprise space. Conducting a needs analysis and documenting strategy and scope is good practice in any project.

Ray Whitney — Sat, 09 Aug 2008 02:30:10 GMT

James:

I always appreciate your articles, since enterprise-scale projects have been my bread-and-butter.

I generally agree with this article, but I think that you are creating terms (or not using terms) for things that already exist (and have perfectly adequate labels). As a result, the water gets a bit muddy.

This muddiness concerns me, because working within the enterprise places a premium on communication across disciplines and organizational levels. As a result, using terms that are well-understood is critical to accelerating and achieving success.

Please bear with me here as I quote you and provide alternatives.

You wrote:

“The needs analysis then informs the creation of an overall strategy, scope and direction. From this clear framework for the IA work, a comprehensive overall roadmap of the activities required can emerge. “

You also refer to this process as a “holistic needs analysis.”

I would call these activities “Requirements Gathering” and “Business Analysis”. These are traditional terms that are understood throughout the enterprise. Personnel with these skill sets are found in many levels of the organization, so it is easy to get a group to grok the activities you (so rightly) identified.

While I understand that there are nuances (you appear to be emphasizing the ethnographic elements of the needs analysis), I do not nees the value of applying a new label to an old task.

You also wrote:

“The strategy also identifies the most critical issues to be solved, along with the activities with the potential to deliver the greatest business benefits. In this way, the IA work can be targeted for the greatest impact.”

and

“Together, the strategy and scope define the “problem” and provide a concrete context for the user-centered design process. Along with the illumination of the practical aspects of the work to come, the strategy also builds the business case for change and creates a sense of urgency.”

I would call strategy and scope development “Product Management”. Again, this is a term well-defined within the enterprise. In this case, you did not apply a new label. I would, however, call it what it is.

While I fully recognize that there are nuances, I find that I have far greater success using generally-accepted terms for processes and roles that already exist within the enterprise.

One of my criticisms of the IA community is that we tend to make it all about us. In this sense we are pre-copernican: the universe exists around the IA.
The reality is far different: IA is a component of the greater enterprise. We need to better understand how we fit into that particular picture.

Richard Dalton — Thu, 19 Apr 2007 12:05:18 GMT

The description of the “Enterprise IA Approach” is spot on – early thinking uncovering the strategy which drives the scope (to use JJGs planes) which then leads into more detailed research/thinking to define the structure, skeleton, surface, etc. HOWEVER, why is this exclusive (or more predominant) to an Enterprise environment? Many IAs (and people who have never heard of the term IA) are doing just that in a non “Enterprise” space.