One of the popular sessions at bpmCamp was a session on offshoring, from which we have a few notes preserved.  Steve Lang from Ford moderated the discussion, which by all accounts was a lively one.

Several of the teams in attendance pointed out that they already have distributed teams, geographically, within the United States.  So the teams are accustomed to conference calls, IM chats, etc.  The teams are largely effective at handing off work remotely as well.

The challenge of a lack of timezone overlap hurt some off-shoring efforts.  Also, a reliance on “hand-offs” (ie, throwing a spec over the wall and expecting to get back a finished deliverable) was not working well for BPM deliverables.  There was a big challenge around how to structure teams and deliverables to get maximum “yield” out of the combined onshore-offshore teams.  One participant pointed out that the problem of hand-offs not working was between roles in the same geography – not just between geographies.  And everyone had problems with attrition undercutting their efforts to onboard staff.  Interestingly there wasn’t much discussion of different locations for the offshore work – not sure if this is because almost all of these projects were considering off-shoring in India or if the geographic differences weren’t that interesting to get mentioned.

Some of the suggested ways to address the challenges:

• Extensive use of webcams, IM, and screen-sharing
• Don’t settle for “newbies” in the offshore team – press for the most experienced people you can get
• Don’t try to fix the scope for your BPM project – BPM scope needs to be flexible to do it right
• Use a tool (e.g. Rally) to improve tracking and transparency in an Agile project
• Eliminate barriers to communication (e.g. going through “proper channels”). People on the project should have access to communicate with anyone else on the project without asking permission. (Emphasis on collaboration)
• Increase time overlap for the onshore and offshore teams.
• Have onshore or offshore members visit opposite location to build relationships and come up to speed.

I’ll make another recommendation: use an offshore team that actually does this stuff for a living in their local geography.  There are many issues working against you when you offshore BPM work -but don’t let a lack of appreciation and experience with BPM be one of them. BPM projects are quite a bit different than the typical IT project, and the collaboration required between business and IT requires more nuance and communication than the typical project.

Or was that the other way around?

Prashant Gadgil gave a presentation at bpmCamp 2010 @ Stanford on this topic – because often business process problems are described as a process but require a full-fledged web application to properly address – or vice versa.  His talk focused on helping differentiate between the two – or to know when you are stepping outside the sweet spot of what a BPMS usually offers you.  Still, if you have a process, you don’t want to lose sight of it as you build out your web application’s functionality!

There was more ground covered in discussion but I don’t have notes from this session, so the slides will have to suffice! Prashant was generous enough to allow us to publish via slideshare (and they are also available to bpmCamp participants via the bpmCamp wiki site).

More to come from bpmCamp notes in the coming week…

The first go-round on Process Debt got quite a few reads and private emails and comments that motivated me to keep thinking about his topic and how to further clarify process debt so that we can use this concept to help manage our process development efforts.  It also motivated me to run a small session at bpmCamp on Creating and Retiring Process Debt.

We had a good discussion during the presentation and lots of examples from recent history to draw on in this room.  A couple of folks from the same company were in the room and as a result they tell me that they now have a common, useful vocabulary for describing trade-off process decisions which are made *all* the time in BPM groups.

Presentation embedded here, but also some rough notes below for those who prefer reading text…

(Incidentally, I used a tool called “Prezi” for this which I find pretty useful for organizing thoughts about a topic that requires a lot of context or gets past a certain number of slides… Something about the spatial relationship of the elements helps maintain context in the discussion.)

First, let’s agree that there is such a thing as Technical Debt, as defined by smarter folks than I. But also, that we can repackage it just a bit to more closely align with Process terminology and concerns.

Why we incur Technical Debt (borrowing heavily from McConnell):

1. Time to market – we want to get our process built quickly so that we can start to reap the ROI quickly – and time is money.  If a process can save you $1M per month, each month of additional development effectively costs you $1M.  Time to market matters.
2. Preservation of budget (for startups, preservation of capital)- We have a limited budget, and we want to make sure we spend it on the things that give us the most leverage for getting ROI.  These are likely the same things that will help justify budget for additional improvements going forward.
3. Delaying development expense.  As a system nears end of life, it takes a very high degree of return to justify anything but expedient fixes -because when a system is retired, its technical debt no longer matters and isn’t paid within that system – it is being paid by whatever is replacing it.

