In response to declining revenue in one of their customer segments due to changes in market dynamics, a group of executives assembled on a Monday morning to come up with a strategic initiative to counter this problem. To do so, the enterprise needed to launch a new digital transformation program to replace the old front-office systems and introduce digital automation that would enable the provision of omnichannel front-end experiences through web-based and mobile technologies. An upgrade to the existing enterprise resource planning (ERP) system was also part of the plan. For anyone who has been in the corporate world long enough, this rhetoric will, most likely, sound familiar.
Based on lessons from experience, it is important to identify and discuss 10 potential risk areas, or blind spots, an executive-level director, program sponsor or program director may encounter when embarking on a transformation program of this nature. Some of these points may be obvious, while others tend to be ignored due to biases and competing forces at play during program delivery. Many of these points speak to the human aspect, because programs are developed and implemented by people.
Blind Spot 1: Getting the Right People Involved at the Right Time
Embarking on a transformation program that cuts across or leverages multiple functional areas can quickly expose whether these parties are working with or against one another. For example, regulatory and compliance issues and security and assurance validations must be addressed before certain programs are launched into the market. Having these parties involved early in the design process can reduce the likelihood of red flags being raised just ahead of the commercial go live. These key parties should be identified early and be kept on board.
As mundane as this might sound, another aspect is having the right decision-makers in the same room for key governance forums (i.e., achieving a quorum). This enables efficient and timely decision making and avoids the need to bring absent stakeholders up to speed. Stakeholders should be on the lookout for repeat offenders who miss important decision-making forums/meetings and take steps to impose discipline on these invitees/parties.1
Blind Spot 2: Building for Tomorrow
In looking at the program’s sustainability, especially in Agile environments with several unknowns, team members can get caught up in the “here and now” as they firefight tactical issues. Program leaders must be prepared to continually refocus the team, flexing between short-term and midterm perspectives and recognizing that there is a bigger picture to consider. This requires intentionality.2 Also, borrowing from Eisenhower’s matrix (a well-known method of prioritizing tasks based on their urgency),3 leaders should encourage the team to distinguish between what is urgent and what is important.
THE INABILITY TO RETAIN CORE COMPETENCIES BUILT UP DURING PROGRAM DEVELOPMENT ALSO MAKES KNOWLEDGE LOSS AND PROGRAM FAILURE MORE LIKELY.
At some point, the solution needs to be operationalized and then managed sustainably. This is where the transfer of knowledge from the program to the enterprise, including new ways of working, becomes critical. To manage this, the program’s resourcing strategy must be balanced: With too much reliance on third parties, the risk of knowledge loss increases, whereas with too much in-house resourcing and influence, the ability to implement new ways of working (e.g., making the business more agile) is hampered.4
The inability to retain core competencies built up during program development also makes knowledge loss and program failure more likely. Deliberate success-planning strategies should be employed.5
Blind Spot 3: Keeping the Relationship Above Water
Written contracts are a necessary part of compliance checks, and they should be put in place and approved accordingly. Even more important is managing the business relationship. One of the principles of Agile is “customer collaboration over contract negotiation.” With good relationships comes collaboration, which is governed less by written contracts and more by psychological contracts. Establishing these psychological contracts ensures that trust is maintained, expectations are managed and risk is shared between parties.
That being said, good hygiene practices should prevail around managing written contracts. It is prudent to have all the necessary written contracts and required documentation in place. Some organizations cannot do business with vendors without stringent procurement checks and balances, and improper contract management processes can lead to a halt in deliveries, impacting momentum and timelines.
Likewise, a psychological contract is insufficient when it comes to loosely worded scope-of-work requirements. It is important to have a written trail of expectations on which to rely.
Blind Spot 4: Cutting the Cloth to Fit the Suit
Building onto the point of scope requirements, pressure can result in a program’s scope going beyond what was initially planned. Unfortunately, saying “no” is not always easy. Due to the interdependence of the enterprise and the program, project team members may be inclined to agree to an additional requirement or revision to build goodwill, hoping to call in a favor somewhere down the line, such as prioritizing a request in a technical release. Over time, these add-ons or change requests can impact the team’s ability to meet its commitment to core functionality, putting pressure on the overall program. Team members get stretched thin, and fatigue settles in. An alternative to saying no is saying not right now. This is not unreasonable or uncommon, as Agile programs prioritize scope on a sprint-by-sprint basis.
Blind Spot 5: Understanding the Impact of Change
When a change is introduced into a program, whether it is related to the scope of technical functionality or the approach to underlying technology deployment, the importance of understanding its true impact cannot be overemphasized. For example, a program may initially use a cloud-based model, but shortly after the program starts, a change to on-premises deployment may be required, owing to challenges in conforming to security and privacy policies. The true impact of such a change should be quantified by considering the downstream effects on system integration, timelines, costs (i.e., hardware, software, personnel), technical skills required, service and configuration management, and security considerations. Although this example involves technology-related change, for other nontechnology-related program changes, the “big three” constraints should be considered: time, cost and quality.
In agile, fast-moving programs, it is critical for program leadership to deliberately pause when these decisions are being made, taking the time to quantify the true impact, consulting the relevant subject matter experts and engaging the sponsors to spell out the true impact of the change before proceeding.
Blind Spot 6: Recognizing That Agility Does Not Equal Lack of Discipline
Contrary to perceptions surrounding the word “agile,” Agile methods do not negate the need for discipline. Agile methodologies such as Scrum require discipline in sprint planning, daily stand-ups, backlog grooming, sprint demonstrations, retrospectives and the like. The focus is not on the process itself; as stated in the Agile manifesto, “Individuals and interactions over processes and tools.”6 However, these structures enable agility in product development.
HAVING THE RIGHT GOVERNANCE STRUCTURES IN PLACE AT THE OUTSET HELPS MINIMIZE THE RISK OF MAKING “NARROW” DECISIONS THAT CAN HAVE FAR-REACHING CONSEQUENCES.
Software that is functioning rather than elaborate documentation is another tenet of the manifesto.7 Again, this does not negate the need for key documented outcomes. Individuals tend to forget commitments and promises, so it is important to get those interactions on paper to help keep everyone honest.
Some believe the Scrum master is the project leader and knows everything. With complex technology programs employing Agile methods, the Scrum master is not necessarily the project leader and cannot be expected to be an expert in all things. With complex advances in technology, the Scrum master simply facilitates a meeting of the minds and helps remove obstacles known as blockers. This is where the management of complex technology projects may differ from that of other types of projects.
In the case of some technology and nontechnology projects that produce a known product that has been developed and matured over time (e.g., well-established enterprise resource planning [ERP] systems), the project manager may have risen through the ranks. In this scenario, the project manager can expect to know more than the delivery team, based on experience. However, when dealing with complex technologies, it is important for the Scrum master or project manager to realize that this is not always the case. The structure and level of knowledge may be less concentrated and less hierarchical, in which case the Scrum master’s role is to facilitate the assembling of specialists. One way to avoid problems is to manage expectations up front and empower all specialist team members to control their own domains.
Blind Spot 7: Achieving Consensus and Making Good Decisions
At the start of these types of programs, it is crucial to clarify among key stakeholders and decision-makers whether the program is a business or a technology transformation. This becomes critical when there are competing priorities related to resourcing and risk or contending views about crucial architectural decision points. Having the right governance structures in place at the outset helps minimize the risk of making “narrow” decisions that can have far-reaching consequences, such as technical debt, unrealized benefits, additional complexities, and even external customer and legal or regulatory risk exposure.
Another related consideration is the impact of decisions on targets and key performance indicators (KPIs). Sometimes conflicts arise among what is good for the organization vs. the program vs. the stakeholders’ KPIs. Creating an environment of transparency, trust and healthy negotiation enables the program to move past these hurdles in the right way.
At some point, it becomes necessary to review the current state of the program against its original intentions to determine whether the business situation has changed and whether the program is still justified. This requires careful analysis to avoid drawing haphazard and emotional conclusions. At the same time, this should not be a purely quantitative exercise because efficiencies, improved control, enhanced customer service, employee engagement and sustainability are not always clearly quantifiable.
Blind Spot 8: Recognizing That the Human Factor Can Make or Break a Program
One thing is certain: Systems impact people, and people have feelings. The human impact of a change introduced by a transformation program needs to be prioritized, as the best solution may not have the best impact on the customer or end-user experience.
Similarly, in preparing the training and rollout plan, certain human aspects, such as teaching users new skills at the right time, need to be factored into planning. Neuroscience research on learning retention found that staff members forget 50 percent of what they learned within one hour (if not applied in real time), 70 percent within 24 hours and 90 percent within one week.8
In an Agile deployment approach, software building may continue concurrently with solution rollout. Thus, delta training and the acquisition of new skills must be managed closely to avoid gaps in knowledge transfer during rollout.
Another aspect of change and adoption is the phenomenon of internal and external shifts in power and perceptions during the program’s life cycle. This needs to be monitored so that any potential areas of resistance to change can be dealt with immediately.
Blind Spot 9: No Program Is an Island
It is natural for team members to concentrate solely on the program, and rightly so. If they were to lose focus on the task at hand, they might not accomplish much. However, inter-program dependency management is something that program sponsors need to worry about. The right organizational structures with the appropriate level of authority should be established up front.
WITH NEW WAYS OF WORKING, SUCH AS AGILE OR HYBRID AGILE METHODS, THE SPEED OF DELIVERY IS GEARED UP A NOTCH COMPARED WITH BAU.
In addition, the program should be equipped to handle the changing needs of the enterprise. Again, having the right structures in place without losing focus on the main priorities is key. One way to manage this is for the program to play a role in business as usual (BAU) decisions, and vice versa—for example, involve the program team in planning a new product launch that impacts the program, or involve business leaders in making key decisions about committing to program timelines.
Remember that delivery speeds may vary between business operations and the program. Multimodal operating models can arise between BAU delivery teams and program teams. With new ways of working, such as Agile or hybrid Agile methods, the speed of delivery is geared up a notch compared with BAU. Simply put, in-house project delivery teams may turn around project-related deliverables at a rate that is not in line with the program’s plan. Unfortunately, the program cannot divorce itself from this dependence, especially when there are integration points with legacy systems that necessitate increased dependence on BAU delivery teams.9
This is not to say that BAU project delivery teams are less competent. BAU teams may have multiple priorities to deal with, whereas program teams may be focused on only their own outputs. Matching the speed of delivery between the program and BAU has an impact on the ability to meet the program’s committed time frames. Providing for this in the program planning estimates reduces disappointments and misaligned expectations.
Blind Spot 10: Acknowledging That People Are the Greatest Asset
Projects are delivered by people, not robots. Large programs tend to push people beyond their comfort zones due to unknowns, high-pressure time lines, and the need for quick decision-making and persistent problem solving. Despite the natural inclination to maximize resource capacity, people can choose whether to bring their best to the program or give only their bare minimum out of necessity. Disgruntled people help neither the team nor themselves.
It is imperative to remember the human element in decision-making. Some questions to consider include:
- Can that release be deferred from this weekend to next week, given that the team has been working so hard?
- Can that tough feedback conversation be held tomorrow morning instead of cramming it into today’s late-afternoon session?
- Can this decision be deferred until an expert has been consulted, even if it means delaying the decision by another week?
IN AGILE TRANSFORMATION PROGRAMS, THERE WILL ALWAYS BE A FEW UNKNOWNS THE TEAM MUST DEAL WITH, AND PART OF THIS IS TAKING RISK AND VENTURING INTO UNCHARTED TERRITORY.
Psychological confidence is another consideration that goes beyond quantitative or technical factors. For instance, program directors should encourage their teams to “fail with integrity.” In Agile transformation programs, there will always be a few unknowns the team must deal with, and part of this is taking risk and venturing into uncharted territory. If team members feel the support of executives, they will be more willing to take this risk and stretch the boundary of current thinking into the realm of innovation.
The absence of this kind of psychological safety net can result in extreme anxiety among a team that is aspiring to perfection and trying to gain control over a fluid situation.10 It is worthwhile to foster a culture that is conducive to such an undertaking and not only encourages risk taking but also nurtures and enhances optimal human-to-human interactions and uplifts team morale among an enterprise’s greatest asset: people.
Conclusion
Risk cannot always be avoided and, in fact, Agile programs of this nature demand deliberate and complex risk taking. These 10 blind spots are not exhaustive, but they highlight focus areas for risk management efforts. In simplifying risk management for these types of programs, the following actions should be considered daily:
- Minimize and prepare for known risk factors.
- Actively mitigate and accept those risk factors within the current locus of control.
- Quickly identify which risk factors to prioritize.
By following this approach, the complexity of risk management can be minimized, while the opportunities presented by risk can be maximized.
Endnotes
1 Raval, V.; R. Sharma; “Mitigating the Risk Factors of IT Project Failure,” ISACA® Journal, vol. 3, 2017, http://kcx9.doinghg.com/archives
2 Monahan, K.; M. Cotteleer; J. Fisher; “Does Scarcity Make You Dumb? A Behavioral Understanding of How Scarcity Diminishes Our Decision Making and Control,” Deloitte University Press, USA, 2016, http://www2.deloitte.com/content/dam/insights/us/articles/scarcity-mind-set-improving-decision-making/DUP_3074_DoesScarcityMakeYouDumb.pdf
3 Lebowitz, S.; W. Cheong; “How to Use a Simple Time-Management Trick Invented by President Eisenhower to Become More Productive and Less Stressed at Work,” Business Insider, 27 December 2019, http://www.businessinsider.com/how-to-use-stephen-coveys-time-management-matrix-2015-12?IR=T
4 Deloitte, “Dynamic Strategy Implementation: Delivering on Your Strategic Ambition,” CFO Insights, 2018, http://www2.deloitte.com/content/dam/insights/us/articles/dynamic-strategy-implementation-delivering-on-your-strategic-ambition/DUP_603_Dynamic-Strategic-Implementation_FINAL1.pdf
5 Pearce, G.; “Enhancing the Board’s Readiness for Digital Transformation Governance,” ISACA Journal, vol. 5, 2019, http://kcx9.doinghg.com/archives
6 Agile, “Principles Behind the Agile Manifesto,” http://agilemanifesto.org/principles.html
7 Ibid.
8 Kohn, A.; “Brain Science: Overcoming the Forgetting Curve,” Learning Solutions, 10 April 2014, http://learningsolutionsmag.com/articles/1400/brain-science-overcoming-the-forgetting-curve
9 Kane, G.; D. Palmer; A. N. Phillips; D. Kiron; N. Buckley; “Coming of Age Digitally,” MITSloan Management Review, 2018, http://sloanreview.mit.edu/projects/coming-of-age-digitally/
10 LinkedIn, “Enterprise Agile: Changing Your Culture,” 31 March 2017, http://www.linkedin.com/learning/enterprise-agile-changing-your-culture
Chris Ngiba
Is an experienced management and technology consultant with 12 years of experience in various industries including financial services, telecommunications, public sector and waste management. He has rich, varied experience within consulting and risk advisory.
Mayank Naik, CISA, CRISC
Is a technology risk advisor currently focused on providing program risk assurance services to clients in the technology, media and telecom (TMT) sector. He has more than nine years of experience in IT audit, risk and controls, and project management.