My Best Advice For Boosting Your IT Project And Winning Your Customers’ Trust
Getting results without betraying yourself
Do you prefer to stick to your budget, even if it means sacrificing the quality of your project, or do you prefer to aim for excellence, regardless of the cost?
A good professional will say it’s a question of compromise. But very quickly, you realize that the decision is not yours to make. The truth is, you have no power over your customer’s project, at least not at first.
In reality, if the customer calls on your expertise, it’s because you’re the expert.
I’ve come to realize that there are two kinds of people at work. The people who have to put up with everything all day long. And then there are the people who love what they do.
But how do they do it?
I have my own idea, because I spent over a year having fun on a project that turned into a real success.
I didn’t betray my values, nor those of the team of developers.
And we respected the customer’s values.
How did we do it? Here’s a simple, common-sense strategy.
The proof is in the user reviews, before and during our intervention
The English translation is below the screenshots.
Left: before our intervention
1*
App probably cobbled together by a (…)
on the iPhone, filling in forms is difficult because the keyboard is superimposed on the form, preventing you from seeing what you’re writing. In the end, you get an incomprehensible error message (pseudo or e-mail does not exist ???) which doesn’t suggest the corrective action to take and therefore blocks (…)
1*
Doesn’t work with latest (version)
Since the last update, the application crashes at login.
Right: during our intervention
5*
All is well
The application works perfectly, everything’s fine
Enriching application
Finally an almost bank account very useful I recommend for people who want to do more with their money …
5*
Services
Very satisfied!
5*
Simply perfect
Fun and efficient
No complaints
Breaking the ice
That was two years ago. I’m working as a Product Owner in a mobile development company. I’d never managed a project on my own, in other words, this was my first challenge. And I know I mustn’t fail.
There are five of us in the team. Alongside me are two LeadDevs (iOS and Android) and two developers (iOS and Android).
The company we’re working for has just audited a native mobile application. The aim of the mission is to maintain the application, i.e. to correct any anomalies.
On paper, the project promises to be boring. Developers hate fixing bugs all day long. So does the Product Owner, who is bored with no planning or features to work on.
But the team is driven by real values: technical quality and user satisfaction.
For the customer and the company, it’s the success of the contract.
But on closer inspection, the customer has changed companies. His previous contract didn’t go so well, and he’s placed his expectations and, above all, his demands on this new partnership. It’s like getting into a relationship with someone who’s just come out of a difficult one.
In reality, the success of the project doesn’t depend on the customer or the company. It depends entirely on the team, who can take the project to the moon or, on the contrary, make it a total failure.
But I’m convinced that a team will excel in its work with commitment and the desire to do well.
The snow globe
At the start of a relationship, everyone wants to impose their ideas.
In the end, it’s the customer who will have the last word, we know that, and frankly, it’s understandable.
But trying to swim against the current is not the best strategy.
In my twenty-year career, I’ve seen managers and teams caught out by customers and thrown out of doors.
I know this. You know it. The customer knows it. He’s the one with the power.
In my IT project, the customer has entrusted us with the maintenance of a mobile application. A lot of bug fixes are in store, along with a few upgrades.
Nothing too exciting for the development team, but the potential is there. The client’s main objective is to increase user review ratings.
We have our list of corrections to make. However, we know that we need to deploy tools to facilitate deliveries. We’ve identified future developments, but also points of friction in the process.
At this stage, it’s pointless to ask for a budget for tools and route changes.
But as mobile experts, we know what works on a project. With experience, we know the best practices and the pitfalls. But for the customer, it’s all a blur.
I like to say to myself, “Stop shaking the snow globe”. Because the more you shake the snow globe, the less clear you get.
Well, it’s the same here: you have to give it time for everyone to find their feet.
A little earlier, I talked about best practices in Mobile projects. Here are the ones we felt were essential for our project at the time:
- Deploy a CI/CD (Gitlab) to streamline the development process and facilitate frequent deliveries.
- Work on an IT test environment with datasets to ensure the quality of our work
- Create a map of critical user paths to identify user friction points.
- Maintain a certificate renewal schedule to anticipate security breaches
- Set up metrics to measure the results of our work
Ignoring these five points is like driving a car in fog after drinking a bottle of vodka.
Sometimes it passes.
The strategy to get the customer’s attention and send the project to the Moon
First action: do what’s expected of me
It’s silly to say, but I did what was expected of me (and so did the developers). In other words, we’ve fixed the bugs.
We have a priority list to respect, with a budget. We stuck to it, and to be totally transparent I kept a tracking chart:
- Anomaly #1 estimated at 2h, completed in 1h30
- Anomaly #2 estimated at 4h, completed in 6h + explanation of overrun
At the end of the sprint (3 weeks of work), I draw up the accounts and send them to the customer.
I kept this log for at least six months. The project lasted over a year. I assure you, it’s no fun keeping the books, but it’s so necessary.
In fact, it was thanks to the transparency of our figures that we won the customer’s trust.
Second action: suggest areas for improvement and explain the benefits
Customers aren’t stupid. They don’t want to spend money, but they don’t want to lose it unnecessarily.
We have our list of requirements for the project (see above). My job is to explain to the customer the benefits and how much it costs. With the developers, we take examples of other projects that benefit from these best practices. This has the advantage of being factual.
The customer accepts the first point. We measure the benefits.
Gradually, the team gains legitimacy in the eyes of the customer.
And little by little, trust is created.
The customer financed the implementation of most of our requests. For others, we negotiated.
The results are there for all to see: the application is now more secure and robust, and the project is gaining in velocity.
Third action: honesty
Nobody wants to be kept in the dark. Especially when it’s their money.
Personally, I’d rather be told I’m doing something wrong than be encouraged to do anything at all. I imagine you wouldn’t either. The customer is the same.
So when a change doesn’t make sense, we talk about it. When we go over budget, we explain why.
Looking back, I realize that we talked a lot on this project. I think that’s one of the keys to its success: communicating with the customer.
It’s a silly thing to say, but the more you communicate, the more you learn and the easier it is.
Fourth action: measure your success
The proof is in the numbers.
All data is recorded. I have a whole list of indicators that allow me to justify the validity of our actions.
It’s because I’m convinced of the quality of our work that I note down everything:
- time spent per anomaly
- time spent per evolution
- non-crash rate by OS → 99,7%
- user satisfaction by OS → 4 stars or +
Thanks to this, there’s a before and an after.
By measuring these indicators, not only does the customer see for himself the results of our work, but it also enables the team to improve.
To sum up my actions
I’m going back three years. I’m working as a Product Owner in a mobile application development company. I’m just starting out in the business, and I’m really keen to do my job well, without breaking with my values.
How can I get involved without betraying the customer, the team and myself?
Trust is earned over time, and we’ve been able to gain the customer’s attention and attentiveness through simple actions. This is what I describe in the article.
It’s not a miracle recipe, but simply common sense and a great deal of rigor.
The team was really committed to this project. In fact, it was no longer the customer’s application, but our application. Our pride and joy.
The team expanded to include a designer, and the customer took part in our rituals.
It was the best experience we’ve ever had on a mobile project.
The result was beyond our expectations, because not only did we exceed the customer’s objective, but we all became friends, including the customer.
If you like my content, you can :
- subscribe to my profile
- subscribe to receive new articles by e-mail
- join the first subscribers to my newsletter
- follow me on Linkedin
More articles on Mobile projects?
