Forums

We (IT team) had a great meeting with our CEO, who told us that in our jobs we were faced to

- one difficulty, which is time management, or how to focus on business priorities while ensuring the "daily stuff"

- one poison, which is the fact that some of our internal customers ask us for things which are not business priorities, without the approval of their boss . We try to do our best and treat their demand, but it is definitely not a priority for the top management (both business and IT)

As the manager of this IT team, i have things to coach them on about time management (thanks to manager tools !) but i am looking for a simple way to manage the "poison".

How would you do this ? I'm thinking of one first step which would be to track the time spent on business priorities versus daily stuff + poison. It may be a good start to measure things and take appropriate actions to "improve the ratio", measure again to see if things improve, and so on

I looked for information/advices on manager tools about the time tracking thing but surprinsigly, i found nothing.

Thanks a lot for your help

 

Tom Green's picture

You need a project tracking system.  Every request is a potential project.  If you view your team as an operational group, providing user defined services a la carte, your CEO will see you as poison delivery central.  If instead you view your team as project leaders, then each request is a potential project, and a project has a scope, timeline, deliverables, budget, payback ... in other words, a business case.  You should have a project request form, simple to fill out, that defines the business case for your work.  And unless you want to be seen as an obstacle, you shouldn't force users to fill the form out, the form is for your team to use when interviewing / collecting the business case from the users.  So where's the answer to your question (How would you manage the poison)?  The poison is a project that has no business case.  Throw out the project form if you can't complete it. 

You can take this to all kinds of additional levels.  Charge your costs back to the department of the user requestor (even a nominal portion of the cost, such as expenses), and get their supervisor's approval on the expense.  This will kill a lot of poison. 

Have your team turn in completed project forms with time spent at the end of the project.  You'll find out who's time is spent on projects and who's is spent on 'daily stuff.'  Keep an eye on the daily stuff people to make sure they aren't poison delivery people. 

Another caveat...  better to say no, or to say not now, later (with a date) than to accept a project form you won't work on.  Kills your credibility if you don't manage expectations. 

derosier's picture

 I remember listing to a cast w/ Mark and Mike where they were talking about how Mike turned around his department at MCI.  I wish I could recall which one it was or even if it was a MT or CT cast. I think the name had the word "support" in it.

One of the fundamental failings of IT departments is basically always telling people NO for just about any request. Or worse: go put that in a formal request document! IT departments are there for the support of an organization's goals and processes, they are not the business itself. Unfortunately, many IT departments act as if they're more important than the business itself and operate as jealous little fiefdoms.

By all means, go ahead and put up a wall in the form of a software system and forms to fill out between you and your customers. You'll quickly see the organization turn against you. Any department with their own technical skills (ie engineering), will likely setup their own shadow IT that doesn't involve IT. Other departments will do everything they can to avoid going to IT, including hiring outside or outsourcing to the cloud. You'll have plenty of time to work on whatever you perceive as your priorities then.

If you get little requests that are simple and easy and quick, do them! The way I see it, the problem the OP isn't realizing is that both of the problems "difficulty" and "poison" are really the same: they're a time management issue. At least from their organization's point of view. If the CEO has problems with people asking IT directly for things that they shouldn't, that's a management and CEO's issue and they shouldn't be asking you to solve what is their problem.

And really, if people are asking for things, why is that? I find it hard to believe that you're getting a slew of stuff that isn't related to work. If you're getting lots of requests from people, they both need something to get their work done, and it's not already being provided.

All that said, Papagreen's advice about tracking the projects and time spent is right on. Fix your time-management problem by figuring out how you spend your time. Get more efficient about it. Realize that you don't have to do every little thing you're asked to do. And yes, sometimes you will have to say NO. But do it in the right way and for the right reasons. Not because they don't have their TPS form filled out correctly.

Frankly, I see the CEO's complaint that people ask you guys to get things done is a positive. If they didn't trust you or you weren't responsive, or you didn't accomplish things, or whatever, they they wouldn't ask you for things. They know your department can deliver results.

BTW - I'm not trying to be harsh on IT departments. I've done IT. I'm mostly over in engineering now though so I've seen it from both inside and out. I've seen great IT departments, and I've seen really really bad IT. I've seen IT that gets great things done for the organization and allows it to excel, and I've seen IT departments who's whole role seems to be to handicap the ability to get any meaningful work done while at the same time trying to lord their superiority over everyone. To paraphrase Mark: I don't hate IT, I hate BAD IT.

 

stevesim's picture

