Enterprise product engineering is a complex beast. It involves navigating in a very complex ecosystem of various tech stacks, stakeholders and different concurrently running projects. Also, there is a huge cultural dimension to the delivery of any successful enterprise project and this is also driven by complex legacy procurement and contract processes.

I have been navigating this space for quite some time now; and so has my team at Atalgo. We developed extensive knowledge and experience in enterprise software delivery space while managing added complexity of employing offshore development team and learnt a couple of things along the way. This further strengthened our consulting practice and allowed us to abstract the pitfalls and learnings of enterprise software delivery. This applied learning is what I am calling APEM, Atalgo Product Engineering Methodology.

Although team Atalgo is developing some detailed collateral, case studies and comprehensive methodology around APEM, I am jotting down my thoughts on this below.

Learning from mistakes – Our experience over the years in delivering enterprise software across various different businesses is that there is a recurring theme of same set of (let’s say half a dozen) mistakes being made everywhere. Most of the challenges in enterprise software development are the same and requires similar set of solutions to fix them. We at Atalgo have collated a lot of data around these pitfalls and done a detailed brainstorming to abstract the learnings so that it can be applied to prevent those mistakes from happening. This is the core of APEM; Atalgo Product Engineering Methodology.

Causal Loop between Learning and Application

Key issues we have found time and again in enterprise software delivery are –

1. Lack of delivery experience in the vendor team
2. Too much emphasis on methodology
3. Lack of ownership from business
4. Lack of experience on business side in managing vendors/projects
5. Underestimating operational and Go Live challenges
6. Lack of collaboration among delivery team and between business and delivery team
7. Lack of business process traceability
8. Lack of framework in getting end use feedback
9. Immature/absent DevOps/Automation processes
10. Underestimating non functional requirements (security, performance)

Our analysis showed that there is a consistent theme of these challenges and most of the problems can be avoided/mitigated if we set robust and proven processes in place to avoid above mentioned mistakes. In this light, below are the key features of APEM which will help us set the right foundations and apply the learnings and wisdom gained from various projects from the beginning –

Business Driven – Atalgo proposes a more central role for the business in enterprise product implementation than current approaches. We in fact champion a formal role of “Business Owner” (as against Product Owner which is usually from any external agency and fills this role). Business Owner is typically an empowered Subject Matter Expert who has spent time in the business and understands business needs and entire landscape really well. Business owner is expected to take the ownership of requirements and design decisions of course aided by the team of Business Analysts and UAT testers. Business owner will provide the sign-off on design and UAT for that specific business area. Business Owner will also ensure the availability and appropriate engagement of business resources (time and again, we have felt that it is not only about spending number of agreed hours per week on the project mostly attending meetings but rather quality of engagement and ownership are what drive the outcome).

Traceability – In Atalgo methodology, traceability is about ensuring that there is a real time alignment of business processes with product features. Product engineering team is usually more comfortable in thinking in terms of

module -> feature -> functionality

whereas business typically sees the business capabilities and current state processes in terms of

Process -> Sub process -> functionality (which is typically L4 and L5 processes)

If not aligned from the beginning, this creates lot of confusion and tension among the project and business teams. Solution to this is to develop a product matrix which maps both product and business traceability and provides a unified view of the product capability and how it is supporting business processes.

Delivery Methodology – This is the most critical aspect of Atalgo methodology. Our delivery methodology takes into account the specific challenges encountered in implementing a solution within a complex ecosystem of ERP systems and other tech-stack within an organization. Few challenges you will encounter in such environments are –

1. Operational readiness related challenges are equally complex and often missed in planning Data migration is poorly planned
2. Access and security related requirements are often not clear and not considered well in time to meet critical milestones
3. Weekly sprints rarely work as business SMEs usually want to do UAT only when end to end functionality is available to them which is usually not easy to deliver in one week. Fortnightly and monthly sprints are more effective
4. Definition of “Done” is usually not clear among stakeholders
5. A team of competent and professional UAT testers (often supplied by external vendor) is needed to keep the flow of UAT going
6. It is challenging to assess the impact of requirements across different business units. A robust governance mechanism and concept of Design Authority is needed to align all business units
7. Integrated environment connected to external systems in dev is luxury hence mitigating integration defects before UAT is always a challenge
8. Hypercare is poorly planned and this becomes more of an issue with DevOps teams as same team is providing support on already released features as developing new features
9. Change management is often introduced very late in the implementation cycle and they are not part of the original methodology, hence frequent tweaking of the plan is needed at late stages
10. Offshore coordination is poor and there is a lack of experience in the team to manage offshore teams effectively

In the light of these challenges and leveraging our experience and learnings across many projects, Atalgo has developed a delivery framework specific to enterprise product implementations. This requires detailed explanation and probably an article focused on our delivery methodology itself which we will be producing soon. In short, below are the salient features of our delivery methodology –

1. Monthly release – We strongly recommend one release per month with commitment to give an end to end functionality to end users which they can meaningfully use to gain more efficiency in their work. This monthly release should include data migration, operational readiness, change management and training. Monthly release allows business to do non-rushed UAT and provide some valuable feedback and dev team has not only time to fix the issues but also has time time to come up with a holistic design. We have also done fortnightly releases in UAT and monthly release in production which works equally well and allows teams to get some early feedback from business.

2. We love RAT – Atalgo engineering team is a big fan of RAT (Riskiest Assumption Test). We want to tackle the complex technical challenges early on and like to provide accurate assessment of the complexity and resource needs sooner than later. We prefer to build technical PoC as part of MVP scope and take the technical challenges related to performance, scale and security head-on

3. N+2 – This is an ideal we recommend enterprise product teams to aim for. Everyone in the product team including business stakeholders should strive to achieve the design approval from business at least two sprints ahead. Even if finer details of wireframes or technical deisgn may not be apparent two months in advance, at least at a high level, business and technical team should understand and be in agreement in terms of what capabilities product is trying to achieve

4. Feedback Loop – Hypercare is built into the monthly release plan. Data from end user feedback and type of issues getting encountered must be meticulously collected and analysed while planning the next release

5. UAT Team – Experience is that UAT becomes a big bottleneck if only left to SMEs who are often very busy in their day jobs and not very experienced software engineering quality management practices. This can slow down the velocity and result in build up of lot of code in dev environment. We have found that having an experienced and independent UAT team plugged into the SME ecosystem benefits product development enormously

This is a very short description of how Atalgo product methodology is suited for enterprise implementations.

Automation – DevOps and Shift Left are natural components of our product engineering methodology. We setup a DevOps platform where Build, Deployment and Testing are automated and our telemetry collects the actionable insights on all aspects of the automation pipeline. We also develop a regression suite as part of our sprint which allows us to test the product on any given version.

End user engagement – In enterprise, usually the people using are not only not same but also not an employee of the company. This is particularly true for digital transformation projects involving mobile apps. The SMEs and other business stakeholders may approve the requirements however when the product comes in the hands of end users during pilot or beta testing, we may find a very different set of requirements. We have seen it many a times over that the feedback from end user is different which resulted in redesigning many features. To mitigate this and avoid the waste, we recommend ways to engage end users during product discovery and early testing phases. Also, design should take into account the potential UI and workflow related changes coming from end user feedback.

This is a brief introduction of Atalgo’s proven product engineering methodology for enterprise implementations. Atalgo team is working on documenting a more detailed version of our methodology which will be published on our website soon. In the meantime, if you have any questions about Atalgo’s methodology, please get in touch at gulam@atalgo.com

#apem