Bridging the Gap with UI - Part 1
It is tempting to go on and on about the relationship between business and IT. Here at Lombardi we like to instead talk about effective cross-functional teams that can build the end-to-end process together. And we practice what we preach - this is why we have BPM Analysts, Consultants and Developers on our delivery teams. Note this does not mean companies have to fundamentally re-organize, but they do need to be able to create dedicated cross-functional teams if they are going to be successful.
That being said, I think that user interfaces are key to how these cross functional teams can work together effectively. This is something that I touched on briefly in my previous post about Web2.0 and “making BPM cool again.”
First let’s provide some context — traditionally, in the BPM world, UI development occurs in the design phase of a process, building on top of what has been accomplished with the flow, integration metrics and controls stages, etc.
But one of the things that I like about Lombardi is how we are structured. Our design group is part of our product management organization, and we work closely with the product manager and our clients from the very beginning, which is untraditional. We’re really the first consumers of any information.
More specifically, we work closely with the product team to make sure we understand what the goals/tasks of the users are, from the start. We use personas here - for example we have businesspeople and IT technical developers and architects that we refer back to, always thinking about what each person wants and needs from a UI perspective. We also do site visits, spend lots time with our customers, doing plenty of onsite testing, customer calls with sales people to demo the product and more. We want to understand what our clients are thinking. We try to get an idea of what is going on at every stage, which helps inform our design decisions. We get as deep and engrained as we possibly can, and it’s worth every bit.
That is, in order to effectively utilize a cross-functional team, you first have to first understand on the most granular level what the needs of each constituency are, at each stage of the process. This might sound obvious, but it isn’t so simple in practice. You can’t fake the knowledge that you need - you have to go out and get it, aggressively if need be. I can’t say enough how much research and user studies are an integral part of how we think about interfaces.
Quickly you’ll realize that in that hand-off between the two organizations, there is a lot of stuff that an IT role might, for example, want to hold onto because it involves what they do well, and there’s a bunch of stuff that IT needs to hand off to a business role on the team, but typically can’t because the UI doesn’t support it. A good UI allows each user to focus on what s/he does best, and this is Rule #1. Trying to find the right way to solve this problem is what keeps us going from a design perspective, and is why we start work at such an early stage. And if you’re evaluating UI’s from a purchasing perspective, for any software category really, it is imperative that a given solution do just that - allow users to focus on doing what they do best and not get in the way.
Now, given a deep understanding of the needs the cross-functional team (and roles), what comes next?
Ed: We’ll continue this post next week with Part 2, in which Craig talks about how to get IT and business on the same page by making careful decisions about the interface(s) through which these two groups interact.
Questions? Leave a comment!


Process People: Describe in as much detail as possible the problem or need on a project level that first made you consider BPM and/or Lombardi as a viable solution.
Unfortunately, this approach just doesn’t work when documenting business processes. It’s not the processes themselves that present a problem — it’s the people. When you try to document each step chronologically, the inevitable result is a trip down rat-hole lane. Rat-holing is when you get caught up with the minor details and exceptions that occur in any process. I’ve seen documentation sessions go on for hours with little to show for the effort because each stakeholder in the room was preoccupied with the subtle exceptions to the steps that they themselves were most passionate about. 





