Mixing
How to handle pressure when I am not fully in control of the issue (and it is beyond my skills)? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
I am responsible for delivering different final product/service requests to Team A (usually Customer Sales, Business Developers, sometimes the CEO himself) using in-house-built Software that is developed and maintained by Team Z (Software Developers).
As the main user of the Software I am also responsible for testing it for bugs and suggesting changes and features to the software product owner/manager, who decides what can be implemented or not, and when. The changes or features I suggest are based on my judgment and interaction with Team A and their different types of requests.
There are two types of situations where I feel I am not in control and yet I get unwarranted pressure:
There are service issues in the hardware/servers/systems that supports the Software, sometimes completely unexpected and outside normal hours, yet I am still given pressure to deliver the product/service to Team A. The Software Developers however are working on something else (they have other projects/deadlines) so cannot help me immediately.
Team A sends completely new types of requests that according to common sense should be supported by the Software, because they are similar in principle; but when I try them they turn out not to be supported, and sometimes even break the Software - again requiring the intervention of Team Z.
In either case I think the best I can do is try different solutions and communicate if it worked or not. I have no technical background so I cannot actually solve any of the issues by myself. However, I am often reminded of deadlines, asked about estimated new delivery times, etc.
What makes things worse is that often the requests are made after the people in Team A spoke with the software product owner/manager (who is also my direct supervisor), who approves the requests and says they should be possible... but they aren't.
There may be multiple issues in my story, but the common thread is that I am given pressure to deliver and I am not not in control. How can I handle this kind of situation? What is the most professional response?
management communication deadlines
asked Sep 1 '14 at 23:40
BoilingWaterBucketChallenge
172
closed as off-topic by Jim G., gnat, IDrinkandIKnowThings, Garrison Neely, David S. Sep 3 '14 at 9:37
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., gnat, Garrison Neely, David S.
suggest improvements |Â
up vote
2
down vote
favorite
I am responsible for delivering different final product/service requests to Team A (usually Customer Sales, Business Developers, sometimes the CEO himself) using in-house-built Software that is developed and maintained by Team Z (Software Developers).
As the main user of the Software I am also responsible for testing it for bugs and suggesting changes and features to the software product owner/manager, who decides what can be implemented or not, and when. The changes or features I suggest are based on my judgment and interaction with Team A and their different types of requests.
There are two types of situations where I feel I am not in control and yet I get unwarranted pressure:
There are service issues in the hardware/servers/systems that supports the Software, sometimes completely unexpected and outside normal hours, yet I am still given pressure to deliver the product/service to Team A. The Software Developers however are working on something else (they have other projects/deadlines) so cannot help me immediately.
Team A sends completely new types of requests that according to common sense should be supported by the Software, because they are similar in principle; but when I try them they turn out not to be supported, and sometimes even break the Software - again requiring the intervention of Team Z.
In either case I think the best I can do is try different solutions and communicate if it worked or not. I have no technical background so I cannot actually solve any of the issues by myself. However, I am often reminded of deadlines, asked about estimated new delivery times, etc.
What makes things worse is that often the requests are made after the people in Team A spoke with the software product owner/manager (who is also my direct supervisor), who approves the requests and says they should be possible... but they aren't.
There may be multiple issues in my story, but the common thread is that I am given pressure to deliver and I am not not in control. How can I handle this kind of situation? What is the most professional response?
management communication deadlines
asked Sep 1 '14 at 23:40
BoilingWaterBucketChallenge
172
closed as off-topic by Jim G., gnat, IDrinkandIKnowThings, Garrison Neely, David S. Sep 3 '14 at 9:37
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., gnat, Garrison Neely, David S.
suggest improvements |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I am responsible for delivering different final product/service requests to Team A (usually Customer Sales, Business Developers, sometimes the CEO himself) using in-house-built Software that is developed and maintained by Team Z (Software Developers).
As the main user of the Software I am also responsible for testing it for bugs and suggesting changes and features to the software product owner/manager, who decides what can be implemented or not, and when. The changes or features I suggest are based on my judgment and interaction with Team A and their different types of requests.
There are two types of situations where I feel I am not in control and yet I get unwarranted pressure:
There are service issues in the hardware/servers/systems that supports the Software, sometimes completely unexpected and outside normal hours, yet I am still given pressure to deliver the product/service to Team A. The Software Developers however are working on something else (they have other projects/deadlines) so cannot help me immediately.
Team A sends completely new types of requests that according to common sense should be supported by the Software, because they are similar in principle; but when I try them they turn out not to be supported, and sometimes even break the Software - again requiring the intervention of Team Z.
In either case I think the best I can do is try different solutions and communicate if it worked or not. I have no technical background so I cannot actually solve any of the issues by myself. However, I am often reminded of deadlines, asked about estimated new delivery times, etc.
What makes things worse is that often the requests are made after the people in Team A spoke with the software product owner/manager (who is also my direct supervisor), who approves the requests and says they should be possible... but they aren't.
There may be multiple issues in my story, but the common thread is that I am given pressure to deliver and I am not not in control. How can I handle this kind of situation? What is the most professional response?
management communication deadlines
asked Sep 1 '14 at 23:40
BoilingWaterBucketChallenge
172
I am responsible for delivering different final product/service requests to Team A (usually Customer Sales, Business Developers, sometimes the CEO himself) using in-house-built Software that is developed and maintained by Team Z (Software Developers).
As the main user of the Software I am also responsible for testing it for bugs and suggesting changes and features to the software product owner/manager, who decides what can be implemented or not, and when. The changes or features I suggest are based on my judgment and interaction with Team A and their different types of requests.
There are two types of situations where I feel I am not in control and yet I get unwarranted pressure:
There are service issues in the hardware/servers/systems that supports the Software, sometimes completely unexpected and outside normal hours, yet I am still given pressure to deliver the product/service to Team A. The Software Developers however are working on something else (they have other projects/deadlines) so cannot help me immediately.
Team A sends completely new types of requests that according to common sense should be supported by the Software, because they are similar in principle; but when I try them they turn out not to be supported, and sometimes even break the Software - again requiring the intervention of Team Z.
In either case I think the best I can do is try different solutions and communicate if it worked or not. I have no technical background so I cannot actually solve any of the issues by myself. However, I am often reminded of deadlines, asked about estimated new delivery times, etc.
What makes things worse is that often the requests are made after the people in Team A spoke with the software product owner/manager (who is also my direct supervisor), who approves the requests and says they should be possible... but they aren't.
There may be multiple issues in my story, but the common thread is that I am given pressure to deliver and I am not not in control. How can I handle this kind of situation? What is the most professional response?
management communication deadlines
asked Sep 1 '14 at 23:40
BoilingWaterBucketChallenge
172
edited Sep 2 '14 at 6:14
asked Sep 1 '14 at 23:40
BoilingWaterBucketChallenge
172
asked Sep 1 '14 at 23:40
BoilingWaterBucketChallenge
172
asked Sep 1 '14 at 23:40
BoilingWaterBucketChallenge
172
172
closed as off-topic by Jim G., gnat, IDrinkandIKnowThings, Garrison Neely, David S. Sep 3 '14 at 9:37
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., gnat, Garrison Neely, David S.
closed as off-topic by Jim G., gnat, IDrinkandIKnowThings, Garrison Neely, David S. Sep 3 '14 at 9:37
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – Jim G., gnat, Garrison Neely, David S.
suggest improvements |Â
suggest improvements |Â
2 Answers
2
active
oldest
votes
up vote
3
down vote
It reads like you're positioned as an intermediary/goalie between Teams A and Z. It also reads like you don't have a supervisor/manager.
Get your supervisor involved/in the loop of your proceedings. The most vital bits of your communications between both teams should have your supervisor cc'ed. Your supervisor's job is to shield you from unnecessary outside interference, so you can do your job. Ideally, requests and deadlines should not even come to you directly. Where is your supervisor in all this? You getting thumped by entities you don't even report to beggars belief. Your supervisor should run interference for you, be able to stem the barrage of requests coming from other teams directly at you.
Do not assume the role of gatekeeper/human shield between Teams A and Z. You're just as much a client of Team Z as Team A and your relationship with Team Z should reflect that. Ensure that Team A is in copy of any correspondence with Team Z on matters of deadlines and new features. When Team Z gives an estimate of 8 months for a new feature, ensure that Team A is in copy of that correspondence so they know what you're in control of and what you're not. When Team A attempts to jump up and down your throat about a deadline, forward the enquiry straight to Team Z (preferably the developers on that team), looping in your supervisor. The point here is that Team A and Team Z must have an established correspondence and communication line, inasmuch as you're the end user of the product. Every and anyone who's remotely involved in any undertaking on this product must be on the same chain of emails.
BoilingWaterBucketChallenge, what's the status of Change Request 1234XYZ?
You: Including Team Z. Please respond
answered Sep 2 '14 at 1:50
kolossus
4,2211440
thanks - 1. My supervisor is the manager of Team Z (Developers) and my job IS to formulate the right feature requests. - 2. The problem is that it is not always clear whether a new request means a new feature. I always try whether the request is possible using the existing Software, failing which I ask my manager (who is also Team Z's manager) for new features. - 3. Finally, Team A has absolutely no technical knowledge, that's why I am the intermediary who both understands what they want and executes using existing software. Hope this clarifies. Thanks for your support
– BoilingWaterBucketChallenge
Sep 2 '14 at 6:36
@BoilingWaterBucketChallenge - Looks like you're being thrown to the wolves and your manager is not doing it right. As an analyst, your job is not to shield the devs, it's to translate business reqs into proper use cases and requirements. If the dev team is dropping the ball, you're not supposed to fall on your sword for it, everyone should bear responsibility for it
– kolossus
Sep 2 '14 at 16:21
suggest improvements |Â
up vote
1
down vote
There are service issues in the hardware/servers/systems that supports
the Software, sometimes completely unexpected and outside normal
hours, yet I am still given pressure to deliver the product/service to
Team A.
Such issues can happen in any system. To have a better position in these cases, you should have an overview of how much time you could work and how much time you could not work on their requests. Note down the time ranges on which you could not work on requests because of these issues. Also note down the times when you actually did work on their requests.
When team A reminds you of some requests, tell them how many hours/days you have worked on the requests and how many hours you could not because of system issues. Show them the list of "downtimes" to make this comprehensible for them.
Team A sends completely new types of requests that according to common
sense should be supported by the Software, because they are similar in
principle; but when I try them they turn out not to be supported.
It seems that you could need more organisation in handling of requests. If a request is submitted to you by team A, don't tell them a delivery date for this request immediately. Tell them you need to analyse the request and possible solutions first. Involve team Z and the product owner if needed. Only when the solution is clear, estimate the effort and communicate a reliable estimated date of delivery to team A. With this approach you know whether the software has to be enhanced before giving out a delivery date.
If team A wants to have a quick estimation of a delivery date, give them your best guess making assumptions. Tell them about the assumptions and the inaccuracy of this guess.
Always use e-mails to communicate estimations/delivery dates/assumptions etc. in addition to verbal communication, so you can refer to this at later points in time.
What makes things worse is that often the requests are made after the
people in Team A spoke with the software product owner/manager (who is
also my direct supervisor), who approves the requests and says they
should be possible... but they aren't.
Convince the product owner and team A that you have to participate in any talks about requests from team A. Clarify with the product owner that no promises should be made in these talks regarding the fulfillment of the requests.
The fact that the product owner is your direct supervisor is an advantage for you. It is her/his best interest that you are able to do your work successfully, so she/he should welcome any suggestions from you to improve the process.
If you have prepared and organised as stated, the responses to the inquiries or the pressure of team A are relatively straightforward. Deadlines will be realistic. In case of delays due to system downtimes you are able to justify them. Of course delays due to other reasons are possible and will happen. But this cannot be ruled out completely.
answered Sep 2 '14 at 8:32
prockel
1,075613
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
It reads like you're positioned as an intermediary/goalie between Teams A and Z. It also reads like you don't have a supervisor/manager.
Get your supervisor involved/in the loop of your proceedings. The most vital bits of your communications between both teams should have your supervisor cc'ed. Your supervisor's job is to shield you from unnecessary outside interference, so you can do your job. Ideally, requests and deadlines should not even come to you directly. Where is your supervisor in all this? You getting thumped by entities you don't even report to beggars belief. Your supervisor should run interference for you, be able to stem the barrage of requests coming from other teams directly at you.
Do not assume the role of gatekeeper/human shield between Teams A and Z. You're just as much a client of Team Z as Team A and your relationship with Team Z should reflect that. Ensure that Team A is in copy of any correspondence with Team Z on matters of deadlines and new features. When Team Z gives an estimate of 8 months for a new feature, ensure that Team A is in copy of that correspondence so they know what you're in control of and what you're not. When Team A attempts to jump up and down your throat about a deadline, forward the enquiry straight to Team Z (preferably the developers on that team), looping in your supervisor. The point here is that Team A and Team Z must have an established correspondence and communication line, inasmuch as you're the end user of the product. Every and anyone who's remotely involved in any undertaking on this product must be on the same chain of emails.
BoilingWaterBucketChallenge, what's the status of Change Request 1234XYZ?
You: Including Team Z. Please respond
answered Sep 2 '14 at 1:50
kolossus
4,2211440
thanks - 1. My supervisor is the manager of Team Z (Developers) and my job IS to formulate the right feature requests. - 2. The problem is that it is not always clear whether a new request means a new feature. I always try whether the request is possible using the existing Software, failing which I ask my manager (who is also Team Z's manager) for new features. - 3. Finally, Team A has absolutely no technical knowledge, that's why I am the intermediary who both understands what they want and executes using existing software. Hope this clarifies. Thanks for your support
– BoilingWaterBucketChallenge
Sep 2 '14 at 6:36
@BoilingWaterBucketChallenge - Looks like you're being thrown to the wolves and your manager is not doing it right. As an analyst, your job is not to shield the devs, it's to translate business reqs into proper use cases and requirements. If the dev team is dropping the ball, you're not supposed to fall on your sword for it, everyone should bear responsibility for it
– kolossus
Sep 2 '14 at 16:21
suggest improvements |Â
up vote
3
down vote
It reads like you're positioned as an intermediary/goalie between Teams A and Z. It also reads like you don't have a supervisor/manager.
Get your supervisor involved/in the loop of your proceedings. The most vital bits of your communications between both teams should have your supervisor cc'ed. Your supervisor's job is to shield you from unnecessary outside interference, so you can do your job. Ideally, requests and deadlines should not even come to you directly. Where is your supervisor in all this? You getting thumped by entities you don't even report to beggars belief. Your supervisor should run interference for you, be able to stem the barrage of requests coming from other teams directly at you.
Do not assume the role of gatekeeper/human shield between Teams A and Z. You're just as much a client of Team Z as Team A and your relationship with Team Z should reflect that. Ensure that Team A is in copy of any correspondence with Team Z on matters of deadlines and new features. When Team Z gives an estimate of 8 months for a new feature, ensure that Team A is in copy of that correspondence so they know what you're in control of and what you're not. When Team A attempts to jump up and down your throat about a deadline, forward the enquiry straight to Team Z (preferably the developers on that team), looping in your supervisor. The point here is that Team A and Team Z must have an established correspondence and communication line, inasmuch as you're the end user of the product. Every and anyone who's remotely involved in any undertaking on this product must be on the same chain of emails.
BoilingWaterBucketChallenge, what's the status of Change Request 1234XYZ?
You: Including Team Z. Please respond
answered Sep 2 '14 at 1:50
kolossus
4,2211440
thanks - 1. My supervisor is the manager of Team Z (Developers) and my job IS to formulate the right feature requests. - 2. The problem is that it is not always clear whether a new request means a new feature. I always try whether the request is possible using the existing Software, failing which I ask my manager (who is also Team Z's manager) for new features. - 3. Finally, Team A has absolutely no technical knowledge, that's why I am the intermediary who both understands what they want and executes using existing software. Hope this clarifies. Thanks for your support
– BoilingWaterBucketChallenge
Sep 2 '14 at 6:36
@BoilingWaterBucketChallenge - Looks like you're being thrown to the wolves and your manager is not doing it right. As an analyst, your job is not to shield the devs, it's to translate business reqs into proper use cases and requirements. If the dev team is dropping the ball, you're not supposed to fall on your sword for it, everyone should bear responsibility for it
– kolossus
Sep 2 '14 at 16:21
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
It reads like you're positioned as an intermediary/goalie between Teams A and Z. It also reads like you don't have a supervisor/manager.
Get your supervisor involved/in the loop of your proceedings. The most vital bits of your communications between both teams should have your supervisor cc'ed. Your supervisor's job is to shield you from unnecessary outside interference, so you can do your job. Ideally, requests and deadlines should not even come to you directly. Where is your supervisor in all this? You getting thumped by entities you don't even report to beggars belief. Your supervisor should run interference for you, be able to stem the barrage of requests coming from other teams directly at you.
Do not assume the role of gatekeeper/human shield between Teams A and Z. You're just as much a client of Team Z as Team A and your relationship with Team Z should reflect that. Ensure that Team A is in copy of any correspondence with Team Z on matters of deadlines and new features. When Team Z gives an estimate of 8 months for a new feature, ensure that Team A is in copy of that correspondence so they know what you're in control of and what you're not. When Team A attempts to jump up and down your throat about a deadline, forward the enquiry straight to Team Z (preferably the developers on that team), looping in your supervisor. The point here is that Team A and Team Z must have an established correspondence and communication line, inasmuch as you're the end user of the product. Every and anyone who's remotely involved in any undertaking on this product must be on the same chain of emails.
BoilingWaterBucketChallenge, what's the status of Change Request 1234XYZ?
You: Including Team Z. Please respond
answered Sep 2 '14 at 1:50
kolossus
4,2211440
It reads like you're positioned as an intermediary/goalie between Teams A and Z. It also reads like you don't have a supervisor/manager.
Get your supervisor involved/in the loop of your proceedings. The most vital bits of your communications between both teams should have your supervisor cc'ed. Your supervisor's job is to shield you from unnecessary outside interference, so you can do your job. Ideally, requests and deadlines should not even come to you directly. Where is your supervisor in all this? You getting thumped by entities you don't even report to beggars belief. Your supervisor should run interference for you, be able to stem the barrage of requests coming from other teams directly at you.
Do not assume the role of gatekeeper/human shield between Teams A and Z. You're just as much a client of Team Z as Team A and your relationship with Team Z should reflect that. Ensure that Team A is in copy of any correspondence with Team Z on matters of deadlines and new features. When Team Z gives an estimate of 8 months for a new feature, ensure that Team A is in copy of that correspondence so they know what you're in control of and what you're not. When Team A attempts to jump up and down your throat about a deadline, forward the enquiry straight to Team Z (preferably the developers on that team), looping in your supervisor. The point here is that Team A and Team Z must have an established correspondence and communication line, inasmuch as you're the end user of the product. Every and anyone who's remotely involved in any undertaking on this product must be on the same chain of emails.
BoilingWaterBucketChallenge, what's the status of Change Request 1234XYZ?
You: Including Team Z. Please respond
answered Sep 2 '14 at 1:50
kolossus
4,2211440
edited Sep 2 '14 at 1:59
answered Sep 2 '14 at 1:50
kolossus
4,2211440
answered Sep 2 '14 at 1:50
kolossus
4,2211440
answered Sep 2 '14 at 1:50
kolossus
4,2211440
4,2211440
thanks - 1. My supervisor is the manager of Team Z (Developers) and my job IS to formulate the right feature requests. - 2. The problem is that it is not always clear whether a new request means a new feature. I always try whether the request is possible using the existing Software, failing which I ask my manager (who is also Team Z's manager) for new features. - 3. Finally, Team A has absolutely no technical knowledge, that's why I am the intermediary who both understands what they want and executes using existing software. Hope this clarifies. Thanks for your support
– BoilingWaterBucketChallenge
Sep 2 '14 at 6:36
@BoilingWaterBucketChallenge - Looks like you're being thrown to the wolves and your manager is not doing it right. As an analyst, your job is not to shield the devs, it's to translate business reqs into proper use cases and requirements. If the dev team is dropping the ball, you're not supposed to fall on your sword for it, everyone should bear responsibility for it
– kolossus
Sep 2 '14 at 16:21
suggest improvements |Â
thanks - 1. My supervisor is the manager of Team Z (Developers) and my job IS to formulate the right feature requests. - 2. The problem is that it is not always clear whether a new request means a new feature. I always try whether the request is possible using the existing Software, failing which I ask my manager (who is also Team Z's manager) for new features. - 3. Finally, Team A has absolutely no technical knowledge, that's why I am the intermediary who both understands what they want and executes using existing software. Hope this clarifies. Thanks for your support
– BoilingWaterBucketChallenge
Sep 2 '14 at 6:36
@BoilingWaterBucketChallenge - Looks like you're being thrown to the wolves and your manager is not doing it right. As an analyst, your job is not to shield the devs, it's to translate business reqs into proper use cases and requirements. If the dev team is dropping the ball, you're not supposed to fall on your sword for it, everyone should bear responsibility for it
– kolossus
Sep 2 '14 at 16:21
thanks - 1. My supervisor is the manager of Team Z (Developers) and my job IS to formulate the right feature requests. - 2. The problem is that it is not always clear whether a new request means a new feature. I always try whether the request is possible using the existing Software, failing which I ask my manager (who is also Team Z's manager) for new features. - 3. Finally, Team A has absolutely no technical knowledge, that's why I am the intermediary who both understands what they want and executes using existing software. Hope this clarifies. Thanks for your support
– BoilingWaterBucketChallenge
Sep 2 '14 at 6:36
thanks - 1. My supervisor is the manager of Team Z (Developers) and my job IS to formulate the right feature requests. - 2. The problem is that it is not always clear whether a new request means a new feature. I always try whether the request is possible using the existing Software, failing which I ask my manager (who is also Team Z's manager) for new features. - 3. Finally, Team A has absolutely no technical knowledge, that's why I am the intermediary who both understands what they want and executes using existing software. Hope this clarifies. Thanks for your support
– BoilingWaterBucketChallenge
Sep 2 '14 at 6:36
@BoilingWaterBucketChallenge - Looks like you're being thrown to the wolves and your manager is not doing it right. As an analyst, your job is not to shield the devs, it's to translate business reqs into proper use cases and requirements. If the dev team is dropping the ball, you're not supposed to fall on your sword for it, everyone should bear responsibility for it
– kolossus
Sep 2 '14 at 16:21
@BoilingWaterBucketChallenge - Looks like you're being thrown to the wolves and your manager is not doing it right. As an analyst, your job is not to shield the devs, it's to translate business reqs into proper use cases and requirements. If the dev team is dropping the ball, you're not supposed to fall on your sword for it, everyone should bear responsibility for it
– kolossus
Sep 2 '14 at 16:21
suggest improvements |Â
up vote
1
down vote
There are service issues in the hardware/servers/systems that supports
the Software, sometimes completely unexpected and outside normal
hours, yet I am still given pressure to deliver the product/service to
Team A.
Such issues can happen in any system. To have a better position in these cases, you should have an overview of how much time you could work and how much time you could not work on their requests. Note down the time ranges on which you could not work on requests because of these issues. Also note down the times when you actually did work on their requests.
When team A reminds you of some requests, tell them how many hours/days you have worked on the requests and how many hours you could not because of system issues. Show them the list of "downtimes" to make this comprehensible for them.
Team A sends completely new types of requests that according to common
sense should be supported by the Software, because they are similar in
principle; but when I try them they turn out not to be supported.
It seems that you could need more organisation in handling of requests. If a request is submitted to you by team A, don't tell them a delivery date for this request immediately. Tell them you need to analyse the request and possible solutions first. Involve team Z and the product owner if needed. Only when the solution is clear, estimate the effort and communicate a reliable estimated date of delivery to team A. With this approach you know whether the software has to be enhanced before giving out a delivery date.
If team A wants to have a quick estimation of a delivery date, give them your best guess making assumptions. Tell them about the assumptions and the inaccuracy of this guess.
Always use e-mails to communicate estimations/delivery dates/assumptions etc. in addition to verbal communication, so you can refer to this at later points in time.
What makes things worse is that often the requests are made after the
people in Team A spoke with the software product owner/manager (who is
also my direct supervisor), who approves the requests and says they
should be possible... but they aren't.
Convince the product owner and team A that you have to participate in any talks about requests from team A. Clarify with the product owner that no promises should be made in these talks regarding the fulfillment of the requests.
The fact that the product owner is your direct supervisor is an advantage for you. It is her/his best interest that you are able to do your work successfully, so she/he should welcome any suggestions from you to improve the process.
If you have prepared and organised as stated, the responses to the inquiries or the pressure of team A are relatively straightforward. Deadlines will be realistic. In case of delays due to system downtimes you are able to justify them. Of course delays due to other reasons are possible and will happen. But this cannot be ruled out completely.
answered Sep 2 '14 at 8:32
prockel
1,075613
suggest improvements |Â
up vote
1
down vote
There are service issues in the hardware/servers/systems that supports
the Software, sometimes completely unexpected and outside normal
hours, yet I am still given pressure to deliver the product/service to
Team A.
Such issues can happen in any system. To have a better position in these cases, you should have an overview of how much time you could work and how much time you could not work on their requests. Note down the time ranges on which you could not work on requests because of these issues. Also note down the times when you actually did work on their requests.
When team A reminds you of some requests, tell them how many hours/days you have worked on the requests and how many hours you could not because of system issues. Show them the list of "downtimes" to make this comprehensible for them.
Team A sends completely new types of requests that according to common
sense should be supported by the Software, because they are similar in
principle; but when I try them they turn out not to be supported.
It seems that you could need more organisation in handling of requests. If a request is submitted to you by team A, don't tell them a delivery date for this request immediately. Tell them you need to analyse the request and possible solutions first. Involve team Z and the product owner if needed. Only when the solution is clear, estimate the effort and communicate a reliable estimated date of delivery to team A. With this approach you know whether the software has to be enhanced before giving out a delivery date.
If team A wants to have a quick estimation of a delivery date, give them your best guess making assumptions. Tell them about the assumptions and the inaccuracy of this guess.
Always use e-mails to communicate estimations/delivery dates/assumptions etc. in addition to verbal communication, so you can refer to this at later points in time.
What makes things worse is that often the requests are made after the
people in Team A spoke with the software product owner/manager (who is
also my direct supervisor), who approves the requests and says they
should be possible... but they aren't.
Convince the product owner and team A that you have to participate in any talks about requests from team A. Clarify with the product owner that no promises should be made in these talks regarding the fulfillment of the requests.
The fact that the product owner is your direct supervisor is an advantage for you. It is her/his best interest that you are able to do your work successfully, so she/he should welcome any suggestions from you to improve the process.
If you have prepared and organised as stated, the responses to the inquiries or the pressure of team A are relatively straightforward. Deadlines will be realistic. In case of delays due to system downtimes you are able to justify them. Of course delays due to other reasons are possible and will happen. But this cannot be ruled out completely.
answered Sep 2 '14 at 8:32
prockel
1,075613
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
There are service issues in the hardware/servers/systems that supports
the Software, sometimes completely unexpected and outside normal
hours, yet I am still given pressure to deliver the product/service to
Team A.
Such issues can happen in any system. To have a better position in these cases, you should have an overview of how much time you could work and how much time you could not work on their requests. Note down the time ranges on which you could not work on requests because of these issues. Also note down the times when you actually did work on their requests.
When team A reminds you of some requests, tell them how many hours/days you have worked on the requests and how many hours you could not because of system issues. Show them the list of "downtimes" to make this comprehensible for them.
Team A sends completely new types of requests that according to common
sense should be supported by the Software, because they are similar in
principle; but when I try them they turn out not to be supported.
It seems that you could need more organisation in handling of requests. If a request is submitted to you by team A, don't tell them a delivery date for this request immediately. Tell them you need to analyse the request and possible solutions first. Involve team Z and the product owner if needed. Only when the solution is clear, estimate the effort and communicate a reliable estimated date of delivery to team A. With this approach you know whether the software has to be enhanced before giving out a delivery date.
If team A wants to have a quick estimation of a delivery date, give them your best guess making assumptions. Tell them about the assumptions and the inaccuracy of this guess.
Always use e-mails to communicate estimations/delivery dates/assumptions etc. in addition to verbal communication, so you can refer to this at later points in time.
What makes things worse is that often the requests are made after the
people in Team A spoke with the software product owner/manager (who is
also my direct supervisor), who approves the requests and says they
should be possible... but they aren't.
Convince the product owner and team A that you have to participate in any talks about requests from team A. Clarify with the product owner that no promises should be made in these talks regarding the fulfillment of the requests.
The fact that the product owner is your direct supervisor is an advantage for you. It is her/his best interest that you are able to do your work successfully, so she/he should welcome any suggestions from you to improve the process.
If you have prepared and organised as stated, the responses to the inquiries or the pressure of team A are relatively straightforward. Deadlines will be realistic. In case of delays due to system downtimes you are able to justify them. Of course delays due to other reasons are possible and will happen. But this cannot be ruled out completely.
answered Sep 2 '14 at 8:32
prockel
1,075613
There are service issues in the hardware/servers/systems that supports
the Software, sometimes completely unexpected and outside normal
hours, yet I am still given pressure to deliver the product/service to
Team A.
Such issues can happen in any system. To have a better position in these cases, you should have an overview of how much time you could work and how much time you could not work on their requests. Note down the time ranges on which you could not work on requests because of these issues. Also note down the times when you actually did work on their requests.
When team A reminds you of some requests, tell them how many hours/days you have worked on the requests and how many hours you could not because of system issues. Show them the list of "downtimes" to make this comprehensible for them.
Team A sends completely new types of requests that according to common
sense should be supported by the Software, because they are similar in
principle; but when I try them they turn out not to be supported.
It seems that you could need more organisation in handling of requests. If a request is submitted to you by team A, don't tell them a delivery date for this request immediately. Tell them you need to analyse the request and possible solutions first. Involve team Z and the product owner if needed. Only when the solution is clear, estimate the effort and communicate a reliable estimated date of delivery to team A. With this approach you know whether the software has to be enhanced before giving out a delivery date.
If team A wants to have a quick estimation of a delivery date, give them your best guess making assumptions. Tell them about the assumptions and the inaccuracy of this guess.
Always use e-mails to communicate estimations/delivery dates/assumptions etc. in addition to verbal communication, so you can refer to this at later points in time.
What makes things worse is that often the requests are made after the
people in Team A spoke with the software product owner/manager (who is
also my direct supervisor), who approves the requests and says they
should be possible... but they aren't.
Convince the product owner and team A that you have to participate in any talks about requests from team A. Clarify with the product owner that no promises should be made in these talks regarding the fulfillment of the requests.
The fact that the product owner is your direct supervisor is an advantage for you. It is her/his best interest that you are able to do your work successfully, so she/he should welcome any suggestions from you to improve the process.
If you have prepared and organised as stated, the responses to the inquiries or the pressure of team A are relatively straightforward. Deadlines will be realistic. In case of delays due to system downtimes you are able to justify them. Of course delays due to other reasons are possible and will happen. But this cannot be ruled out completely.
answered Sep 2 '14 at 8:32
prockel
1,075613
edited Sep 2 '14 at 8:48
answered Sep 2 '14 at 8:32
prockel
1,075613
answered Sep 2 '14 at 8:32
prockel
1,075613
answered Sep 2 '14 at 8:32
prockel
1,075613
1,075613
suggest improvements |Â
suggest improvements |Â
