Telling manager project isn't worth the effort?

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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."

Answer 7

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.