What are the types of Technical Debt that we can be concerned with:

1. Unintentional Debt – debt incurred due to poor technical choices, but not with forethought.
2. Intentional Debt – debt incurred for strategic reasons, with explicit trade-offs.
   1. Short-term debt:  sacrifices made to get a specific release out by a certain date.
   2. Long-term debt:  typically architectural decisions (assuming only one database platform, for example) that can be good trade-offs measured in years.

And then we have “Product Design” debt – which I believe can occur in process projects where functionality is added over time until the originally simple screens have become cumbersome and unwieldy.  This isn’t quite the same as Process Debt – but process projects can become afflicted with it.

Finally, we have Process Debt itself.  I think we can follow on the Technical Debt framework and build on it:

1. Unintentional debt
   1. Process Shift – this happens when performance of the process degrades over time.
   2. Requirements Shift – this happens when the external realities change but your process fails to adjust adequately.
   3. Squeezing the balloon – the local process gets optimized at the (greater) expense of other parts of the organization (or customers or vendors)
2. Intentional debt
   1. Short-term trade-offs to get a release out – scope removed, etc.
   2. Experiments to find out which possible solution is the right one
   3. Manual work-arounds in place of system integration (SOA team can’t give you your webservice in time? will a manual work around work for the first few weeks or months?)
   4. Sub-optimal integrations (batch instead of real-time, etc. )
   5. Assumptions around geography or localization or product line support.

Tracking Debt:

1. Enter tasks into work tracking or defect tracking software to track both the items that need to be worked on and the effort required to retire the debt incurred.
2. Measure the process for squeeze-the-balloon effects (can be difficult if the other parts of the balloon are not measured).
3. Teach the team not to take short-cuts that “aren’t worth entering compensating tasks in the software tracking tool” – if they’re not worth it then the short cuts aren’t worth it either.
4. Another suggestion (from James Shore) is to measure Source Lines of Code (SLOC) as an approximation for technical debt. It isn’t an exact measure, but since lines of code will affect cost of maintenance, it is a reasonable proxy.

The starting point is that you have to have a system for tracking your work and work backlog – and from there you can mature the way you think about Process Debt based on what works for your organization.

At bpmCamp we had a great session on BPM Requirements led by Zelda Durden.  Often the answer to the question “How much is enough?” is “I know it when I see it” – but we wanted to go deeper, and Zelda offered to help shape the discussion. How can we tee things up so that we know how much is enough as part of our requirements process?

She broke things up into two phases for consideration:

1. Exploring – no budget approved yet, no Project Manager either.
   1. Strategy – what needs to be improved from 50,000 feet, and what are the business priorities and goals.
   2. People – who and how much commitment from the business?
   3. Process- scope, SIPOC
   4. System – What is the current system?  Current state of the process?
   5. Discussion:
      • getting people commitments is difficult at this stage
      • using this information to help prioritize projects – along with ROI and other tools
      • scope management is difficult once users see what is possible.
2. Discovery – a real project is on the books, with budget.
   1. Strategy – Critical Success Factors (CSFs), ROI calculations if necessary, alignment with corporate objectives
   2. People – current skill set of process users versus new required skill set?  Change management: figure out the influential people and engage with them.
   3. Process – full process audit/investigation.
   4. System – plan for legacy systems, determine the extent of Teamworks (BPMS) in the solution.
3. Development Starts

First playback drives a lot of requirements changes.  Not planning for that level of change is just kidding yourself.

• Iterative development – iterations range from 3 weeks to quarterly – which keeps the lifespan of requirements to some reasonable level.
• Initial “onboarding” of process focussed on keeping it very simple (no integrations, or as few as possible) – get the process right first.
• Best process information comes from the end users – have to get in front of them and get feedback.
• Blueprint could be used for initial process modeling / analysis – but has the disadvantage of forcing you to consider licensing issues (unless you have a site license, etc. )
• Some people don’t get flowcharts: figure out the tools that work to communicate with them.  Draw on the whiteboard, for example.
• Teamworks as a process document repository (even for processes that are never intended to be TW apps).  While this isn’t the primary use of Teamworks, there was general support for this idea.
• “BPM Document” like a mini-BRD
• BRD still developed for interfaces / web services, etc
• Plan to develop process for project selection/kickoff

