Trust is something that builds slowly at the beginning of any relationship.
When I start a new project, I often meet new people on the project team. As I get acquainted with these "newcomers," I have to build their trust in me from scratch. Thing is, if they're non-technical colleagues, trust levels typically start from below zero, because of their unfamiliarity or previous negative experience with technical people.
I've been assessing the time-, work-, and emotional-investments made in developing good relationships with the people I worked with -- doing favors, sharing perks, exchanging stories and jokes, socializing at Happy Hour, basically becoming friends. It's taken a lot to get where I am, leveraging collaborative relationships for project successes.
The typical mistrust from non-technical colleagues is an unavoidable obstacle to project success, and takes time and effort to overcome. It may take more than a project or two to build enough trust for a relationship to become fully collaborative.
The more I think about this, the more it reminds me of the Catholic religious concept of Original Sin...
MISTRUST is the Business Anlayst's ORIGINAL SIN, passed down from previous generations of failed technical projects. And a BA must be baptized with a successful project before this Sin is forgiven!
2009-08-24
2009-07-03
Unemployed
On July 1, I joined the 14.7 million unemployed in the United States. I was laid-off as my employer decided to down-size and move headquarters from Oakland, CA to Scottsdale, AZ.
I just turned 47 last month, with a wife to support and an upside-down mortgage to pay off. With what, I don't know. I'd try my luck switching career to music, but that'd be fool-hearty of me, what with a dependent and a long-term debt.
I'll probably lose my house now, but that might be a blessing in disguise. I bought it at $240k 2 years ago, and the county just re-assessed the value at $43k.
I just submitted my unemployment insurance claim yesterday. I've been paying in for so long, it's about time I got something back!
Who knows when I'll find my next full-time job! The way things look, it just might take a year or more.
What to do in the meantime? Network, job-hunt, network, write music, network...
Life can be real simple sometimes! :D
I just turned 47 last month, with a wife to support and an upside-down mortgage to pay off. With what, I don't know. I'd try my luck switching career to music, but that'd be fool-hearty of me, what with a dependent and a long-term debt.
I'll probably lose my house now, but that might be a blessing in disguise. I bought it at $240k 2 years ago, and the county just re-assessed the value at $43k.
I just submitted my unemployment insurance claim yesterday. I've been paying in for so long, it's about time I got something back!
Who knows when I'll find my next full-time job! The way things look, it just might take a year or more.
What to do in the meantime? Network, job-hunt, network, write music, network...
Life can be real simple sometimes! :D
2009-02-10
Lay-off Looming Ahead...
Aaaah, yes! It's that time again, another workforce reduction. I've lost count since 1989 when I started working at my current employer's. I'm about to be laid-off. Ya know, I've heard recently I'm not the only one going through this... :D
Well, I've survived all the past layoffs, and I'll survive this one too -- maybe not with the same organization, but I'll survive somewhere, somehow. I don't let challenges like this become an identity crisis; I think of it as an opportunity to venture into undiscovered country. Got many eggs in my basket and I only need one to hatch.
I'm NOT looking back... NEW HORIZONS, HERE I COME! :D
Well, I've survived all the past layoffs, and I'll survive this one too -- maybe not with the same organization, but I'll survive somewhere, somehow. I don't let challenges like this become an identity crisis; I think of it as an opportunity to venture into undiscovered country. Got many eggs in my basket and I only need one to hatch.
I'm NOT looking back... NEW HORIZONS, HERE I COME! :D
2009-01-09
RIP, Gigi!
I've been rolling with the punches life has been throwing, but this one last week just knocked the wind out of me...
I just had to put down one of my cats Gigi. My wife and I missed our time to have children, so these cats are really family for us.
Gigi always jumped on my lap the instant I sat up in bed in the morning, and she did the same when I came home from work and sat down to relax--every day, without fail. She had the loudest purr I've ever heard, and I've known quite a few by now. I felt a big heart-ache getting up the last few mornings, knowing there'd be no more Gigi to come cheer me up. :(
I usually pride myself in being happy without being rich, but I wish I could've afforded to give Gigi regular checkups so her condition was caught earlier. I HATE being cash-poor right now!!!
Rest In Peace, my beloved Gigi!!!!! :.(
2008-10-21
Waiting for the Right Opportunity for Requirements Management
Over the last 12-18 months, I've come to fully appreciate the importance of waiting for the right business opportunity to introduce Requirements Management into any development project. The value of requirements elicitation, analysis, and validation/verification is not always immediately obvious to business managers.
I've often been pulled into projects mid-stream to fix problems, and whenever I asked for a Requirements document I often get blank stares (like "what's a requirements document?"). Sometimes there's not even a Project Charter, and it'd take several rounds of emails just to identify all the Stakeholders. No matter that some projects have dragged on for 3-6 months without real progress, all the managers still wonder why they need to stop and rethink what they're doing and why they're doing it. They're all desparate to just "fix the problems," and saw any Requirements Management efforts as unnecessary further delays.
What can an analyst do to improve project performance, when even troubled projects aren't being perceived by management as any argument for Requirements Management? I thought that waiting till problems arose would be all it took to bring Requirements Management into projects, but it hasn't turned out that way. Hmmmm...
I don't think my company's unique in this pattern. Unless a company develops and sells software, it's business managers wouldn't have much exposure to IT Business Analysis, and probably no knowledge of what Requirements Management is in the first place. For my company, the situation is exacerbated by the fact that the IT function has been drastically downsized, leaving a knowledge/skills "vacuum" that pulled me from web/elearning development into business/systems analysis for the Global Campus these last 3-5 years.
Try as I might, my marketing efforts for Requirements Management fell on deaf ears. It wasn't until very recently that I "saw the door open just a crack," after 2 devlopment projects in a row took months instead of weeks to complete, and one executive decided that something should be done and allowed me to spearhead some process improvments. Not exactly appreciation for the value of Requirements Management, but for me I think it'll have to be close enough. :D
For me then, the Right Opportunity turns out to be an explicit request from a business executive to fix ongoing problems, NOT the mere fact that problems arise in projects. The wait's been far longer then I would've preferred, but then again that's probably just my anxiousness to apply new knowledge.
I'll do my best to sell the boss and the team on Requirements Management, even if the only perceived benefit were to minimize communication breakdowns. But...
Is this always the way Requirements Management needs to be introduced to a team, to wait for the leaders to fail before helping them? I wish they had started listening to me before the projects went south! I could've helped save the two projects that failed!! But then again, I realize now I would've been just inflicting help where it's not wanted.
Please Comment! :)
I've often been pulled into projects mid-stream to fix problems, and whenever I asked for a Requirements document I often get blank stares (like "what's a requirements document?"). Sometimes there's not even a Project Charter, and it'd take several rounds of emails just to identify all the Stakeholders. No matter that some projects have dragged on for 3-6 months without real progress, all the managers still wonder why they need to stop and rethink what they're doing and why they're doing it. They're all desparate to just "fix the problems," and saw any Requirements Management efforts as unnecessary further delays.
What can an analyst do to improve project performance, when even troubled projects aren't being perceived by management as any argument for Requirements Management? I thought that waiting till problems arose would be all it took to bring Requirements Management into projects, but it hasn't turned out that way. Hmmmm...
I don't think my company's unique in this pattern. Unless a company develops and sells software, it's business managers wouldn't have much exposure to IT Business Analysis, and probably no knowledge of what Requirements Management is in the first place. For my company, the situation is exacerbated by the fact that the IT function has been drastically downsized, leaving a knowledge/skills "vacuum" that pulled me from web/elearning development into business/systems analysis for the Global Campus these last 3-5 years.
Try as I might, my marketing efforts for Requirements Management fell on deaf ears. It wasn't until very recently that I "saw the door open just a crack," after 2 devlopment projects in a row took months instead of weeks to complete, and one executive decided that something should be done and allowed me to spearhead some process improvments. Not exactly appreciation for the value of Requirements Management, but for me I think it'll have to be close enough. :D
For me then, the Right Opportunity turns out to be an explicit request from a business executive to fix ongoing problems, NOT the mere fact that problems arise in projects. The wait's been far longer then I would've preferred, but then again that's probably just my anxiousness to apply new knowledge.
I'll do my best to sell the boss and the team on Requirements Management, even if the only perceived benefit were to minimize communication breakdowns. But...
Is this always the way Requirements Management needs to be introduced to a team, to wait for the leaders to fail before helping them? I wish they had started listening to me before the projects went south! I could've helped save the two projects that failed!! But then again, I realize now I would've been just inflicting help where it's not wanted.
Please Comment! :)
Subscribe to:
Posts (Atom)