How do techs raise requests in your company?

Discussion in 'Business & Enterprise Computing' started by mickeylieu, Sep 16, 2021.

  1. mickeylieu

    mickeylieu Member

    Joined:
    Jan 7, 2002
    Messages:
    1,485
    Location:
    Sydney, NSW
    Hoping the OCAU brains trust can help me on this one since it is so hard to network these days.

    I work in a large organisation where we have distinct technology teams request services from end users and from one another. I'm particularly interested in hearing about the experiences of tech team to tech team. Example of "tech-to-tech" requests that end users would never see could be:
    • Requesting a DNS record change

    • Setting up a new AD group for a new application

    • Creating SCCM site boundaries
    These are all handled by separate IT teams due to segregation of duties.


    However, there isn't an unified way to raise requests for each of these teams - these could be through:
    • Fully-fledged ITSM ticketing system (eg Remedy/ServiceNow)

    • Simplified web interface that integrates into ITSM tooling

    • JIRA Service Desk

    • Email DLs/Teams channels

    • Direct Teams messages/phone calls/walk-ups

    • Help desk requests

    Attempts at fixing this include:
    • Making help desk triage all requests (drowned our help desk team in emails)

    • This was quickly followed by forcing all "tech folks" to raise an ITSM ticket and not contact help desk (which led to creating a "quick interface" for techies to raise/query tickets etc. without having to log in/fill in 50 fields

    • Having a single Confluence webpage to direct tech users but these quickly become outdated

    Obviously this creates a lot of confusion for new starters who have no idea how to raise requests and rely on others to help navigate the maze that is our IT.

    I would love to hear how other companies tackle this problem. Apart from giving tech people admin rights to everything, how does "wayfinding" work for your company where segregation of duties are required? Does it work effectively? How have your techies reacted?
     
  2. NSanity

    NSanity Member

    Joined:
    Mar 11, 2002
    Messages:
    18,393
    Location:
    Brisbane
    Sounds like your ITSM isn't working properly with adequate governance and appropriate sla's.

    You probably need a BA/EA to come in and have a deeper look into why that's failing.

    So to be clear, siloing is first and foremost about paying less for technical resources. Its only more recently that siloing has become about security i.e who watches the watchmen etc - which is 100% valid.

    Once an org gets to a certain size, to meet security auditing you're going to need silo'ing - but you can still have a single individual do this - just with the appropriate approvals/gates on JIT access that is only handed out when approved by an appropriate approval chain.

    You're never going to have the agility without deep automation of various tasks that you might of had in a SMB (say < 500 seats) where you just have that "one guy" who knows and does everything - but you also make a fuckload more revenue.
     
    Last edited: Sep 16, 2021
  3. Elmf

    Elmf Member

    Joined:
    Jan 6, 2007
    Messages:
    1,554
    Location:
    Melbourne
    My vote is what you've done. Raise requests to eachothers queue in ServiceNow. To combat confusion around raising requests, ensure you have an easy to use catalogue that's segregated per team and make sure each teams part of their catalogue includes a basic "ask us a question" ticket type, as it's not always "change dns of this" that's needed, but more general advice
     
  4. PabloEscobar

    PabloEscobar Member

    Joined:
    Jan 28, 2008
    Messages:
    14,621
    Tickets via whatever method you use.
    Quick tickets for commonly done things
    Automated (and audited) tickets where they make sense.
     
  5. QuakeDude

    QuakeDude ooooh weeee ooooh

    Joined:
    Aug 4, 2004
    Messages:
    8,612
    Location:
    Melbourne
    We do everything via ServiceNow rom New user requests right up to ordering equipment, or even business cards. Everyone looks after their own queue, and the outcome is users have a simple portal to use to request whatever they need. Its alot harder than it sounds - it requires the business to embrace the change.. and want to change.. but well worth it in the long run.
     
  6. chip

    chip Member

    Joined:
    Dec 24, 2001
    Messages:
    3,964
    Location:
    Pooraka Maccas drivethrough
    sounds like OP's org needs some ITIL
     
    andrewbt and Dilbery like this.
  7. NSanity

    NSanity Member

    Joined:
    Mar 11, 2002
    Messages:
    18,393
    Location:
    Brisbane
    hahahahaha
     
    Arctic_Silver08 likes this.
  8. PabloEscobar

    PabloEscobar Member

    Joined:
    Jan 28, 2008
    Messages:
    14,621
    ITIL, the cause, and solution to all IT Problems.
     
    MrSnuffy likes this.
  9. D.Frost

    D.Frost Member

    Joined:
    Nov 9, 2007
    Messages:
    559
    Yep we have a similar layout and we raise tickets.
     
  10. Arctic_Silver08

    Arctic_Silver08 Member

    Joined:
    Aug 11, 2012
    Messages:
    1,595
    Almost spat my food out haha, good one!!
     
  11. Renza

    Renza Member

    Joined:
    Dec 1, 2004
    Messages:
    4,938
    Location:
    Melbourne
    Managed in GitHub and deployed via a CI/CD pipeline after the appropriate approvals are obtained via codeowners. Makes it largely self-service.
     
    mickeylieu likes this.
  12. 7nothing

    7nothing Member

    Joined:
    Feb 15, 2002
    Messages:
    1,560
    Location:
    Brisbane
    Create RFC, wait 3 days for someone who doesn't understand RFC to approve it.
    Forward approved RFC to service desk.
    Wait X days where X seems to indicate service desk don't have to adhere to any form of SLA.
    Get notified service desk have closed request.
    Identify the 3 steps in simple instructions they failed to follow.
    Just fix it yourself, because you had the ability to do the work all along but have wasteful and time consuming processes to follow.
     
    mooboyj, caspian and Elmf like this.
  13. Elmf

    Elmf Member

    Joined:
    Jan 6, 2007
    Messages:
    1,554
    Location:
    Melbourne
    Not quite how i've seen it in many orgs (you'd raise a Service Request, not an RFC) but spot on otherwise :p Frustrating times for Enterprise IT :D
     
  14. OhFoRkMe

    OhFoRkMe Member

    Joined:
    Apr 27, 2005
    Messages:
    3,376
    Location:
    Joyner 4500
    Request tickets raised and triaged by Servicedesk to correct team.
    Everything is run through SNOW.
    Offshore teams then sit on ticket for a few weeks unless you start emailing managers and their managers.
     
  15. 7nothing

    7nothing Member

    Joined:
    Feb 15, 2002
    Messages:
    1,560
    Location:
    Brisbane
    You're probably not dealing with enough Telstra partner MSPs to experience true nirvana.

    Created a service request the other day "We have no concept of what form of checklist you may have for new server builds, but please add these 2 clearly defined steps which the business has endorsed"

    Week later: I've been advised you need to create an RFC for that.

    ok... I'll request a change to a process I've never seen. Can do.
     
  16. Elmf

    Elmf Member

    Joined:
    Jan 6, 2007
    Messages:
    1,554
    Location:
    Melbourne
    Standard lol
     
    SayitaintSo likes this.
  17. caspian

    caspian Member

    Joined:
    Mar 11, 2002
    Messages:
    11,993
    Location:
    Melbourne
    if it was my org I'd say you forgot:

    - being told to put in a front door request
    - after a week you might even be able to find out where to do that, because it's moved since last time for reasons
    - first two access requests are denied because "security"
    - waste about a week before finally getting access to the platform

    - be told by change management that you need to present it to CAB, because that way if anything goes wrong it's someone else's fault for approving it
    - jump through a bunch of useless hoops to satisfy vague and arbitrary requirements of the CAB process, including carrying steps that have absolutely zero use other than ticking boxes in the presentation
    - close date for next week's CAB was yesterday, so submit and wait another week for no reason other than change management power tripping
    - present at CAB and volley a bunch of irrelevant questions from people who have no idea what they are talking about, but feel the need to query something to justify their positions

    (BONUS POINTS: change management still haven't figured out I make deliberate and obvious errors in my CAB packs, because once they've found something to object to, they stop looking and ignore all the stuff that's genuinely wrong or missing)

    - try to schedule change request but be told that you can't do so for at least three weeks in the future by process
    - project manager freaks because his delivery timeline is on fire and requests executive CAB approve an expedited delivery timeframe
    - the cat herding process of trying to get all of the stakeholders together for an eCAB now takes place over about a week, because everyone's calendar is full for months in advance and nobody cares less about anyone else's project
    - eCAB shreds the proposal and says I can have half of what's needed over twice the timeline it needs to be done by

    - again try and raise change requests but because it's been deemed a "critical" change due to having to be approved by eCAB, the lead time is now four weeks, because reasons
    - placate the gibbering project manager and push implementation dates out four weeks into the future and submit
    - change management reject the changes because of some pettifogging new rule about how many disrupting changes can be made in a certain time period, and this change exceeds the maximum limit - despite nobody being able to show me a calendar of what's already planned so I can work to it
    - try again for five and six weeks into the future with the same response

    (insert obligatory Dilbert cartoon)

    [​IMG]


    - finally succeed at seven weeks into the future, report to project manager that the rollout now cannot be finished before end of year change embargo kicks in, so it will now commence in mid January, despite being supposed to have been finished in the last calendar year.


    as the project manager heads off to cast himself off the roof of the building, I dial into a meeting to explain why we are requesting additional headcount in next year's budget despite the number of projects we handle going down.

    the above is a fairly accurate representation of one of my recent projects.
     
    mickeylieu and stiben like this.
  18. EvilGenius

    EvilGenius Member

    Joined:
    Apr 26, 2005
    Messages:
    10,845
    Location:
    elsewhere
    [​IMG]
     
  19. phreeky82

    phreeky82 Member

    Joined:
    Dec 10, 2002
    Messages:
    9,764
    Location:
    Qld
    My word, you summarised my experiences well.

    Probably the only thing I'd add is that the PM gets flicked, exec call in a mate to run it and all get told to do exactly as he/she says, and all other tasks get pushed aside for it to get completed in record time.

    Prev proj team get tainted with never achieving anything so more governance gets added up front in PMO and with additional proj reporting.
     
    Elmf likes this.
  20. caspian

    caspian Member

    Joined:
    Mar 11, 2002
    Messages:
    11,993
    Location:
    Melbourne
    I've on my fifth PM for the project. seventh depending on how you count them, maybe more, if you count the same person being reassigned to it.

    PM1 started the project, then got pulled off to something else.
    PM2 ran it for nearly 12 months, then got pulled off to another project too.
    PM3 never actually got a handover from PM2 before PM3 got reallocated to another project.
    PM4 therefore walked in cold because PM2 left for good just as they started, and PM3 had virtually no knowledge of what was going on.

    after 6 months PM4 decided he'd had enough of the permanent crisis that seems to define project management, and decided either he got a new job or he went out the window himself. luckily he got a new job.

    so PM1 was again allocated to the project, but also won a new job before they even started, so it was again given to PM2. who had to be pulled off their project and that given to someone else.

    and now, with it actually running pretty well and just the final stages of phased delivery to accomplish, we now have PM5 for some reason, right when it would just been easier to let PM4 coast to the end. but no, we can't have that.

    of course, at every swap we've had to train the person to understand the project to at least function minimally effectively. why is it so hard for manglement to just make a decision and stick with it?
     

Share This Page

Advertisement: