Introduction
In my project and portfolio management practice I frequently come across the following question:
"We are embarking on a very large project and a very significant portion of the scope will be outsourced to our vendor. Do you have any tips on what challenges we might experience? What tricks would they be hiding up their sleeves? We heard some horror stories from our colleagues about their past projects and just want to be better prepared ..."
So, without further ado, here are some of tricks that vendors use to inflate the project scope, generate additional income and hold their clients hostage.
Trick #1: They Will Say "Yes" to Everything and Then Surprise You Later
You may prepare the best, most detailed RFP outlining the high-level requirements of the system your company is trying to build. During numerous meetings with the vendor you will be asking them if their platform has capability X, functionality Y or performance parameter Z. And guess what? You will always hear, "Absolutely! As a matter of fact, our organization is a market leader in these domains!"
But once your project moves into the execution stage you will slowly start discovering that capability X, functionality Y or performance parameter Z in the their system are either non-existent or weak
Usually when I mention the first trick used by the vendors, someone in the audience says something to the effect of,
"But we will have an ironclad contract prepared by our procurement and legal teams! They will surely be forced to deliver whatever they promised!"
To answer this question let us examine the remaining tricks the vendors will most likely throw at their unsuspecting customers.
Trick #2: They Will Deploy Time-Bombs in the Requirements Documents in the Form of Ambiguous Wording
Words like "fast", "seamless", "efficient", "state-of-art", "adequate" and "user-friendly", to name a few, are freely used by "normal" people in their personal and professional lives without knowing the dangers these terms carry in the project management world.
Why are they dangerous? Imagine you have ten stakeholders on your project. Do you think they will all have one unified opinion on what is a "home of adequate size" or ten different ones? What is a "fast car"? A car that is capable of travelling at 100 km/h? 200 km/h? 1,000 km/h?
Now that you are aware of this trick, see if this situation sounds familiar:
You: You know, we received a complaint from our Finance people that the reports are taking a bit too long to generate.
Vendor: How long?
You: Usually between 5 and 10 minutes. However your requirements document states that the reports shall be generated "sufficiently fast".
Vendor: Well, 5-10 minutes is definitely fast enough by our standards ... But you are saying you need them to be produced even faster?
You: Yes!
Vendor: Well, since this functionality was not a part of our original contract, we will have to address this issue via a change request. We can definitely change the report generation from "fast" to "super-duper-fast", but it will cost you extra ...
Trick #3: They Will Miss Alternatives and Exceptions in Your Business Processes
It has been established by psychologists that when asked to describe a business process an untrained mind always focuses on the successful scenario. What does it mean? If you ask an airline employee to describe the process of registering a passenger onto a flight, they will - guaranteed - same something like this:
"Well, I check the passport, then find the passenger's name in the tickets registration database, then confirm whether he has a visa, followed by security questions, etc. ..."
An experienced requirements analyst will right away explode with the following questions:
- What happens if the passport is expired?
- What happens if it turns out to be a forgery?
- What happens if the passenger presents someone else's document?
- What if you can't find his registration?
- What happens if he does not have a visa to the country of destination?
- What would you do if he provides "wrong answers" to the security questions?
All of these inquiries lead us to the alternatives (i.e. we will get to the "print out the boarding pass" point, but not directly) or exceptions (sorry, you are not getting on the plane).
The problem is that very frequently vendors - either purposely or accidentally - fail to ask such questions. This leads to unpleasant discoveries (oops, we did not look at this scenario!) later in the project. By the way, these requirements more often than none are not covered by the specification documents or contracts, leading to additional expenditures to implement them.
Trick #4: They Forget to Talk to The Right People
Have you ever witnessed the following scenario on one of your projects? The representative of the vendor talks to the head of, say, HR team and records her requirements for the new ERP system. At the end of the conversation he fails to ask one simple but extremely important question:
Who else from the HR team uses this system? Should I be talking to someone else?
The head of the HR department (again, she is not trained in requirements elicitation) is very happy to end the conversation only to discover twelve months later that her senior recruiter and employee benefits specialist also needed to provide their requirements for the recruiting and benefits modules of the ERP platform. As a result, these modules were either not configured properly or omitted altogether ...
Trick #5: They Will Push You to Read and Approve The Requirements Document As Quickly As Possible
The project manager from the vendor company will pressure your organization to read and vet the sometimes 500-page requirements document as quickly as possible, constantly threatening you with missed deadlines.
Why do they do that? The less time you spend reading and analyzing the requirements specifications, the more likely that you will miss issues like ambiguous words, missed alternatives and exceptions, and even whole chunks of requirements. Once the document is signed off and the execution phase starts, it becomes exceedingly easy to just point at the contract and proclaim,
"Sorry, you failed to list this as your requirement. We will address this issue through a change request and charge you accordingly."
Trick #6: If You Have a Fixed Contract They Will Charge You Arm and a Leg For Your Change Requests
Don't rush into a celebratory dance if you think that you managed to force your vendor to concede on all financial points and signed a fixed-price contract with them seemingly covering all possible scenarios. A corollary that is rooted in tricks 2 to 5 states:
"Once your vendor realizes that your organization is past the proverbial "point of no return", they will charge you large amounts of money for the change requests submitted by you."
In the next blog posting I will discuss some tools and techniques your organization can use in order to address the issues described in this article.
About the Author
Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East. Read Jamal’s Blog @ www.thinktankconsulting.ca
- Please follow me on Twitter:
- Like our page on Facebook:
- Connect with me on LinkedIn:
- Subscribe to my RSS feed:
Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.