December 7, 2015
Six Do’s and Don’ts for Directly Capturing Objectives
Pega offers an interesting set of methods and tooling for directly capturing requirements and specifications into the system, called Directly Capture Objectives or DCO. The core of DCO is having DCO sessions where business and IT delegates work out the process flows and draft UI together. From practice I’ve seen that it’s not always easy to make it work on the short run. Expectations of the results can be unrealistic and it takes some time for people to get used to the DCO way of working. But don’t lose hope because when it starts working, it really gives a good vibe to your BPM project. This blog explains three do’s and don’ts for working with DCO.
|Do’s for DCO||Don’ts for DCO|
|+ Involve the right people on time and be prepared||– Don’t set expectations that DCO will directly work|
|+ Make yourself comfortable in the case designer tab||– Don’t start too early with DCO sessions|
|+ Emphasize the building work that is still needed||– Don’t directly start with real-time capturing sessions|
The three do’s for DCO
Involve the right people on time and be prepared
The people involved should be a good representation of business & IT and have the mandate to make decisions about the process. It’s especially advisable to assign process owners that have the mandate for one business process. Preparation is very important, so that people can participate effectively. When people are not prepared, be ready to postpone the session: An unprepared DCO session will not help the willingness of those who are prepared. To make DCO sessions effective, it’s also important to have a facilitator that guards the topics and parks irrelevant discussions. For example, discussions about the user interface are important, but should be parked when they consume too much time.
Make yourself comfortable in the case designer tab
When the draft process and UI is directly built out in Pega during the DCO session, the system architect will mainly be working in the case designer tab working out the stages, flows and draft UI. It’s best then that this system architect is experienced in doing this and knows his way around the system. The system architect should know what kinds of rules are created while editing on the fly. It is also important to have a pace that people can follow: explain what you’re doing and don’t switch screens a lot (‘ninja alt-tabbing’). There is a risk of people not being able to follow you.
Emphasize the building work that is still needed after having a draft UI
The draft process and UI is the most tangible result from the DCO session, especially for more business-oriented participants. It might give the impression that the process is ready to run for end users and high expectations are set. In practice, a big part of the development time is still to be spent on fine-tuning the details. For example, the underlying data model has to be modelled and the interfaces to other systems are still to be agreed and created. As these development tasks are not so tangible, they tend to be underestimated. Keep emphasizing what happens in the ‘engine of the car’.
The three don’ts for DCO
Don’t set expectations that DCO will directly work
Although DCO has a powerful potential, it takes a while for people that never worked with DCO to get used to the new way of working. Imagine a person who mainly worked using the waterfall approach that joins a DCO session for the first time. This person has to get familiar with the concepts and the way of working. People don’t mind change as long as they can control it. For DCO this means that it needs some time to get up and running. If this is acknowledged, you’re on the right track.
Don’t start too early with DCO sessions
When there is no consensus about how the business process looks like, it might be too early to start DCO sessions. DCO sessions are more effective when there’s a common understanding of the business process that has to be built. It has to be clear where the process starts, what the major steps are and where it ends. The case designer tab might still support this discussion but it shouldn’t be in the DCO session format. Added to this, it’s often forgotten to go through the current process in detail, even if it’s mainly a manual process. I would always recommend doing this ‘operational walkthrough’.
Don’t directly start with real-time capturing sessions
It takes some experience and skills for a system architect to work out the process and draft UI directly in Pega during the sessions. You might get stuck and this will put you on the ‘hot seat’. Therefore, it might be better to start off drawing it out on a whiteboard and then working it out in Pega after the DCO session. Or you can use a hybrid approach where more complex tasks are drawn out and easier tasks are configured directly. If direct capture is a must, make sure to have one Pega-experienced person focused on the discussion and another focused on the configuration in Pega. Talking and developing at the same time is harder, especially when doing more complex configuration tasks.
So how do I make it a success?
I’ve explained some common do’s and don’ts that I have encountered in BPM projects. But DCO is an extensive set of methods and tooling and every client’s situation is different. If you want to get more insights into DCO, I would recommend you to follow the DCO essential course on the Pega Academy. And feel free to contact us about implementing DCO.