The top 3 considerations for starting a Pega project

I am going on a Pega journey and this is what I take with me…

Everyone will remember this famous (Dutch) game from their childhood. I go on a journey and take .. with me, the next persons repeats the former and adds something, on and on until someone forgets something that has been mentioned and he or she is out of the game. When you start a Pega project it is a bit the same. There is so much to think about and if you forget or neglect something crucial, you might encounter major challenges or high cost to fix it later. From my seven year experience as Pega project-/delivery manager, I have listed the top three things to take into consideration when you start a Pega project.

 1 – First who then what

This well known principle from management guru Jim Collins also applies to Pega projects. Most big companies have outsourcing contracts with big system integrators. Usually they are only able to deliver one of a kind resources (technical experts). Although technically capable, they lack other skills like understanding your business and design thinking. Some projects even start off shoring straight away. Although this might seem cheap at first, this usually quickly turns the other way as collaboration is difficult and there is little (business) understanding and lack of involvement. Usually a lot of effort from onsite is needed to guide and improve off shore work.

“ The best team to start with is an onsite team with internal people and experts from key implementation partners with the right combination of experience “

Based on my experience, the best team to start with is an onsite team with internal people and experts from key implementation partners with the right combination of experience. Finding the right expertise and capacity at one vendor is usually difficult. Some vendors are excellent at starting up a Pega project in the right way, but lack the ability to scale quickly when the project is successful. Other vendors can scale quickly, but have no business knowledge, little experience in setting up the right delivery approach and architecture. My advice for bigger organizations is to work with at least two vendors to get the best results and also keep everyone sharp. In the beginning you should also get the involvement of the software vendor.

Next to the IT roles, the Product Owner is a crucial role in agile projects, so selecting the right PO is crucial to success. What a right PO is has been extensively described by many others, so I won’t go into detail on this subject.

2 – Think before you develop

Almost all IT projects are done in an agile way these days. With agile projects people tend to jump into action and start building asap. This might seem like moving quickly in the beginning, but the pitfall is that you haven’t properly thought what and how you should develop, which results in a lot of rework later on. So take your time to make a proper (business) analysis and compose your start (enterprise) architecture. A Project Start Architecture document is crucial to success. Make clear choices what you do in Pega and what you do elsewhere. After this, design a proper application architecture before you jump into development. And with proper application architecture I mean more than the Enterprise Class Structure.

3 – Think big, start small and show success

Opportunities are plenty with Pega, so before you know it you want to change the world in one big bang. But this may lead to long delivery timelines and losing the change momentum. You better start small, provide quick results and then build out. Pega is build for change, so focus on the Minimum Lovable Product (MLP) and expand from that. The role of the product owner is crucial in this, he or she is responsible for making the right choices on what to build. But the implementation partner/team should challenge the product owner on this and work together to define the MLP and acceptable delivery timelines. Don’t go for a big bang change as also the organization has to change. So when selecting your first project/process take this into consideration. Align this with your design thinking as mentioned above.

Conclusion

If you take the above things into consideration, your Pega journey should lead you to success. It may sometimes be painful and difficult but you will succeed. Remember, when you fail to deliver results people start blaming the technology, but in almost all cases it’s not the technology, but the business and IT management that has failed to do things the proper way. In case you have questions about starting up your Pega project or you feel you are stuck and might need help, don’t hesitate to reach out to us.

We are also happy to share our knowledge and experience with the market. In our whitepaper “The seven steps for a good start of your Pega project” we describe which core activities must be carried out to ensure a good start of your Pega project and which points for attention.

[whitepaper-1]