Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Stress – It’s Not Fair Expand / Collapse
Author
Message
Posted Sunday, November 27, 2011 8:47 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: 2 days ago @ 9:16 AM
Points: 6,784, Visits: 1,895
Comments posted to this topic are about the item Stress – It’s Not Fair

Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #1212206
Posted Sunday, November 27, 2011 10:27 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 3:05 PM
Points: 37,080, Visits: 31,639
Heh... you've gotten really good at hitting "hot spots" for me in your articles, Andy.

[Rant ON]

Unless you're the project manager, there's no way to reduce this type of stress other than to realize there's nothing you can do about it except report the reasons correctly and without emotion. People always wait until the last minute or some teams do a less than stellar interpretation of the requirements they've been given which requires rework and the resulting stress that causes.

When a project is being put together, people need to realize that there aren't "different" teams. There's only one "project team" and the individuals and groups in that team need to work together and keep each other informed about the project on all fronts... especially if you have a less than stellar project manager.

I am, by no means, suggesting an "it's not my job" attitude (which becomes self-prophesizing at times). For a team to perform and perform without stress, the component parts of that team must constantly and effectively interact on a daily or even by-the-minute basis. There is no stress in a well-oiled machine that's running on-time.

I'll also say that stress in a project is normally and unwittingly a "planned" thing because most managers don't plan for contingencies that will take extra time or even add scope to the things that need to be done. The old saying of "failure to properly plan is planning to fail" has a lot of merit to it.

