BPM: Professional Services

Change Requests are an integral part of every BPM project.

Although frustrating (why didn’t they think of it till know) time consuming (great, now we’ll need to do rework), and never ending (another delay to the go-live) it’s all part of the fun, and should be encouraged.

BPM projects need to be agile projects. It’s the approach we all preach.

The problem is: Customers don’t understand agile. They expect a solution that does everything, especially functionality that they haven’t planned or thought of as yet.
Its only after the next few sets of changes, version 1b, version 1c that the customer feels comfortable enough with the agile approach.

Then you’ve got the issue of professional services.. basically, who is paying for the changes.

• All changes are included in the project cost (I think it’s called assisted suicide)
• All changes will be paid by the customer (Sure.. Xmas come early?)
• The original payment includes x number of changes (using tokens)
• The vendor believes that future revenue is worth throwing in the freebies (mmm…)

And then you’ve got the politics:
• Customers mix support with professional services (I’ve paid for support. Doesn’t that include any changes that I will need?)
• Sales teams are willing to sacrifice PS revenue in order to close the deal. (Sure, any change you need, just call us..)
• Professional Service managers don’t want to hear about unpaid services. (Freebies is something you get at McDonalds with your happy meal)

The main difference of managing BPM professional services is knowing how to deal with change requests.
Unlike regular IT projects where you push back on change requests, In BPM projects you need to know how to encourage them.