An article in the Austin-American Statesman, not long ago, posited that there was, in 2010, a dearth of ‘camps, after a flurry of them in 2008 and 2009.  However, a quick followup was penned by Omar Gallaga, about the fact that ProductCamp was still going strong.  Mostly, Camps are free events sponsored in someone’s corporate offices or in a bar (thus the early “barCamp” labeling), and generally only target local attendees.  But these events are hard work to put on:

Paul Young, who founded ProductCamp Austin, said many events modeled after the same concept simply petered out for lack of interest or organization. “They show up, run their cycles, then die out,” Young said. “I think the reason that happens is that people are surprised for an ‘unconference’ how much coordination it actually takes to put an event on.

I think people are also surprised how difficult it is to pull off a free event!

We’re proud to be having bpmCamp in Austin as well. While we couldn’t pull it off as a free event, we are keeping it as affordable as possible, while still making the event attractive enough for people to travel to Austin to attend.  We also freely admit that we need to produce some of the content up front for similar reasons, rather than doing it all on the fly – but we’ll also keep time (and rooms) available for impromptu sessions that weren’t thought of ahead of time.

If you are interested, the registration page is right here. You just need to be a Lombardi BPM practitioner to attend.

bpmCamp is back, and it is coming to Austin, Texas!  We’re very proud to announce that we’re holding the second bpmCamp here in Austin.  Time is short – only 52 days until the event starts!  It is an aggressive time frame but with urgency comes creativity.  Following is the F.A.Q. with all the most important questions addressed.

F.A.Q.

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 Austin bpmCamp:  October 14-15, 2010. Mark your calendars.

We hope to host additional bpmCamp events in the future.  The first was at Stanford. This one, in Austin, should be special because of its proximity to ground zero of the Lombardi ecosystem (Lombardi’s headquarters was Austin, and IBM has a very large operation in Austin, including the Lombardi team).  It is also the headquarters of BP3.

If you have any questions in the meantime, contact us at:
bpmCamp at  bp-3.com

How Much Does it Cost to Attend?

bpmCamp Austin does not benefit from the free space that Stanford provided to the inaugural event.  Still, we’ve managed to find an affordable venue with great food, and therefore the impact on event costs was reasonable.  We’re charging $150 to attend the two-day conference (early-bird) from now until September 17, 2010.  Regular pricing will be $200 -  and the last day to register is October 7, 2010.

How Do I Register for bpmCamp?

Please go to:  http://bpmcampaustin.eventbrite.com/ to register! ( Early Bird Rates apply until January 1, 2010).

Where is bpmCamp Austin? Who is hosting?

Having the right host for any activity is a plus.  And having the right setting can really frame an event and set a backdrop for a good collaborative and rejuvenating experience.  BP3 will be the hosts for the event.  We’ve been working with BPM and Lombardi’s products for more than 7 years, and we’re looking forward to hosting the kind of informal conferences we always wanted to attend, right here in our home town.

We’re having our bpmCamp 2010 @ Austin event at III Forks Austin – one of Austin’s finest restaurants, but also a space that has a great historical Austin vibe to it, even while housed inside one of the more modern “Austin Architecture” buildings in town.   Importantly there is a lot of informal gathering space available, as well as a main room and at least two break-out rooms. III forks has been great collaborating menu options and space with us.  We’ll be a stone’s throw from Town Lake (aka Lake Lady Bird), right across the street from City Hall, and within walking distance of many restaurants and other venues.  Austin itself is home to Lombardi, and the base of operations for Lombardi as a part of the larger IBM campus here.

Travel Logistics

Please refer back to this page for travel logistics.

Where is the Landing Page?

UPDATED:  www.bpmCamp.org

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/Lombardi Edition and Blueprint) who participate in deployments to attend, and we’re extending an invitation to IBM/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 (there are limited sponsorship slots).  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 do I Contact the Organizers?

The best way is via the bpmCamp email address:

bpmcamp at  bp-3.com

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.  Please respect that we are keeping sponsorships limited to prevent over-commercializing and to make sure the sponsorship is worth something.

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??)
• Incorporating A/B testing into my process
• How much requirements gathering is too much?

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

Go HERE to add your ideas to the Agenda Wiki.

Who is Coming?

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

Why focus on a single vendor? Why not another BPM product? Is this a Lombardi- or IBM-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 Edition and BPM Blueprint 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.

