Do “to-be” process models improve agile project governance?
Blog: LitheIT
BPMS vendors are strong proponents of using agile methods to implement their solutions, highlighting the increased potential of rapid ROI compared to using traditional waterfall approaches. I believe that there are a number of tests which can help determine if agile methods are likely to work, but I’ll leave that subject for another day. Assuming these tests are met, I strongly agree with the vendor position.
It can be a hard sell to Finance Directors who are rightly wary of such promises, even if agile is likely to succeed. It becomes an even harder sell if the balance of risk of not achieving the ROI lies with the customer.
A recurring complaint levelled against agile methods, especially by those new to them, is that the business cannot define strong acceptance criteria in advance of the project as functionality delivered will be determined during each sprint. This is a valid complaint as it makes it difficult to create a contract where the vendor is “on the hook” to deliver a working system. It is unfair to expect the vendor to commit to a fixed price contract without knowing the work involved, and equally unfair to expect the customer to agree to write a blank cheque to support implementation. So what to do?
I advocate spending time to develop a robust “to-be” model using the BPMN 2.0 notation. The approach to modelling depends on the level of improvement sought, knowledge and availability of skilled process experts, and timescales to deliver change. To become best in class, it is hard to see how external benchmarking can be ignored; similarly if the process needs to be operational within a short timeframe then a FAST method is likely to offer the best approach.
Once a verified model is created it allows the business to determine those activities which are “Must haves” to be delivered during the project. It is also important to define acceptance criteria for each activity, understanding that this is unlikely to be universal for all parts of the process. For instance, customer facing process activities are likely to contain data validation, error handling, performance constraints, escalation steps, and conform to a defined accessibility standard. For other parts of the process it may be acceptable to live without an escalation alert, custom error handling, or a pretty screen. Creating an acceptance matrix and linking each activity to this is a good way to gain and document agreement and doesn’t require too much effort.
With this information available, the customer and vendor can enter contract negotiations better able to agree on the work required for the creation of an end to end workflow, with those activities categorised as “Must haves” fully configured, creating the potential for acceptance criteria linked to a payment schedule.
I don’t want to suggest that a “to-be” model is right in all circumstances, but from a governance perspective, it is difficult to make a good argument against creating one.
If you want to discuss this or any other BPM related subject please drop me a note at AnthonyMurphy@LitheIT.com, visit www.litheit.comor call me on 0141 314 3707.
Leave a Comment
You must be logged in to post a comment.
