I discovered these 5 surprises in managing an agile digital project

Apr 29, 2019 | Agile, Change Initiatives

Latest Articles

Get the latest change articles delivered to you!
Subscribe Now

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.

Change Compass

Signup for the most indepth change management articles

Related Posts

The ultimate guide to measuring change

The ultimate guide to measuring change

Updated 1 August 2024   A lot of change practitioners are extremely comfortable with saying that change management is about attitudes, behaviours, and feelings and therefore we cannot measure them.  After all, a big chunk of change folks are more interested in...

Do Agile Teams Really Need Change Managers?

Do Agile Teams Really Need Change Managers?

The role of change managers has been left out of the various agile methodologies.  This is even though most fully acknowledge the importance of change management in the success of initiatives. Does this mean that the agile teams should and can take on...