I had a remote product demo of SmartBPM prior to PegaWORLD, then a briefing from Kerim Akgonul at the conference. A lot of the changes to the product over the past year and a half have been focused on making it easier to use, trying to fight the perception that it’s a great product but that the inherent complexity makes it hard to use. In fact, the two main themes that I saw for this version are that it’s easy to use, and easy to share through design and runtime collaboration.

Once again, reference to themes of simplicity and ease of use.  Sounds like some of the bigger players in the BPM space have awakened to common themes.  The question is whether there will be real, substantive follow through on these themes from the same vendors.

Related posts:

1. Sandy Kemsley Reviews HandySoft
2. Sandy Kemsley Reviews CloudExtend
3. Sandy Kemsley Reviews Bruce Silver’s BPMN Training

Sandy Kemsley quotes Tom Higgins of Territory Insurance Office in Australia as saying “Waterfall contracts and iterative development don’t mix.” Apparently he spent quite a bit of time talking about the contractual aspects of the project they took on with Appian, and Sandy took the opportunity to comment as follows:

The contract needs to focus on risk management, and you can’t let your lawyers force you into a fixed-price contract that has pre-defined waterfall-type milestones in it if you don’t know exactly what you want; in my experience, no BPM project has ever started with the business knowing exactly what they want ahead of time, and I don’t imagine that many do, so don’t mistake a contract for a project plan. If you plan on doing iterative or Agile development, where the requirements are defined gradually as you go along, then a fixed-price contract just won’t work, and will be a higher risk even though many (misinformed) executives believe that fixed price is always lower risk.

It is certainly true that waterfall contracts (often milestone or deliverable contracts are really waterfall contracts, so beware) are not an optimal fit for iterative development.

Having said that, you may find yourself in a situation not of your own making – where a Waterfall contract has been put into effect, and you have the responsibility of delivering the project.  At such times, it is still in your interest to convince the project team to go down an iterative path and get the contract revised to reflect it.

At BP3 we have been brought into just such situations when major outsourcing shops bring our firm in to help lead a customer BPM deployment.  We articulate the value to both parties to help them see the light that although the Waterfall contract would allow a lot of choke-the-vendor opportunities, and a lot of change-order opportunities – it would also bury the team in change-order requests, and it would likely fail to meet the business objectives and time-lines.  We do this by making a simple commitment to both parties:

1. The business will prioritize the work in each iteration (In other words, the business MUST prioritize).
2. The delivery team will deliver the highest priority work in a quality, repeatable fashion (in other words, technical team will honor the business’ prioritization decisions)
3. The iteration will be accepted if the business accepts it as having substantially delivered their top priorities and as having prepared the team for moving to the next iteration.

The difference in productivity, and in the tenor of the relationship is dramatic.  Of course we have to follow up words with deeds – delivering value, and delivering on the priorities the business has set for the team.  We have to take commitments seriously.  After establishing a pattern and habit of success with this new paradigm, we’re much more likely to achieve success.

A more common scenario is to get into a waterfall-methodology-oriented environment, where the contract may be more generally structured (perhaps even T&M).  In such cases, we have had a lot of success in applying iterative and/or agile techniques within the overall waterfall framework – including characterizing early development work as prototyping or design work, in order to pull some of the riskier technical or requirements issues to an earlier point in the deployment.

Regardless of the situation you find yourself in, you’re going to be better off if you can apply iterative techniques to your BPM deployments.  Once you apply those techniques, success will reinforce the approach.

Sandy makes another point in her post about working with people you trust – I couldn’t agree more.  If you don’t have that trust in your customer relationship, you have to work hard to earn it. If you don’t trust your vendor, find someone you do trust.

As a proposal, challenge yourself to think about your project as “Fixed Effort” rather than “Fixed Price” or “Time and Materials”.  What is Fixed Effort?

1. Honor the budget by deploying the process within the allotted budget.
2. Use iterations to always stay close to a production-worthy deployment.
3. Always work on the highest priority elements that meet the business objectives, and get you as fast as possible to a “minimally viable process” (For more information on this subject, look for Minimum Viable Product or MVP).

This approach honors the realities of the world that are often ignored at the peril of the project and its team members:

1. The Budget is LIMITED.  Fixed effort honors that by delivering a production ready process with real ROI within that budget.  Let’s say that again:  a Fixed Effort project honors the budget by delivering a production-ready process with real ROI within the budget.
   
2. Wrong requirements are among the most expensive mistakes a project can make, if they make it to production.  Iterations and Agile methods will expose these missed/mistaken/wrong requirements earlier in the process.
3. By always staying close to a production-ready release, at any time the Business should be able to say “this is good enough” (translation: we have a minimum valuable process), and you should be within just a couple weeks of going “Live” by doing a little cleanup and final QA before go-live.
4. By focusing on the business priorities, we’re focusing on the parts that add the most value / ROI – rather than the check-boxes that might meet IT requirements or might make us feel better about the project.
5. If pieces are left off in the end – they are likely less valuable and provide less return than the parts we’ve already implemented.

I realize “Fixed Effort” may not catch on in popular lexicon, but it keeps you focused on realistic budget in BPM projects.  The requirements aren’t fixed, as they are in a typical “Fixed Price” contract, so the vendor can’t easily commit to delivering static requirements.  A Fixed Effort approach is the way to address that requirements risk, while still addressing the budget risk.  Its a balanced approach, and managed properly, it works really well.

Related posts:

1. Fixed Effort, Variable Scope? #bpmCamp 2010 @ Stanford
2. Lombardi Events in the fall of 2009
3. Forrester’s Business Technology Forum Recap #BTF09

