This diagram shows the primary activities I perform as a Business Analyst in support of IM/IT projects, and the typical order in which these activities are initiated. The arrows do NOT indicate a waterfall approach. I revisit each of these activities throughout the life of the project.
Depending on the complexity of the project, the amount of existing material for reuse, and the experience of the Business Analyst team, a project team can choose to risk* skipping several of the initial activities to start working on the IM/IT solution sooner.
*Risk: Skipping the earlier activities often leads to an increase in the amount of rework that needs to be done by the IM/IT solution provider, essentially removing the assumed benefit of an earlier start.
I’ve decided that this diagram and the activities it describes is an effective way to tag the contents of this site, I will this list as I add more content to this blog.
- Participate in Project Planning: Mainly through the identification of Stakeholders, the Communication Plan, and the identification and scheduling of tasks to be performed by the Business Analyst team in coordination with the other project teams.
- Review Existing Documentation: Any documentation that describes the AS-IS state of what needs to be changed, or describes why a change is necessary.
- Strategic Analysis / Assess Influencers: Identifying why the change being implemented by the project is needed.
- Meet with Subject Matter Experts (SMEs) to verify information and models
- Gather new Requirements
- Manage the Glossary: For my work I’ve found that consistent use of terminology is critical, in the past I often found that requirements were completely misunderstood because the SMEs had different definitions of the same term.
- Model the Business Objects: I work for an information based organization that receives, generates and disseminates information as Business Objects, identifying what these Business Objects are, what information they contain, and why that information is needed is critical to understanding the Business Services they relate to.
- Manage the Domain Model: The domain model captures the concepts that are important to the business, such as person, facility, equipment etc. and the relationships between these concepts (person operates a facility, equipment located at a facility)
- Manage the Requirements
- Model Business Services
- Model Business Scenarios
- Model Business Processes and Activities
- Assess Proposed Data models against requirements: DBAs can use the information contained in the Domain Model to create normalized conceptual, logical and physical models for storing the information. As a BA I’m often assist in verifying that information once stored in a normalized form can be reassembled in a non-normalized to support decision making.
- Manage the Data Dictionary
- Assess Proposed Use-cases, wire-frames and mock-ups against Requirements: Previously as a BA I would create these artifacts for the development team, but in the past few years I’ve requested that the development team assign someone to the role of Application Designer to create these based on my other work. I’ve found having the Application Designer create these artifact is a useful step to confirm the development teams understanding of the overall requirements
- Model User Stories
- Assess Proposed IM/IT solutions against requirements
- Support User Acceptance Testing
- Support the Implementation of the Service/Solution
- Project Closeout