I discovered these 5 surprises in managing an agile digital project

I discovered these 5 surprises in managing an agile digital project

As someone who is normally oversees the change management side of large programs and portfolios, I now find myself being in the shoes of a project manager. Here’s the background. I now manage a digital software-as-a-service business (The Change Compass) aimed at those who are driving multiple changes in their organizations. In terms of managing change deliverables and stakeholders, I was perfectly comfortable, having done this with some of the largest organizations in the world. However, I was not trained as a project manager, particularly not in managing a digital product.

Having worked on very large digital projects over the years I‘m familiar with the different phases of the project lifecycle and lean/agile/scaled agile methodologies. However, managing a digital project hands-on has revealed some very surprising learnings for me. I will share this in the following.

1. The customer/user doesn’t always know the best

Over the years we have received quite a lot of customer feedback about what worked and what didn’t work and we have iteratively morphed the application in line with customer wishes. However, a ‘customer/user suggestion or wish’ is not always the best for them. There are some features that we have developed to enable the user to build different reports. However, after lots of feedback, and iterations, we’ve found that the users don’t use these features much at all. On the other hand, there are other features designed based on our observations of how users have behaved that are very frequently used. In the design phase, some users have commented that they are not sure if these features will work. However, after trialing these they have easily adopted them and have not made any suggestions or comments since.

It is probably similar to when the first iPhone was released. A lot of people were negative about how it did not have a keyboard and that the lack of tactile pressing of buttons was a sure sign that it was not going to work. Did Apple derive the iPhone purely based on customer feedback? Did customers already know what they wanted and simply told Apple? Nope. Well, the screen-only mobile phone with no or limited buttons is now a standard across mobile phone design.

Example: In our digital project management experience with The Change Compass, we initially prioritized implementing a feature based on numerous customer requests. This feature allowed users to customize their dashboard layout extensively. However, after analyzing user behavior data post-launch, we discovered that this feature was rarely used by our target audience. Surprisingly, users preferred a simpler default layout that we had originally designed based on our understanding of their workflow and preferences. As a result, we decided to refine the default layout further and focus on enhancing features that aligned more closely with user needs and behaviors within our change management software.

To read more about avoiding key gaps in managing customer experience click here.

2. Setting clear expectations is critical


At The Change Compass, we have a very diverse and scattered team. We have our development team in India, a UX designer in Canada, a graphic designer in Europe, and Analysts in Australia. Most of our team members are quite familiar with agile practices. They are familiar with each phase of the agile life cycle, Kanban boards, iterating releases, etc. For our Ultimate Guide to Agile for Change Managers click here.

However, one big lesson I learned was the importance of setting clear and mutually agreed-to-work deliverables. With such a diverse team composition comes a diverse understanding of the same concept. In agile, we try not to over-document and rely on discussions and ongoing engagement to achieve collaboration and clarity.

However, what I learned was that clear documentation is critical to ensure that there is a crystal clear understanding of the scope, what each deliverable looks like, what quality processes are in place to reach the outcome, the dependencies across different pieces of work, and what each person is accountable and not accountable for. All of these sound like common sense. However, the point is that it is common for agile projects to err on the side of too light in documentation, therefore leading to frustrations, confusion, and lack of outcome achievement. In our experience, documentation is critical.

Example: At The Change Compass, we’ve learned the importance of setting clear and mutually agreed-upon work deliverables, especially with our diverse global team. Despite our team’s familiarity with agile practices, we realized that documentation is critical to ensure a crystal-clear understanding of project scope, deliverables, quality processes, dependencies, and individual accountabilities. By documenting these aspects thoroughly within our change management software, we’ve achieved better collaboration, clarity, and outcome achievement across our distributed team.

3. Boil everything down to its most basic meaning

In digital projects, there is a lot of technical jargon with backend, front end, and mid-layer design elements. Like any technology project, there seems to be a natural inclination to become overwhelmed with what is the best technical solution. Since I did not have a technology background I forced myself to become very quickly familiar with the various technical jargon in delivery to try to compensate.

However, what I found was that with such a diverse team, even within the technical team there is often misunderstanding about what a technical term means. On top of this, we have other non-technical team members such as Analysts, UX designers, and Graphic Designer. We have experienced lots of team miscommunications and frustrations as a result of too much technical language.

To ensure the whole team is clear on what we are working on, how we are approaching it, and their roles in this along the way, we’ve tried hard to ‘dumb down’ the use of technical jargon into basic language as much as possible. Yes – there is a basic set of digital language necessary for delivery that all members should understand. But, beyond this, we’ve tried to keep things very simple to keep everyone on the same page. And the same can also be applied to non-technical language, for example, graphic design technical terms that the techies may not be able to understand can also cause misunderstanding.