He did a closer look at many of the vendors’ messages, pointing out the nonsense of much of the marketing speak about how easy and beneficial that BPM is. Agility in that context means that the process can be re-modeled; in fact, that’s often the only point of agility that the BPM vendors allow (although I would argue that integration of rules management creates significantly more agility without process model changes).

I would dispute that BPM vendors are only arguing that only “modeling” can be more agile – they are, in fact, arguing that the execution of the process can be altered with more agility than the present state of affairs in the IT infrastructure with legacy apps and bespoke implementation of processes. In addition, elements of the process can be exposed to process owners (the business) to modify the behavior of the process without requiring a development effort.

He then turns to the fact that process is deployed within IT infrastructure, within the context of these existing applications – and that that, in and of itself, precludes agility.  Well, certainly one can imagine processes being more agile without the heft of these legacy systems or existing infrastructure- but the point isn’t “agility” measured against some absolute zero.  The question is – does BPM make you more agile than your current situation, and does that additional agility have sufficient value?  Clearly the answer to both, for most companies, is yes.

Finally he points out:

Other factors also impede agility: the issue of migrating work in progress when the process model changes, including changes to related services. The conclusion: although the vendors make process model changes look easy in the demo, it’s not that easy in reality.

Certainly these factors impede agility.  However – even moreso without a BPMS.  And while these scenarios aren’t “easy” they are much easier in a BPMS because they are actually identifiable and measurable.  (As an example, the versioning-related features in Teamworks 7 put issues like this on the front burner and directly address the challenges Mr. Hoogland is presenting).  Still, is it any wonder that software vendors make something look easier in a demonstration than it might be with production data and volumes?

Next, the complexity of process models is attacked.  At some level, processes are only as simple as they are, and no simpler (with apologies to Einstein).  However, having the right process abstractions makes them more accessible to the human mind (and specifically, to the people within the Business who need to understand them).  You have to design in a fair amount of the “knobs and levers” that you want to be able to customize after going to production, and:

This requires an explicit step during the process design to design what parameters have to be able to be changed by the business users on the fly without changing the process model (I am going through exactly this exercise now with a client, and completely agree with his assessment), and ensure that the BPMS is capable of providing those as parameters under direct control of the business.

That makes three of us.  I think in general Mr. Hoogland is trying to inspire the academic and research community to tackle fairly intransigent problems – complexity and expressiveness, agility and in-place upgrades.  He’s right to call attention and further effort to these areas – there’s no doubt they can improve dramatically over the current state of affairs.  And yet, a good BPMS already offers a clear improvement over the status quo in organizations who are not equipped with a BPMS (with room for improvement still).

Related posts:

1. Complex Organizations are… Complex.
2. Agility and BPM
3. “Simplifying” a Complex World

Sandy Kemsley recently reviewed both the latest release of Blueprint, and the latest from SAG Alignspace.  I believe at least the latter was based on a Webex or walk-through, rather than on actually having hands-on-access.  Good capture of the strengths and weaknesses of each.  It sounds like Alignspace is more focused on community and less on modeling, and Lombardi comes at it from a collaborative modeling “point of view”.

I’m interested to see Sandy’s take on IBM’s offering as well, since she’s getting a good look at more than one tool in close proximity. This is a really valuable service the independent voices like Sandy and Bruce give us.

One interesting comment on Sandy’s Blog was from Terry Schurter of Global360.  He claims that these social sites are a recipe for disaster.  Well, certainly they won’t all succeed equally.  But to claim that the feedback from the user community on these sites won’t be useful misses the boat.  Lombardi and SAG won’t need to ask their users what they think (although I’m certain they will do so), they’ll be able to see for themselves how users are using their respective sites – which features are laying fallow and which ones are drawing attention and usage.  They’ll be able to introduce a new feature and observe whether it enhances user perception or utility. Terry discounts these benefits out of hand, which I think is a mistake.  It is a mistake to think that just a few experts at each of these vendors have all the answers for what should go into a product.

Having led sessions much larger than the one Terry describes (3 people), I can say definitively that there is a technique for adapting to larger groups of stakeholders and still driving progress – and two of the key ingredients are having a clear decision maker, and having an outside consultant or facilitator (someone who can’t be tarred with any particular internal politics or biases).  There are, of course, a whole host of minor adjustments to the process as you get a larger (or smaller) participation group. These social / collaborative tools should just give us better technical tools to augment what we’re already doing in conference rooms and videoconferences.

Related posts:

1. The Process around Social Tools
2. Blueprint June 2010 Update, Incrementally More Social
3. Why use BPM over other workflow tools?

Another link from Sandy – I’m not sure how I feel about this – a book on BPMN, that (I think) is intended to read like a novel… I don’t know whether to be afraid, or very afraid…

Related posts:

1. Bruce Silver’s 5 things left out of BPMN 2.0
2. Sandy Kemsley Reviews Bruce Silver’s BPMN Training
3. A BPMN 2.0 Update from Bruce Silver

Here’s the slideshow:

Slide 14 is what did it for me:

• Business Process:  What the business does.
• Requirements:  How the system must support What the business does.
• Rules:  Control behavior of What the business does.

This is a really concise way of explaining why you want to separate these things, without even going into the details of what goes wrong when you don’t.  But, for those who need more proof, there are another 51 slides!

Related posts:

1. Good Presentation on Mixing Rules and Processes
2. The Trouble with Rules (and who owns them)
3. Why Rules are More Complicated than they Appear