There was much more discussion than what we’ve captured here – but that is the nature of these things – you get into the conversation and you forget to take notes!  A few related thoughts come to mind for me, which I’ll share here.  Our CEO, Lance Gibbs, has some great common sense yardsticks that he often communicates to people on BPM projects who aren’t familiar with how to think of requirements:

• Does it affect ROI?
• Does it impact business objectives?
• Does it impact customer service?
• Does it impact throughput?
• Does it impact quality in a measurable way?

You can think of similar questions.  If a requirement doesn’t address any of these concerns, it should probably go in a secondary bucket to “come back to later” after you’ve first dealt with requirements that DO affect these criteria.

We applied a similar approach to documentation:

• Does it reduce work?
• Does it reduce waste?
• Does it reduce risk?
• Is it required for regulatory or other legal reasons?

It turns out we as an industry turn out a lot of doc that does none of these things.

More to come from bpmCamp 2010 @ Stanford…

bpmCamp's patio

Last week Stanford hosted the first “bpmCamp” for Lombardi Teamworks and Blueprint practitioners.  By all accounts the event was a success – sold out at 40 participants – and with some truly great interactive sessions and discussion that is hard to have at a bigger forum.  Our Stanford hosts did a wonderful job hosting, including all of the little details like name badges and maps, but also helping organize logistics around lodging, transportation, parking, and providing an excellent facility in which to have our meetings.  Encina Commons is one of the older buildings at Stanford – sandstone and arches and wide covered patios, surrounded by lots of green – a perfect atmosphere for sharing.  We were lucky to get a reprieve from the rain for 2 days so that we could really enjoy the surroundings (and make the occasional trip for espresso).  Thank you to Lombardi, and Apex (and bp3) for sponsoring the dinner on Thursday night at Pampas – an all-you-can-eat Brazilian feast.

The lawn outside Encina Commons / bpmCamp

And thanks most of all to everyone who came and led a session, contributed their opinions, reached out to their colleagues and made new friends and contacts.  What a great experience.

We’ll follow-up with a series of blog posts based on bpmCamp to share some of the content with a chance to step back and editorialize a bit. The biggest takeaway that I had was that the community needed an event like this to step out of the daily grind of delivering processes and process improvement – to see what others are doing, to see the forest for the trees.  Sessions ranged in size from 5 people to 40, and discussions were often lively…

bpmCamp in Session

Meanwhile, we’ll start with a short session from Friday morning, when we had a cameo appearance from Phil Gilbert, giving his impressions of the acquisition and the plans for Lombardi products for the next 6 months.  There’s a clear focus on proving that they can deliver and innovate “even faster” after the acquisition, as Phil put it.  And they have set themselves some very high, but relevant goals.  In particular, making it as easy to install Teamworks on Websphere as it is to install Teamworks on JBoss today (cur

Phil Gilbert holds forth @ bpmCamp

rently JBoss is your option if you want an embedded appserver), and making upgrades to Teamworks 7 a truly good experience.  The goal is to bring the ease of use of Teamworks to IBM’s customers, and to leverage key IBM technologies but expose them in ways that let you cut through the noise and focus on delivery. It was a motivating message for our bpmCamp crowd because clearly Phil’s attention is still on the BPM game, and this prioritization will keep Teamworks relevant for the audience.  Knowing the developers that IBM/Lombardi are putting on this project and upgrade paths, I also know that this is a crack team of some of the best engineers at Lombardi, which says something about the commitment from the executive team.

Someone in the audience noted afterward that this was a more tactical set of goals than they expected to hear from Phil- who usually talks in terms such as “the Second Decade of BPM“… but if the focus on the tactical reveals that they believe the tactical may BE the strategic right now, I think its a welcome shift-  because truly, what’s holding people back from BPM is not the knowledge that it has value – the press and blogs are full of information on that score – but rather, its the “getting started” effort required that slows things down.  The easier a software company can make the transition from “business problem conceived” to “BPM project underway” the more likely it is that BPM software is applied to that problem instead of sticky notes and a change order on an ERP system scheduled for 2 years out.

There were so many more great sessions to report on, so there will be more posts here about the sessions.  One thing anyone reading this can do for me that will help – is let us know if you’d be interested in attending a future bpmCamp, and if you would travel to attend, or if not, where you’re located so we can judge where we have critical mass for another event.

Thanks again to everyone who participated, and watch this space for more information!

