Hi guys, let's continue our #BA_FAQ series! I'm picking up where we left off on the topic of internal projects (part 1). As mentioned at the end of the previous post (which I had to cut short due to its length), internal projects also come with inherent challenges like:
Lack of process: Companies often struggle with workflow processes. Some have processes in place but don't follow them. Others might not even have any processes at all, doing things haphazardly. This leads to situations where software development needs to go hand-in-hand with process development. And since people are resistant to change... Well, you know how it goes, the project drags on and on.
Change Requirements (CR): This is all too familiar to BAs, isn't it? In internal projects, CRs are even more frequent than in other types because they don't cost extra money (the fact is, they do but not easy for you to see). And since the software is meant to serve internal users, they're treated like royalty and expect their every whim to be catered to.
With all this information, you probably have a good grasp of the common issues encountered in internal projects, right? Based on my personal experience, I have some suggestions that hopefully can help you resolve or mitigate difficulties when working on internal projects:
Clearly identify stakeholders: Sounds basic, right? But it's incredibly useful, and you might overlook it because it's internal, it's "family," so how could you not know who everyone is? That's not what I mean. You need to manage and SHARE information so that everyone involved understands their own rights and RESPONSIBILITIES, as well as those of others. RACI or Stakeholder Matrix are helpful techniques in this case.
Ensure transparent communication: Transparency is essential for most projects to run smoothly across all parties. Transparent communication doesn't mean every department needs to know everything about the entire project, including information irrelevant to them. It means providing accurate and complete information to the relevant stakeholders. This sharing also helps build trust between you and the stakeholders. You can also see it this way: when you share all the necessary information with stakeholders, you also have the right to request relevant information from them (of course, within the scope of their department's involvement in the project).
Determine priority: This should be done from the initial steps, when you're working on the Stakeholder Matrix or RACI. When the project starts or before kick-off, all parties involved need to agree on the priority order for modules/features to be developed. The clearer this is, the less conflict there will be during the project. Moreover, an official email or document will help BAs avoid a lot of trouble later on when communicating with stakeholders.
Build relationships: This depends on each individual; not everyone enjoys or can do this effectively. It requires quite a bit of soft skills. However, you can at least make a good impression with a few approaches:
Share project information: As mentioned above.
Respect their opinions: You may not agree with everything they say, but you should learn to listen and instead of immediately refuting, calmly consider their opinions. You might discover their underlying "needs."
Find common ground: This is a bit tricky and requires observation. If you and the stakeholder have something in common, conversations will flow easier, and you'll get more information. That doesn't mean you can't achieve anything without common ground; as I said, this is just one of many approaches.
Maintain a professional attitude: This might sound a bit formal, but a professional attitude earns client trust. If you have to work with someone professional, your work attitude will naturally be influenced accordingly.
"Chit-chat": Engage in casual conversations unrelated to work. You can do this gradually, during or outside of working hours (if during work, try not to let it affect your tasks). This helps you understand stakeholders better, their personalities, and their working styles. It's hard to truly understand them solely through daily work and meetings. Understanding them makes the work go more smoothly.
In short, to manage relationships in internal projects, everything must be clear, professional, and above all, you shouldn't be too rigid in your interactions with other departments. Principles and processes are necessary, but being flexible at the right time and creating a good impression will significantly improve interdepartmental collaboration.
These are my personal opinions on the challenges and ways to build balanced relationships when working on internal projects. For more details on specific cases, don't hesitate to leave a comment or PM me directly.
Comentários