In this blog post I aim to provide an appraisal of the Pega Developer Network articles “What is the SmartBPM Methodology?” and “Using Pega BPM with PRPC“, based on my experiences working on Pega projects in the field.
I am a Certified Pega Business Architect (7.2) and Pega Methodology Black Belt, and here I provide an alternative to SmartBPM (now known as PegaBPM), which I hope addresses what I perceive to be the shortcomings of the methodology. This post addresses the SmartBPM methodology only and not the Pega Scrum methodology. Moreover, it does not address techniques specific to any discipline (e.g., use case modelling).
Note that Pega clearly states that the SmartBPM methodology “is not a concrete prescriptive process”, that it is adaptable and that the phase information is an outline only. Therefore some of my suggestions are nothing more than an adaption of the methodology and others merely add detail to what is currently in outline form. However, other suggestions are the result of the problems I see with the original PDN article or with the methodology itself. You can download the full appraisal in PDF form from the link below, but here are what I consider to be the critical flaws in SmartBPM.
Not insisting on establishing business objectives during Project Initiation
The author has worked on Pega projects where not only were business objectives not documented in Pega but no member of the development team could say what they were nor where they were documented. Since Pega’s DCO tools do not make it mandatory to capture business objectives, nor mandatory to assign a primary business objective, it is left to team members to exercise due diligence, which they often do not.
Using the Inception phase to investigate current processes
Despite Pega’s definition, the Inception phase is not the appropriate time for process improvement. Formal process improvement results in a To Be business architecture, which should be in place before PRPC is even chosen as a technical solution. When a business change initiative is so immature that the client does not know what their To Be business architecture is by the time Inception starts, then the project is already on the path to failure. While project staff should be looking to improve business processes throughout the project, for example, by merging or changing the proposed order of process steps, it should be remembered that PRPC is not a process re-engineering tool; it is a process implementation tool.
Not addressing the mitigation of key technical risks
SmartBPM is based on the Rational Unified Process (RUP). In the RUP, one of the major purposes of Elaboration is to mitigate key technical risks. Pega does not address this at all and I see it as the critical flaw in their methodology. I have met Pega Certified Lead Systems Architects who did not understand the importance of mitigating the key technical risks during Elaboration, with the result that they tackled the “easy” stuff first for the “quick win”, but were left at the end of the project with little time left to tackle the “showstoppers”.
Not addressing the need to build testing environments during Construction
An omission in SmartBPM is that by the end of the Construction phase, all testing environments must be built, otherwise the Transition phase will be delayed. It’s possible that Pega state this elsewhere, but I could not find it in their PDN.
Implying that we should iterate between Elaboration and Construction
Elaboration and Construction are distinct phases in a project and each has its own objectives. Once a phase is complete, we move into the next phase. However, we do not move backwards and forwards between phases.
The Elaboration phase is so called because one of the key objectives is to elaborate on the requirements. However, the name sometimes confuses people who have only ever used a Waterfall methodology and causes them to think that it is only about elaborating requirements. The Construction phase is named for its main activity: construction of components of code. This causes some people to think that it is only about construction and they assume therefore that in order to work iteratively, they have to continuously cycle between those two phases. This understanding of “iteration” is implied by one of Pega’s illustrations , which I represent here:
This illustration misrepresents the nature of iteration. Moreover, in a PDN article from 2015, Pega explicitly tell us that we should be “cycling through Elaboration and Construction phases”1.
The terms “iteration” and “iterative” refer to the fact that we constantly cycle through the project disciplines (not phases) as we deal with each increment of work to be completed. For example, we might go through the analysis, design, construction and function testing of a single, critical path through a use case, then do the same for a critical path of a different use case, before cycling back to complete the first use case. Therefore if we were to visually represent the concept of iteration, it would look more like the following:
Some business-critical use case paths will go through a full cycle during Elaboration. Use case paths of low business value might not even start analysis until sometime during Construction. Some use case paths will start their lifecycle during Elaboration and complete it during Construction.
You can download a PDF copy of my full appraisal by clicking here. The PDF contains my alternative to SmartBPM.
What have your experiences been? Do you agree or disagree with my points? Please do call me out if you think I am wrong, as it will force me to either explain myself better or change my thinking.
Kind regards,
Declan Chellar
Leave a Reply