We now have our venue chosen for bpmCamp 2010 @ Austin, October 14-15, 2010.  We’ll be at III Forks Austin, right in the heart of downtown, next to City Hall and the Lake.  III Forks is one of Austin’s best steakhouses, but it also has a great interior space for meetings of our size, and they have agreed to open their doors during the day (when they are normally closed for business), to host bpmCamp!

I want to thank III Forks Austin for allowing us to u

se their space.  We’re looking forward to some fantastic food and snacks during the day.  Moreover, thanks to Red Velvet Events for helping connect us with III Forks along with other finalist locations.

We’ll have more announcements on this space, regarding bpmCamp, as we get the wiki, mailing list, and other travel logistics sorted out.  Please let us know if you have any questions – either in the comments here, or on our various email addresses.

Keith Swenson has announced a case management mentor meeting (or ACM Mentor Camp) following the BPM 2010 conference, at the same venue:

The “Adaptive Case Management Mentor Camp” has just been announced.  This will be a meeting of minds for people interested in learning effective techniques for using case management for knowledge work.  It is right after the BPM 2010 conference, at the same venue, symbolically representing ACM as the next thing after BPM.

I think it is a great idea to put something like this together – these informal gatherings are often more valuable than more formal conferences – the only danger is conference burn-out!  At BP3, we’re looking forward to bpmCamp in Austin.   Sadly, I can’t make BPM 2010 this year unless my schedule changes, and therefore I also can’t attend the ‘camp.  Its a great gathering of people, definitely recommend attending to anyone who can make it.  Keith argues that the symbolism is that ACM is the “next thing after BPM” – but I’d argue it also supports my point of view – the same vendors, practitioners, and customers are going to be interested in BPM and ACM…  Keith and I just draw different conclusions about what that means for what will be defined as the “BPM” market.

We’ve set our dates for bpmCamp 2010 @ Austin:  October 14-15, 2010.

Watch this space for additional announcements about bpmCamp 2010 @ Austin.

We had a great success with the original bpmCamp @ Stanford in January, this year.  We’re now ready to start the ball rolling for a bpmCamp in Austin.  We’re just at the formative stages, but we are targeting dates in October, and currently scouting locations in Austin.  We’ve also had tentative discussions with Stanford about having another bpmCamp at Stanford, but a bit later in the year 2011 (maybe even in the summer of 2011). Our goals and thought process are much the same as last time:

1. BPM Conferences are good, but BPM Conferences are (usually) too general, too big, too expensive, and stuck on platitudes because of the above.
2. bpmCamp is intimate. It was 40 people (max capacity) at Stanford.  We’ll figure out our max capacity for Austin, it might be just a tad bigger.
3. bpmCamp is specific.  We will be focused on the Lombardi Software products acquired by IBM earlier this year, and now known as IBM BPM Blueprint (aka Blueprint), and Websphere Lombardi Edition (aka Lombardi Edition aka Teamworks).  (We would welcome the chance to organize a bpmCamp for another product offering – but we need a partner to help)
4. bpmCamp is affordable.  Exact price is TBD, but it won’t break your budget.
5. bpmCamp is focused on what attendees care about.  Topics are crowd-sourced, so anyone attending can help shape the agenda.

If you’re interested in attending, watch this space, or keep an eye on posts with the tag bpmCamp. If you’re interested in sponsoring bpmCamp, we’ll have more details about that soon.

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

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

I’ve been a little remiss in reporting in on my own session at IBM Impact.  As part of Lombardi Day, I gave a short presentation on the unconference we put together, in collaboration with Stanford University, in January.

I’m embedding the presentation here – I added a couple of words and images to clarify a few points that I can’t talk to live when you view it online.

If you attended the session and have any comments or feedback, please let me know, I’d love to hear it.  If you’re interested in hosting bpmCamp where you live, let’s talk – maybe we can get one organized!

IBM’s Lombardi team recently posted an updated schedule for Lombardi Day and Lombardi sessions that will be happening later in the week.  We’re still on for a 3:45 session on Monday discussing what we learned from bpmCamp 2010.

Every so often, a conversation builds to critical mass and demands an in-person meet-up.  Eric Ries pulled this show together, and I have to say there is some great video, and there were some great presentations to browse to get to understand better what you can do with a lean-startup approach.