Example: In our digital project management endeavors with The Change Compass, we’ve encountered challenges due to technical jargon and miscommunications within our diverse team. To mitigate this, we’ve prioritized simplifying technical language into basic terms that everyone, including non-technical team members like Analysts, UX designers, and Graphic Designers, can understand. By keeping communication simple and clear, we ensure that everyone is on the same page regarding project objectives, approaches, and roles within our change management platform.

4. Team dynamics is still key …. Yes, even in a digital project


To get on the agile bandwagon a lot of project practitioners invest deeply to undergo various training to become more familiar with how agile projects are conducted. While this is critical what I’ve found is that no matter what project methodology, agile or non-agile, digital or non-digital, the basics remain that effective team dynamics are key to a high-performing project team.

Most of the issues we have faced are around team communications, shared understanding, how different team members work with each other, and of course cross-cultural perceptions and behaviors. Any effort we have placed in discussing and resolving team dynamics and behaviors has always led to improved work performance.

Example: Despite the focus on agile methodologies and digital tools, effective team dynamics remain crucial within The Change Compass. We’ve observed that issues around team communications, shared understanding, and cross-cultural perceptions can significantly impact project performance. By investing effort in discussing and resolving team dynamics and behaviors, we’ve consistently improved work performance and collaboration within our change management software, resulting in better outcomes for our clients.

5. The struggle of releasing something that isn’t perfect is hard


Being a typical corporate guy having worked in various large corporate multinationals it is ingrained in me that quality assurance and risk management are key to any work outcome. Quality work ticks all boxes with no flaws and that does not expose any risks to the company. In the typical corporate world, any flaws are to be avoided. Thorough research,, analysis, and testing are required to ensure the quality is optimal.

Example: As individuals with a background in corporate change management, we initially struggled with the agile approach of releasing minimum viable products (MVPs) within The Change Compass software. While ingrained in the notion of quality assurance and risk management, we learned to embrace the agile principle of continuous improvement. Instead of aiming for perfection upfront, we focus on releasing usable features and iterating based on ongoing customer feedback. This approach allows us to deliver value incrementally and adapt our change management software to evolving user needs and preferences.

The agile approach challenges this notion head-on. The assumption is that it is not possible to know exactly what the customer or user reaction is going to be. Therefore, it makes sense to start with a minimum viable product, and iterate continuously to improve, leveraging ongoing customer feedback. In this approach, it is expected that what is released will not be perfect and cannot be perfect. The aim is to have something usable first. Then, work to gradually perfect it.

Whilst in theory, it makes sense, I’ve personally found it very difficult not to try and tick all boxes before releasing something to the customer. There are potentially hundreds of features or designs that could be incorporated to make the overall experience better. We all know that creating a fantastic customer experience is important. Yet, an agile approach refrains from aiming to perfect the customer experience too much, instead, relying on continuous improvement.

Ready to streamline your change management process and drive better outcomes with The Change Compass? Book a demo today to see how our software can help your organization succeed.

The death of the change heat map

The death of the change heat map

Change heatmaps are considered valuable by many organizations struggling with facing too much change. Heatmaps are easy to understand and people intuitively get heatmaps without much explanation. The darker colours are bad, or too much change. The lighter colours are good, less change, or at least this is a common interpretation.

Change heatmaps are commonly used to help decipher whether there is or there is not too much change going on. Stakeholder groups such as the program management office, senior managers, operations managers and other project professionals commonly use the heatmap to show the change ‘heat’ levels of a part of the organization.

So why is this article entitled ‘The death of the change heatmap’?

The problem with most organizations using change heatmaps is that it is often blindly used as a singular discussion point.

A program team would typically review the change heatmap with business stakeholders regarding the current slate of changes. Typical conversations would focus on how many initiatives there are within a given month, and arguments would start around whether it is indeed considered ‘too much change’ or ‘not too much change’. This can become quite rhetorical since it is really anyone’s opinion since this is not a quantitative, numerical discussion.

In this type of discussion, the change manager is often the one raising that there could be too much change going on. A typical response from senior managers would be “Yes there is a lot of change and this is what we need to get on with”. From the senior manager’s perspective, even when presented with a ‘red’ heatmap insinuating too much change, the business is still functioning and has not collapsed. Therefore, the change manager must not be connected to the realities of the business (or at least, what goes through the senior manager’s head).

A discussion focused purely on too much, too little, or just right in the level of change is quite limiting to add value to the business. Are we really only concerned about the magnitude of the change without any other consideration? And how could anyone rely on individual opinions of whether there is or there isn’t too much change when this may not be tied to actual business performance? Most change heat maps are not quantitative summations of change impacts but individual opinions – how might we make this more scientific?

From ‘too much’/’too little’ discussion to story-telling

