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…

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"

Continuing on the theme from yesterday, we’ll point out a few more topics here.

• We’ll have a session (or several sessions) on UI frameworks inside and outside of Teamworks, discussing trade-offs of various approaches and benefits of each.
• The relationship between the BPM solution and systems of record.
• Offshore BPM – what is effective / ineffective – discussing real world experiences.
• BPM Requirements Analysis – how much is too much?  How do you know when to say “when”?
• A/B Testing for process improvement

I met with Lee Merrick at Stanford yesterday and we’ll be meeting again today for some final prep for tomorrow’s conference.  We’re excited and looking forward to working with everyone attending to create a great experience.  Thanks to everyone for supporting this idea with your participation and willingness to speak!

I’m excited about the topics taking shape for bpmCamp this week, and I’m going to send out a few teasers before the event starts on Thursday morning.  We’ll do our best to capture as much as we can and share insights with readers of this blog as bpmCamp happens, so keep an eye on this space or bookmark the bpmCamp tag.

Some of the sessions we’re looking forward to:

1. Phil Gilbert is going to stop in to discuss the acquisition by IBM and take questions from customers.
2. We’ll have a few members of the Lombardi product team in attendance to give us some insights into Teamworks 7′s operations, and upgrading to Teamworks 7.
3. We’ll talk about what “Fixed Effort” means as a way to focus on delivering value.
4. A case study discussion of an application of Agile to a project.

There are 20 other topics on the potential list, more to come tomorrow…

bpmCamp 2010 @ Stanford has sold out!  The waiting list is open, however, and we’ll evaluate additional attendees on a first-come-first-serve basis if we get any cancellations.

We’re looking forward to seeing 40 participants from at least 11 companies, plus independent practitioners.  Topics of discussion will likely include:

• Teamworks 7 and upgrading
• Scaling Teamworks 7
• “Process Debt” and BPM programs – creating and removing process debt
• Delivery Challenges: Moving to BPM Software Delivery (Value Driven) from a Waterfall experience base (Plan Driven)
• BPM Requirements Analysis – How much is enough?
• UI frameworks with Teamworks
• Teamworks and Rules
• Teamworks and Systems of Record
• A/B testing and BPM
• Myriad additional technical and project and process-improvement topics

We’ll continue to revise the agenda topics and schedule as we approach the first day of the conference – and we’ll continue to accommodate new ideas even during the conference.  Look for more on the conference as it approaches, and afterward we’ll share some of our impressions and nuggets of wisdom that we’re able to glean.

Time to register for bpmCamp …7 days left to register, and we’re nearly sold out.

Stanford has offered to reduce the regular registration price to the early bird price- $100 for a two-day BPM Conference on the beautiful Stanford campus. Can’t ask for a better bargain.

Still a few days left to register…

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.

Travel logistics have been updated, click here for details.  The short version:  we’ve secured a discount to the Stanford Guest House, which has the advantage of being on shuttle routes and being on campus… and being highly affordable.  But there are lots of other options in the area as well.

We’ve also posted some directions from the airports, and recommendations on trains and shuttle routes.

See you at bpmCamp!

To join the bpmCamp discussion, just join the Google Group below.

Membership in the Group also gives you full editing access to the bpmCamp wiki – where you can propose topics, volunteer to speak or lead a discussion, etc.

Subscribe to bpmCamp Stanford 2010

Email:

Visit this group

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.

The official wiki for bpmCamp 2010 is up (and the landing page has been updated accordingly).  The direct link to the wiki is www.bpmCamp.org/wiki which forwards you to a Google “Sites” wiki.  Although it arguably isn’t the best wiki product, we use a fair number of Google apps and the wiki functionality has definitely improved over time.  It also doesn’t require you to learn a wiki-fied markup language – you just have to remember to click the “Edit Page” button.

Unfortunately I don’t didn’t see a way to make the site “public” while hosting it in the bp3 subdomain.  So, if you want access drop us an email  (bpmCamp  at  bp-3.com) and I’ll get you invited pronto.  Even if you don’t think you can attend, you can participate in the wiki discussions.  There’s also a mailing list attached to the wiki that you can join (a Google Group for bpmCamp Stanford 2010).

Looking forward to getting the discussions started!  Only 59 days left…

(As Sandy points out below, you can just join the bpmCamp google group to get access to edit the wiki!)