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! :)

Who's more unpopular? BA or PM?

I asked the trainer at a recent Business Analyst training session, "Who's the most unpopular person on any software project? The Business Analyst or the Project Manager?" Without hesitation, she answered, "Project Manager."
I thought that was interesting, since I figured the BA probably has to ask everyone a lot more questions than the PM. There's always a risk of sounding stupid.
On the other hand, the PM has to keep the project progressing forward, on time and on budget, which the BA doesn't worry about. That probably guarantees unpopularity.
I guess it comes down to asking the RIGHT questions as a BA. This probably decides if I or the PM would be the more unpopular person on a project.
What are your thoughts? Comment please! :)

Lost Processes: A Formula One Example of Brain Drain

At many organizations I've worked with as a contractor, more than a few directors/managers refused to document business processes, saying "we're too busy to stop our work just to write down how it's done."

While workload pressures are real, the risk of serious brain drain from lost processes is also equally real, though not as immediately threatening. The following story shows the real damage of brain drain from lost processes, when workers change jobs/roles.

Surprisingly, this comes from F1 Racing Magazine (f1racing.com)! In a recent interview with Patrick Head, Engineering Director of the former Formula One World Champion team Williams [now Williams Toyota], I saw a Formula One example of brain drain from lost processes.

There were several factors in Williams' recent loss of engine partner BMW -- a critical setback in competitiveness -- but Head was shockingly frank about one in particular:

Some people had reached retirement age and so retired, and the people put in their place were much younger and didn't necessarily have all the method and procedure given to them in written form -- so a number of approaches we'd developed over many years departed with the people that retired and were not suitably replaced.

Willams BMW had arguably the most powerful engine on the grid in 2006, contending for the Championship as a top-3 team. After BMW left in 2007, the team dropped into the midfield and didn't win a single race.

So, I guess the relevant question for all businesses is, how much productivity do we sacrifice for process documentation, in order to properly manage or minimize risk of this kind of brain-drain damage?

Your Comments, please! :D

"Never Let a Good Editor Go" article on BATimes.com

"When documenting systems, quality assurance requires quality support people, especially final content editors. They are worth their weight in gold-edged certificates. If you are part of a large project that has a very large documentation aspect, learn to nurture, develop, and retain a good editorial staff, and do not forget to keep everyone's skills current on the tools you are using!..."
Read more of David Egan's article on BATimes.com:
http://www.batimes.com/index.php?option=com_content&task=view&id=179&Itemid=1
[full story requires registering with batimes.com]

I've seen many IT projects in many companies suffer terrible UATs and roll-outs exactly because end-user documentation was inadequate. Both business and IT execs are prone to cutting user-training from system rollouts [to "save money"]. They think a user guide written by the programmers can replace this training. Well, I don't think anyone needs to read this article to know how bad user guides can be these days. Good programmers don't really make good editors or writers. :D

"Where Business Meets Jazz" article on CLOmedia.com

It was great to find this article by Lindsay Edmonds Wickman on CLOmedia.com last month! The concept really rings true for me especially, connecting my two occupations together.

Here's a brief excerpt:
"'For most of the 20th century, the idea of autonomy was you win, they lose. That’s how you did it in business. Well, that doesn’t work anymore, and in jazz, it never did. The idea of autonomy in jazz is based completely in a mindset of inclusion, and that’s because, in the jazz ensemble, we are constantly transitioning back and forth between a position of leadership and a position of support. The leadership actually makes it possible, through the way they relate, to be instantly influenced by the reaction of the supporting team,' [Lindsay] said."

Read more at...
http://www.clomedia.com/executive-briefings/2008/January/2058/index.php

Vision for Learning & Development

I was asked to participate in developing a Vision Statement for a training department, but I just couldn't get started without feeling I was just "dreaming up stuff in a vacuum." My head was overflowing with assumptions I couldn't possibly validate, so I had to shrink the scope of my personal vision for a possible upcoming presentation...
The video below is a Vision, not a Vision Statement. This way I've hopefully limited assumptions about the Business to just one: "The Business needs SPEED TO PERFORMANCE."



The one political risk in the message behind the video is the classroom instructors' potential fear of exclusion/extinction. I wanted to highlight and maximize the difference between the slowest way and the quickest toward business performance, so obvously the classroom clip was required in front and a sci-fi clip was required at the back. Truth be told, I'm neither a classroom-hater nor a technology-lover. ;)
I'm certinaly not implying that classroom learning per se is outmoded; I still strongly believe that the classroom environment is a must for certain types of learning. If we had the budget, I'm wagering we'd be rolling out 3-5 times more classroom training, but the business reality I'm seeing is very different. Classroom training's just... very slow!
Okay, Learning Professionals out there: Any questions/comments/ideas? I wanna know please! :D

Video clips were extracted from two highly-entertaining movies below. Rent them again! I enjoyed them both thoroughly. :)
Ferris Bueller's Day Off* [Copyright 1986 Paramount Pictures]
The Matrix [Copyright 1999 Warner Bros Pictures]
*The movie's in color. I just made the clip here b/w to give the 2nd clip more dramatic contrast.