How to introduce formal request system
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
I work as the head of a small team of developers for a business with around 100 employees. Our core work is handed to me by directors which I then assign to a developer (either myself or one of the others in the team). On top of our core work users will make change or feature requests.
There is currently no formal process for requests and the majority of these are made either by email or someone coming over to our desks. I have told the other developers that such requests should be passed on to me and I will then decide whether we can take on the work or if it needs to be escalated to a director for approval/rejection.
The problem with this approach is that users will target specific developers, go to their desk and say that they need changes doing urgently - stating things such as 'I have a meeting tomorrow morning, it is crucial this change is made by then.'
Despite what I have told the other developers about not taking on work without speaking to me first they sometimes cave under the pressure, which I can understand - it is difficult to say no to someone when they refuse to take that for an answer and stand at your desk demanding you do what they ask.
These under the radar changes result in rushed code which is not reviewed risking the introduction of security vulnerabilities and/or bugs. They also distract from core work which is typically of much higher priority.
My current idea is to introduce a formal system where requests are put in to a queue to be reviewed in our weekly development meeting. Anything a user considers to be urgent could be flagged as such and would be reviewed before our weekly meeting to see if immediate action is needed.
I can foresee resistance to this with users being reluctant to make requests in this formal way, seeing it as a way of us getting out of doing work, and wanting an explanation as to why this change in process has been made.
There is also the issue that users typically view all of their requests to be of high urgency and importance - I can imagine the majority of requests made would be flagged as 'urgent' when they are not necessarily.
How can I explain the situation and need for a formal request system to users without provoking a hostile response? Also how can I try to prevent users from incorrectly flagging requests as urgent?
project-management
suggest improvements |Â
up vote
3
down vote
favorite
I work as the head of a small team of developers for a business with around 100 employees. Our core work is handed to me by directors which I then assign to a developer (either myself or one of the others in the team). On top of our core work users will make change or feature requests.
There is currently no formal process for requests and the majority of these are made either by email or someone coming over to our desks. I have told the other developers that such requests should be passed on to me and I will then decide whether we can take on the work or if it needs to be escalated to a director for approval/rejection.
The problem with this approach is that users will target specific developers, go to their desk and say that they need changes doing urgently - stating things such as 'I have a meeting tomorrow morning, it is crucial this change is made by then.'
Despite what I have told the other developers about not taking on work without speaking to me first they sometimes cave under the pressure, which I can understand - it is difficult to say no to someone when they refuse to take that for an answer and stand at your desk demanding you do what they ask.
These under the radar changes result in rushed code which is not reviewed risking the introduction of security vulnerabilities and/or bugs. They also distract from core work which is typically of much higher priority.
My current idea is to introduce a formal system where requests are put in to a queue to be reviewed in our weekly development meeting. Anything a user considers to be urgent could be flagged as such and would be reviewed before our weekly meeting to see if immediate action is needed.
I can foresee resistance to this with users being reluctant to make requests in this formal way, seeing it as a way of us getting out of doing work, and wanting an explanation as to why this change in process has been made.
There is also the issue that users typically view all of their requests to be of high urgency and importance - I can imagine the majority of requests made would be flagged as 'urgent' when they are not necessarily.
How can I explain the situation and need for a formal request system to users without provoking a hostile response? Also how can I try to prevent users from incorrectly flagging requests as urgent?
project-management
2
Read: meta.programmers.stackexchange.com/questions/6629/â¦
â Jan Doggen
Nov 5 '14 at 9:34
1
As you don't have direct responsibility for the users who are dumping your devs with requests, you need buy-in at director level first. What's wrong with presenting them with a simple list of advantages, as you've done here?
â Julia Hayward
Nov 5 '14 at 10:56
suggest improvements |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I work as the head of a small team of developers for a business with around 100 employees. Our core work is handed to me by directors which I then assign to a developer (either myself or one of the others in the team). On top of our core work users will make change or feature requests.
There is currently no formal process for requests and the majority of these are made either by email or someone coming over to our desks. I have told the other developers that such requests should be passed on to me and I will then decide whether we can take on the work or if it needs to be escalated to a director for approval/rejection.
The problem with this approach is that users will target specific developers, go to their desk and say that they need changes doing urgently - stating things such as 'I have a meeting tomorrow morning, it is crucial this change is made by then.'
Despite what I have told the other developers about not taking on work without speaking to me first they sometimes cave under the pressure, which I can understand - it is difficult to say no to someone when they refuse to take that for an answer and stand at your desk demanding you do what they ask.
These under the radar changes result in rushed code which is not reviewed risking the introduction of security vulnerabilities and/or bugs. They also distract from core work which is typically of much higher priority.
My current idea is to introduce a formal system where requests are put in to a queue to be reviewed in our weekly development meeting. Anything a user considers to be urgent could be flagged as such and would be reviewed before our weekly meeting to see if immediate action is needed.
I can foresee resistance to this with users being reluctant to make requests in this formal way, seeing it as a way of us getting out of doing work, and wanting an explanation as to why this change in process has been made.
There is also the issue that users typically view all of their requests to be of high urgency and importance - I can imagine the majority of requests made would be flagged as 'urgent' when they are not necessarily.
How can I explain the situation and need for a formal request system to users without provoking a hostile response? Also how can I try to prevent users from incorrectly flagging requests as urgent?
project-management
I work as the head of a small team of developers for a business with around 100 employees. Our core work is handed to me by directors which I then assign to a developer (either myself or one of the others in the team). On top of our core work users will make change or feature requests.
There is currently no formal process for requests and the majority of these are made either by email or someone coming over to our desks. I have told the other developers that such requests should be passed on to me and I will then decide whether we can take on the work or if it needs to be escalated to a director for approval/rejection.
The problem with this approach is that users will target specific developers, go to their desk and say that they need changes doing urgently - stating things such as 'I have a meeting tomorrow morning, it is crucial this change is made by then.'
Despite what I have told the other developers about not taking on work without speaking to me first they sometimes cave under the pressure, which I can understand - it is difficult to say no to someone when they refuse to take that for an answer and stand at your desk demanding you do what they ask.
These under the radar changes result in rushed code which is not reviewed risking the introduction of security vulnerabilities and/or bugs. They also distract from core work which is typically of much higher priority.
My current idea is to introduce a formal system where requests are put in to a queue to be reviewed in our weekly development meeting. Anything a user considers to be urgent could be flagged as such and would be reviewed before our weekly meeting to see if immediate action is needed.
I can foresee resistance to this with users being reluctant to make requests in this formal way, seeing it as a way of us getting out of doing work, and wanting an explanation as to why this change in process has been made.
There is also the issue that users typically view all of their requests to be of high urgency and importance - I can imagine the majority of requests made would be flagged as 'urgent' when they are not necessarily.
How can I explain the situation and need for a formal request system to users without provoking a hostile response? Also how can I try to prevent users from incorrectly flagging requests as urgent?
project-management
asked Nov 5 '14 at 8:43
user29281
191
191
2
Read: meta.programmers.stackexchange.com/questions/6629/â¦
â Jan Doggen
Nov 5 '14 at 9:34
1
As you don't have direct responsibility for the users who are dumping your devs with requests, you need buy-in at director level first. What's wrong with presenting them with a simple list of advantages, as you've done here?
â Julia Hayward
Nov 5 '14 at 10:56
suggest improvements |Â
2
Read: meta.programmers.stackexchange.com/questions/6629/â¦
â Jan Doggen
Nov 5 '14 at 9:34
1
As you don't have direct responsibility for the users who are dumping your devs with requests, you need buy-in at director level first. What's wrong with presenting them with a simple list of advantages, as you've done here?
â Julia Hayward
Nov 5 '14 at 10:56
2
2
Read: meta.programmers.stackexchange.com/questions/6629/â¦
â Jan Doggen
Nov 5 '14 at 9:34
Read: meta.programmers.stackexchange.com/questions/6629/â¦
â Jan Doggen
Nov 5 '14 at 9:34
1
1
As you don't have direct responsibility for the users who are dumping your devs with requests, you need buy-in at director level first. What's wrong with presenting them with a simple list of advantages, as you've done here?
â Julia Hayward
Nov 5 '14 at 10:56
As you don't have direct responsibility for the users who are dumping your devs with requests, you need buy-in at director level first. What's wrong with presenting them with a simple list of advantages, as you've done here?
â Julia Hayward
Nov 5 '14 at 10:56
suggest improvements |Â
3 Answers
3
active
oldest
votes
up vote
6
down vote
The first step is to pitch this idea to your own manager or director. When you do this, you should emphasize the reasons why informal requests lead to a less productive and unhappier team.
Assuming you get approval, it's important to get buy-in from other senior leaders within your organization. You probably emphasized the negatives in your meeting with your own management; in this meeting you should emphasize the positives, e.g. a formal process will help prioritize work, making your team more efficient and allowing important projects to be delivered more quickly.
One way to minimize every request being marked as "urgent" is to mandate that requests can only come from department-level management. That keeps the squeaky wheels in every group from wasting your time with things that their own managers don't consider important.
Exactly. To implement a process, the leaders need to be on board. Once they are on board, draft an SOP and get it approved by them and sent out in a memo to the entire company.
â Raystafarian
Nov 5 '14 at 13:35
suggest improvements |Â
up vote
0
down vote
Sounds like you are basically proposing that your team switch to Scrum with weekly sprints.
The usual arguments for having more control on where people actually get their work from is metrics based on how much of their time is spent on ad-hoc requests or what impact that is having on the scheduled deliverables.d.
You can also argue that having a single entry point for work makes it much easier to understand what everyone is actually working on and to make sure they are working on what is actually the highest priority.
suggest improvements |Â
up vote
-2
down vote
Your developers need a secret alarm button to call you for help, like they have in banks.
Then you show up at their table too and "complain loudly" why feature X is not implemented yet and that it's super important and needs to be done "right now". And after that "immediately" features Y and Z, really really important.
After your rant, you can slowly turn around to the intruder and ask in a completely innocent voice: "hello, how can I help you?"
Then whatever he says, refer him to the online system, since you are all so busy with important stuff. Learn to say no and they will learn to show up earlier.
Pretense/lying never works well
â Jan Doggen
Nov 6 '14 at 10:31
suggest improvements |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
The first step is to pitch this idea to your own manager or director. When you do this, you should emphasize the reasons why informal requests lead to a less productive and unhappier team.
Assuming you get approval, it's important to get buy-in from other senior leaders within your organization. You probably emphasized the negatives in your meeting with your own management; in this meeting you should emphasize the positives, e.g. a formal process will help prioritize work, making your team more efficient and allowing important projects to be delivered more quickly.
One way to minimize every request being marked as "urgent" is to mandate that requests can only come from department-level management. That keeps the squeaky wheels in every group from wasting your time with things that their own managers don't consider important.
Exactly. To implement a process, the leaders need to be on board. Once they are on board, draft an SOP and get it approved by them and sent out in a memo to the entire company.
â Raystafarian
Nov 5 '14 at 13:35
suggest improvements |Â
up vote
6
down vote
The first step is to pitch this idea to your own manager or director. When you do this, you should emphasize the reasons why informal requests lead to a less productive and unhappier team.
Assuming you get approval, it's important to get buy-in from other senior leaders within your organization. You probably emphasized the negatives in your meeting with your own management; in this meeting you should emphasize the positives, e.g. a formal process will help prioritize work, making your team more efficient and allowing important projects to be delivered more quickly.
One way to minimize every request being marked as "urgent" is to mandate that requests can only come from department-level management. That keeps the squeaky wheels in every group from wasting your time with things that their own managers don't consider important.
Exactly. To implement a process, the leaders need to be on board. Once they are on board, draft an SOP and get it approved by them and sent out in a memo to the entire company.
â Raystafarian
Nov 5 '14 at 13:35
suggest improvements |Â
up vote
6
down vote
up vote
6
down vote
The first step is to pitch this idea to your own manager or director. When you do this, you should emphasize the reasons why informal requests lead to a less productive and unhappier team.
Assuming you get approval, it's important to get buy-in from other senior leaders within your organization. You probably emphasized the negatives in your meeting with your own management; in this meeting you should emphasize the positives, e.g. a formal process will help prioritize work, making your team more efficient and allowing important projects to be delivered more quickly.
One way to minimize every request being marked as "urgent" is to mandate that requests can only come from department-level management. That keeps the squeaky wheels in every group from wasting your time with things that their own managers don't consider important.
The first step is to pitch this idea to your own manager or director. When you do this, you should emphasize the reasons why informal requests lead to a less productive and unhappier team.
Assuming you get approval, it's important to get buy-in from other senior leaders within your organization. You probably emphasized the negatives in your meeting with your own management; in this meeting you should emphasize the positives, e.g. a formal process will help prioritize work, making your team more efficient and allowing important projects to be delivered more quickly.
One way to minimize every request being marked as "urgent" is to mandate that requests can only come from department-level management. That keeps the squeaky wheels in every group from wasting your time with things that their own managers don't consider important.
answered Nov 5 '14 at 13:31
Roger
7,17132644
7,17132644
Exactly. To implement a process, the leaders need to be on board. Once they are on board, draft an SOP and get it approved by them and sent out in a memo to the entire company.
â Raystafarian
Nov 5 '14 at 13:35
suggest improvements |Â
Exactly. To implement a process, the leaders need to be on board. Once they are on board, draft an SOP and get it approved by them and sent out in a memo to the entire company.
â Raystafarian
Nov 5 '14 at 13:35
Exactly. To implement a process, the leaders need to be on board. Once they are on board, draft an SOP and get it approved by them and sent out in a memo to the entire company.
â Raystafarian
Nov 5 '14 at 13:35
Exactly. To implement a process, the leaders need to be on board. Once they are on board, draft an SOP and get it approved by them and sent out in a memo to the entire company.
â Raystafarian
Nov 5 '14 at 13:35
suggest improvements |Â
up vote
0
down vote
Sounds like you are basically proposing that your team switch to Scrum with weekly sprints.
The usual arguments for having more control on where people actually get their work from is metrics based on how much of their time is spent on ad-hoc requests or what impact that is having on the scheduled deliverables.d.
You can also argue that having a single entry point for work makes it much easier to understand what everyone is actually working on and to make sure they are working on what is actually the highest priority.
suggest improvements |Â
up vote
0
down vote
Sounds like you are basically proposing that your team switch to Scrum with weekly sprints.
The usual arguments for having more control on where people actually get their work from is metrics based on how much of their time is spent on ad-hoc requests or what impact that is having on the scheduled deliverables.d.
You can also argue that having a single entry point for work makes it much easier to understand what everyone is actually working on and to make sure they are working on what is actually the highest priority.
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
Sounds like you are basically proposing that your team switch to Scrum with weekly sprints.
The usual arguments for having more control on where people actually get their work from is metrics based on how much of their time is spent on ad-hoc requests or what impact that is having on the scheduled deliverables.d.
You can also argue that having a single entry point for work makes it much easier to understand what everyone is actually working on and to make sure they are working on what is actually the highest priority.
Sounds like you are basically proposing that your team switch to Scrum with weekly sprints.
The usual arguments for having more control on where people actually get their work from is metrics based on how much of their time is spent on ad-hoc requests or what impact that is having on the scheduled deliverables.d.
You can also argue that having a single entry point for work makes it much easier to understand what everyone is actually working on and to make sure they are working on what is actually the highest priority.
answered Nov 5 '14 at 18:45
Eric
4,11911125
4,11911125
suggest improvements |Â
suggest improvements |Â
up vote
-2
down vote
Your developers need a secret alarm button to call you for help, like they have in banks.
Then you show up at their table too and "complain loudly" why feature X is not implemented yet and that it's super important and needs to be done "right now". And after that "immediately" features Y and Z, really really important.
After your rant, you can slowly turn around to the intruder and ask in a completely innocent voice: "hello, how can I help you?"
Then whatever he says, refer him to the online system, since you are all so busy with important stuff. Learn to say no and they will learn to show up earlier.
Pretense/lying never works well
â Jan Doggen
Nov 6 '14 at 10:31
suggest improvements |Â
up vote
-2
down vote
Your developers need a secret alarm button to call you for help, like they have in banks.
Then you show up at their table too and "complain loudly" why feature X is not implemented yet and that it's super important and needs to be done "right now". And after that "immediately" features Y and Z, really really important.
After your rant, you can slowly turn around to the intruder and ask in a completely innocent voice: "hello, how can I help you?"
Then whatever he says, refer him to the online system, since you are all so busy with important stuff. Learn to say no and they will learn to show up earlier.
Pretense/lying never works well
â Jan Doggen
Nov 6 '14 at 10:31
suggest improvements |Â
up vote
-2
down vote
up vote
-2
down vote
Your developers need a secret alarm button to call you for help, like they have in banks.
Then you show up at their table too and "complain loudly" why feature X is not implemented yet and that it's super important and needs to be done "right now". And after that "immediately" features Y and Z, really really important.
After your rant, you can slowly turn around to the intruder and ask in a completely innocent voice: "hello, how can I help you?"
Then whatever he says, refer him to the online system, since you are all so busy with important stuff. Learn to say no and they will learn to show up earlier.
Your developers need a secret alarm button to call you for help, like they have in banks.
Then you show up at their table too and "complain loudly" why feature X is not implemented yet and that it's super important and needs to be done "right now". And after that "immediately" features Y and Z, really really important.
After your rant, you can slowly turn around to the intruder and ask in a completely innocent voice: "hello, how can I help you?"
Then whatever he says, refer him to the online system, since you are all so busy with important stuff. Learn to say no and they will learn to show up earlier.
answered Nov 6 '14 at 0:45
Greg
1
1
Pretense/lying never works well
â Jan Doggen
Nov 6 '14 at 10:31
suggest improvements |Â
Pretense/lying never works well
â Jan Doggen
Nov 6 '14 at 10:31
Pretense/lying never works well
â Jan Doggen
Nov 6 '14 at 10:31
Pretense/lying never works well
â Jan Doggen
Nov 6 '14 at 10:31
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f35824%2fhow-to-introduce-formal-request-system%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
Read: meta.programmers.stackexchange.com/questions/6629/â¦
â Jan Doggen
Nov 5 '14 at 9:34
1
As you don't have direct responsibility for the users who are dumping your devs with requests, you need buy-in at director level first. What's wrong with presenting them with a simple list of advantages, as you've done here?
â Julia Hayward
Nov 5 '14 at 10:56