24

My manager has passed-off a project to me from one of our former co-worker who left the company. Some of our team members are spending 20+ hours a week on creating reports and accessing databases and I've expressed that it should only take 3-4 hours a week to do that portion of the project. We've already created programs, Macros, etc..that has cut down the process significantly.

Manager has already got developers, programmers, and our software engineering team involved. My manager basically wants to automate the process and make it so we have a superuser that runs database reports in the back-end and upload those to a secure server to be accessed by our team.

The more I dig, the more complex it gets as I have to get multiple people, including our SQL team, to try and figure out the functionality of our back-end system and if it allows host logins and having it upload from within a virtual machine to one of our local drives. Also, my job is far from a technical role.

I feel our process can be heavily improved and made more efficient. What's the best approach to communicate this without basically saying it's not worth the effort?

  • 36
    It's a bit unclear what you are advocating for here: you say the process could be more efficient, but you also seem to be arguing that it is not worth the effort: could you edit this to clarify if you are trying to argue that the goal itself should be abandoned (and if so in favor of doing the reports manually, or simply not having any), or if you are trying to argue that there is a better way to achieve the goal or at least something of comparable utility? – Chris Stratton Jul 29 at 19:39
  • 12
    Probably in the same vein as @ChrisStratton comment, but I think your title contradicts your question: telling your boss "I feel our process can be heavily improved and made more efficient" is practically the opposite of telling your boss "the project isn't worth the effort". I see that you mentioned your job is not a technical role, so maybe what you mean is that this project isn't worth your effort and they should give it to someone else? That's perfectly understandable, and also totally different than both prior statements. – walen Jul 30 at 6:47
  • 6
    Don't give your manager a problem, give him an alternative. – Mast Jul 30 at 6:54
  • @Mast is right. Rule number 1: Never go to a manager with just a problem. You need to have plan(s) for solving things ready to go. Or even better, solve it in your spare time/extra time. – HenryM Jul 30 at 12:36
  • 1
    @HenryM That's horrible advice. You aren't always smart enough, qualified enough, have the time, have the resources, or have the right skill set to solve every problem even though you can see one. Rules like this are stupid games and ass kissing, and the funny part is they don't even work. In any sane workplace, someone who recognizes a problem that can be solved is applauded for getting the ball rolling. This rule is a benefit to such a small percentage of issues that repeating it is toxic and harmful. – Gabe Sechan Jul 30 at 19:23
54

There is no way to say its not worth the effort, without implying its not worth the effort. Automation is basically trading a significant upfront cost for a low long term cost and Report generation is something that is often very standardized and doesn't need to change much.

You can do the basic maths yourself to see if its worth it. If each report takes you 15 minutes to generate. And it would take you an estimated 400 hours to implement the system, you would need to generate 1600 reports to break even in terms of hours spent. Find out how many reports you generate per year then determine how many years it would take to get those man hours back.

Alternatively, you could recommend a different tool that will link with your SQL database and help generate the reports for you automatically. However the key aspect of implementing any new technology (in house or purchased) is making sure you have the correct expertise to implement it.

  • 4
    If each report takes 3 "man" hours to generate. It would only take around 200 reports to break even (even less than that but I like whole round numbers). If each report currently is actually taking 20 hours to complete each report. Then a automated projected that only took 480 hours (3 months) to complete would be a deal. "man hours" is just the name of the concept which describes how long it takes a team to complete a project. – Donald Jul 29 at 3:23
  • 8
    And it also depends on who has to expend the hours. If 1000 developer hours can save 300 management hours, depending on pay and availability of personell it could still be a net profit / desirable for the company. – Falco Jul 29 at 9:49
  • 45
    xkcd.com/1205 obligatory! – Silviu Burcea Jul 29 at 10:21
  • 49
    bear in mind that automation doesn't isn't necessarily just about time saved it may also be about increasing the consistency of the reporting – jk. Jul 29 at 13:02
  • 17
    @jk.: Which also regularly increases correctness, and therefore the confidence in the result. – Matthieu M. Jul 29 at 13:23
17

It's your job to communicate this to your manager, so do so. Just tell them.

Part of their role is to determine what constitutes "worth it". They can only make decisions based upon the information they have.

It's your job to ensure that should new information come to light, they have access to that information so they can make the best decision.

If you give them that information, and they make a decision, you should follow that decision.

For more information, see Curt's Answer

8

It sounds to me like you are not enjoying the task because it has turned out to be more complicated than you thought.

Not only does automating this task free up one of your team members for 20 hours per week which is like gaining half a person on the headcount but it would mean that the reports are available for the business much sooner than now.

Make sure that you understand the bigger picture and you are certain that the time saved in your team and expediting the reports for the rest of the business is not worth the effort expended before telling your manager you don't think this is worth doing.

  • I wasn't the downvoter, but for most business reports, the most cost effective thing a business could do is not create them at all. That also saves time at the next management level reading them and collating the contents into a higher level of useless report. The very few things that really matter should be monitored in real time, not by periodic reports. – alephzero Jul 29 at 12:03
  • 1
    @alephzero Thanks, but the OP doesn't say what the reports are for. I was just wondering specifically why someone downvoted my answer so would prefer the person who did it to give thier reason so I can improve it. Thanks. – Old Nick Jul 29 at 13:28
  • @OldNick I didn't downvote, but one thing to point out (if I read the OP correctly) is that he is saying that via some simple scripting / macros etc, the current 20 hours a week can easily be cut down to 3-4 hours a week. So most of that "half-person" can be easily gained. What the OP objects to is then doing a complex project to automate everything and get the remaining 3-4 hours / week. – DaveG Jul 29 at 16:38
  • As I stated, the issue is efficiency – Noah Jul 29 at 16:57
  • I should've specified and I apologize, these reports are provided directly to our clients, not managers. – Noah Jul 29 at 16:58
