I thought it might be interesting to relate how a BA influenced me when I was a project manager I had started a job as a project manager in an organization in which the project managers, almost all of whom rose through the technical ranks, were expected to gather (yes, gather, not elicit) requirements. There was no formal definition of requirements, let alone any pretense at doing business analysis. Project managers all had their own way of documenting requirements, most of which was brief and folded into the design specification. Each project manager was expected to meet with SMEs, but not spend too much time. They weren't productive, of course, unless they were working on "the important stuff." I was lucky. When I started at this company, I was "given" the organization's first BA as an experiment to determine if this new position of business analyst added value to the project and to the organizations.
I choose the word "given" carefully. The powers that be said something to the effect of "Starting on Monday, Kristin (not her real name) will join your team. Let's see what she can do for you. Good luck." I'm not sure what they were expecting. It turned out, however, that Kristin was a gift, indeed. She had many talents, one of which was to subtly but effectively give me work direction and she quickly became my trusted advisor. Here are just a few examples.
A new team member, Joanne, showed up unannounced and unexpected one day to work on our project. The project was undefined and the only thing we knew about it was its name and the name of our sponsor. Well, here came Joanne out of nowhere, asking where she should sit and what she should start working on. She said that she had seen a yellow sticky on her phone directing her to join our team (this is not just urban legend. It really did happen). I was at a complete loss. I was about to ask her to wait until we had more definition of our project, but Kristin gently urged me to find a spot for Joanne, and suggested that she start analyzing the current documents and interfaces. This work was important would keep her productive while we tried to get the project more structured.
Another instance occurred at a cross-functional requirements meeting. Several SMEs were unhappy about the direction of the project. Conflict arose between two business areas, both of which were vital to the success of the project. I was about to make a decision in favor of the area funding the project when Kristin suggested that perhaps I should meet with the sponsor, which I did. Such advice, while in all honesty was not completely welcome at the time, turned out to be well-advised. It didn't take me long to realize that she was absolutely right. The decision was not mine to make.
Yet another time I was ready to recommend a change in project scope. One of the business SMEs requested an enhancement, insisting that he could not use the system unless this enhancement was added to the project. Kristin researched alternatives and suggested that the request had some pretty significant business and technical impacts. She recommended that the request be its own separate project. She convinced me that trying to add it to the current project, even if the sponsor authorized it, would not only cause the baselined scope, time and budget to change dramatically (my main concern), but more importantly that the request didn't align with the business problem or project objectives we had defined. She explained this to the requester, who withdrew the request. I updated the project sponsor with the good news.
One last example; It was Kristin who taught me the importance of defining the business problem. I had always documented the project solution without much thought given to what problem it was solving. However, one time a sponsor wanted "just a little enhancement" on a project. After Kristin convinced me of the benefit of defining the problem, we realized that the enhancement would not solve the problem. Kristin was able to convince me and I was able to convince the sponsor that to solve the problem the current system needed to be scrapped and replaced.
These are just a few examples. It seems that she constantly persuaded me to take some kind of action. Her suggestions were always based on her experience and research, as well as her good analytical and critical thinking skills. I quickly came to trust her suggestions. Although I didn't always want to listen to her advice, I almost always did and almost always with a good outcome.
This article was originally published December 22, 2009
Don't forget to leave your comments below
Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth's speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide - Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide - 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner's Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at email@example.com