That includes the "worker bees", as well. Many developers (front-end and back-end) will "plan" their own priorities in the project along with other projects (and ad hoc tasks they're given every day) they may be working on and they usually grossly under-estimate what actually needs to be done and the time it will take. By the time they get around to working on "the project", it's already too late to have any chance to properly meet the actual deadline. As a result, they end up taking huge shortcuts just to "get things off their plate" and it fails in test which requires still more time in the form of rework and you end up with totally-crap-code and a death spiral of rework (along with the related stress) in the project.

Right after all of that, a new form of stress arises... the stress of having a totally pissed-off customer because either the code doesn't work correctly or doesn't scale to meet their needs. Reworking that, of course, causes additional stress because the deadlines for all the other poorly planned or poorly controlled projects have deadlines looming, as well.

This vicious cycle of stess can be broken but it takes everyone to do so. Managers need to stop making silly, uninformed promises as to when something might be done and they need to build in some contingency time for things that (it seems and therefore should be anticipated) WILL go "bump" in the night during development, testing, and deployment.

Project Managers need to do the same and they also need to learn that things are easier to say than do. It's not that Developers intentionally lie... they just underestimate especially when under pressure to meet a deadline (no one wants to admit to something that will take longer than the given deadline). Developers need to understand that things will go wrong and provide estimates that have contingencies identified ("If we don't have data to work with to test for scalability, we'll need to build code that builds adequate test data.", etc).

Developers also need to properly test (happy-path, unhappy-path, performance, scalability) their own code because it's much easier and much more time effecient for a Developer to catch his/her own mistakes rather than starting the horrible "rework after test" cycle which can take a whole lot more time than simply taking the time to do it right the first time. That also means that a Developer must have an absolutely clear understanding of not only the requirements of the code they're writing, but what the process that uses the results from that code will be doing.

I know... I know. The thought that most folks will have after reading all that will be "Jeff... You're talking about a perfect world that will never happen." That would be another of those self-prophesizing statements. You've got to start somewhere because if no one starts to make a change, then you're right... it'll never happen. And, yes, I have seen what happens when "the Team" get's it all right... early and less costly developent and deployment, much less stress, and 40 hour work weeks for everyone.

[Rant OFF]


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1212219
Posted Sunday, November 27, 2011 3:40 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Saturday, August 30, 2014 9:14 AM
Points: 1,258, Visits: 13,554
Fantastic article! Andy!
thanks for sharing your ideas and experiences!



rfr.ferrari
DBA - SQL Server 2008
MCITP | MCTS

remember is live or suffer twice!
Post #1212239
Posted Sunday, November 27, 2011 4:21 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 3:23 PM
Points: 5,617, Visits: 25,217
Jeff - you have summed it up perfectly........ I have been in situations as you described, unfortunately going to hell in a hand basket all to fast and way too often .... and yet have been in other situations where although not perfect but with managers / developers working as a team with the results that you know and have stated will happen. In those cases, when all is said and done, one feels as if he ls walking on cloud 9.. the feeling of satisfaction with a job well done is an aphrodisiac know to no others.

If everything seems to be going well, you have obviously overlooked something.

Ron

Please help us, help you -before posting a question please read

Before posting a performance problem please read
Post #1212244
Posted Monday, November 28, 2011 4:13 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, September 5, 2013 3:47 AM
Points: 1, Visits: 24
I deal with this on a regular basis. Great observation!

I mainly see this, not between development groups, but between the standard Business to Business Analyst to Developer flow. Naturally our solution is to "partially" implement poorly understood processes and call them Agile to solve these problems. Now we seem to get to the stress scenario you describe quicker than we used to!

I believe that it all stems from poor communication.....like all all relationships.
Post #1212395
Posted Monday, November 28, 2011 7:01 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
"Stress" is primarily an endocrine reaction to fear or anger.

In this case, it's primarily going to be low-intensity fear, engendered by a threat to project success, as a reaction to unknown vectors entered into a survival calculation. Of course, getting to fear requires passing through antagonism and anger, on a standard emotional curve.

So, the genesis of it hints directly at a cure for it. First, it's a reaction to unknown factors being entered into a survival calculation, so a positive response is gather more data, disseminate more data, and validate new calculations/plans based on that. In other words, communicate, then communicate some more, then communicate some more, with the areas affected.

The single most common cause of both work overload and project failure is doing work twice. The most common cause of that is picking up some piece of work (opening an e-mail, looking at a piece of code, whatever), and not handling it right then and there, but instead deciding to handle it later. Right there, you just made yourself do at least twice the work of analyzing whatever it is you just had to analyze a first time. The second most common cause of double-work is not doing something right the first time, usually in a false sense of "just get it done".

In summary, three very easy ways to reduce work-related stress in most circumstances: Communicate more, and more effectively; Do it right the first time; Don't pick something up, analyze it, then decide to handle it later.

The biggest stress factor after that is fear engendered by people who just plain enjoy spreading bad news. Simple solution, just avoid those people if you can.


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #1212474
Posted Monday, November 28, 2011 8:17 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 2:03 PM
Points: 1,335, Visits: 3,069
Great article Andy! I am also reminded of great saying in our business that I use all the time to throw the stress back into their (BA's and PM's) court. "Lack of planning or fore-thought on your part does not necessarily constitute an emergency on mine". My boss has stopped many deadlines cold because of this.

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1212540
Posted Monday, November 28, 2011 9:07 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 6:39 PM
Points: 1,657, Visits: 4,740
When something like this arisis, it helps a lot when the team's manager acknowledges that he or she is aware of the situation and understands the reason for delay is external and outside the team's control. Even better is when the other team's manager acknowledges the situation. That reduces the sense of unfairness and stress.
Post #1212571
Posted Monday, November 28, 2011 9:16 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, February 11, 2014 1:58 PM
Points: 65, Visits: 259
In my experience, the "other team" stress has usually been worse, because of how blame was distributed. In one case, it never seemed to matter what had happened for most of the project cycle, the blame went to IT for projects being late. The IT manager put up a chart, tracking the dozen or so major milestones that all projects went through. These were the projects that were consistent and similar enough that estimating each step was pretty easy. The chart went up in the break room, so everyone saw it when a project was behind and knew which team caused it. After a while we didn't need the chart.
Post #1212577
Posted Monday, November 28, 2011 9:30 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Saturday, September 13, 2014 7:14 AM
Points: 2,717, Visits: 3,849
I've found the one and only thing that can mitigate the impact of this kind of stress is communication.

I was recently involved in a rather large company acquisition/merge project that involved the entire IT department for a solid year. Toward the end, there were several months straight where overtime became an issue for everyone because of the “im-proper prior planning ….”. The stress level rose to a rather extreme level.

To my point, I was the only manager that seemed to communicate issues that affected timeline to the executives. Although I could have been considered the “sky is falling” guy, the adverse was true. I was praised for my “matter of fact” delivery. No matter the bitterness of the news it was delivered.

It seems all too often that people get stuck in their roles and perceived effectiveness to manage and forget the common goal of the TEAM. Many will not raise the red flag for fear of being seen as this “sky is falling” guy, often causing more stress. We all know that if someone came to you and explained the situation when they know it’s an issue that you’re less likely to take the “it’s not fair” attitude. Wait until it’s too late, then all hell breaks loose.

Put simply, “Communication Is the Key, although it’s often hard to find the lock.”


______________________________________________________________________

Personal Motto: Why push the envelope when you can just open it?

If you follow the direction given HERE you'll likely increase the number and quality of responses you get to your question.

Jason L. Selburg
Post #1212590
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse