How do you guys handle projects?

Posted by Power_Stone@reddit | sysadmin | View on Reddit | 29 comments

Gonna be real here. I started out at my current employer as a desktop technician doing the hands on work. Changing out mice/keyboards/monitors while also reinstalliing end point software, etc. I have since transitioned to a true SysAdmin/Infrastructure role but I keep running into a problem... How do you guys judge what a "timely" manner is for a project? Or is that just made up management speak and when the task is done its done and you don't really worry about it? For context: I am currently working on setting up a new VM for our Solarwinds. We are not reusing the old DB so I'm building EVERYTHING new. Alert triggers, email alerts, adding back in all of the nodes for monitoring...custom property values...everything. So I am now thinking, what is a \*reasonable\* pace/timeline? I'm trying to change my pace/habits to be a bit healthier than what I do now as I try to better manage myself, my workflows, my jobs duties, and the like.

Reply to Post

29 Comments

[-]

uptimefordays@reddit

We track projects in Jira like everyone else!

[-]

pdp10@reddit

Your management and leadership are supposed to be setting and communicating expectations. That said, it's very common for people to be in roles they're not very good at, because they're poor at managing expectations for their direct reports. First, go direct: ask what the expectation is for wall-clock completion time and/or amount of hours of effort, given that both of you know your current tasking and priority list. (Needless to say, you've already established that you both know your current tasking and priority list.)

[-]

Power_Stone@reddit (OP)

Yeup, I feel like my current situation is a lack of experience and forethought. I have never been good with time management and I haven't really ever been taught time management nor have I had a need to really learn it up until this point. I have a touchbase meeting with my manager in a couple days so I will definitely be bringing this up in that meeting

[-]

EconomistFar666@reddit

For something like what you described, no one expects a hard date from the start because you’re building from scratch. What is expected is breaking it down and showing progress: what’s done, what’s next, what might block you. A reasonable pace usually looks like: define the main pieces, chunk them into smaller steps and give rough estimates. Then adjust as you go instead of trying to be perfect upfront. What helped me was having everything visible in one place (tasks, dependencies, progress). We use Teamhood for that, mainly so it’s clear what’s moving and what’s stuck without overplanning everything.

[-]

hologrammetry@reddit

I just make shit up. It’s been working for 25 years now.

[-]

electricpollution@reddit

Here here 👆

[-]

heubergen1@reddit

I have a PM for that :) We work with Jira so we break down an Epic (the project) into multiple tickets all with a complete summary, description, testing requirements etc. Then the team estimates them. Now you just have to know the teams velocity and can then estimate how long it will take.

[-]

ErrorID10T@reddit

What takes me a couple hours might take you a week, and what takes you a couple hours might take me a week. You figure out a reasonable time to do the project then double it. "Reasonable" depends on your team's skills and available time. The single most important thing is to budget extra time and make sure you deliver on time. How fast you perform is usually less important than how often you meet expectations.

[-]

Prudent_Cod_1494@reddit

If it’s a project you scope it, make a rough estimate of what it would take to do it, determine priority, then start looking at it against your schedule and give an estimate on a target go live. If they say that’s too long, show them your other projects and ask them which of them they’d like you to deprioritize so you can do this one faster.

[-]

Ok-Double-7982@reddit

"I have since transitioned to a true SysAdmin/Infrastructure role but I keep running into a problem" Ummm, y'all use Solarwinds? A true SA would not be using SolarWinds since 2019.

[-]

TerrificVixen5693@reddit

I wing it.

[-]

iama_bad_person@reddit

Yip. I give a rough timeline, then tell them this timeline will slip every time I am given another task to do and I can't just "quickly" troubleshoot some other issue and have it not affect what I am doing.

[-]

iamLisppy@reddit

True.

[-]

david_edmeades@reddit

Experience, some minor padding to my mental estimate, and open communication channels to your team and the users. Sometimes you've just never done this before and you have unknown unknowns that blow your timeline up and you need to be able to give a progress report that explains why it's not done yet, but you've identified the problems and have solutions in mind. My biggest one was buying a big enterprise storage system. I had no idea what I was in for and I thought I'd have it locked down in 4-6 weeks. It took a _year_ to navigate all of the sales pitches, get quotes, get the funding done on my side, and finally get it delivered and integrated. Luckily nothing was riding on my initial estimate, but it was quite the learning experience.

