As someone who is normally overseeing 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, and 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.
The customer/user doesn’t always know 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 inline 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 actually 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 these 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 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.
To read more about avoiding key gaps in managing customer experience click here.
Setting clear expectations is absolutely 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, 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 learnt was the importance of setting clear and mutually agreed to work deliverables. With such a diverse team composition comes 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 learnt was that clear documentation is absolutely critical to ensure that there is 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.
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 jargons 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 designer 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.
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 still remain that effective team dynamics is key to a high performing project team.
Most of the issues we have faced is around team communications, shared understanding, how different team members work with each other, and of course cross-cultural perceptions and behaviours. Any effort we have placed in discussing and resolving team dynamics and behaviours have always led to improved work performance.
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 is one that 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.
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 that is 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.