The cast Derosier is referencing is "Internal Support Roles And Responsibilities" (2/'17/2012).

Steve Simmons
CGEIT, CISA, CISM, CISSP
DiSC=7115

Tom Green's picture

 Everything Derosier says is a genuine pitfall of a project tracking system for IT.  This is why I strongly suggest you have your team fill out the forms for the requestor, don't put this up as a barrier to access.  Done right, the form is an agenda for a project chartering meeting between the prospective project manager (from your team) and the key stakeholder (the requestor).  

Saying no all the time is also bad, but saying yes and doing nothing is worse.  And recognize that if one of your people spends 15 - 30 minutes filling out the form with the requestor, you've implied you're going to follow through.  The conclusion of the meeting where the form is filled out is "thanks for helping us understand this request.  We'll put it into our prioritization process, and based on the relative value added, we'll either do the project or let you know why we don't think it is worth doing."  

Your CEO is against "things which are not business priorities, without the approval of their boss " so would definitely be against 'shadow IT' which really is a pitfall.  You have to collect the request and show there is no business case.  The tracking system I'm advocating can be a continuation of the dialogue with the various bosses referred to, and the CEO, to show you are following up on the directive.  

I agree that your team needs to see the difference between small requests that you just do, and larger requests that become projects.  

Having 'been there and done that' I'm trying to give you actionable suggestions that will help you avoid "BAD IT."  Instilling a project management mindset into your team is the best way I know to do that.  

flexiblefine's picture

Your description of the "poison" has the answer right there: "some of our internal customers ask us for things which are not business priorities, without the approval of their boss". Make sure the requests all have the appropriate boss's approval.

My first thought was to have some form that required a boss's written approval, but you don't need the form if you don't want to use it. Just make sure you wrap the need for boss approval in something like "We're trying to make sure we apply our efforts to the right priorities, so we want your boss to assign an appropriate priority level to it." 

I have a people-pleasing tendency myself, so I know how big, important projects get delayed while you get nibbled to death by smaller tasks.

flexiblefine
Houston, Texas, USA
DiSC: 1476

tomjedrz's picture

The CEO gave you some cover to act.

First .. talk to the CEO and make sure that you are aware of the "business priorities", and then make sure your staff is aware. If you can't get clear guidance, talk to the other managers.

 

Second ... institute a time and request tracking system .. NOW. The company should be willing to spend some money for it, since the CEO has directly told you improvement is needed. The team should not gripe too much, since the CEO has told you that better time and request management is needed, and you can't manage what you don't measure. Don't have the users enter requests, have your staff do the entry and management.

 

Review the requests and the time spent on them frequently with your team.  Discuss them in light of the CEO's guidance. 

Third ... Direct your people to ask for management approval when a request is not clearly in line with those business requirements. Tell them that when in doubt, get approval. Have their back when they do so.

Fourth ... work on your relationships with the other department managers. Tell them your issues and challenges. You need to know the issues and challenges in their worlds. This is even more important if you don't get clear guidance from the CEO.

Good luck.

mspeas's picture

I run an IT Ops team and we use a Kanban board to track all of the request that come in.  We have a daily stand up meeting for 15 minutes in the morning to review and then do a formal weekly review during our team meeting.  This help discuss priorities as a team and I can broker situations where a priority call needs to be made.  

Here's an article on how Spotify used this methodology.  Down the road I plan to write a post on how we actually did this in our organization.  Good luck as this is a difficult challenge. Especially for support organizations with shrinking staff counts.  

 

 

jay2k's picture

Laurentmorel,

I'm curious, do you work in an IT Development department that focuses more on projects and a little on support operations or do you work on the Service Desk/Desktop Support side where your main goal is to provide quick operational support?

jamie_p's picture

You need to learn your customers' business needs and priorities, prioritze the priorities and create a master priority list*, relay this list to your directs, and you and your directs should priortize their work based on the list.  This allows you and your staff to communicate your accomplishments based on the greatest needs and priorities of your company and customers.  If a staff member is spending too much time in a week on "poison", you can provide feedback in your 1:1. 

* I recommend doing this on your own and relaying it to your manager for his/her feedback.  You and your manager should agree on the master priority list.

dmb41carter36's picture

Thanks for giving me the inspiration for a future article

We have found some success in managing the ever-growing project list. We do project selection 1-2 times per year. We create a 1 year plan with selected projects. We attach owners and dates. We then set a monthly SSC meeting (stop start continue) where we "authorize" the actual projects in the one year plan in a progressive manner.

We post the projects which were not selected, for all to see. We give the suggestor feedback as to why their project was not selected.  I emphasize a face to face, one on one type of approach. During this "Rejection" meeting, we explain how the suggested project does not fit into this year's plan. We often place their idea in a benefit/effort matrix so they can see, graphically, what they asked for. While the suggestor is not happy, at least they leave with a sense of understanding. We place the "Rejected" project on the "Hold" list. We let the suggestor know that when we do project selection again, their idea will be considered. This way the ideas are not lost, they are simply on a hold que.

Also, we have interns that often need filler projects. As long as we have this public list, there are when we grab and knock off one of the "hold" projects.

Lastly, you could also consider blocking some of your capacity for "Rush requests". I agree with the other posts on creating a master plan, but consider blocking out some amount of time to work on those "Emergency" projects. This allows you some flexibility and avoids the crushing sense of "Here we go again" in your team.

dmb41carter36's picture

You could also consider the possibility of qualifying a 3rd party IT firm to outsource requests. The requesting department would have to fully fund the 3rd party vendor. Sure, there would be some interface with your group but it would dramatically less than if you turn down the request in total.

We use this option for our maintenance group. It really helps the requesting group as it gives them another option.