In this blog post I aim to provide an appraisal of the Pega Developer Network article “Getting Started with SmartBPM”, based on my experiences working on Pega projects in the field.
I am a certified Pega Business Architect and Methodology Black Belt, and here I provide an alternative to SmartBPM, 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.
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 highlighting the limitations of the Application Profiler
Pega stress the use of the Application Profiler throughout its guidance on SmartBPM. However, the Application Profiler, also known as the Application Profile Wizard (APW), should not always be used. For example, where the project is to implement the CPM framework with minimal enhancement, a GAP analysis between what the framework provides and what the business needs should be done and existing Pega Rules amended, whereas the Application Profiler is for building a bespoke application. Moreover, the Application Profiler was designed to capture requirements about business processes, workflows in particular. It is not suited to business rules engine (BRE) projects where no processes are to be implemented. It can even be more complicated than that, when a project is part workflow, part BRE, part data retrieval/display and part non-workflow process. You will find the APW does not work as smoothly as you expected if you apply it to your project with a broad brush.
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:
Figure 1: How Pega illustrates iteration in SmartBPM
This illustration misrepresents the nature of iteration. Moreover, in the PDN, Pega explicitly tell us that we should be “cycling through Elaboration and Construction phases”.
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:
Figure 2: My illustration of iteration
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, which you can also download in Excel format by clicking here.
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