Raising the Business Analyst Bar to Higher Levels
Schedule of Events: October 28th, Chapter Meeting November 4th Webinar November 18th, “Virtual“ Chapter Meeting December 7th, Chapter Holiday Social Event!
CBAP Study Group Every Wednesday at Noon Contact us to get the call in details:
Volume 1, Issue 6
October 20th, 2010
A Non - Theoretical Practitioner’s Perspective on Process Engineering —Chapter Meeting On October 28th! What this session is not: It is not about the latest software toolset It is not theoretical This session will provide a foundation that will allow you to build your personal process development skills that are transportable to new assignments and/or employers. We will: Raise awareness of Process & Procedure development elements Examine the importance of process thinking Enhance Process & Procedure investigation and discovery skills Examine the importance of sequential thinking
Gary L. Goforth, PMP, PMM
Emphasize ―aggressive‖ listening Examine the importance of interview techniques
Inside this issue: Going Virtual West Wing
Member Highlight Structuring Lessons
Chapter Holiday Party!
Requirements as Part of SDLC
IIBA Membership Feedback!
Our Sponsors Chapter Volunteer
Gary L. Goforth, PMP, PMM Education: Oklahoma State University & University of Southern California Professional Experience: Thirty years working in the Aerospace & Defense Industry. In addition to five years as an entrepreneur which resulted in hundreds of Consulting Engagements for Process Improvement Workshops. A sample of my client list includes: NASA – International Space Station, United States Air Force, United States Navy, General Motors, Northrop - Grumman, Hughes Aircraft, Direct TV.
Project Manager and Business Analyst: Are They One or Two Roles? - sponsored by Watermark Learning When: Thursday, Nov. 4th Time: 1:00 - 2:00 p.m. CST Cost: Free Presenter: Elizabeth Larson, PMP, CBAP, CSM Registration Link: https://www2.gotomeeting.com/register/421469418
Free Webinar -
A question many organizations have recently asked is whether or not one person can be both a project manager (PM) and a business analyst (BA) on the same project. This presentation explores the pros and cons of separating these two important project roles and discusses some of the key issues that need to be considered when making the decision to combine them. Finally, it looks at how each role can function effectively on a variety of different kinds of projects, what the handoffs are, and how these two roles can work together to best meet project objectives.
Chapter News / From the West Wing Page 2
Volume 1, Issue 6
IIBA Fort Worth Chapter—Going Virtual in November! The Fort Worth IIBA Chapter is trying something new! Our November 18th Chapter meeting will be VIRTUAL! If feedback and participation is well received by our members, the Chapter Board would like to conduct the meetings virtually on a quarterly basis. Your chapter board is always looking for new ways to bring you value. Make sure you participate and provide feedback if you feel this is the right solution for you! This is a trial and feedback is necessary to assure the chapter is aligning to our community needs. Why go virtual? So many of us are challenged balancing work and family that there is often no time left for time to invest in ourselves. Although we all know if we don’t, the others will suffer in the long run. Take time out to interact with other local analysts that are dedicated to bring industry topics and top leaders to help us all continue to develop our analyst skills and deliver value to our customers and employers. Going virtual removes the barriers of location and makes it easier to juggle other commitments. All you need is internet access and you are there!
Virtual Meeting All you need is internet access!
Benefits: Access to top industry talent for presentation materials You pick the location—your home, coffee shop, office, the patio, endless possibilities. Create time for you—You could be participating while the kids are playing a game or you’re making dinner.
The West Wing: A message from Your Chapter President Howdy Cowtown BA Professionals! How Y’all Doin?
Ken Alexander Your IIBA Fort Worth Chapter President
In support of our community, All are welcome to participate in our Fort Worth IIBA Chapter Meetings, Webinars, Workshops, Special Events and more. See what we are all about!
I am excited about being a part of the local Fort Worth Chapter IIBA group. It is a pleasure to meet and chat with each of you at every meeting. I ―dream‖ of high accomplishments with this chapter and I believe that we will achieve many goals and enjoy many successes. As our Board of Directors has started planning for our next year goals, I am reminded of a quote by Robert K. Greenleaf, ―Behind every great achievement is a dreamer of great dreams.‖ We will be planning for newer and greater things to happen in the near future and we will need your help and participation. I know that many of you feel that you are being pulled in many directions already. But we want you to be involved and help make the dream and vision for this chapter come to fruition. There will be opportunities for participation on committees and to become active on the Board of Directors. We will be voting during the October meeting to update our bylaws to start a board of directors shadow program. Stay tuned as more information is published. If we all dream of what can be; there will be unbelievable and unspeakable achievements for the Fort Worth Chapter IIBA. I continue to look forward to seeing you all at the monthly meetings and other local functions. The Fort Worth IIBA is an avenue for all the BAs in the DFW area to come together and support one another, as well as get exposure to great networking, quality training, and informative lectures. You are welcome to come out and participate in all of the Fort Worth IIBA activities and please let us know what we can do to make Your Fort Worth IIBA Chapter more beneficial for you.
Education & Professional Development Volume 1, Issue 6
Member Highlight: Rob Dubois Rob has over 20 years of IT experience. He has worked and consulted in various industries ranging from Aerospace, Retail, Telecommunications, Healthcare, Emergency and Operating Room technologies, Transportation, and Cement manufacturing. Rob has worked with customers on numerous levels from development teams, Directors, VPs and C Level executives. Rob has led several near-shore projects as a PM and BA with teams in Argentina for a Fortune 50 corporation. Rob is currently working at Lockheed Martin where he is a member of the IT Program Management Office working with Jewell Griffith and Lynn Lang on defining, educating and establishing a BA methodology and discipline within Lockheed Martin Aeronautics.
Rob grew up in Arlington where he attended both TCJC (now TCC) and UTA and was in and out of school as his career path changed and his family grew and became active. Rob lives in Arlington with his wife Rhonda, has four children, 1 boy and 3 girls. Rob and his wife were recently blessed with their second grand daughter and are expecting their first grandson in December. Rob is active in the IIBA Fort Worth Chapter and serves on the Newsletter Committee. He has conducted several presentation at Chapter Meetings. Most recently, he presented the BA Role and Elevator Pitch at the July Social Event. Did you know that Rob spent a week in the jungles of Nicaragua with the Texas Baptist Men mapping via GPS in native Moskito Indian villages?
Structuring Lessons Learned Discussions—by Mark Monteleone Lessons learned is a summary of the valuable experiences that team members walk away with from a project and may evolve into best practices. As business analysts, we need to collect lessons learned at all stages of a project – not just at closeout. In collecting these lessons learned, the business analyst (BA) needs to use an effective process for catching all aspects of the lessons. Just asking at the end of each project stage, ―Does anyone have any positive or negative lessons learned?‖ provides limited responses. The BA needs to structure the team discussion to ensure all aspects of lessons learned are analyzed and captured from resolved problems and successfully managed risks.* One possibility for this collection process is an innovative adaptation of fishbone diagrams commonly used for root cause analysis. The BA can use the following process to structure team discussions: Lessons Learned Collection Process Step 1. Step 2. Step 3.
Provide a list of all resolved problems or successfully managed risks addressed during this stage of the project. Unresolved problems should also be considered at closeout. Draw a fishbone diagram (Figure 1) with eight ribs protruding from the spine. At the outer tip of each rib, write one of eight potential aspects from Table I:
Table I. Potential Aspects Staff
Education & Professional Development Volume 1, Issue 6
Continued… Structuring Lessons Learned Discussions—by Mark Monteleone Step 4.
Write a resolved problem or successfully managed risk from the list in step 1 at the head of the fishbone (Figure 1).
Ask, ―What aspects were involved in resolving the problem?‖ For each aspect involved, determine: Positive Lessons Learned ―What would have prevented this aspect from contributing to the problem?‖ ―What successful corrective actions were taken to prevent this aspect from contributing to the problem in the future?‖ Negative Lessons Learned ―What unsuccessful corrective actions were taken to prevent this aspect from contributing to the problem in the future?‖ OR Ask, ―What aspects were involved in successfully managing the risk?‖ For each aspect involved, determine: Positive Lessons Learned ―What successful risk responses lowered threats or prevented threats from developing into a negative event? Was the threat probability and/or impact lowered?‖ ―What successful risk responses heightened opportunities or ensured opportunities were realized as a positive event? Was the opportunity probability and/or impact heightened?‖ Negative Lessons Learned ―What unsuccessful risk responses were attempted on threats and/or opportunities?‖ Step 6.
Iterate step 4-5 for each resolved problem or successfully managed risk until the list is exhausted.
Example One: Step 1. Provide resolved problem – User Resistance to Solution Steps 2/3/4. Draw fishbone diagram (Figure 1) with resolved problem stated Step 5. Team discussion points to Staff aspect What would have prevented….user involvement in solution development What successful actions………establish user role on project team
Education & Professional Development Volume 1, Issue 6
Continued… Structuring Lessons Learned Discussions—by Mark Monteleone Lesson Learned - Establish solution champions within the user group to promote the project by including users in solution development thus establishing buy-in Example Two: Step 1. Provide successfully managed risk – Lack of stakeholder meeting attendance Steps 2/3/4. Draw fishbone diagram (Figure 1) with successfully managed risk stated Step 5. Team discussion points to Management aspect What successful risk responses.......project sponsor invites stakeholders Lesson Learned - Utilize project sponsor commitment to motivate stakeholder meeting attendance through direct sponsor communications Since this process provides a visual and reuses a familiar technique from root cause analysis, the BA should find this process easy to introduce and utilize with the project team. However, the BA may opt to have someone else facilitate the discussion; this will allow the BA to fully participate in the content of the discussion. After the collection process, the BA should follow-up with the Center of Excellence to validate the lessons learned as new entries in the organization’s Best Practices database. *Unresolved problems are excluded from the process since they are still works in progress or considered at the end of a project as outstanding issues. Unsuccessfully managed risks (threats) are realized as problems and may be addressed in this process as resolved problems. Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSMTM) and Certified Scrum Product Owner (CSPOTM) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – email@example.com.
IIBA Fort Worth Chapter Holiday Party BA Cowtown Special Event You Will NOT Want to Miss!
December 7th Holiday Social Event!
The Special Event Committee would like you to Hold Tuesday, December 7th Open for the Annual Holiday Social Event! Yes, the Holidays are just around the corner and there is no time like the present to start to plan. The Chapter will be promoting Cowboy Santas and coordinating a Toy Drive. Many more fun and exciting details to come in the November Issue of your Cowtown Connection Issue. Cowboy Santas is a non-profit program that provides toys to children from low-income families during the holiday season. Cowboy Santas Program Inc. serves the entire Tarrant County including the cities of Fort Worth, Arlington, Bedford, Mansfield, Hurst, North Richland Hills, Forest Hill etc. In 2009, through the kindness of our community, our sponsors and volunteers and individual donations, our program was able to distribute toys to 12,323 children and more than 5,000 families.
Education & Professional Development Volume 1, Issue 6
Requirements as Part of the Software Development Lifecycleâ€”by Rob Dubois Requirements (Business and Functional) are the binding communications and agreements between all stakeholders on a project. Software requirements for IT solutions are no different than blueprints for a house. The blueprints and architecture renderings tell the client/customer what the house will look like, how it will be organized, and what and where everything will be when completed. This same document(s) is also used to communicate to the sub-contractors (plumbers, electricians, painters, concrete, framers, roofers, cabinet makers...) what is to be done and conveys the concepts of the client into concrete terms. This same document (blueprint or requirements) is also, what will be used to effect changes against, and is used during the project life cycle and at completion for sign-off/acceptance. The software construction industry (if you will) is still in its infancy when compared to other industries and has fought against the adoption for this need of a blueprint or requirements that the construction industry depends upon for its very existence. This resistance is not only expressed by the developers and the customers in some cases, but also expressed by management through their lack of action and or support. There is still today a push to begin working on the architecture or coding components, assuming we already know something of what is to be expected as part of the project. It is as if to say that if the development team is not immediately busy on a project then we are wasting time, money and resources.
1. The Problem Is Two Fold 1.1 Philosophical Value
So what we have is a two fold problem. We must philosophically agree that requirements are of tremendous value and vital to the success of any project. I can find a zillion articles and industry experts and experiences proving this point. This philosophical agreement must be expressed by management and everyone else, not as lip service but expressed in accountable actions. Requirements are not the stick in the mud that slows a project down. They are not something that is overkill or states the obvious. To many times I have seen what was thought of as simply known items that turned out to be problems because what was communicated was interpreted differently, implemented differently, or just a poor assumption. A problem easily solved by requirements definition. We also tend to place value on what we believe are good relationships with our clients/customers. As a result, we become lax or relaxed in how we work with them. The relationship suffers. Because the bottom line is, no matter how good your relationship is, or you believe it is, the client/customer must be consulted and treated in the same manner and ultimately accepts the solution based on their expectations. If the client/customer did not receive what was expected then the fault lies with the software provider. It is the responsibility of the Project Manager and Business Analyst to manage their client to ensure that what is being asked for and eventually provided is understood, agreed to and documented. Anything less than full attention to this responsibility is a recipe for project failure or hardship. The Project Manager and Business Analyst are the two roles with the direct face-to-face meetings and interactions. The rules of engagement must be clear. They are not harsh, condescending or introduce difficulty in execution, but are done as a professional respect for the client/customer, his/her time and his/her money. The acceptance process of the final product or deliverable begins with requirements and not with the final delivery. The acceptance process spans the full lifecycle of the project. Development Team Resistance Developers tend to resist requirements because it does several things that make them un-comfortable. It is perceived that requirements take away some control or ability to code as they see fit. Requirements also hold developers accountable which is also resisted. Finally, requirements tend to indicate that development is not as important a role because you have told me what to do. These issues are all a result of misperception, poor management and communication. Requirements when done correctly communicates to the developer what to do and in a very high level how something has been requested to function, but how that requirement/functionality gets implemented is still up to the developer. Holding developers accountable is not only good for the developer, but also the project. To this point, it helps protect the developer from chaotic changes and provides a stable known work structure. Finally, developers as end users of the requirement information should participate in the review and acceptance of requirements. Of all the artifacts produced, requirements affect the most stakeholders and therefore are an artifact with the most customers or users of that information than any other. As a result it is critical that all stakeholders receive that information in the format that they can use to be successful in their role on the project. It is the responsibility of the analyst to ensure that the requirements contain the information in the format needed by each stakeholder or user of the requirements information. This information and the recognized value is what drives the second problem.
Education & Professional Development Volume 1, Issue 6
Requirements as Part of the Software Development Lifecycleâ€”by Rob Dubois 1.2 Artifacts of Information and Communication
The elicitation, creation, maintenance and management of requirements information and artifacts is probably one of the least understood and immature processes in the software industry. As companies and universities, diligently train technologist in how to solve complex problems via architecture, hardware, and various software languages, the role of the analyst and requirements process is typically left up to chance. More times than not the analysts were developers who have been caught up or tasked with the analyst role. In past years you did not see formal training on how to interact with a client/customer to extract the true problem, their thoughts and desires and concepts. You did not see training on how then to best capture those thoughts, desires and concepts in some concrete artifact such use cases, storyboards, screen flows, textual statements, prototypesâ€Ś Finally, you did not see training on how to manage a client/customer with respect to requirements. Changes are underway and several companies and universities now offer this type of education for the Business Analyst. Adoption by companies to recognize the value, undertake such training and then to allow the tools and techniques to be applied is slowly beginning to accelerate. To date companies utilize numerous methods for capturing requirement information and how that information is then shared with their stakeholders on the project. I have seen PowerPoint utilized, Visio, MSWord, and various tools that are emerging into the market. As I mentioned above, the informational needs of the stakeholders in the format that they use is critical and this mindset should be at the forefront of the analyst. What must be considered by companies is who are these stakeholders of requirements information and what can we as analyst determine are the best means to provide this information so that they are successful in their roles. The analyst must also be able to communicate and work with the various stakeholders. This includes the client/ customer, designers, architects, developers, testers and technical writers. To do so the needs of each of these stakeholders is different. To find a single artifact or technique that satisfies each discipline is something that I do not believe exists. Because we are translating and capturing conceptual information into concrete terms, multiple artifacts, variations, techniques are needed to successfully communicate the needs of the client/customer. The stability of working with a known set of internal stakeholders or as part of an organizational methodology from project to project does provide the opportunity to somewhat standardize these artifacts based on the needs, scale, scope and complexity of the project. Not every artifact, tool or technique is needed on every project and perhaps not to the same degree within an artifact or from project to project. There should be a set of artifacts, tools and techniques for the elicitation and creation of requirements information that serves as a tool box for the Business Analyst to use. The IIBA BABOK is an example of how this discipline is advancing and gaining momentum in this area. The communication of information to the client/customer predicates other artifacts that may or may not be utilized by the other stakeholders. Depending upon the client and project, storyboards, use cases, prototypes, scenarios, simulations, flows, diagrams etc. may be required to ensure that the clients concepts, desires, wishes are extracted, captured and communicated back to and agreed upon by the client/customer. There is an assumption that in one meeting we can ascertain the information from the client and immediately turn around in 24 hours the concepts into a concrete form that correctly captures enough information to immediately begin coding. This mentality in my mind is arrogant on our part, disrespectful to the client/customer and fails to address the importance of this activity and the needs of the stakeholders. Communication is ongoing, long term and continuous. Communicate, but do so not for your edification, but for the success of the stakeholder.
2. Business Analyst Role the Foundation 2.1 The Role
It is not intended that the business analyst role becomes some supreme role in the process or a company. It is also not intended that thousands of artifacts or hundreds of pages be created through analysis or analysis paralysis. The intent is to be that liaison between the client/customer and the project team. To provide a minimal set of information needed to communicate to all stakeholders the concepts of the project into a concrete form such that there is sound communication, understanding and agreement. To work in this way will bring us closer to delivering projects on time, budget and with a tremendous amount of value and satisfaction by both the client/customer and the project team.
Education & Professional Development Volume 1, Issue 6
Continued... Requirements as Part of the Software Development Lifecycle—by Rob Dubois 2.2 The Foundation
For companies to move towards a model that can truly provide what is a critical aspect of any project, the requirements definition process, I would suggest that companies look at what has been done in the requirements and analysis arena and address this on multiple fronts. Who are the analysts, what are their needs, concerns, lessons learned, tools – resources – methods used. Work with and identify the needs of your Stakeholders this includes but is not limited to – PM, Designers, Architects, Tech Leads, Developers, Testers, Deployment, Maintenance, Tech Writers (Help Screen, Manuals…), Help Desk – Customer Support. What tools and training are available that exist already in house or new that may be utilized to advance this discipline and area in the software development lifecycle. Numerous products and specialized training for the Business Analyst and Business Analysis are available and provide value especially with their advancements in utilization for distributed teams and stakeholders. Requirements are the foundation and if the foundation is not sound then the entire project is at risk of being built upon shaky grounds.
So to close I see three areas to address. The philosophical issue concerning the value and need for an earnest Business Analysis discipline and process that is defined yet flexible and tailored to the needs of the project. Secondly the establishment of artifacts, tools and training within this discipline that is globally adopted at both the grassroots level and in management by all stakeholders. One artifact or tool will not provide the silver bullet that so many people look for. The third area pertains to the ongoing capture and management of this information. The ability to elicit, maintain and support requirements more than anything requires discipline. The use of tools helps to assist with that discipline, but without the discipline in the first place and the recognition for the analyst role in this, the tools become obsolete and unused. In order to move forward companies will be required to invest in people, time and resources. If we cannot address the three areas I have identified and see the need to invest in analysis and requirements, then I believe we are destined to remain isolated entities, each solving the problem the best way we know how but unable to work successfully without struggling and becoming frustrated at the outcomes as we do. To that end, engage with passion and effect change in your project, environment and organization. Carpe diem!
Business Analyst Certification ( IIBA® CBAP® ) Study Group: Join your local Fort Worth Chapter CBAP 2.0 Study Group today! Every Wednesday the Study Group conferences in over their lunch hour. It’s easy and convenient. The Study Group reviews a knowledge area every week. Learning Industry Best Practices puts you ahead of the game!
When: Every Wednesday from 12:00 noon to 1:00pm Where: Contact us to get the call in details at: firstname.lastname@example.org
The IIBA® has created the Certified Business Analysis Professional™ (CBAP®), a designation awarded to candidates who have successfully demonstrated their expertise in this field. This is done by detailing hands-on work experience in business analysis through the CBAP® application process, and passing the IIBA® CBAP® examination.
IIBA Membership Volume 1, Issue 6
Are You an IIBA Member Yet? Your Local IIBA Fort Worth Chapter Board Members:
Ken Alexander President
When you join IIBA®, you become a member of an international association dedicated to developing and promoting the Business Analysis profession. Our members are part of a global organization of business analysts who want to: Expand and share their knowledge with other BA’s Learn how to improve their job performance and advance their careers Network with other professionals in the field Promote the BA profession to the business community
VP of Education Lynn A. Lang
Become a member of our community of thousands of business analysis professionals worldwide – join IIBA® today at:
VP of Professional
Membership Benefits: Al Henry VP of Communications Sandy Schmidt Secretary Cheryl Harris Treasurer
Contact us at: email@example.com ba.org
Access to a free copy of the Business Analysis Body of Knowledge® (BABOK® Guide) v2.0 Free access to the Online Library of more than 300 books Discounted fee for the Certified Business Analysis Professional™ (CBAP®) certification exam Knowledge sharing and networking opportunities through the IIBA Community Network Access to exclusive IIBA monthly publications such as the IIBA BA Connection monthly newsletter and Quick Tips for Better Business Analysis™ eBulletin Eligibility to join a local IIBA Chapter Access to a free copy of the Business Analysis Competency Model Access to IIBA Webinars a range of professional development topics Job search capabilities using Career Center
We want to hear from you! Do you have BA
Cowtown Connection Feedback or Suggestions?
Get on the IIBA Fort Worth distribution list (membership not required):
BA Cowtown Connection, Work Shops, Webinars, Special Events & Chapter Meeting Notices Contact us at: firstname.lastname@example.org
Our Sponsors Volume 1, Issue 6
Special thanks to our Patron Sponsor: Chapter Meeting Location: Downtown Fort Worth 275 W. 13th Street Fort Worth, Tx 76102
TEKsystems is the premier IT and Communications Staffing Organization in Fort Worth and Dallas. Visit their website at: http://www.teksystems.com/Locations/United-States/Texas/ Ft.Worth.aspx Currently interviewing for a Premier sponsor. If an organization is looking to sponsor the Fort Worth IIBA, please find out about the benefits of sponsoring our group by contacting us at: email@example.com
Email: firstname.lastname@example.org a.org Linkedin: http://www.linkedin.com/ groups? gid=92328&trk=hb_side _g Yahoo: http:// finance.groups.yahoo.co m/group/fortworthiiba/
IIBA® is the independent non-profit professional association serving the growing field of Business Analysis. Whatever your role—requirements management, systems analysis, business analysis, requirements analysis, project management, or consulting—the IIBA® can help you do your job better. If you are interested in joining the Fort Worth Chapter of the IIBA® come to our next meeting! We meet on the 4th Thursday of each month at 6:00 pm.
VOLUNTEER OPPORTUNITIES WITH THE FORT WORTH IIBA CHAPTER We are on the Web! fortworth.theiiba.org
Do you have experience or interest in any of the following areas, and would you be willing to help if needed? Sponsorship Committee Special Events Committee RCC (Registered Company Coordinator) Committee Publicity Committee Education Committee Website Development Committee Member Services Speaker Committee
Contact us at: email@example.com