Managing Complex Digital Transformation Programs
Managing digital transformation programs is inherently complex. Learn how to instill predictability and use the provided templates to ensure success.
Managing Complex Digital Transformation Programs
**Reducing Complexity & Bringing Predictability**
© 2022, GlobalLogic, A Hitachi Group Company
1741 Technology Drive
San Jose, California
95110
<a href="https://www.globallogic.com/"> www.globallogic.com</a>
<a href="mailto:info@globallogic.com">info@globallogic.com</a>
All rights reserved. No portion of this book may be reproduced in any form without permission from the publisher, except as permitted by U.S. copyright law.
**Important! Tips for Getting the Most Out of This Content**
Click the 'Read on' button below to get started.
Navigating This Guide
< > From a chapter introduction page, right or left-facing arrows enable you to go forward or back between chapters.
Read on takes you into the chapter to access all content.
'Home' returns you from anywhere in the document to this page.
< > Once inside the chapter, arrows enable you to flip through content pages or move to the next chapter.
Table of Contents
Or, navigate directly to a section of your choice below.
Introduction
Digital transformation programs, by definition, transform the way businesses operate, sustain, and succeed.
Digital transformation programs, by definition, transform the way businesses operate, sustain, and succeed. We generally call them “Complex Digital Transformation Programs.”
However, the term 'complex' does not always arise from the virtue of the complexity of business requirements, the complexity of architecture/code, or the pressure of delivery timelines.
These programs sometimes become complex because of the basic things we overlook or ignore while managing these programs.
Any program of such nature has two basic elements – Upstream & Downstream.
If managed well, these can significantly reduce the delivery complexity. In this guide, we'll look at each of these elements individually and explore strategies for managing them efficiently and effectively. You'll find links to sample plans and templates to help guide your own strategy, as well.
Home
Managing Digital Transformation: Upstream
In this chapter, you'll find recommendations to manage **upstream** effectively.
Upstream takes your project from business-ready to engineering-ready.
In order for requirements to meet the DOR (Definition of Ready), they go through a defined lifecycle.
For a pure backend platform development program, the upstream flow will be: Requirements Sign Off -> Solutioning -> Solution Signoff
For an End to End platform development Program (both Backend and Frontend), the upstream flow will be: Requirements Approval -> UX/VD Creation -> UX/VD Signoff -> Solutioning -> Solution Signoff
The following recommendations can help you manage upstream effectively.
1. Rather than tracking over emails or in excel sheets, create tasks in JIRA/ADO to track every single upstream activity – their status should be tracked throughout the upstream readiness cycle.
2. Define dates for completion of each upstream activity.
Access a Sample Upstream Delivery Plan
3. Track closures against the dates.
4. Raise alarms/escalate to leadership and client upfront if readiness dates are not met.
5. Emphasize reducing the cycle time/number of iterations required to get the requirements “Ready.”
6. If the client requires you to solution “dirty,” raise it to the client. The requirement can be optimized/refined to enable an optimized solution. Do NOT compromise on a stop gap solution, or you risk technical debt later.
7. Avoid starting development till DOR is met. If it must be started to consume Engineering capacity, have this signed in writing with the client that any changes post development start will be taken as CR.
8. NFR is part of functional deliveries. Do not park them in the future, or they will need a complete code rewrite.
9. Follow Ideal Epic/Feature structure:
- Separate Backend stories
- Separate Frontend stories
- Backend-Frontend Integration story
- E2E Testing story
- Stories for NFRs – Eg Screen Loader, UI Locator, Performance, etc.
10. Make each story as granular as possible to enable independent development and testing.
Access an Upstream Readiness Tracker
Home
Managing Digital Transformation: Downstream
In this chapter, you'll find recommendations to manage **downstream** effectively.
Downstream takes your project from engineering-ready to acceptance-ready.
In order for requirements to meet the DOR (Definition of Ready), they go through a defined lifecycle.
For the requirements to meet the DOD (Definition of Done), they go through the following stages:
Requirements Ready -> Sprint grooming -> Sprint planning -> Sprint execution (Development + QA Testing)
The following recommendations can help you manage downstream effectively.
Sprint Grooming, which consists of:
- Functional Grooming
- Technical Grooming
1. Epics/features to be developed in the nth sprint should be groomed in the (n-1)th sprint. Grooming in the same sprint leads to improper planning and delayed development.
2. Ensure proper attendance in grooming - leads, developers, and QA along with PO/BA and architects. Missing members leads to communication gaps and can result in increased bug counts later.
3. Record the grooming sessions for later reference.
4. Maintain a Query log (see a sample here) for open questions after grooming, and hold a follow-up session to clarify any doubts. BAs should provide answers against the query log.
5. Architects should carry out technical grooming (solution walkthrough) with the entire development team before the development begins. Having both frontend and backend in the same technical grooming will ensure the integration gaps are minimized.
Sprint Planning, which consists of:
- Story estimation
- Story assignment
- Story tasking
1. Story estimation aims at arriving at estimates for each story (either in SP or PD) by the entire team, so the entire team’s participation is needed.
2. The team should have a common estimation model against which they should estimate. This will reduce the chances of varying estimates.
Access a Sample Estimation Guidelines Framework
3. Estimates (SP or PD) are the cumulative estimates of both dev and QA.
4. Story points should be based on three major factors: Complexity, Effort, and Uncertainty. Using a standard SP model based on these three factors will standardize the SPs.
5. Some factors to consider while planning for capacity include the impact of unplanned leaves, the impact of COVID, and the effort required to be planned for tech debt (if no hardening sprint is considered in overall plan).
6. It is very important to do a proper assignment of stories (keeping in mind the team's strengths and weaknesses) and proper tasking of stories with original estimates captured on the first day of the sprint.
Access a Sample Story Point Framework
Sprint Execution, which consists of:
1. Commit stories in a sprint as per the load factor of the team. (Ideal load is 78-80% of the team’s capacity) [Capacity = No. of Dev & QA x working days in a sprint].
2. The first day of the sprint should focus only on planning and requirement analysis. The better the requirement analysis by dev and QA, the better will be the quality of delivery.
Access a Sample Sprint Cadence
3. To reduce understanding gaps, the test cases should be reviewed by BA and shared with the dev.
4. Any gaps in the story (discrepancies between AC and VD or between AC and solution) should be raised before delivering the story.
Discussions at a later stage when a bug is raised increase the cycle time of fix.
5. There should be a proper sprint cadence with dev cut-off date, deployment to each environment dates well defined, and strictly followed throughout the sprint.
6. The delivery of stories to the QA team should be planned in batches rather than as a big bang towards the sprint end.
7. The deliveries should not only be certified by the Product team but by Architects, as well.
This will ensure that no tech debts are accumulated and that the development is in accordance with the solution.
For this, a weekly review by architects during the development and testing phase should be a part of the sprint cadence.
8. Stand-ups should be duly and properly held where the status of each item in the sprint should be tracked rather than the status of each individual.
Access a Sample Standup Tracker
9. Daily or at least each alternate day SOS is a must for effectively managing digital transformation programs.
- Must have attendees: Delivery owner, SM of each team, QA Manager.
- Agenda: Track the status of each epic/feature planned in the sprint.
- Track whether due dates are being met; if not, come up with a mitigation plan. Call required stakeholders on a need basis and resolve the queries towards closures.
Access a Sample SOS Tracker
Home
Conclusion: Best Practices for Digital Transformation
Key tips and takeaways
Keep these best practices in mind for digital transformation program management success.
1. Get specific.
Dive into details, understand, and ask questions. This is the only way to preempt risks and proactively mitigate risks.
2. You can’t manage what you can’t measure.
Ensure data correctness and completeness. Automate reporting to enhance effectiveness.
3. Never compromise on quality.
Follow proper cadence to ensure due time is given to testing.
4. Remember that NFRs are as important as functional deliveries.
What fun is building a 100km/hr lane if your car can only go 20km/hr?
5. Have well-defined ownership.
Ensure RACI is defined for each stakeholder in delivering such programs and revisit it regularly.
Home
About GlobalLogic
A Hitachi Group Company
About GlobalLogic
GlobalLogic is a leader in digital engineering.
We help brands across the globe design and build innovative products, platforms, and digital experiences for the modern world.
By integrating experience design, complex engineering, and data expertise—we help our clients imagine what’s possible, and accelerate their transition into tomorrow’s digital businesses.
Headquartered in Silicon Valley, GlobalLogic operates design studios and engineering centers around the world, extending our deep expertise to customers in the automotive, communications, financial services, healthcare and life sciences, manufacturing, media and entertainment, semiconductor, and technology industries.
GlobalLogic is a Hitachi Group Company operating under Hitachi, Ltd. (TSE: 6501) which contributes to a sustainable society with a higher quality of life by driving innovation through data and technology as the Social Innovation Business.
Visit our website at globallogic.com.
How Can We Help You?
Let's explore how the right digital engineering partner can help transform your business. Get in touch to book your free 15-minute initial consultation now.
