Why You Should Be Prudent in Engaging IV&V

What is IV&V, and what does it have to do with monitoring and controlling project work? After all, Project Managers have their own processes to help ensure that project execution goes according to plan and the project remains within budget.

IV&V is common shorthand for Independent Verification and Validation. It is a systems engineering discipline designed to build quality into the software application during the project lifecycle. It is an independent process because it is conducted by an organization separate from the IT provider that is building the system.

Think of verification as answering the question, “Are we developing the system right?” That is, every phase of the software lifecycle must fulfill the requirements for that phase.

Validation, on the other hand, answers the question, “Are we developing the right system?” The system must meet the client’s objectives that were established in the project charter.

To that end, IV&V involves a variety of rigorous activities tailored for each project phase. These activities include assessments, analyses, reviews, evaluations, and software testing.

IV&V is designed to provide assurance to the client that the system will be delivered as error-free as possible. The client can have confidence that the system will meet its end-users’ needs. A well-functioning IV&V process will catch significant high-risk errors early enough in the development lifecycle such that they can be remedied without major rework. IV&V status reporting provides client management with ongoing status indicators of project performance. When the IV&V status reports correspond with the IT provider’s status reports, the stakeholders have confidence that the project is progressing well.

I agree with all the above in theory. If implemented with this intent, IV&V is indeed a best practice within the software development industry. The early identification of risks and quality issues gives management higher visibility into the project processes and allows for quicker mitigation of issues as they arise.

In my previous article, “10 Best Practices to Monitor and Control Projects”, I outlined monitoring and controlling activities I have found to be beneficial to ensuring that the project is delivered successfully. So why do we need IV&V?

Perhaps we need IV&V because as an industry we are not as transparent with our clients as we should be. You have undoubtedly seen behaviors such as the following on your own projects:

  • the project begins to slip and, in your unbridled confidence in your team’s ability to bring the project back on track, you assure your client that everything is progressing well; or
  • the client staff on your project interpret their requirements differently than you do, so you attempt to persuade them that your interpretation is the correct one; or
  • the end-user testers are uncovering more software defects than expected, so you complain that their testing wrong.

I remember to this day an incident that occurred on a project more than 30 years ago. We were training end-user testers on the application we had just finished developing. As we walked through the system functionality, 20 end-users said, “But that’s not what we were expecting.” Imagine our shock! These client staff had been with us from the beginning of the project. We had spent several million dollars. We adhered to the timelines. How could we have missed by that much? We had to scramble to get everyone back on track.

So, as I stated earlier, I strongly agree with the concept of using IV&V on software projects. If implemented with the correct intent. However, it has been my experience that the IV&V process is often misused. I may be biased, having been on the receiving end of poorly executed IV&V assessments. Nevertheless, I have some cautions for projects that elect to use IV&V services:

  • Many of the IV&V vendors I worked with felt it was their responsibility to “inspect quality into the software” after the fact. Rather, they should help guide the team to build quality in as the project progressed.
  • Yes. the “I” in IV&V signifies “independent”. However, the IV&V vendor is often a competitor of the IT provider. In many procurements in which I participated, vendors who chose to bid on the main development effort were not allowed to submit a bid for the IV&V effort. If a vendor felt they could not win the main project, they would bid on the IV&V contract. During project execution the IV&V vendor would then throw up roadblocks for the IT provider (their competitor) under the guise of helping to assure a successful, quality project.

    Additionally, I have witnessed IV&V vendors lobbying the client, criticizing the IT provider while building themselves up. This was done in the hope of favorable consideration for future business opportunities with the client.

  • Often the IV&V vendor staff are not qualified to assess project quality or progress. It’s as though the vendor reserves its “A” team for more lucrative system development jobs and send its “B” team to IV&V projects.

    The “B” teamers, in their inexperience, resort to quoting contract terms and Internet articles as to why they felt deliverables needed to be redone or project issues raised. Rather than helping to move the project along, they become roadblocks.

  • Even on well-executed projects, I have seen IV&V vendors raise issues with project quality or execution. Their reasoning – they feel that if they do not find something wrong, the client will think they are not doing their job. Frustrating!
  • Many contracts do not require the IV&V vendor to be on-site fulltime. IV&V believes they can assess project progress and quality simply from reviewing deliverables and calling into project status meetings. They create their assessment from that. However, when the IT provider’s team is on-site fulltime with the client, and the IV&V vendor is not, they cannot be aware of all that is happening daily. IV&V has an uninformed view into the project execution and their assessments are suspect.
  • IV&V vendors are seldom held accountable for their assessments even if their reporting disagrees with the IT provider. Much time is wasted in resolving the discrepancies. Once resolved, the IT provider must carry on while also making up for lost time and effort.

I offer these cautions not to dissuade organizations from engaging an IV&V vendor, but rather to be aware of what can occur. In my experience, IV&V often has been detrimental to the project. This is not because the concept is wrong, but rather that the implementation is flawed.

It is instructive to note that in the examples I cited above, rarely did disagreements between the IT provider and IV&V vendor have anything to do with properly executed verification or validation. The disagreements were typically the result of “one-upmanship”, or competition, or lack of experience.

It also has been my experience that a competent stakeholder with strong leadership skills and expert judgment can quickly determine whether the IV&V services are benefiting the project. If not, he or she must correct the problem.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.