Steve Blank has one of the best overviews with links to all the important content.  And here’s a link to the stream of his talk.  You can find almost all of the presentations on slideshare with the sllconf tag.

Maybe I relate to this conference effort because we put on the bpmCamp unconference earlier this year.  Mainly, I applaud the effort to build momentum and credibility around some really great frameworks.

One of the most anticipated sessions at bpmCamp was a discussion on off-shoring.  It had one of the highest turnouts of day 1. There were some interesting observations from the discussion :

1. Everyone agreed that daily communication across multiple mediums was a must: phone, email, instant messaging, screen sharing.
2. Structure helps: Daily SCRUM sessions, for example.
3. Bringing offshore folks onshore for a while helps – consensus is that this is more important than the reverse, though both are good.
4. Despite having productive off-site working relationships within the US, several participants reported a drop-off in productivity when going off-shore – despite no obvious logistical/infrastructure difference besides timezone.
5. Integration and collaboration among the teams is vastly more important than documentation and specifications.  The trend toward increasingly exact specifications to manage off-shore resources mirrors what happened with software development methodology in the US many years ago – with increasing gateways and overhead, and slowing velocity and innovation. (This led to a waterfall backlash, and the popularity of Agile software methods)
6. There’s a lot of potential in the follow-the-sun model, and in cost-savings.  But the challenges to productivity are real.

My own advice: when off-shoring, work with firms that do BPM deployments locally, for local market customers.  The adjustments they have to make to do a remote-BPM project are less-severe than the adjustments technical staff have to make from traditional IT projects to BPM projects.

We had a session on User Interfaces built on top of Teamworks at bpmCamp.  It was an interesting, technically detailed discussion – but what I took away from it were some key questions for process authors or process application developers:

