Managing any remotely custom eCommerce project, let alone those on Magento, can pose quite a challenge to merchants. Enter Magento Solution Partners – those caring companies that make sure all the pieces of a puzzle that is a Magento website fit together.
So, how do we do that?
Here is a quick overview of some of the key building blocks of a successful eCommerce project and five tips from our experience on managing Magento projects effectively.
When a merchant is about to embark upon an adventure that is a new eCommerce project (using Magento, of course), they will have to work with a lineup of usual suspects.
More often than not, you won’t find all of these profiles within a single company. You can then imagine how a merchant who is thrown at this happy-but-often-not-very-aligned bunch of partners feels, right?
And even if these guys are all doing a great job on their own, who will actually take care of the project and the client’s business as a whole?
Well, this is exactly the role of a Magento Solution Partner company – we should be the ones establishing lasting partnerships with eCommerce merchants as that’s the best way to ensure both sides (and, by extension, Magento as well) are set for growth.
How do we go about that? Other than merely stating “we care”, how can we create an environment in which we prove it to the client, and ourselves, day in, day out?
Here are five quick tips from our experience.
(S)elect a project owner who is good at sharing
We all love to assign and delegate tasks, and some people are even very eager to take them on. But, do you have someone on the team who is more than a technical lead or a project manager, someone who really takes good care of both the project and the client, someone who will truly be a project owner? Ownership has often been a bit misused term, but it perfectly describes the state of mind in which you need to have at least one person on the team.
And you should make sure this person fits the desired profile. This is especially true for high-paced, multi-team project environments where your company will be held accountable for the end result – in that situation there’s nothing worse than a project owner not up to par with their role.
One thing often neglected when considering people for this particular role is their willingness and ability to share – see, I haven’t mentioned “communicate” or “delegate” here. By sharing I mean actively spreading useful information to people who need it, being on their toes at all times, sharing quick wins within the team and beyond – this all plays a huge part into project owner’s ability to spread the ownership spirit across the team.
Client isn’t always right… and neither are you!
Here’s a surprise tip, right? As obvious as it may be, this one is at times so difficult to recognize and act on it – can I have a show of hands how many of you have at some point during a project thought: “It would have been much easier if this project didn’t have a client attached to it”?
We’ve all done it, and at times – yes, our clients can have odd, strange, even flat out wrong suggestions or requests.
But we too have done so many mistakes that it would be a bit arrogant to think we know best – we might (and should) know better, or have more experience to anticipate certain outcomes more accurately, but it doesn’t give us the right to come off as patronizing.
The best way to see who’s right? A/B it! And why not make a small bet with your client about who’s going to be right? Ok, not everyone has this type of a relationship established, but we’ve done a similar thing with one of our clients. Luckily, we won.
We’re in this together, and we’re constantly learning. If one party is stubborn and unrelenting, then we have a whole new problem on our hands.
Be flexible while keeping focus
We all say we want an engaged, hands-on client as that helps us make faster progress and achieve more (and hopefully better) things together. But, what do you do when you have to manage new requests in the middle of the project because, well, a competitor just rolled out a new awesome feature that we’ll need to emulate and/or make even better?
Enter estimates vs fixed bids. Hopefully you’ve all by now learned that “fixed” and “eCommerce” can’t fit in a same sentence – ok, other than this one 🙂
But seriously, we all love a good challenge, and doing some custom features that will have positive effect on our client’s bottom line certainly is rewarding – it’s only a matter of trying to find that sweet spot between keeping everything on track and making sure we don’t allow ourselves (or the client) to stray off course too much.
Whenever possible, agree on two sets of features: must-haves vs nice-to-haves and leave all “the other ones” for after the initial launch – you’ll see that many will no longer be so nice-to-have later on as new requests will emerge and replace the old ones.
Don’t become slaves to a framework
You can quickly get entangled in agile vs waterfall, scrums, sprints, releases, milestones, checkpoints, what have you – and the discussions, as well as project progress, can suffer.
I guess we’ll always retell the story of a project when one of our teams was hired as some sort of a rescue unit working on-site as a part of a larger client-operated environment – this client had a certified scrum master on board.
The guy was so involved in the methodology that everyone had to have morning standups to talk about project progress and associated emotions of everyone involved. Now, call us robots if you will, but when a project is falling to pieces, it really is not the best time to talk about feelings.
Noone will miss one or two standup meetings, but everyone’s feelings will be hurt at the end of the day if a project fails. Whatever you do, don’t leave common sense at home.
If it doesn’t work – fix it!
Somebody call the nearest Chinese restaurant, ’cause we got all of the fortune cookies right here! It’s actually funny to see how we sometimes consider certain rules so obvious and understandable that we fail to apply them, almost as if we think they will somehow magically come to life on their own.
We can get so immersed in a custom feature development that we fail to see the forest for the trees – if you are too tangled up in a task (or a batch of them) and can’t see the light at the end of a tunnel, is it perhaps time to go back to the drawing board? Should you change the request or leave it for phase 2 if it significantly affects the scope and timelines? Powering through is ok, banging your head against a concrete wall – not so much.
We like to brag that we are in the problem-solving business more than anything else. So how do we go about solving problems we come across once we’re deep inside a project? Do we openly discuss the issues we come across with the client and help them understand the gist of it? And what happens if we fail to see eye to eye?
Your thoughts and pieces of wisdom?
So, what do you say? What are some of your own tips and tricks of handling Magento projects stemming from experience and mistakes you made? What works and what doesn’t for your teams?