Also, lest you think that BPM was the only educational opportunity at Stanford last week, I stopped by the Cantor Museum for Visual Arts and took a few photos of Rodin sculptures – the collection is the second largest in the world and nearly every piece was on display:

the infamous "Gates of Hell"

I’m pleased to announce that Apex Consulting and bp3 will be co-sponsoring a free dinner for attendees of bpmCamp 2010 @ Stanford on Thursday, January 28, 2010. We want to welcome anyone who can attend bpmCamp to also join us for dinner and conversation afterward.  Thanks to Dave Knapp for offering to co-sponsor dinner with us, we’re looking forward to it!

Location and logistics will be announced before the event.

And if you’re reading about the news that IBM acquired Lombardi, not to worry:  bpmCamp is on, and there’s even more reason to be attending now, to keep abreast of the latest developments and make connections with a broader community of practitioners.

Registration for bpmCamp is now open.

Please Register Here.  All registrations are subject to approval to make sure that we fill our limited space with Lombardi practitioners first.  If you’re a partner or employee of Lombardi, rather than a customer-practitioner, please drop us an email (email address can be found on the bpmCamp wiki) to discuss attending and how you can help.

We’re pleased to announce the pricing for bpmCamp will be $100 for early-bird registration, and $150 after that.

Early Bird registration ($100) ends January 1, 2010.

Regular Registration ($150) closes January 21, 2010.

bpmCamp 2010 @ Stanford will get started on January 28, 2010.

Also, thanks to a tip from Sandy Kemsley, the bpmCamp wiki is now easier than ever to view – just go to http://www.bpmcamp.org/wiki/ .  Join the Google Group for bpmCamp to get editing privileges – there’s a link on the left-hand-side of the wiki that makes this easy to do, or drop us an email and I can invite you directly.

We’re looking forward to seeing everyone at bpmCamp in January!  57 days and counting.  Registration site will go up as soon as tomorrow.  More lodging and transportation logistics are coming this week as well.

Following up on yesterday’s announcement of bpmCamp, here are the most crucial details for bpmCamp, to answer the most obvious questions you might be asking.  There are many more details to come, and all of this information will find its way into a bpmCamp landing page soon enough.

When is bpmCamp?

We’ve said it before, but it bears repeating.  We’ve selected a date for the first one:  January 28-29, 2010. Mark your calendars.

We hope to host additional bpmCamp events in the future, but this is the inaugural event. 

Where is the First bpmCamp? Who is the host?
Having the right host and location for any activity is crucial.  And having the right setting can really frame an event and set a backdrop for a good collaborative and rejuvenating experience.  I think that we have scored on both counts with our hosts for the inaugural bpmCamp.

I’m very proud to announce our host for bpmCamp:  Stanford University -  specifically, the Stanford SeRA BPM team. I’ve previously blogged about their potential contributions to the BPM community.  We share a vision of a more collaborative and communicative practitioner community and this is our collective attempt to initiate something that can really improve all of our efforts with BPM.

Lee and his boss Minh Nguyen are graciously donating the use of a beautiful conference setting for this event,* including A/V and wireless Internet.  We’ll send out exact location details as we get closer to the event, but our tentative location includes a fully equipped room and two fully-equipped breakout rooms.  The outdoor space surrounding is beautiful, and Stanford isn’t the kind of place that gets snow in January.  We couldn’t be happier about the location, and we couldn’t be happier about the spirit of collaboration and community our hosts and location will help foster for this event.

We’ll follow up with information about transportation logistics, hotel options, and other sundry details as we get closer to the event date, but in plenty of time to make plans with that information. Stanford has excellent transportation and lodging facilities surrounding it, so we’ll have some top notch options available to us.

*The free space is limited, however, and if we outgrow it based on interest, we’ll have to either limit attendance or explore other options on campus that will cost a bit more. Also, bpmCamp is not *sponsored* by Stanford – but Stanford is hosting the event, donating use of facilities, and Stanford BPM community members will be full participants in the event – Stanford is not endorsing the products or services of any of the sponsors or attendees of bpmCamp.

Where is the Landing Page?
The landing page for bpmCamp will be coming soon.  We’ll send out pointers to it when it is up.  In the meantime, you can keep up with announcements by following the RSS feed for the bp3 blog, or by bookmarking posts tagged with bpmCamp.