1. When should one deviate from the “stock UI builder” included in a BPMS?  Teamworks ships with a great out of the box prototyping UI builder.  It let’s you build simple interfaces extremely quickly (integrated with process data), but has some limitations when it comes to more customized look-and-feel.  But when is a departure from the standard UI worth it?
2. Once one decides to roll a custom interface, which frameworks have the most currency?  There were people present that had worked with ExtJS and Flex, or just used Ajax to customize the Teamworks user interfaces.
3. Why can’t access to process work be more universal?  There was a lot of discussion about the process portal, but why aren’t tasks and updates available via twitter, RSS, SMS, SalesForce, and email among other things?
4. There was general consensus that the reporting framework should be more “open” out of the box- providing useful data for charting in a simple XML format, along with optional detailed information in an XML format, in order to make it easier to support alternate visualizations.  This approach would make it much easier to plug in different charting tools.  (Note: to that end, bp3 has built a reporting framework that supports Google Visualization (and soon Fusion charts).
5. There was a lot of interest in using the newer REST api’s for Teamworks.

I think the key take-away for me is that BPM practitioners want it to be easier to publish process information to whatever platforms their users want to receive them.  BPM information still needs to be further democratized.

The second take-away, related to the first, is that “portals” have gotten a lot less interesting.  In some environments, a portal is needed for a specific process- and only for that process.  In other environments, a portal needs to support multiple processes in one unified interface.  There’s no one right answer – as evidenced by divergent opinions at bpmCamp.  BPMS vendors either need to re-imagine the concept of the process portal, or they need to open their platforms for more innovation by embracing social media.

We had two somewhat related sessions at bpmCamp – one in which Flournoy Henry presented findings and data for scaling Teamworks, and another discussion with Dave Knapp engaging the group in a discussion about testing in Teamworks. Of course, many of these points were not specific to Teamworks.

Some of the key points from the testing session:

There was a general consensus that too much attention is given to “User Acceptance Testing” as a phase at the end of a major project, rather than engaging in continuous user acceptance testing.  At the very least, incorporating user acceptance testing with portions of the solution at each iteration is critical.

Being near the top of a pyramid of integrations and business system dependencies, a major challenge is testing process applications with all the external services required to make the process work. It isn’t just the fact that there is a dependency – one needs consistent test data across several systems to make for realistic testing prior to going to production.  There’s also a complexity in promoting process applications – to get all the directly BPM-related assets promoted in concert with any updates required in dependent systems.

There was also discussion around fail-over and roll-back testing.  It reminds me of the old adage for backup systems:  don’t tell me how often you back-up your systems, tell me how often you’ve done a full restore from backup.  Switching successfully requires practice in order to have it go smoothly.  But practicing has cost and risk as well.  This is part of why cloud computing is so compelling: High Availability software deployments are expensive when you want to do them right.

I’ve been remiss in getting the last couple of bpmCamp updates out to the the blog,

In one of the sessions on the first day, I gave a summary of an approach to BPM projects that I like to call “Fixed Effort” – but clearly I didn’t come up the ranks through marketing.

The whole point of the discussion was to give people a different way to think about a problem they face all the time with BPM projects: changing and evolving requirements.  As I pointed out in the discussion, the point wasn’t to argue whether requirements should change or shouldn’t change, the point was to discuss how to organize around principles that will protect you from the negative effects of requirements change.

I have found that sometimes a fresh set of analogies and thought models can help give business and IT leaders new arguments to support “doing the right thing” for their process projects.  I’ve previously discussed “Fixed Effort” in our blog, but this is an opportunity to really focus on it.

A quick review of the familiar approaches:

• Fixed price.  Typically you fix the scope as well before agreeing upon price.  The customer is paying for deliverables rather than hours of work.  Any changes go through change-order (and cost) process.  The problem: The biggest risk to any project is getting the requirements wrong – and because we’re fixing requirements early, they are very likely to be wrong.  And because the bid is fixed based on the fixed scope, any change we make will likely increase our budget, reducing ROI. Fixed price projects also fail at a pretty high rate, and the Vendor takes on a lot of the financial risk.
• Time and Materials.  Scope may change, at additional cost.  The customer is paying for hours worked, not results.  Generally a light change-order process.  The problem: Timeline and budget risks are high (scope changes lead to longer delivery times and increased hourly charges). Customer takes primary financial risk.

So what is Fixed Effort?

Deliver variable scope on a fixed budget.

It sounds impossible, but it is, in my opinion, the most responsible way to deliver BPM projects.  The emphasis shifts to prioritizing scope based on importance of each item to the business (return) and based on cost to implement (investment).  The basic idea is: any new items get prioritized into the existing list, and the BPM team works on the highest priority items first, and the team makes sure to pull it together into a production release with completed items before the budget runs out.

Of course, there is more to it than just that – but philosophically, that’s all there is to it!  One of my catchphrases at bp3 is “Respect the Budget” – don’t assume you can go back to the well for additional funds – make sure you are production-ready before you run out of money.

What I really love about this approach is that I can treat a T&M project as though it is Fixed Effort, by emphasizing prioritizing, and making sure that we’re always in a position to shift gears and go live with what we’ve got.  You can even get a Fixed Price project to behave more like a Fixed Effort project if you can convince your colleagues to treat the change-order process as a prioritize-and-replace process.

Of course, we got into a lot of discussion about specific cases and situations and how these techniques can be applied – but since I was speaking I didn’t capture that in my notes!  Comments to add to this are welcome -

I’m happy to announce that I’ve been invited to speak at IBM Impact / Lombardi Driven – I’ll be sharing what we learned at bpmCamp 2010 @ Stanford, covering several topics from the unconference we held at Stanford at the end of January.  I’ll do my best to boil it down to the highlights for sharing with the community, but I invite anyone who wants to speak more about the contents and learnings from bpmCamp to seek me out directly and initiate a conversation – either at Impact or offline via email.  If you’re interested in helping us organize a bpmCamp in your area, again, let me know – we may be able to work together on it, and I’d love to share the bpmCamp experience with more BPM practitioners in other geographies, or gauge interest for doing a bpmCamp in Austin.

Our session on lessons from bpmCamp is from 3:45 to 4:10 on Monday, May 3rd.  May 3rd has an entire Lombardi Driven or “Lombardi Day” agenda set up with over 20 Lombardi sessions and 100+ BPM sessions overall.  For Lombardi customers and IBM customers and prospects this should be an interesting value proposition.  While Impact runs from May 2-7, a two-day pass would get you to Lombardi Driven plus an extra day to check out the rest of the conference.   We’re planning on attending from May 2 to the 4th, and for anyone that would like to meet and chat in person, please reach out to me via my twitter handle (@sfrancisatx) or email, so we can plan in advance.

I’m looking forward to meeting new faces and reacquainting with familiar faces at Impact.

This isn’t particular or specific to the world of BPM conferences – there’s a general “conference malaise” going on – in which only the “best”  conferences are really tearing it up.

Outside of the BPM world, its clear that conferences like SXSW in Austin are doing just fine (and did just fine last year too, by the way).  Record attendance and a record number of panels and bands and acts is just the norm at SXSW these days (conference starts today).

But in the world of BPM, 2009 was tough for conferences, when the expectation was that people would still be attending BPM conferences due to how applicable they are to everyone’s business.  Several vendors postponed their conferences or took them virtual (Lombardi’s Driven), but the ones who waited until the fall (Appian) benefited from the beginning of the rebound in businesses planning for the future rather than businesses just living in fear of the next shoe dropping.

Sandy Kemsley has pointed out this problem with BPM conferences several times, as has Theo Priestley, and we’ve chimed in as well on the topic.  Some fresh perspectives:

• Sandy points out that 2010 looks like a rebound year for conferences.  We’ll see – Gartner’s BPM summit is in March in Las Vegas, and IBM’s “Impact” is in May – good test cases of the demand for these conferences.  Word from the London Gartner summit implied that attendance was low?  (I wasn’t there, so its second-hand to me).
• Theo Priestley and Mike Gammage hypothesize that Gartner and IQPC could merge events by 2012 – which again sounds like weakness rather than strength to me.
• Interestingly, Gammage was more encouraging about Gartner’s latest offering, while Jon Pyke’s contacts were not impressed.

Theo has a separate blog post, and while the bulk of it is about building community more broadly, at the end he makes a telling argument:

“When a sponsor at a BPM conference turns round and says he was perplexed at why there was such a low turnout given how important BPM has become according to what surveys seem to suggest the answer may be in the fact that we can’t even agree on what we’re telling clients in the first place.

For a group that practices change we’re incredibly resistant to it ourselves…..”

I’ve said before and I’ll say it again: I think BPM conferences need to do a few things:

1. Localize.  Have the conference closer to the bulk of your attendees, so that more people can come without travel costs.
2. Face-to-Face.  Tele-presence and high-def video conferencing is great.  But a virtual conference is a broadcast medium.  If attendees want one-way communication they can read the book or watch the video after the fact.  If they want interaction, then you need physical presence to really encourage that.
3. Respect budgets.  Don’t make cost of attendance a barrier – keep it reasonable. For anyone traveling, travel costs should dominate their total expenses, not registration costs.
4. Crowd-source.  Leverage the community to arrive at the topics.  There’s been too much top-down sourcing of content at conferences, without soliciting feedback from potential and actual attendees.
5. Narrow the focus. The narrower the focus, the more involved the people who attend can be.  People mistakenly think you have to broaden the audience to get more people – but the point isn’t MORE – the point is BETTER.  If the event is BETTER then you’ll get more value out of your investment of time and money.

We’ve followed this philosophy for bpmCamp and it was a great success for us – the feedback has been enormously positive, with a lot of interest in repeating the event next year.  But of course, our “unconference” was limited to 40 attendees – and its easier to organize around these principles when you keep the size of the conference smaller. Still, I think there are lessons to learn for those who would put on BPM-focused events, and the biggest one is:

It’s about the audience, not about the organizer.

For more information from bpmCamp, follow this link to our blog coverage of the bpmCamp event.  The element that I think is most crucial is the impromptu discussion that can happen in a more intimate setting.  Questions don’t wait for a microphone or a moderator – the hand goes up or the question is proposed and people can jump in and contribute.  I was really pleased with how this dynamic worked at bpmCamp and I hope we can reproduce this at other events.  I think 2010 will be a better year for conferences, but organizers need to keep in mind how to make these gatherings *more* valuable for attendees or they’re going to lose their attention next time.

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.

Lance Gibbs gave a well-attended talk on moving from Plan-Driven to Value-Driven delivery at bpmCamp 2010 @ Stanford.  There are some great slides in this presentation, and the approach dovetails well with Lance’s ability to get people focused on what matters most to their project success.

It starts with realizing that requirements are estimated, and resources and time are fixed, which is inverted from the typical plan-driven approach.  There’s also a focus on “should” rather than “could.” In particular, slide 4 jumps out at me, as it spells out what you should value, for example:  working software over comprehensive documentation.  Amen!

The presentation is embedded here:

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…