6

Provide numbers, and be prepared to back them up.

You're currently spending X hours to generate reports per week. Automating that task not only means you're not spending X hours to generate reports, you can now spend those hours doing productive work instead.

This means you can produce more actual product than you can when your reports are automatically generated.

Now say it takes Y hours to automate the report generation. And your project will be running for Z weeks.

Even if X*Z is larger than Y, it might still be worth automating because you're freeing man hours to do more productive work.

Plus reporting is hardly anyone's favourite task, so you're improving the quality of life and the job satisfaction of your team, which is a good thing as well.

  • 5
    Another benefit of automation is that it removes the mistakes that would inevitably occur during hours of boring manual work. – Robin Bennett Jul 29 at 12:43
2

Sounds like it's not so much an issue of automating the reports, so much, as it is a question of feature creep...

Everybody, including you and your manager thinks that report automation is a great idea and everybody seems eager to help it along ..e.g. making macros, etc.

Now, the manager is adding a 'feature creep ' to the process -- insisting on a supervisor process that needs to do things outside 'normal' processes and is considerably more technical than you thought it would be.

I'm sure it's probably doable (maybe...and depends on if a VM can write to a local disk or if you'd need like ftp or something else) and worthwhile, but, you might want to go back to your manager and say, "All this is great, but, what you want is considerably technical and requires more expertise than I currently have....while, I'm not saying I don't want to be involved with this -- it's going to require more man-hours and I'll need a bit more help on the technical side to implement what you would want..."

Make it such that it's not that you don't want to contribute, but, that this new feature is a bit tricky and you're worried that you're lack of the technical background might slow things down. Or at least let them know, it's not a simple as it sounds on paper.

Let your manager figure it out...is it worth the time.

2

Whether it's "worth it" is a business decision that may involve more than just the number of person-hours spent and saved.

Obviously you want to look how many hours you're going to spend developing the system versus how many hours it saves per week to get an idea of how long it will take to pay for itself in that narrow sense. But there are plenty of other things for which it's not as easy to assign a value (especially a specific number) that may be considered benefits from a project.

For example, it may be surfacing (more clearly exposing) problems within parts of your system or organization that are affecting other projects as well, or would affect future projects. These could be that there's no good mechanism for handling authentication of automated tools to the DBMS, there's no place to store temporary or semi-permanent data that offers appropriate sharing between various systems, details (or even existence) of the "band-aids" in the "band-aid systems" you describe, or even just that certain people are designing or running their systems in a way that makes automation harder.

Another goal might be to gain experience with particular technologies that are going to be or are being considered for use in future projects. This may let you later do more accurate estimation in a project where accurate estimation is important (such as for an external client) while learning in an environment where missed "deadlines" are not such a big deal. Or it might lead you to use different technologies for a future project because you've found out that the technologies you tried don't work as well as you had hoped.

What you should do is avoid telling your manager whether the project is "worth it" or not, and simply put together the data you have now and present it to him. If you're running into problems, explain the problems and how that will affect the schedule, or how you are finding it difficult to tell how that will affect the schedule. (The description of those problems may be exactly what he's looking for from the project!) Of course, if you had previously given him estimates of how much time would be saved and when the project would start paying itself off, you should give him whatever refined estimates you have for that as well.

You can also propose any changes, such as reducing project scope, that you feel might make the project more "worth it." But keep in mind, you don't necessarily know everything about what's making the project "worth it."

  • Thank you Curt. This is by far the best answer here. – Gregory Currie Jul 30 at 3:13
1

Make your base assumption in cases like this that there's probably something you don't know. Phrase your observation as a question instead, and not "why is this not stupid?" but "could you help me understand the priority?"

First, there might be factors you aren't aware of that make the project make a huge amount of sense. In this case, saying it doesn't make sense at all could make your boss doubt your judgement, especially if they don't realize you don't know something that explains everything.

Second, oftentimes while someone's trying to explain something they trip across a logical error they hadn't noticed before. Letting them find the mistake is better for their ego and you're the coworker that helps them see things. Very useful!

Example: "hey Mr. Boss, I'm wondering if you have a couple minutes to help me understand the motivation for this project... when done it should save X man-hours a week, right? Do we have an estimate of how man-hours it's going to cost? Y? So, given X and Y, our brake-even... isn't it the year 2037? Of course it's valuable to have this but is there nothing more urgent?"

And the answer may be, "gosh you're right!" Or it may be: we have a project coming in 2020 where we need these staff; if we let them go now the redundancies will kill us then we'll have to hire replacements. So in effect the workers are free. Or it might be: sure but the components we develop now will be reused for the next six projects, where the real savings will be.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.