November 27, 2011 at 8:47 am
Comments posted to this topic are about the item Stress – It’s Not Fair
November 27, 2011 at 10:27 am
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.:-P
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. :w00t: 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
Change is inevitable... Change for the better is not.
November 27, 2011 at 3:40 pm
Fantastic article! Andy!
thanks for sharing your ideas and experiences!
November 27, 2011 at 4:21 pm
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.
November 28, 2011 at 4:13 am
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.
November 28, 2011 at 7:01 am
"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
November 28, 2011 at 8:17 am
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. ...:-D"
November 28, 2011 at 9:07 am
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 28, 2011 at 9:16 am
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.
November 28, 2011 at 9:30 am
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[/url] you'll likely increase the number and quality of responses you get to your question.
Jason L. SelburgNovember 28, 2011 at 9:39 am
Nice hot topic button Andy. If you are already under a fair amount of stress, adding this outside stress compounds the problem. Being able to communicate the cause of this secondary stress (and report reasons for delay) while keeping emotions at bay is difficult. Nonetheless, it is an important thing to learn.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
November 28, 2011 at 11:06 am
WolforthJ (11/28/2011)
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.
Personally, I'm not a big fan of this kind of public display to get a point across, because it destroys team building and tends to promote a pay-back atmosphere (us vs. them) in the department. I think there are other more tactful ways to deal with this, even if it did turn out to be effective. You can motivate people in other positive ways than mounting signs in the break room for EVERYONE to see (including the janitors and vending machine operators) IMHO.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
November 28, 2011 at 11:32 am
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".
That is a great point. Try to finish something now that you've already started. Don't go 3/4 down a task and say "I'll finish it up next time", even if it's Friday afternoon. Or maybe especially because it's Friday afternoon 😀
Ken
November 28, 2011 at 11:51 am
ken.trock (11/28/2011)
.....That is a great point. Try to finish something now that you've already started. Don't go 3/4 down a task and say "I'll finish it up next time", even if it's Friday afternoon. Or maybe especially because it's Friday afternoon 😀Ken
it's true and very common in most people!!!!
November 28, 2011 at 1:18 pm
ken.trock (11/28/2011)
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".
That is a great point. Try to finish something now that you've already started. Don't go 3/4 down a task and say "I'll finish it up next time", even if it's Friday afternoon. Or maybe especially because it's Friday afternoon 😀
Ken
Actually, starting something Friday and finishing it Monday is a good way to end up with your mind locking on the incomplete action all weekend, thus ruining any chances to pay real attention to the weekend at all. Essentially, you get to work the weekend for free, off the clock, even when you're asleep, because your mind will still have pieces of that work stuck in it. So, finish what you start, if you can, and finish as close to when you start as 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
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply