RACI Errors: Impact on Project Integration Management

In developing a good project integration management, it is critical to understand the role of responsibility assignment matrix. The goal of project management primarily is to deliver results through other people. This involves a clear role and responsibility for every work package or function that will play a critical role in project delivery. One such responsibility assignment matrix is the RACI.

I have often seen RACI filled incorrectly and have blogged (Rajagopalan, 2014). However, I would like to discuss the following two issues further as they have a relationship on other aspects of project management knowledge areas.

1.  Mixed roles with "A" and "R": When a person or function is marked with both these roles, then this may introduce the risk of project schedule slip. If the individual responsible for doing the function fails to perform, then typically the accountable person will monitor the slip and ensure that the work is getting done. Alternatively, if the work is not completed satisfactorily, the accountable person shares the onus to check on the quality and the cost of poor delivery. However, if the "R" person also is the "A" person, then the latter will not put any pressure on the former because they are both the same. This impacts risk, time, cost, and quality. Similar challenges can be seen with "R" and "C" or "I" overlap.

2. Too may "A"s: If two people are accountable, then there are two types of problems. The first is the blindness game each "A" role plays thinking that the other role will keep an eye in ensuring the task is completed. When this task fails to be done, the blindness game becomes the blame game reasoning with the "I thought you would have done it." This introduces project delays that may impact time and introduces challenges with procurement. The second issue is the team gets conflicting directions from each "A" person leaving the team to get caught between power plays. The resulting team dynamics may lead to HR and stakeholder challenges.  Furthermore, these issues may impact other areas of project management.

There are several symptoms that a proper RACI may resolve for the project manager to proactively address. But unless a project manager has a good understanding of RACI, the symptoms deteriorate leading to major problems requiring surgical intervention from executive management.  The project manager can avoid these strategically by planning to succeed with end in mind. 

References

Rajagopalan, S. (2014). RACI: Errors and Implications in building the right one. https://agilesriram.blogspot.com/2014/07/raci-errors-and-implications-in.html

Project Quality: Whose job is it to guarantee it?

In a series of training that I was recently providing to project managers, software testers, and business analysts, I found discussions that focused on who was responsible for software quality in projects. The project managers thought it was a QA department role.  QA passed it back to requirements form business analysts who then delegated to directions from the project managers.  With so much literature on total quality management, Six Sigma, capability maturity model, and organizational project management maturity model, it dawned on me that it is this inherent lack of ownership for quality is the reason why quality is suffering in many projects.

Basic requirements of quality are often described as adherence to requirements and fitness for use.  When you look at the key deliverable of this statement, “requirements” stems from the project requirements. In traditional projects, this requirement may come from the client, business analyst, project manager, or the product owner at a minimum. In agile projects, this could be coming from the product owner or client, scrum master or coach, and the team at a minimum. The “fitness for use” stems from timely release of the futures to ensure that the client can benefit from the release.

But does this definition unambiguously tell whose responsibility quality is? The Chartered Quality Institute comes to rescue as it defines quality management as a company’s approach to “…understanding precisely what customers need and consistently delivering accurate solutions within budget, on time, and with minimum loss to society.” (“What is Quality”, n.d., para 1) This definition emphasizes quality within the project constraints budget and time limiting the focus to the scope of the project’s requirements but also to the needs of the society relating to the fitness for use. A project manager is not developing the code or involving in the execution of tests. But quality is the fourth constraint that is compromised as the other project constraints are modified. Therefore, the project manager is accountable for the quality. This is why Quality Audits are associated with the project manager (or product owner).

It reminds me of the famous parable on the virtue of citizenship from the “Adventures from the Book of Virtues.” Many subjects in the kingdom complained about many things in the kingdom and not taking true ownership for improvement. The king hid a pot of gold beneath a big boulder and waited to see who took leadership for removing the rock enhancing safety and quality experience for the others that passed by.  Quality is the same thing as the citizenship requirement. It is everyone’s job. The more structured approaches the organization uses in testing accuracy through automation, test case development, and test execution, the more the project manager becomes attuned to following through on quality, the more the team members will become focused on providing quality by design rather than expecting it to be accidentally evolving.

References

What is Quality? (n.d.) The Chartered Quality Institute.  Retrieved March 28, 2013, from http://www.thecqi.org/The-CQI/What-is-quality/

Agile – Is it a Panacea or a Placebo?

It is true that the fundamental twelve principles of Agile Manifesto (n.d.) have helped many projects succeed in organizations. These results are evident in the increasing 61% of agile practitioners promoting the adoption of Agile in organizations, as noted by the 7^th annual state of agile development survey conducted by Version One. But, several agile purists focus on some of the buzzwords, such as the Test Automation, making it as though Agile is the cure-all for all business problems.

Those in the technical world may understand the famous statement, “Not all business problems are nails to use the same hammer as the tool,” when common object request broker architecture (CORBA) was initiated to introduce by Object Management Group (OMG) the communication between software components regardless of the underlying language used to develop them. However, it is interesting that some agile practitioners are inclining towards test automation as a cure-all (panacea) treating all test cases alike.

Testing requires two basic requirements namely verification and validation. Verification is the process of evaluating test cases, test scripts, requirements or user stories to ensure that the process of testing is going to ensure that the required functionality is present to meet the user requirements. The focus of verification is on the process and is therefore an improvement process oriented towards assuring quality (QA). But validating is the ongoing approach to testing the software with the goal of identifying defects. These defects could be traced to the faulty code, inaccurate design, incomplete or ambiguous requirements, misinterpretation of the requirements, or a combination of these factors. Validating therefore aims at controlling quality (QC).

So, test automation can help in the validation to ensure that every incremental build is tested for the new features but also for the previous features. It is therefore not a placebo but is not a panacea for all business problems. Depending upon the unique business requirements, some requiring can’t be easily automated even if technology can allow it. For instance, testing the human interfacing with the interactive voice response (IVR) at various points in the call flow to check for the disposition code, checking for the line breaks in the email, or the accidental mix up of Far Eastern Asian Language characters because languages such as the Chinese, Japanese, and Korean share a common base do benefit from manual testing.

It is therefore important to evaluate what is the business need in test automation and identify areas that can lead to efficiency gain. Redman and Nielsen (2013) very nicely paraphrased Deming suggesting to carefully select the right process to automate explaining “… automating a process that produces junk just allows you to produce more junk faster". Deming might have inferred this long before the agile was conceived but some golden principles do stand the test of time.

References

Principles behind the Agile Manifesto (n.d.). Retrieved February 13, 2013, from https://agilemanifesto.org/principles.html

Redman, T.C., & Nielsen, D. (2013). Computerization in Health Care Demands High Data Standards. Harvard Business Review. Retrieved February 28, 2013, from http://blogs.hbr.org/cs/2013/02/computerization_in_health_care.html