Project Boundary

[chunlou]

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.)

[chromatic]

I don't understand why software developers and customers keep insist on trying to fight each other tooth and nail. It's not as if they don't have the same goal.

Insisting that the customer come up with a comprehensive list of requirements before you start the project is silly. You might as well put "The customer can't ever change his mind, ha ha!" in the contract.

Insisting that changes to the scope of work can be fit in to the project as-is without changing the time, resources, or cost is silly. You might as well put "The developers can't ever change their estimates, ha ha!" in the contract.

Either way, trouble's brewing. I don't want to fight with people with whom I have a business relationship.

Aside from, say, the space shuttle, trying to gather requirements (as if they were ripe grapes, waiting to be plucked from verdant vines by barefoot virgins in billowy gauze wraps) up front, once and for all, looks like a recipe for disaster, yet, somehow, "software engineering" still promises it can make wine from unplanted seeds.

What would happen if you agreed to much smaller milestones, one every couple of weeks, letting the customer choose what to do and letting the developers decide how much time it would take?

Maybe it'd take a little more investment from the customer beforehand, but you could avoid the big thud of specifications and negotiations up front and start delivering actual, working code much faster.

Maybe customers and developers don't have to fight. Maybe you can both be happy.

(Yeah, I wrote a book about this.)

[tjh]

(Yeah, I wrote a book about this.)

Well yes you did. And, at B&N, when I clicked your name to see other books by you, I got the reply shown here:, which said, among other things, "We found 14,957 titles from author Chromatic," which is of course, extraordinary. You're quite prolific. :) Arthur Chromatic Clark? (Thought you'd get a kick outa your 14,957 books...)

Meanwhile...

It always seems unthinkable that two parties, in this case a programmer and the scope-streaming employer, should so often come to such impasses. They mostly want the same things, but, like so many other similar situations, can't get past an ethos of "the letter of the law (agreement)."

chromatic's urge to work it out so that both get more of what they want is too obviously the most useful approach. Regardless of academic temporizing about the motives of each, or each side's justifications for their behavior, no matter how logical they sound, they still have to arrive a mutually rewarding end result. Otherwise, they are each risking chronic bridge-burning, something harmful to long-term success.

I suppose logjams such as these beget "best practices" in scoping / contracting / deliverables scheduling / sign-offs and the like.

Policies, standardized procedures, rules - all mostly exist to more objectively help regulate what the humans, in the moment, can't themselves manage to take some non-dramatic responsbility for. Those too worried about being taken advantage of create the inverse situation, which is equally charged.

Who really wants to work under a microscopically phrased scoping, that has no willing flexibility for the inevitable product evolution. Coding is simply one more step in the product evolution and often (even "usually") sparks more ideas.

Neither side can afford to put blinders on their partners and expect the best results and creative contributions. But, it does seem to happen all the time.

[geektron]

Maybe it'd take a little more investment from the customer beforehand, but you could avoid the big thud of specifications and negotiations up front and start delivering actual, working code much faster. Maybe customers and developers don't have to fight. Maybe you can both be happy.

i have a decent relationship with most of my clients now that i've gone indy, and i don't think there's much fight going on at all.

i've sat down with the client, talked for a couple hours, delivered some 'milestones'/ partially-completed components for preview, and the suggestions for revision fit in nicely.

and if the client wants to have some meeting to feel like "we're on the same page", there's nothing that keeps me from meeting with him/her/them for a period of time, taking the laptop to a cafe with wireless, and showing client what is done, what needs to be done, etc. that way, client is still involved ( but not much ) and there isn't a big hit of last-minute changes and such.

one client in particular has been notorious for scope creep, and all it takes is a quick, firm "that's for our next round", and he's happy and i'm not derailed from the code in front of me.

but it's not foolproof. i have another client for whom i pretty much subcontract, and some of their clients change their collective mind at every term. but that client i charge by the hour. ;-)

[chunlou]

Yes, there're indeed still many happy stories out there. I guess engineers tend to be trained as a pessimist.

It probably helps the situation if the client doesn't have or exercise his immerse bargaining power over the developer, such as someone working for a multinational firm, who may think everyone is simply dying to work for them at all costs.

And, o yea, it's always more pleasant if you can simply directly chat with your client instead of his attorneys (happens more often during contract negotiation). We're once bogged down in a negotiation (concerning profit sharing, among other things) for almost a year (the client got plenty of lawyers). In the meantime, the product development and marketing were partially stalled.

O, right. That's why sometimes a programmer should appreciate his business counterpart for getting the verbal bitch-slapping from a client for him, if nothing else.

[chunlou]

I guess, the "fight" is partly due to the lack of cross-displinary training in school and at work.

A business folk often found the rigorous nature and process of a programmer inconvenient, whereas a programmer insists the everchanging business world should behave as orderly as the development process. It's a mutual misunderstanding. It's like abs(x) approaching 0 from opposite directions, connected but discontinuous.

[adrianh]

Maybe customers and developers don't have to fight. Maybe you can both be happy

Amen brother.

Working projects in a more agile style has made these sorts of requirements wrangling problems disappear for me too. Suddenly I have co-operation instead of conflict. A very pleasant change.

[didier]

Hi adrianh

It could be interesting to have a description of what
you call "a more agile style".


Regard

[bm]

An interesting perspective on scope creep can be found here.

Perhaps, as the article suggests, a moving project boundary is unavoidable. The question is how you manage it.
--
bm

[chunlou]

Right, the article also said it nicely, "Scope isn't the set of stuff customers have asked for. Scope is the set of stuff we've agreed to deliver."

[johndageek]

Depending on what is being discussed, a non-disclosure statement signed by all parties provides some protection both ways, and helps open up communications.

Project negotiation is a lot like comuniccation at home with teenagers. e.g.: Dinner is at 6:00.

Teenager hears the words, and thinks:run in, sit, eat, run out. - total time expected 12 minutes assuming some conversation is required.

Adult hears the words and thinks:What should we have? do we have the ingredients? (iterate first 2 questions as necessary - branch to store if need be). Will everyone eat at least one thing that will be on the table? (add item if you must). Account for preparation time and effort. Setting table. Sit down and eat. Get up, try to corral teenager and/or spouse before they bolt. Get dishes from table to kitchen. wash and dry dishes, put them away wipe down table, counters and appliances. Empty garbage if needed. Now run out. total time investment minimum:1.5 hours, maximum 5 hours

Why this confusion? Is it lack of communication? Sure, but how much does each side want to understand of the others needs? How much is each side willing to give to reach a balance?

I am a parent of both a difficult teen and a less difficult one as well as a programmer for both difficult clients and easier ones. Negotiation techniques are similar. Initial discussions are presented in relatively neutral terms, allowing the client/teen to express their perception of what is needed. Then state some constraints perhaps more stringent than necessary. Watch the response - reasonable resistance to the more extreme constraint, with acceptance of the reasonable constraints signals a reasonable customer/teen. Resistance/ pushing of all limits or total acceptance of all constraints indicates an unreasonable client/teen - either extreme indicates a disregard for your limits and may work the situation to their best benefit regardless of cost to others.

Once a reasonability factor is determined, basis for negotiation can be reached. Reasonable clients/teens can be dealt with in a more lenient manner, because you both are looking for a balanced solution.

Unreasonable Clients/teens must be dealt with in smaller more controlled bits. Each piece of the plan or work that is exposed must be paid for immediately, or the project halts until that given small piece is completed including payment. As you go along, they will want changes - stop the project, point or display the pieces already done, explaining the costs to change each of those pieces. If the change is agreed upon as needed. Go back to the beginning piece, make the change, get payment, halt project until payment is received. This is a herky-jerky way to have to control a project but it is the only way to keep from letting unreasonable demands erode the profitability of a project. People without regard for other people's value will begin to see the advantages of not being unreasonable because the costs are passed directly back to them, and are not absorbed by you for any length of time.

Advice is free.
Advice is easy.

Experience costs like a -----.

Listen to other's advice, learn from their experiences.

Good luck!

John

[chunlou]

Very interesting perspective. Reminded of a saying which I paraphrase: God chose our relatives; we choose our clients.