loading...
Cover image for Dealing with non-educated Clients / Project Managers.

Dealing with non-educated Clients / Project Managers.

boianivanov profile image Boian Ivanov ・3 min read

I presume at some point, each one of you have had to deal with clients that did not know what they wanted from their project or project managers that want to help both sides, but end up making the whole part of developing a simple website and communicate that to the client, a tedious process.

So how come I decide to write this post ?

Well, I have to give a bit of a backstory first. I'm currently working in a not that big web development company. My day job is being a Full-Stack web developer (mainly PHP and JS). For more than 6 months now I've been in the same company, having the same project. Things are currently at almost the end point of the project. Client previewing environments are set up, all of their initial designs were completed and to my knowledge the project is at its end.

Were's the issue then ?

Well, glad you asked. You know how many companies are proud to use words like "AGILE", "SCRUM", "KANBAN", etc ? Well ours does not use those. Instead we have other nice words like "spreadsheet" or "word document" or "bug reporting spreadsheet" and so on. You see, until the last step of the project that we're developing for our client, everything went good (not great, but good). But when we began having to get "bugs" or "issues" reported back to us, there began my worst nightmare.

You see, it's difficult enough to have to deal with issues in a project that you're personally involved in and have done so much for it, but it's a completely different thing to have bogus issues reported to you in a 500+ rows of a mess called a spreadsheet. I really hope that none of you have to deal with that bad of an issue handling system.

Let me explain the current system.

So releases are done every two weeks. The client sees the changelog sent by us, checks if the things that we have been reported as done/fixed are working correctly, if not they write a row in the infamous spreadsheet, explaining the issue, after that they add some broken images to a word document for additional info hopping for us to understand their request and correct the issue.

After that we go through the spreadsheet, check the issues, explain to them why this is not an issue and why it's having that behaviour in the first place, set a "status" in a cell at the end of the row and hope for the best. If there is an issue to fix, it's mostly a cosmetic one, somewhere, somehow, bootstrap's boxes did not appeal to their pixel measurements and the 2px difference to the left/right is a site wide, breaking issue.

Why are you complaining, there are thousands of companies like that ?

True, true. I'm not saying that this behaviour is only in my office and that company alone. But this has to stop. We have the tools in our hands. There's Github, Jira and tons of others. Interestingly enough the company uses Jira for other projects, but because of the knowledge gap between project managers and developers, some projects can be like this one.

So if there is something that I want you to leave with is, please for the love of god, don't use the office packages that people used in the 90s to count the income of the office and upgrade the way you tackle bugs/issues between the developers and your clients.

I want to hear your thoughts on the matter. What do you use in your daily jobs? How would you tackle issues like that if you had to? And how would you explain to your project managers that they & the client loses money using tools like those ?

Thank you for your time.

Posted on May 23 '18 by:

boianivanov profile

Boian Ivanov

@boianivanov

Senior Full-Stack Developer with client-side and server-side technologies, mainly PHP and JavaScript. In love with structured code.

Discussion

markdown guide
 

You may want to convert your users to tools to create GIF, the explanation will be quicker. I use Peek on Linux, you may want to use ScreenToGif on Windows (No idea for Mac)
What You See Is What You Debug aka WYSIWYD. Text or screenshot are not always enough (whether bugs are in spreadsheets or in tracker issues)

 

It's not clear to me whether the frustration is with the tool or the things being reported in the tool.

Eg you could report a 2px difference in a bug tracking system, also. The issue with that one seems like a print-world perspective, which wouldn't be mitigated by better tooling (I'll assume you're correct and it isn't a reasonable expectation on the web).

If the issue is the tools themselves, then I don't think the article makes it clear why the tools are failing. Perhaps the spreadsheet makes it difficult to identify duplication and thus the same issue shows up on 20 different rows. Perhaps the lack of support for first-class conversations around the issue leads to discussions through other channels which are then not reflected in the spreadsheet / word document. Perhaps multiple versions of the documents are floating around, making it difficult to know which is the most recent (or worse, multiple divergent copies), or perhaps everyone edits the word document with different conventions making it difficult to keep track of who said what and what the state of the document was at the time they said it. But if any of these are the frustration, the article doesn't make that clear.

 

First of all, thank you or your response. To address some of your points, yes, maybe some of my points were not fully clear. I have to say that while writing this article I was frustrated at the system , at the project manager and at the clients, so that could have added to the "unclear" nature of the article.
My frustrations were actually with everything addressed, but mostly the issue was the project manager. He, not knowing how to use any of the tools for the job, opted to begin bug reporting using spreadsheets and I'm generally blaming him. Maybe the clients contributed to the whole mess, being a big company and having a lot of people writing on one spreadsheet, not knowing their colleagues' opinions.
Other than that I'm all for you, the issues that you added, are real life issues that I have had with this project. Multiple versions of a file, same issue reported on multiple places, issues like "Blue links are too blue" have been real "issues" that we had.
Sorry if you thought that this article was just a kid complaining, but those are the issues that people in tech companies have on daily bases and it's good for them to be addressed.

 

Oh, I wasn't trying to put it down or anything.

My point was that the example of being 2 pixels off didn't sound like a problem with spreadsheets. Probably I was curious what the issues with the spreadsheet were, b/c I wouldn't have automatically assumed it would be a problem. Eg if someone said "lets use a spreadsheet", I'd probably say "okay, sure", until I hit some issue with it. So I was curious what issues you were hitting, figured it would sharpen my sense of what to require in a tool.

Regarding things like "blue links are too blue", I think I'd be okay with that, presuming you have some way to sit down with them and tweak the hex until you arrive at the desired blueness. Maybe the PM gets in the way there, IDK, but I wouldn't expect someone to know that precisely what they want, so some ability to figure it out with them is important.

Ok, so my core issue is the tools selection for the job. A spreadsheet is really difficult to manage, especially without correct setup. Having 5 people add to a spreadsheet, without each one of them reading previous issues and marking issues as complete, or marking a complete issue as an incomplete one by the clients, is a mess doing it in a spreadsheet that doesn't have any way of managing it.
If at some points columns, filters and so forth are added, it maybe could get a tiny bit better, but it's still miles away from current ways of doing with that kind of issue management.
I can say, to a good extend, that I have lost more than half a month just answering to issues that are either non-existent or already fixed, but because they were reported many times and/or the client doesn't really understand were/how they were solved they're either still "open" issues or reported again. That's a lot of development time lost in answering and explanations to client questions.

 

I know what you feel, bro. The same in my company, and worse: my team has members don't have a software development background, and the stakeholders, don't know well how to use software (there're tales about some users didn't know how to use a mouse).

Although, I try everyday to convince to use Trello for the team but only we the developers, use it. The other members use drafts papers to annotate everything.

The "QA" team use word for recording the test results haha..

How I deal with that? Before coding, I try to imagine all the exceptions for malintentioned user behaving and then when I do coding in a way to reduce the failed tests and also do integration tests manually (that belongs to QA): I do more work that I should.

If my english is not very bad, you can notice that I have not solved that, just do my best effort and learning from that every day. I propose every month new point of view, frameworks, posts, etc. but the real solution is to leave the company.

 

Take a break, go drink some pinacolada and soak some Sun. Everything else is normal. That is how the world works.

 

Yes, true, but why should it? We have the power to change it.
If we continue having that way of thinking, nothing will change. So shouldn't we push for change ?