E-commerce Client Project Management
By Greg Hanson
March 12, 2020
Photo by You X Ventures on Unsplash
Moving from writing code to managing the show
Many times engineers/developers make the move from development to project management. It’s a natural move, we want the folks who know the nuts and bolts of e-commerce projects to eventually manage them.
So that’s all fine and dandy, but what if you haven’t been a “manager” before?
- How do you manage an e-commerce client?
- How do you manage an e-commerce project?
- How do you manage engineers/developers for an e-commerce project?
An answer for each of the above is always: “It depends.” Or maybe more familiarly for Perl developers: TIMTOWTDI.
The reason for that of course is that all of the above questions have variables that will change for every situation.
As a developer, you understand the large number of outcomes that can be introduced into an application by using a single variable. You also understand that the number of outcomes increases proportionally with the number of variables.
The same holds true for management. When you are faced with managing a project, your “variables” now move from placeholders in your code, to placeholders in your project. Where you may have assigned a variable for a “string”, “integer”, or “boolean”, you now may have a “client”, “project”, or “team of developers”.
The point here is that while variables will change from project to project, the “structure” of how you run that project can still remain consistent. Much like designing code to return consistent results while using a wide range of variables.
In order to achieve this type of consistency, the core operations that run within the project, need to be reliable. Over time you will come to develop processes in your projects that will be reliable, and that you will return to time after time, project after project. To get you started, here are a few that should be at the core any project management:
- Know your client.
- Learn the project.
- Know your developers.
These are 3 basic rules that should guide any project, and we will explore each in more detail below.
Now as you can see, each situation will vary widely. A good project manager will understand that any project is multifaceted, and consists largely of human resources.
Let me also note that while this topic is titled “E-commerce Client Project Management”, it could just as easily be titled “Client Project Management”. The principles of project management apply to many different environments.
So if you are new to project management, the first piece of advice I will give is to:
1. Know your client
Everything flows from the client. Always remember, the client is paying you to represent their best interest. This can sometimes mean that you will need to tell the client that you are not the best choice for a particular project!
“Wait…” you will ask, “why would I tell a client to use someone other than me to manage their project? And how would that benefit me? I am in business to manage projects after all!”
I would answer that question with another: How long to you want to be in business as a project manager? If the answer is anything other than “a long time”, you can stop reading now.
Let me give you a quick analogy. Let’s say you went to a car “lot A”, and told the salesman that you needed a very specific type of vehicle because you deliver a highly perishable product. Let’s also assume that this salesperson did not have that specific vehicle on his lot, but that he also knew of another “lot B” where the exact vehicle was sitting. What would you want that salesperson to do? Would you want him to just tell you that they could customize a vehicle on their lot to do most of what you need? Would you want him to refer you to the other dealership?
Or, would you like him to explain all options that he knew of that might apply to your situation? If you chose this last option, score extra points for your potential future as a project manager. To further reinforce this, remember, very few clients only need one project managed.
Ok, so we have established that you need to know your client. That sounds easy, or does it? How do you “know your client”? Let’s try to distill it down a bit. There are many ways of “knowing” someone. We can know their personality, their family, their business, their religion, politics… ok, enough already. But believe it or not, all of the aforementioned points will come into play with a long-term client. But we want to talk about the basics here. We will assume we have a first-time client, with a first-time (to us) project.
Find out about the clients’ business. How do they make money with this business? While you are talking to the client about this, ask questions that get the client to explain and promote their business to you. For most, this will be easy… sometimes to the point of having to learn how to politely stop them! But you will learn far more about their business, and their personal approach to that business by listening than you will by talking.
Just get them started, and let them roll. In the early meetings, ask questions about why and how the client feels their product/service is superior to others. Find out who in the company was responsible for various aspects of the product/service. Learn who the stakeholders are. Try not to ask too many technical questions until the project outline has been defined, and you personally have a good feel for what it is comprised of.
Clients are not free
Clients are a long-term (and ongoing) proposition. Take care of them and they will return again and again. Ignore them and they will respond in kind, and usually very quickly. The time you spend building client relationships is normally non-billable. So keep that in mind the next time a client is hard to deal with and you think “We don’t need clients like this, let’s just find a new one”. You will invest a lot of time and energy with a client. Try not to waste it.
2. Learn your project
If you have a good understanding of the client and their business, you next want them to explain to you what they are attempting to accomplish with this project. Let me clarify here: You do not want them to explain how they want to do a project. You want to first learn what the client wants to accomplish with the project.
This is important, and should be understood completely because if you blow this phase you can easily miss one of the major points of e-commerce project management. I have found that about 7 of 10 clients have major misconceptions about how things actually work in our business. They usually have a very good idea of what they want to have happen in the end, but not so much how to make that happen.
When I say understand completely, I am talking about the 3 of 10 that do know what they are talking about and need to be taken literally.
It will be up to you to determine what type of client you are dealing with. Use your past experiences with people to figure this out. It can be hard. You have to make sure you don’t insult someone’s intelligence, and at the same time you need to know on what level you should attempt to communicate with them. I have found it’s best to let the client talk, try to ask “steering” questions that can unearth what level of experience you are dealing with. These conversations will set the stage for the rest of the project. You will determine how much you will need to supply in the way of structure and advice for the project, as well as give you a clue as to what developers and resources you will use for the project.
Because this post is geared towards developers becoming project managers, I would tell you that this is a place to lean on your background. You should be able to listen to the client, ask the right technical questions, to get a good feel for how you will manage the project.
Once you have figured out how much of what type of role you will have to play in the project, you will need to either define the proposed scope of the project, or examine scope definition given to you by the client. There are many threads that can stem from this, but are not germane in this post, and we can move on to resourcing or how to manage your developers.
Depending on the project, you will most likely need to:
- Small project: Just do it once client approves.
- Small to medium-small project: Give a ballpark estimate of costs, usually un-billed.
- Medium project: Give a more detailed estimate, perhaps billing for estimating time.
- Medium to large project: Give a detailed estimate, billing for estimating time.
- Large to very large project: Give estimate of time for a formal quote. A quote is in essence a small project on its own.
Again, estimating a project is an art in itself, and is not part of this post.
Normally, in all of the above other than #1, you will need to confer with developers on your team to supply the client with an accurate estimate of costs. Of course, in order to be an efficient PM, you first need to:
3. Know your developers
This should be pretty self-explanatory, but obviously you are not going to put a front-end developer on a code-intensive back-end project.
Another obvious point is that we are talking about a situation in which you have the luxury of multiple developers to choose from. If that is not the case, then you will be faced with another task, that of serving as a “translator” between the client and the developer.
Given that statement, there are nuances that need to be considered when matching developers with clients, or how to control communications.
If the client is a larger company, try to get them to assign a champion for the project, someone who is preferably somewhat technical, has authority to make some level of changes and decisions, and who is appointed by a high-ranking person in the company. This person should be the contact point, representing the client for all daily project decisions and questions. In larger projects, this person may oversee a team from the client, that will interface with your team of developers. Without this person, you should warn the client that undue and excessive delays due to communications will occur.
If the client is a smaller company, try to get an owner or other heavily committed person to be your point of contact who will automatically escalate your questions so that you do not have to wait around for answers. You won’t want to wait for answers, and the owner will not want to pay for your time or lost calendar days to wait for answers either!
All this so far is great, if you are the point of communication for your company. In many cases it will prove to be best for this to happen. You can monitor all conversations, communications, and prevent misunderstandings and hopefully anticipate problems before they occur.
But if you need to have your developers talk directly to the client’s rep, you have some thinking to do. Certain traits do not mix well:
If your client is very opinionated about their project, try to work out directions and methods before allowing communication between developers and client. Use Trello, Slack, etc to assign specific tasks for specific people. Try to track progress of predefined tasks, and limit creation of undiscussed features. Stick to the program; this is not the place for “developer creativity”. This is where you really get tested, you have to know your developers so that you do not create resentment through restraint, but at the same time picky clients will not accept drawing outside the lines.
If your client is tech-savvy, easy to get along with, and you can convince your developers of that, direct interaction can be extremely productive. But don’t just assume this will work. Be on the the first phone calls or video conferences, be a fly on the wall, observe the dynamics. Don’t run the meeting; step in only if necessary.
Use your resources. If you have two front-end people, and you have friction between the client and one of them, introduce the other for a separate task. Observe, did it work out? Do I need to phase out one in favor of another?
If possible never “pull” a developer completely off a project, unless of course it’s requested/required. (Do the words “burning your bridges” sound familiar?)
Always talk to the developer in private about whatever the issue is, and always point out to developers that relationships do not depend on talent alone. What works for one client will not work for the next.
Make sure you know your developers. You need to stand up for them when talking to clients. If you are not comfortable with a developer, you need to either discuss it with a superior, or if you are the superior you need to let them go. You cannot lie to a client about your faith in a developer. Clients don’t want to hear you bad-mouth a developer in your own company — this simply makes you and the developer look bad. The client expects you to have faith in your developer, and to stand up for them.
With that said, back to rule #1, know your client. You have to know what that client will tolerate or expect. You may have to be firm with some clients, so that you can give them what is the best solution for their project.
Other clients may require a soft approach and may completely understand “how this stuff works”. When you get one of those, you will understand very quickly, and be very thankful.
Summary
Managing projects is a challenging proposition. But if you put things in perspective, you will find that it can be simplified and rewarding. Try to keep the big picture in mind as you proceed through the project. It’s easy to get drawn into the details of a project, and sometimes that is what is required. However, if you have good resources available to you, it is up to you to put the areas of responsibility into the proper hands. Coming from development, this will be a real temptation. However, you have a new title now, so put it to work!
Remember, you are not working on this project to create something for you, or your developers. You are creating something for your client. The project’s goals are largely dependent on your clients needs. I am not saying that you cannot create something that you or your developers like, quite the contrary. I am suggesting that by focusing on the needs of the client, and really listening to them, then sharing the expertise of you and your team with the client, you can arrive at something that will not only work extremely well for your client, but also provide you and your team with a great sense of accomplishment.
Comments