Continuing the #BA_FAQ series, as requested by Huy, today I'll be writing about issues related to internal projects and how to balance relationships between BAs and stakeholders. Since this turned out to be quite lengthy, I'll split it into two parts. Part 1 will focus on internal projects and common challenges.
Internal projects are software projects developed to serve the very company where you work as a BA. Implementing internal projects as a BA has some differences compared to other types of projects, such as:
Outsourced projects: These are "software outsourcing" projects. Your company receives software development requests from partners. Stakeholders in this case are generally "clients." They could be business domain experts from the partner company or employees from corresponding departments. They have the right to decide what the software needs to have to serve their needs. in Vietnam, large companies like CMC Global, Fsoft, Nashtech, etc., are typical examples of this type.
B2B product projects: Similar to outsourced projects, but the clients here are not as "powerful" as those in outsourced projects. In most B2B companies that I've worked with or learned about, client opinions only have a partial influence. The software company still holds the final decision-making power. Companies like Misa, 1Office, etc., fall into this category.
Mass-market product projects: The clients are a large user base, and it's challenging to understand them because there are virtually no limitations. You might gather requirements from a few people, or at most a few hundred, but the mass market can reach thousands, even millions or more. With this group, client requirements are mainly suggestions and sometimes lack specifics.
Internal projects often have some common challenges you might encounter:
"Passing the buck" between departments: This is especially prevalent in older companies. You can imagine how this affects a BA's plan. Just a few delays in confirmation or meetings can cause endless shifts in the plan and impact the overall schedule.
Priority: As it's an internal project, it might not be prioritized as highly as projects that generate revenue. These projects are often treated as the "stepchild" because many companies tend to utilize available resources for them and pull people away when other projects arise, leading to a chaotic situation.
Business knowledge: Projects specific to a particular domain usually only require specialized knowledge in that domain. However, internal projects, such as ERP implementations, involve various business processes from different departments. Lack of specialized knowledge can hinder your project implementation.
Let's pause here. Although there are a few more points about these challenges, this post is getting a bit long. I'll continue sharing in part 2. You can read it here [link to part 2].
Comments