PMdistilled ForumExample Category: PMdistilled forumThe RACI Conundrum in Product Env …Post Reply

Post Reply: The RACI Conundrum in Product Environment !

<blockquote><div class="quotetitle">Quote from <a class="profile-link highlight-admin" href="https://pmri.in/forum/profile/pmdistilled/">pmdistilled</a> on 14/04/2025, 8:29 PM</div>
<p class="has-medium-font-size">We are all aware of the fact that RACI charts helps us to define the roles and responsibilities with absolute clarity. It helps to make it crystal clear about who is Responsible, Accountable, Consultative and Information recipient for all major tasks in projects which is the foundation for effective teaming. The challenge starts when someone goes beyond their defined responsibilities and accountabilities inorder to make the product better. I have two cases here...</p>

<ol class="wp-block-list">
<li class="has-medium-font-size">Senior management bypasses the product owner and start providing requirements / changes to the development team. The senior management have the positional power where as the product owner has the expert power. The senior management is not doing it becuase the product owner is bad. They just have this tendency to bypass, and this creates lot of friction at the workplace. </li>

<li class="has-medium-font-size">The Q.A professional provides suggestions related to functionality which gets shot down stating that 'that is not your job' to realise later that all those suggestions were valid.</li>
</ol>

<p class="has-medium-font-size">In both these scenarios the intent was good and at the same time was contributing to dysfunctional work places. In the first scenario where the senior management was bypassing the product owner, the main root cause was the fact that it is startup, hence too much power (perceived) is centralised at the top, hence nobody dares to correct. The best solution for this scenario is to define a light weight process, train, implement and continuously measure the effectiveness. </p>

<p class="has-medium-font-size">In the second scenario, the culprit is conflicting metrics of productivity. For QA it is always about the number of defects detected where as the number of defect detected has a negative impact on the programmer. Quality is conformance to requirements and fitness for use which everyone must appreciate. 'Non-Conformance to defined requirements' is easy to be classified as a defect where as when it comes to 'fitness for use' especially performance and usability it becomes debatable. Having joint responsibilities for QA and Engineering for customer satisfaction related KPI's will resolve this issue. That is the main reason why in Agile it is just one development team comprising of both developers and QA. </p>

<p></p>
</blockquote><br>

Cancel