Change is about design. In planning for change we are designing what the change journey is going to be like. When we have a clear picture of what is going to change, and all the elements around when, where, what, who, how, etc. then we are able to truly paint a picture of what the change experience is going to be.

From this clear picture of the change experience (through having a singular integrated picture of change that is data-based), we are then able to start to tell stories of what will happen and what those experiences might look like.

For example, a story could be that the call centre will be facing significant challenges in balancing both customer call volumes and going through the 12 initiatives during November. Customer call volumes are anticipated to start to trend up, whilst 4 different types of training sessions are expected to take place as a part of the roll out of 4 major initiatives. Those teams supporting Product A will be particularly challenged given 2 of the initiatives impact that team more than other teams. In addition, the desired behaviours being focused by the initiatives are quite different. Some are reinforcing compliance and process adherence, whilst others are about thinking out of the box and experimenting with new ways of working.

You can see from the above example that having a rich set of data about what changes is going to happen can paint a vivid picture of what is going to happen, and therefore emerging challenges and opportunities. The conversations go significant beyond the quantity and judgment of magnitude, through to the type of experiences, possible operational and capacity challenges, behavioural expectations and potential customer impacts.

How might we move on to more valuable discussions beyond the heatmap?

For those who have experienced situations where a heatmap discussion did not lead to any significant business outcomes, what else could we talk about?

  1. Link heatmap to quantitative business impacts

At a basic level a heatmap can inform stakeholders the foundational picture of how much change if there is direct linkage to time and capacity impacts. For example, given there are 12 initiatives occurring within the call centre in November, how much time is expected to digest and embed this change within that month? 5 hours per week? And would this impact 1,000 call centre staff? Therefore, how does this compare in terms of manpower planning projections in November? Are there challenges to service projected customer call volumes and go through the 5 hours per week required for call centre agents?

To do this we also need to ensure any generated ‘heat level’s are calculated based on actual quantitative change impact levels of each initiative. With historical data on change impacts, it’s also possible and highly impactful to draw correlations between change impact levels and resulting business performance indicators.

  1. Dive deeper into what is really going on within a particular business.

Instead of focusing on the magnitude of change, zoom in on the specific risks or opportunities. Good questions to ask to paint a story around these include:

  • What has this part of the business experienced in the past and how might they perceive this set of changes?
  • What types of leadership do we have in this business? What are some of these characteristics? How do these impact how change will be implemented and embedded?
  • What support and engagement channels do they have? Do they have change champion networks that can support a multitude of initiatives?
  • How has this business been communicated about the myriad set of changes?
  • Has there been a clear picture painted by the leaders of where they are going and how these changes will get them closer to their goals?
  • How might we better package, sequence or link the set of changes to enhance adoption?
  1. Show how the strategy is being implemented

A set of strategies will only come to live through successful change implementation. Again, armed with a clear integrated single view of change, you can present a picture of what initiatives are impacting the organization for each of the strategic pillars that the organization has invested in. Particular attention may be drawn to to what extent certain strategic pillars may be making more impacts on the organization at particular points in time.

This is one area in which senior managers will be highly interested. The discussion is not just about operational capacity, but instead moving to the strategic realm to question what the strategic change implementation looks like and how this compares to the intent. Is the set of changes we are planning at the right pace? Or are we not executing fast enough? Is it expected that strategic pillar A exerts more impact in business unit A than B? Or are there gaps in how we’ve designed the overall change journey to realize our objectives? What capabilities may be required for certain lines of business units given the set of changes they will be going through?

So, you can see the change heatmap should absolutely not be the singular focus in understanding multiple changes. If you only focused on the change heatmap with your stakeholders then be prepared for lots of challenges and questions as to the value of this artefact.  So, it is not that the change heatmap should not be used or can never add insight. Instead, probe deeper into your data and paint a rich picture of what is going to happen, what this means to the business in tangible terms, and even how the organization’s strategy is being implemented.

For case studies of how some companies have identified risks and opportunities through painting a rich picture of what is going to happen to the business visit here …

Case study 1

Case study 2

Visual images paint a thousand words. If you would like more information on how to visually represent change in all its different facets to tell the full story of what your organization will go through, please trial The Change Compass for free, or drop me a note on [email protected].

The Ultimate Guide in Designing a 5 star Change Journey

The Ultimate Guide in Designing a 5 star Change Journey

Designing a change journey is a design process.  Like in any design processes, you need to know intimately the impacted people you are working with, the world they are in and their expectations and behaviours.  In this way, design is about anticipating and shaping the experience of people.

  • What are the elements of a 5 star change experience?
  • What is the role of data in design?
  • How does branding and communications shape the experience?
  • How do we anticipate people needs?

For a comprehensive guide on how to undergo this design process to come up with a 5 star change journey, check out our guide.

Click here to download the guide.

Ultimate guide to 5 star change journey