Who’s Invited to bpmCamp?
The goal is to have a high-quality gathering of people who know the products well and are looking to collaborate and exchange ideas with peers and colleagues.  We’re inviting customer / users of Lombardi products (Teamworks and Blueprint) who participate in deployments to attend, and we’re extending an invitation to Lombardi to participate as well.  If you’re a Lombardi or bp3 partner interested in attending/sponsoring the unconference / bpmCamp, please reach out to us at the email address below.  If you’re an analyst or blogger and you think bpmCamp would benefit from your attendance, contact us.  If you don’t fit any of the above descriptions but still want to attend, drop us a line with your thoughts.  All attendees will need to register, once the registration site goes live.  If you’re interested in receiving an invitation to register, send us email at the bpmCamp email address.

How to contact us:
The best way is via the bpmCamp email address:

I want to Sponsor bpmCamp – how can I help?
If you think your organization would be interested in being a sponsor for bpmCamp, please contact us at the above email address and let us know you’re interested.

How Much Does it Cost to Attend?
We do expect to charge an attendance fee, which I believe is a departure from typical unconference protocol, but we’re doing so for a couple of reasons.  First, we have limited space, and we want to make sure attendees are serious about coming.  Second, if we need to go to a larger back-up space, that may require additional expenses (which attendance fees would defray).  We have a nominal fee in mind – primarily to cover catering meals- and are in the process of proving out the budget.  As soon as that process is complete, we’ll update with pricing information.  I don’t want to publish tentative numbers, but if you need to know ballpark just drop us a line and I’ll tell you privately what our working numbers are.

What will bpmCamp Cover?
We will beat the drum for topics and themes that we think will resonate.  However, we want this conference to cover topics that YOU care about.  In particular, we want to crowd-source topics for the event so that we can make sure we cover topics that attendees really care about.  The expectation is that the setting will be ripe for interaction among attendees during the sessions – that very few of the sessions will be presentation form rather than a loosely-moderated-discussion format.  However, we think it likely that attendees will be interested in a keynote address or two with Q&A to follow.  What kinds of things are fair game, you may be asking?  How about:

• Building Teamworks Coaches with YUI or GWT?
• Actual use of Optimizer in the wild?
• How to make Teamworks scale Really Big?
• Design reviews of actual Teamworks Processes?
• Making my Waterfall organization more Agile/Iterative?
• Tools for managing BPM projects (something better than MS Project??)
• <fill in the blank!>

We’ll have room for breakout sessions to accommodate more than one interest at a time.

Who is Coming?
We’ll release information about attendees and speakers as we get closer to the event date.  Expect the bp3 team and the Stanford SeRA team to be there!

Why focus on a single vendor? Why not another BPM product? Is this a Lombardi-sponsored Event?
In short, we want the specificity and detail that we can get from a single-vendor conference, but the independence of a crowdsourced event.  bpmCamp isn’t sponsored nor endorsed by Lombardi.   We chose Lombardi products because it is the BPM suite, and community, that we have the most extensive contacts with (and because we had already decided that a single-vendor conference could be interesting).

While we’ve worked with other tools and vendors, our network is not as deep in those communities.  If you work with another software vendor or geographic location and you’d like our help to run a similar event with you, get in touch with us, perhaps we can help.

(editor’s note: bpmCamp is not affiliated with or sponsored by Lombardi.  bp3 is not acting on Lombardi’s behalf, nor is bp3 an affiliate nor subsidiary of Lombardi. )

Background: BPM Conferences Are Good…
Conferences are a great way for colleagues and peers to network, share best practices, and re-energize and re-motivate their efforts.  In particular we’ve enjoyed participating and presenting at Lombardi’s Driven conferences in the past, and at bp3 we’ve attended Lombardi Driven, Appian’s conference, OMG’s Thinktank, Gartner BPM, and Forrester BPM conferences (when we weren’t too busy with customers).  Conferences have some of the value of an off-site meeting within the company: recharging the batteries and motivating action.  But they also provide a chance to be exposed to much more diverse points of view, to out-of-the-box thinking, to new tricks of the trade, and to new market dynamics.  In smaller conferences, or small breakout sessions, real discussions break out that can really be illuminating (OMG’s Round Table format is a well-known example of formalizing this kind of small-discussion format, and it led to the six barriers to BPM Adoption at a very humorous and educational round table that I was fortunate to attend).

