Abstraction and Collaboration by

John Reynolds writes that “Gathering, Reviewing and Approving are almost always Collaborative

Of course he’s right.  And in fact, rather than explicitly model such things:

Credit: John Reynolds

Credit: John Reynolds

I’d recommend modeling the review process as a self-contained “activity”.  Prepare proposal should be separated from “revise proposal” in any respect. Now, what happens inside that magic “Review Feedback” Activity is up to us to define.  Implementation details.  A few thoughts on implementation details follow.

There used to be a quite clever SharePoint integration feature within Lombardi – it would create a discussion in SharePoint for these types of activities.  with a responsible party identified who could “complete” the discussion when they felt that it was sufficiently complete.  In this case that could be the reviewer or the approver, or it could be the person who started the whole process.

Sadly, this feature didn’t find its way into current product offering but i thought that a version of this that didn’t depend on SharePoint would actually be quite useful.  a group chat, a Google hangout, a Skype call, whatever.    Simple integration to capture a discussion.  There are quire a few choices here,  but simple is better than complex. Don’t try to replace the human interaction, just create a convenient place to capture the outcome.

I think this is just the kind of feature that software vendors are in the right position to implement, rather than define it in BPMN.  It isn’t that BPMN can’t capture the interaction, it is just too granular a level of detail for a BPMN diagram – unless the review process by necessity must be highly formalized and audit-trailed.  And I have seen such review processes before. But they’re the minority.

 

  • http://twitter.com/anatoly_mt Anatoly Belaychuk

    Scott

    I just commented John’s post with thoughts very similar to yours.

    >> Prepare proposal should be separated from “revise proposal” in any respect.

    Yes indeed, I call it “do-redo” pattern http://mainthing.ru/item/295/

    >> a responsible party identified who could “complete” the discussion when
    they felt that it was sufficiently complete. In this case that could be
    the reviewer or the approver, or it could be the person who started the
    whole process.

    I’d say it’s not about who can complete the discussion – it’s about who is responsible for the outcome and hence must complete it at some point.

    >> it is just too granular a level of detail for a BPMN diagram

    It’s just another level – task management, not process management.

    I’d suggest looking at the BPMN diagram as a definition of who is responsible for the task, assuming that there may be other contributors.

    The best implementation for the collaboration for me would be social functionality – something like what Rhonda Gray presented at bpmNEXT.

    • http://www.bp-3.com/blogs sfrancis

      regarding “who can complete” – yes, this person should be “who is responsible for the outcome” – I didn’t explain it clearly, but that’s what I had in mind – that this is one and the same :)

      and yes, it is more task management than process management. typically though task management isn’t “multi-person” in most BPM suites, and in this case needs to be. Still a very solvable problem.

      • http://twitter.com/anatoly_mt Anatoly Belaychuk

        Don’t you think that potentially *any* task may involve contributors?
        But I won’t call it a multi-person task, meaning that there are different roles: one performer/responsible and a number of advisors/contributors.
        Technically it can be implemented as one person authorized to input data to the task and to commit it and a number of contributors who are invited and/or subscribed to the task authorized to view the task data and to write to the task feed to help the performer to do the job.

      • http://www.bp-3.com/blogs sfrancis

        Just thought I’d add – of course any task could involve contributions from others- and some tasks require contribution from others by design – interview feedback, design discussions, etc.

        Both approaches are interesting, to me. (i was just pointing out that often the tools themselves have limitations you have to work around when the task involves contributors in an “official” sense)