[-]

Master-IT-All@reddit

For projects I do: 1. Find out when it is required 2. Build out a work breakdown summary where I list all the tasks I believe are involved, how much time each task takes, and then sum it all up to get a rough estimate of work time in hours. So DB deployment 20 hours, Solarwinds install 20 hours, add nodes 20 hours, new triggers 20 hours, total 80 hours... 3. For rough outlining double the amount of hours needed to allow for issues/unforeseen 4. Convert the number of hours to days 5. Determine the number/precentage of hours per day I will spend on the project 6. Subtract the days from the when it is required to determine when I'll start NEVER START NOW!!! That's a good rule, never jump from thinking to planning to doing in one go. So in your situation I would find out when the business needed this done. So say they want it done by May 29, 2026. Building out a new Solarwinds environment, lets say we do budget 80 hours for this work, and we'll have only 4 hours per day out of the 8 hour day to work on it. So I would kick off the project on May 1, and begin work on May 4.

[-]

Power_Stone@reddit (OP)

I'm starting to think this is somewhat of a two-fold problem between my manager and I. She is great, hands off, doesn't really bother me, but I'm realizing now that aside from certain things like trainings there isn't always a hard "we need done by this date" tied to a lot of the project work. Granted...I can kinda take care of that myself by just guessing an expected deadline and working to meet it... either way you all have given me some direction on this

[-]

benuntu@reddit

I approach this with the "under-promise and over-deliver" mentality. If I think it's going to take 1 business day, I multiply that by 2 or 3 depending on what unknowns there may be. I let other managers or execs run this estimate up the chain if they feel like their project deserves elevation in priority over others.

[-]

LeadershipSweet8883@reddit

The project should have a project charter that explains why the project is being done, what the goals are, the expected benefits and what the definition of done is. If you don't have one, just create a basic unofficial one and get feedback from your manager at least. Then you have a project plan. Break down what needs to be done into the major components. Yours might have initial environment setup, recreating templates, adding nodes back, configuring alerts, go-live, troubleshooting go-live issues, retiring the old environment. You might choose to do it one application at a time even, starting with your more important systems. Just break it down into chunks that you can actually estimate and then give each one a number of work hours. Now this part is important - double it. There's no way you estimated that correctly and there will be unexpected issues and wait times. That will give you an approximate timeline. The priority of this project and how much you are supposed to be working on it should be set by your manager. For simplicity, I just ask my manager for a percentage allocation towards it... 10%, 20%, etc. Then I work on it around that many hours per week. With the both above, you should be able to estimate when you will finish. If your boss wants it done sooner then they will have to allocate you a higher percentage towards it. It's also important to note that all of this is a work in progress. You will get a better idea of how long the major components will take as you work and then you should go back and adjust the estimates and timelines accordingly. Don't overcomplicate it or use a planning tool. Just break it down, estimate and start work. The whole thing should take you an afternoon.

[-]

SirLoremIpsum@reddit

> How do you guys judge what a "timely" manner is for a project? > So I am now thinking, what is a *reasonable* pace/timeline? How longs a piece of string? You've given no context. No one would ever give you an answer "a project should take sox weeks". A project should be estimated and budgeted for and planned based on the size / scope / complexity, the available resources and what else is going on. What's reasonable is up to you. All I can say is you need to start planning this and not just winging it.

[-]

Greed_Sucks@reddit

Don’t wing it. Use a project manager application and set milestones, tasks, etc. even if you don’t use it completely getting it mapped out is useful.

[-]

Recent_Perspective53@reddit

Honestly, that's a personal idea, you know what's important. Started a month ago, been working on fixing backups. Done fixed. SD card on our old hp server dies, ordering new ssd will configure in raid1. Waiting Oh this past weekend, SAN locked up and didn't delete snapshots from years ago. Fixed. Friday we were closed, I took my son to the er and answered the call from my boss 3 times before we finished up and I was able to drive in. Oh the nic on the 1 host server, the one that everything lives on, that connection to that san dropped. All the vms crashed, site was down. After massage, called wife said going to work, fixed it. Need new hosts, new switches, more drives in the san. You know what I know I need to prioritize? The one vm, running our important sever, on an os that hasn't been supported in over 10 years! Pick you apple of the cart, which ever one you want, buy it, eat it, throw what's left away, buy another apple! That's only about 8% of what I need to fix, also 8% an arbitrary number I pulled out of the air.

[-]

UCFCO2001@reddit

With experience you'll be able to guestimate more accurately on projects (whatever you think you'll take always add 10-25% more). I wouldnt say I'm perfect, but I'm usually pretty close to what I think a project will take. Until you have that experience though, try and either ask coworkers for what they think or just wing it and give your best guess (still always over what you think). Sometimes though, do to things out of your control (scope creep) your timeline goes to hell fairly quickly. You just have to roll with it.

[-]

poizone68@reddit

In addition to the other comments, what can be of help is also to think about task separation. For example, setting up a notification system is a project task, but making sure John or David or Emily gets specific alerts etc would be more "Business As Usual" tasks that can take place after the project part is done. Same with nodes. Creating the structure for how the nodes are organised is a project task, as well as a procedure for adding in new nodes. Import the most critical nodes as part of the project, then additional nodes to be done could be a BAU task. Same with authentication and role based access. Think of the levels of access a group of people would need and how they would authenticate. Those are project tasks. Making sure John or David or Emily has specific rights is part of BAU. By doing this consistently you cut down on a lot of the chatter that lead to projects taking longer than they should, and you have a "minimum viable product" that you can show to management and the team. It also leads to easier estimation of tasks for future projects.

[-]

phoenix823@reddit

There usually isn't a good definition for "timely" unless you also have a good answer to "why?" So in your example, why are you completely reimplementing Solarwinds? Why not reuse the old DB? As an outsider looking in, I don't know why you'd want to do that, I don't know what's driving it, so I don't know or care when it's done. Contrast that with moving off a platform that's going end of life, patching a zero-day, automating employee onboarding to reduce manual effort, etc. where there's a good answer. Timely has a meaning in those cases.

[-]

Power_Stone@reddit (OP)

The reason we aren't using the old DB is mostly because it wasn't originally setup right and its showing issues when compared to the performance of what a properly setup DB has, not to mention just the installation old machine doesn't work as expected. In concerns to \*timely\* projects, I could better insight to that by specifying something like, finding all of the nodes that need to be moved off of EOL Operating system, spinning up the new machines, and working with the teams to migrate necessary files over.

[-]

ScannerBrightly@reddit

Quick rundown on the difference between Goals, Projects, and Tasks. Goals: Goals are ephemeral, and often are about the state of things as compared to a real object. For example, "Have a clean Garage" is a goal. But Projects often feel the same way. "Clean the Garage" is a project you need to accomplish to get to your goal of having a clean space to work in, store things, and park your car. But that's not a task you can just start working on. If you have a giant list of things you need to get done and one of them is 'Clean the Garage', you skip right over it because there is nothing to DO in that task. It's a project, not a task. So you need to create tasks to accomplish that project. "Take all the boxes of winter clothing on the floor and put them in the rafters" is a task. "Open the boxes full of books and sort them into 'throw away' and 'sell at the used bookstore' piles" is a task. If you are looking down your giant 'to-do' list and you see 'move two boxes to the rafters', that's something you can get done in like 10 minutes, before you have to go pick up your kid from baseball practice. And boom, you are moving on to getting your goals done! IT Related fun: Put that shit in Microsoft Planner and share it with the team, and your manager, so you can all see where you are in each step.

[-]

Power_Stone@reddit (OP)

Thanks, I think this is what I needed. I just find it easy to get overwhelmed with the overall "Goal" that I forget I just need to piece out the work and take it step by step

[-]

MrExCEO@reddit

Depending on how many endpoints this can be 4 to 8 weeks easy

[-]

caponewgp420@reddit

It’s hard to say without knowing the workload. I just try to keep working on anything work related while on the clock. Projects or tickets. Obviously everyone has bad days when the work might not be so efficient.