…but Missing the Mark.
There are just a couple of problems.  First, conferences run by Analyst firms and Conference organizers are often too expensive (especially with today’s budgets).  Second, vendor conferences are too focused on the sponsoring vendor’s messaging, and often neglect the real needs of attendees. Attendees to both types of conferences get value, but I often hear them expressing an interest in getting into more detail – moving past concept to tactics.  Moving past platitudes to showing real solutions.

Its our belief that it is just too hard to get into the specifics and details in a multi-vendor conference.  Even with respect to project methodology, the *right* approach to a project has to take into account the realities of the technology being used.  If you’re using a BPM tool that doesn’t provide rapid UI prototyping, you’ll need a different approach to your project than someone using a BPM tool that does provide rapid UI prototyping.  And that’s just one trivial example.  When we get down to sharing technical best practices, going cross-vendor just doesn’t make much sense- BPM execution level detail simply isn’t that portable.

…So What’s the Answer?
If we put together a conference that is focused on what attendees want to talk about, we’ll get more value for the dollar.  If we aren’t looking to clear a profit on the event, we can lower the investment barrier required to attend.  If we focus on a single vendor, we can focus all the way down to shared source code if it has value. To that end, we’re going to borrow from concepts pioneered by unconferences and barCamps, leveraging advice from folks who put on the SXSWi barcamp in the past.

With preamble aside, I’m very happy to announce what I believe to be a first:  a BPM unconference for BPM practitioners of a single product suite.  We’re calling it bpmCamp.

This first event is focused on users of Lombardi’s Teamworks or Blueprint products.  We’re focusing on this community because it is the set of products and practitioner community that we have the deepest connections into, and because we want the event to be a single BPM product event for the reasons stated above.

Why bpmCamp?

We really think the BPM community/ecosystem needs events like this to foster growth, success, and maturity.  We believe maturity requires:

• technical breadth and depth
• project methodologies to support the roll-out of processes and improvements to those processes
• process improvement techniques and strategies that can actually be implemented and maintained in BPM suites

Also, we actually want to learn something new.  When we get the right  practitioners in a room, we’re going to learn from them, and help propagate those best practices into the BPM ecosystem.  We’re also going to share what we know from prior experience directly with the conference.  This cross-pollination is good for everyone.

Finally, we decided to put action behind our words.  We’ve long agitated politely for more tactical, focused topics at BPM conferences, but we’ve reached the point where it is time for us to contribute back to the community by creating an intimate event that fosters that kind of discussion.

When is bpmCamp?

We’ve selected a date for the first one:  January 28-29, 2010. Mark your calendars.

We hope to host additional bpmCamp events in the future, but this is the inaugural event, and it should be special.  Please watch this blog as we’ll put up an F.A.Q. as soon as tomorrow with more details.

If you have any questions in the meantime, contact us at:
bpmCamp Email: 

(editor’s note: bpmCamp is not affiliated with or sponsored by Lombardi.  bp3 is not acting on Lombardi’s behalf, nor is bp3 an affiliate nor subsidiary of Lombardi. )

We’ve been blogging about BPM and the economy since last fall.  In particular, it started with a talk by Jim Sinur at the OMG BPM ThinkTank 2008. So it seems fitting that another post by Jim got my attention today, and this time it was about the Gartner conference on BPM in London.

It reminds me that Gartner is really getting behind BPM – including publishing their Magic Quadrant for 2009 – and that the message that BPM is a key investment area for most firms (and therefore one of the most recession-proof IT sectors).  I don’t know what Gartner would typically see at a BPM conference in London, but I am guessing it is typically something less than 300 people.  Another conference is coming up in San Diego, and I expect it will be hopping.  Jim Sinur points to the fact that BPM can help your business survive, thrive, and capitalize.  We’re seeing projects that are targeted at each of these objectives – short-term survival, longer-term thriving, or capitalizing on the distraction the economy presents for weaker competitors…

I think the assumption is that conferences will have weaker attendance this year.  But I think if the conferences get the content / agenda right, and press their case with attendees, that they’ll see good attendance.  Getting it right means: focused on value and giving attendees ways to make back the investment they are putting into the conference.  BPM conferences in particular should be doing well this year, relative to the whole, I think.  More to come at the end of March…