I got a call a few days ago from one of the founders at Global Syons, a development outsourcing startup. He wanted me to help analyze their presales process in light of the fact that they were bumping into a number of problems during the execution of their projects. Most of them had to do with the selective interpretation of requirements on behalf of the client.
This is rarely new. Possibly the first wheel ever invented was square because caveman #1 wrote the requirements while caveman #2 built the actual thing.
In my friend’s case all problems were a direct result of incorrect requirement specification in their work statements.
There is an implicit advantage for clients when discussing the gray areas a loosely written requirement entails. As a client I hold the advantage in the interpretation because as the client I’m always right (i.e. I’m paying the bills so you better not antagonize me.) Yet, if the ground work is properly done outsourcers can shift the advantage to their side.
The problem lies not in writing and estimating the most comprehensive list of requirements when creating the statement of work, but rather a comprehensive enough list. When estimating in an early stage, more often than not, requirements are vague and there are basically two ways to reduce uncertainty: ask or assume.
The trick lies in mastering the art of deciding when to use one and when to use the other, and to not overdo either one of them:
- If you ask too much then the client will tend to add tons of new features but will not readily accept the new cost. More so if your competitors estimated without asking too much and hence presented low prices.
- If you assume too much the scope can be ludicrously small and either the client will detect it or the project will become tangled in so many change requests that it will be unmanageable.
As a for instance let’s say a client asks you to develop a registration form. You might come up with the following complexity scenarios:
- Very low complexity: Fields for e-mail address and password. Basic validations (length, e-mail format).
- Low complexity: Fields for e-mail address, password, user name, name and last name. Basic validations.
- Medium complexity: Fields for e-mail address, password, user name, name and last name. Complex validations (password strength, confirmation mail)
- High complexity: Multiple page form with all personal information (phones, addresses, credit card info, hobbies, etc) and complex validations.
You need to decide what your complexity target is in order to build a competitive proposal in terms of price but that will also allow you to execute the project properly. Once you figure it out, then you need to figure out what is the correct amount of questions and assumptions that will allow you to get there.
Whatever you do not specify as in scope, that you know the client will eventually request, will haunt you later. Be warned: Assumptions do not eliminate trouble, they just finance it. You are purposely kicking trouble forward to a time when the damage is less, or at least different.
In other words: It’s one problem to have no business because you failed to turn in a competitive proposal and a completely different problem to have a bumpy project because you have specified an incomplete set of requirements.
Once you understand that no project is trouble-free I believe you will prefer the second.
Shuje
On my next post: A raft for mice, a Frisbee, a sushi plate and 97 other good uses for your iPad. Have any good requirement stories? Comment below or e-mail them to shuje@holoom.com
Posted by shuje 