My answer is YES.

It all comes down to planning and managing the project properly.

Defects cost Money!

This may sound cliché but it is the truth.

As IT organisations are transitioning from traditional delivery model to outcome based vendor delivery model, the impact of defects are becoming more profound.

Think of a scenario where a company has engaged a vendor to deliver a project. The procurement and service contract was signed off between the two parties. The vendor is on-boarded, given network access and started their work. Obviously one would expect that the requirements will be part of that contract so that the vendor can deliver a product that meets the business requirements.

Guess again!

I recently delivered a project where an US based vendor was engaged to develop a key product that was coming to an end of life and hence had to be replaced. The PM went through the rigour of creating a detailed procurement and service contract. The contract was signed and everything was supposed to be locked in.

When we were engaged to deliver (develop, test and implement it in production) the project, we found some glaring gaps:

• Since the contract was signed, requirements have changed and the new changes were no longer part of vendor delivery. As per the vendor, these were change requests. Note that business had sanctioned IT to deliver the product. So if IT failed to properly include the requirements as part of the contract, do you think business will be happy? They WERE NOT HAPPY.
• Every organisation has a specific SDLC process where the code goes through system test, staging/pre-prod test and then gets deployed to production. Throughout this process, the code is regenerated few times and deployed to different test environments. In my current organisation, we have a system test, a staging test and a production equivalent test environment. The purpose of the production equivalent test environment is to have a test environment that is in sync to production and incidents can be quickly replicated. We found out that there was not enough test environment provisioning included in the contract. So we were short of one test environment. As the vendor has to provision the test environments in the data centre, they never budgeted for this. Who do you think was responsible for this oversight even when IT recommended the number of environments we needed?
• The development team started on the build process before the requirements were locked in. As a result, when the build process was in mid stages, business requested further changes in requirements, This caused the SAD (Solution Architecture Document) to be revised and caused additional delay in development completion.
• Since the vendor was an US company with a subsidiary in Australia, their entire development team was based in USA. This means that defects had a significant turn around time. For example, a critical defect (sev-1) raised on Monday (Sydney, Australia time) was not analysed by the vendor’s development team until cob Tuesday (US Time). This caused the testing to be significantly impacted as we were faced with large number of test cases being blocked until the sev-1 issue was resolved. Again, this could have been easily resolved if the PM had the oversight to anticipate these issues and setup a framework across the two time zones.
• During the middle of the test phase, it dawned on us that the vendor was not prepared for the enormity of the work. Genuine defects were being rejected without proper explanation or analysis by the vendor’s team. Complex defects were marked as change requests as these were not part of the requirements defined in the contract. As a result, we ended up with a large number of “orphan” defects from vendor as no one was taking ownership.
• Project also did not provision for run time support after the warranty period expired. This became a critical issue as we found ourselves with no plan or no technical team to provide service management and address production incidents.
• Lastly, due to non-provisioning of test environments, vendor was late in commencing data migration from old to new system

So when we invited business for UAT, they were not impressed with the large number of open defects that vendor was yet to resolve. I don’t blame them. If I were the business, I would have been equally disappointed with the outcome too.

So do you think these issues could have been avoided if the project was managed properly and with an understanding of vendor management?

I believe THESE ALL COULD HAVE BEEN  AVOIDED.

• Before the contract was signed, requirements should have been locked in so that the requirements were included as part of the contract and vendor deliverable
• Detailed test environment provisioning specs should have been prepared with strict schedules
• Vendor should have been on-boarded and committed to providing on site support from day 1
• A triage team should have been formed from day 1, consisting of vendor and our internal technical teams, to analyse open defects
• A defect turnaround SLA should have been agreed from day 1
• A full spec for data migration should have been created before build process started, clearly articulating schedule and risks/assumptions

In my opinion, a lot depends on how successfully and efficiently a project is run. A poorly run project will run into a lot of issues. While we will work collaboratively to address those issues, we need to ask ourselves why run into these issues in the first place?

Resolving issues by putting more people to make up for lost time, overtime etc. adds to the project budget. Any missed requirement ends up causing headache for business and IT. Poorly constructed requirements ends up as production defects and cost IT money. Similarly poorly tested application ends up costing the business.

In today’s IT market, everything is being measured in terms of money and ROI (Return on Investment). More and more public companies are transitioning to running IT as a business. And in business, the bottom line matters. As savvy Managers, we must ensure that there is as little wastage as possible for the entire SDLC process. Only when we are able to deliver projects by avoiding the obvious pitfalls through efficient project management, can we offer ROI to business.

So interested to move into project management space?