As a freelance, entrepreneur, or just a motivated programmer, we're often inclined to do whatever it takes to get a project done--without taking away everything we've got, hopefully.
Sometimes, a client may keep asking for "small changes" at the end of the project upon reviewing and inspecting the "final" product. Eventually, such series of "small changes" may amount to another two, three months of work or more, almost just like another brand new project, which the client insists is covered under the original contract for the current project.
It's a problem of fuzzy project boundary, both technically and legally.
* * * * * *
Project boundary means you have clear definitions of your problem domain (what problems you're trying to solve), as well as the functionalities/features of the product you're going to deliver (how you're going to solve the problems)--that's the technical idea. Legally, it's often just all about the feature set.
A good way to conceptualize problem domain and project boundary is to think of it as the interaction of client's needs and client's stated requirements (not union or either one).
Project boundary can be defined when you have a well-formed architectural view of your project and product.
Timeline is often a "boundary" set on a contract. But since timeline really depends on the feature set to be built, it's meaningless to arbitrarily set it independently, technically speaking. After all, you're ultimately paid and valued for what you deliver, not really how much time you work.
The business and legal processes may, nonetheless, upset the meaningful definition of a project boundary from the outset.
* * * * * *
A common misconception from many people is that a generic and simple requirements specification or product description leads to a more flexible system--and a flexible system is easier to build (DEAD WRONG!). The misconception is probably due to the erroneous association between ease of use and ease of building it. Many people do think that if it's easy to use, it's easy to build; therefore it should be easy to describe and should not need precise definitions. Hence, fuzzy project boundary.
Another common mistake is to completely set a (fuzzy) project boundary early on on a contract--even way before requirements analysis done at all. It often happens when someone is too eager to "close the deal."
I don't think a project boundary could and should be set hard, legally and technically, before any partial requirements analysis has been done and a few artifacts or even prototypes (screenshots, activities diagrams, etc.) have been produced, reviewed and agreed upon by the client, in order to keep everyone on the same page.
* * * * * *
Sure, sometimes a prospect could take advantage of the requirements analysis phase (or "request for proposal" phase) as a free service from someone coming up with some professional application design for them and then walk away from the talk with the design (or proposal) without paying a dollar or euro. "Early termination fee" could be a mechanism to deter such behaviors. But this kind of issue is a bit beyond of the scope of the discussion of project boundary.
* * * * * *
Setting project boundary does not mean having unchangeable requirements specification. Setting a project boundary is like declaring your major in college, whereas requirements specification akin to the courses you're actually going to take.
Sure, you can change boundary and architecture if necessary. But such changes will be more costly as you're getting deeper into your project.
Good project boundary will be definitions (legal and/or technical) you can use to make almost a yes/no decision on whether a new change is or is not within the boundary. "Productivity Enhancement & Training System" (PETS) makes a catchy brand name but does not constitute any boundary at all. Anything from weight loss to sleeping better to time management to accounting training could be tucked under PETS.
A project boundary may be adequate if you could build a decision tree out of it (not that you have to). For example, to decide if a change or a feature should be in PETS and relevant, you may ask (not necessarily in any particular order):
- Does it help improve employee's productivity in Company ABC? (Not their kids or friends in Cancun or wherever.)
- Is it under direct controlled by HR? (We don't want a system that need to be admin'ed by a personal trainer, nutritionist or biochemist.)
- Is it about time management? (The current scope of the project in term of skill training, not finance, not accounting, not programming.)
- Is it an integrated part of the workflow? (Not something that need revamping the underlining system architecture.)
- ... and so on and so forth.
Feasibility and other issues are to be considered after we deem a feature or change is relevant and within the project boundary.
Occasionally, some clients did deliberately tuck some out-of-boundary changes or requirements to the current project just to get extra mileage for their money. It could become a nasty word game if the definitions of the boundary are not clear.
* * * * * *
Once, we finally terminated a contract on a client without "finishing" the project. Well, it took a few months to complete the project based on the initial requirements. The client then asked for changes, which eventually dragged on for almost a year--without paying extra (or maybe only a little). The client significantly changed the underlining workflow of the system, which was agreed upon and detailed out in the requirements. It didn't change the problem domain but it changed the feature set as well as the architecture somewhat dramatically, and the client admitted it.
At first, it was a business decision that we continued with the changes. Turned out to be a bad business decision (the product never had a successful market entry). The termination decision was made partly due to the high opportunity cost as well, as we had better and more profitable projects to do.
* * * * * *
Project boundary is not just for external clients but internal clients as well, such as your account managers or sales reps, who may have some say as to who will do what. You don't want a manager to claim certain resources (i.e. the programmers) forever under the everlasting "current" project. Some people did that in order to cling to the best programmers for themselves. (Project boundary won't be a solution for that but at least an ammo.)