Recently, I had a conversation with an acquaintance.  The same conversation I have had at least five times in the past year.

Everyone's sick of their job.  And... they are. so. sure. It's better somewhere else.

I don't judge others' professional choices.  Everyone is walking a unique path in life with a lot of variables.   I just want to dispel one of the myths that I hear absolutely everywhere.  I can't stand it anymore.

This is one of the most common grass-is-greener myths that I constantly hear.  I'd just like to blow this one wide open.  

Where do we get this assumption?   I remember feeling it too, many times - that people in my role at other companies must be walking around in cooler clothes, smiling confidently in their larger offices while they whisk their software delivery through slick, documented, cutting edge internal processes.  Meanwhile, I'm stuck with this crappy company that still has half of its data on a legacy system, overworked middle managers who spend hours in meetings arguing about the definition and the prioritization of everything, and organizational/policy changes every six months, swinging wildly from one end of the spectrum to the other.  We're centralizing.  No, we're specializing.  Oh, guess what?  We're centralizing again.

Wait, you're saying that's your company, too?

Well, if everyone's experiencing this, then where are all the cool kids?

I'm not saying that well developed, tightly executed processes don't exist.  They do.  I just don't think that the typical concept of process health is very realistic.  Take people, for example - do we meet people and judge them, overally, by how 'functional' they are?  The people that I know are very well developed in certain areas, and struggling in others.  One might be a successful professional with infinite patience and generosity, but have an uncontrollable weight problem. Another might be attractive and very healthy mentally and physically - but has repeated financial difficulties.  Often, we overlook these things in people as we make friends and professional connections, because we understand that human beings all have weakness in one or more areas.

Guess who runs companies?

This is my chief process theory:  as long as people are imperfect, then what they make will be imperfect - probably to a higher degree, since our imperfections are compounded.  As soon as we recognize that, then it's easier to see two things.  First, that company with the perfect web site and dazzling advertisements might not be so perfect on the inside (actually, they might have a typo on their web site - keep looking)!  Second, and most importantly - if you're focusing on the weaker processes at your company, you might miss the strong formal execution of everyday things that you take for granted.  Sure, your software deployment might have a 75% production issue rate - and it's embarrassing.  However, what is working?  Do you get your paycheck on time?  Do you receive timely system updates regulated by your IT department / system administrator?  Does the open enrollment period for your benefits come every year at the same time from HR?   These are processes, too, and not everyone can count on those things where they are.   

Not convinced?  You might have to change jobs to find out that your new organization has stellar QA and a 10% defect rate, but their release schedule is so slow to deliver that the market is light years ahead.  Another company's shiny, hip product might be popular, but you'd have to go to work there to find out that they've been cutting corners for so long that the next version is about to break down in ways that no one has ever seen.  Some things can't be explained - they have to be experienced.  But I had to warn you.  I can't stand it anymore.

See another myth busted in the next installment of Lessons Learned.

When my thought process and my output match, one of them is usually redundant.

That's all.

Take the same set of requirements, and ask for signoff from two different people. One says they're fine and signs off. The second returns them two days late, and says he can't sign off until you have one more meeting.  During that meeting, he shows you a copy of your requirements with so many comments you barely recognize it.  He asks you questions like, "Do we really need this one?" and "This doesn't make any sense to me.  Can you explain where this requirement came from?"  and "What is the impact of this change on the downstream system?"

Some people would call that second guy a jerk.

I call him my best friend.

People who genuinely want to solve the problem will give you their full attention and consideration.  And there is no way, people, that we as analysts can get all of the documentation done right in the first draft, alone.  Look at software development - QA is built right in!  Why do we have QA?  Because everyone assumes that the first thing to come out of software development is going to be a big round of bugs.  There is an entire role specifically trained to find and document those bugs.  It's a widely accepted iterative process.  No one assumes that a developer will just write a big batch of perfect code and send it off to deployment.

So let's break down what the second stakeholder actually gave us, and look for the hidden treasure.

1.  He returns the requirements two days late.
This one is good, because you know he spent time reviewing them.  The stakeholder's primary job is.... HIS JOB.  That is usually what qualifies him as a stakeholder.  He does not, in general, review software requirements for a living.  So what you're asking him to do will take time away from his job and will take focus and consideration.  I usually build a margin into my due date so that I give my stakeholders a few days of extra time to return feedback, before I'm late to the PM.

2.  He comments up the requirements document.
This is golden - if you can get it to happen.  Does it hurt for a minute to see your work all scribbled over in MS Word Track-Change red and purple?  Well, it depends on your perspective.

It used to hurt me a lot.  For a while.  Why?  Because my documents were MY DOCUMENTS.  I was emotionally attached to my work.  I was designing, analyzing, strategizing.... I was CREATING.

Then I woke up.

Once I started seeing the documentation I was producing as a service I was hired to perform for the client, I became about 300% more productive and about 3000% less of a pain in the neck to be around when it came time to shape things up as a team.  If the project failed, who lost a ton of money?  My client.  If the project needed more resources, who hired them?  My client.  And at the end of the day, where did my paycheck come from?  You guessed it.  

3.  He asks annoying questions.
This falls into the same category as the understanding that this documentation is the client's property, and I am the guardian.  I am also the guardian of keeping these requirements accurate, and in scope, so these are great opportunities if I recognize them:
"Do we really need this one?" - Possible opportunity to cut scope.  Almost never happens.  It's like a four-leaf clover made of rainbow gold.  Don't get offended.  Cash it in.
"This doesn't make any sense to me. Can you explain where this requirement came from?" - This is another great opportunity to either cut scope or clarify the requirement.  Maybe it's unrelated to the business objectives and therefore out of scope, but was brought up by a secondary stakeholder.  Or maybe it's just poorly written, and if he doesn't understand it, the developer might not either.  He caught that for you.  Maybe say thank you.
"What is the impact of this change on the downstream system?" - You have no idea how much I love stakeholders with a conscience.  It is really, really good when someone has your back in these areas.  If this hasn't been considered, it's a good catch.  If it has been considered and just hasn't been documented (or documented clearly), it's a good opportunity to hash it out one more time from a business perspective (his), which could yield valuable data format or business rule details.

On the other hand, some people are just in the room to get a promotion, and eventually it shows.  Getting a nod and a smile will feel good for a moment, but seriously - it's not going to feel as good in post-production when you're writing midnight requirements for that hotfix.  Trust me.