There's been some changes within our department where the BA role is now under the "umbrella" of the project manager. The BA roles were reduced to one so now the PMs are taking on the role of BA (including writing BRDs) for small scale projects. While I get that some of the PM skills can be translated to BA I have not ever had to write BRDs or be responsible for facilitating and leading requirements meetings. I was sent to one training class (online) that was about 4 days long. Now I'm being asked how long will it take me to "get up to speed". The former manager of the BAs is no longer responsible for BA work, the one BA transitioned to PMO is new too and my manager does not have BA experience. What is a fair answer? I am also being asked what it will take for my success and that I can answer that I should have coaching and support from an "expert" BA. I'm a bit lost here and looking for input/suggestions... Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
There are way to many parameters for this to be a 1 or 10 answer. I've worked with 'business analysts' who were in the position for years that did a worse job than a person not even in a BA role. It like a musician, almost everybody can learn to play an instrument but only a few can be called musicians because they do not learn like a parrot, they also understand. Somebody with good basic skills (analytic, inquisitive, big picture thinking etc, etc.) can become a good BA within a matter of months, experience in how to facilitate, elicit, interview etc. if they have never done its will make them better over time. Saving Changes...
I'm thankful that I was a BA before a PM. It was easier to transition to PM work after being a participant in projects and observing the PMs. PMs typically don't have time to observe BAs.
If you are just "gathering" requirements (a term I dislike), it shouldn't take too long to "get up to speed". But if you need to be a true BA, that is a journey that can takes years and lots of training.
There is an art and a science to identifying and eliciting requirements, understanding the difference between functionals and non-functionals and how the non-functionals can kill your project. Ferreting out the true stakeholder needs, not what they think they need, is difficult. Documenting requirements that follow the IEEE standards is a skill and so is understanding how the nuances of language can cause misunderstandings and misinterpretations.
You asked for input and suggestions, so here are a few:
Luckily, you are in the Chicago area. You have an excellent training resource available. Group Atlantic is the company that trained me when I was a new BA and their "Right Requirements Right Now" workshop is excellent. You will be well prepared after taking their workshop.
Download a copy of the IEEE standard 830. It's old, but has very good information. Section 4.3 describes the development of requirements. Skip the parts about formatting a spec; you'll use whatever template the org already has.
Join the IIBA Chicago chapter and network with the BAs. They have some very interesting speakers.
I recently authored an article on a very useful analysis technique. See section 3.1 in this newsletter: https://www.ppi-int.com/ppisyen67/
Good luck! Let us know how you are doing. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
^ Bob - Great comment and insight. Saving Changes...
Kurt KochProject Manager, Pediatric Clinical Integration| University Hospitals Rainbow Babies & Children's HospitalWadsworth, Oh, United States
In my previous position, the PM's were de facto Business Analysts as well. It made for a difficult situation, as most of us were not formally trained in the discipline. I'm not sure how you define "good". Its my opinion that one should be formally trained in business analysis to be effective in it. That would be the beginning of my answer to Management if I were asked how long it would take to get up to speed... Saving Changes...
Christina MixonDirector of PMO| Altar'd State, Inc.Maryville, Tn, United States
In my team, the project managers are required to do BA work for our projects. It is a challenge especially if you are responsible for a wide range of project types (e.g. collecting requirements for a development agile project is a lot different than a waterfall compliance project). Your best "get up to speed" approach will probably rely on previous project artifacts or an existing library of templates to help structure what information you need to identify. Did the previous BA team have documented processes? Those processes can help you figure out what the organization expects from a BA experience.
When a manager asks me a "get up to speed" type of question, especially around new or different duties, I provide two answers: 1. Minimum viable -- I can perform basic job duties with basic proficiency with xx resources by xx date. 2. Ideal state -- I can be an expert with access to xx advanced resources (live training, external consultant mentoring, etc) and with xx amount of experience based on the type of work our team does.
In a situation where you feel completely unsure how to answer that question, ask your manager to review the situation after your first BA effort. If you have a good relationship with the former BA group, ask someone to look over your work after the first attempt. If you don't have someone internally to ask, maybe visit your local PMI chapter to connect with someone locally who can offer some mentorship. Once you know what you missed, you will have a pretty good idea of what gaps in training you have to reach your minimum viable and ideal states.
Jean A. MarshallLead Consultant| Brij Consulting, LLCCabot, Pa, United States
The best advice I got from a CPA early in my career is to define the business plan and understand the project. Lately as business is using more agile methods the workflow and the story impact of the project is losing a kind of metric cohesion. Also, the way the project is funded is losing that PMO approach and becoming too broad brushed. Honing in on KPI's, Rates and Portfolio Performance should eventually fall into place again, when their Productive Assets become Cloud Performers. A financial engineering strategy to develop the right kind of PERFORMANCE METRICS AND MEASURES exists in the concept of VARIABLE RATE DEMAND. The economic model needs to emerge and everything will be more productive around it. Saving Changes...
Rebecca many nice interventions here all very good. It is clear there is no single answer, and it all depend on your experience and many other factors.
It will be constructive experience, keep us posted. Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
Alas ! So many organizations underestimate the importance of a Business Analyst . A Business Analyst represents the Business needs and is a very specialized skill-set to have. A good Business Analyst requires years of experience working in different industrial sectors. The skills of Business Analysis and Project Management are transferable but one cannot exist without the other. It is extremely difficult for a Project Manager to be a Business Analyst at the same time because that will cause conflict of interest. For successful project outcomes, Both Business Analyst and Project Manager (Separate People) must work together and maintain specific areas of Focus (project Scope for Project Manager vs Product Scope for Business Analyst)
A Business Analyst Must be exceptional communicator and facilitator Must be able to successfully hold an audience of multiple stakeholders and balance their needs Is a "Big Picture"professional who understands the Business Architecture and Solution Landscape of the organization Needs the ability to thoroughly understand and write Business Cases, if required May well be recruited before the Project Manager on Initiatives Needs to understand Business Strategy and how the solution fits into the overall Business Strategy. Is responsible for Eliciting, documenting and refining Business Requirements- both Technical and Non Technical Must be a stickler for writing and insisting on Testable Requirements Must own the Requirements Trace-ability Matrix and understand the life-cycle of requirements from Inception to Handover Needs to keep Building and maintaining productive Relationships with Stakeholders Is a gatekeeper for Customer Quality Expectations (Prince 2 speak) Is expected to understand the Business Process and what Business Value is being achieved Has the acumen to decouple Technical Jargon and Business Speak and understand how to translate one to the other without losing the meaning. Needs to keep the project focused on Product Scope at all times Is an interface between the Product Owner and Product Development team in Agile speak
If I was a Project Manager and did not have a Quality Business Analyst on my project , I would try my level best to justify the need for one Saving Changes...
Jean A. MarshallLead Consultant| Brij Consulting, LLCCabot, Pa, United States
You asked a complex question and my first answer is that your maturity as a business analyst is being interrupted by changes in the field. My second answer is related to how to bridge the gap between your experience and the requirements that are being put upon you. Always TRUST in servant leadership. Move forward and bridge your knowledge with the knowledge of others and make a path as a TEAM. Look for mentorship in the older or experienced people who have been around the block. Start to look for the MODEL (there may be more than one, even mini-models) that build into the future. Saving Changes...
