Dark matter is a term I've heard for requirements that were not explicitly included within a specification (whether a BDUF detailed spec or an agile user story). Typically dark matter is the cause of most disagreements about scope on fixed bid projects.

For example, if the user story states that there should be a password and confirm password field but validation isn't discussed, it is within or outside of the quoted scope to ensure that the password and confirm password field matches?

What about an application which must check inventory level where the developer assumed this was a field in the product database and in fact it requires integration to a complex third party system?

What about a client having "assumed" that inventory would be on a per warehouse basis and explaining that without that the project is unusable and they are out of budget for changes? If the fact that they had more than one warehouse was never mentioned, this can cause a problem.

On our part, while we might try to take care of the password/confirmation password issue, we make it very clear that unless something is written down as part of a user story, it is not included within the project. The fact is that we can't provide a fair fixed bid for features that will meet a clients business needs as we have no idea what kind of dark matter might be lurking. We do our best to poke around in the discovery time available, but all that we commit to within a fixed bid is creating working software that implements the explicitly documented elements of the user story.

The problem of course is that this often doesn't meet the clients needs which is not good for either of us - which is why we're looking to move towards a blended approach.

I've found it very interesting that on an XP list recently there's been quite a lot of talk about fixed price for features which at first seemed to me the antithesis of the Agile approach. At the same time, we've been developing fixed price software for years, but I'm wondering if a blended model might be the ideal solution . . .

[More]

As you may have noticed over the last few days, I've spent quite some time thinking about both operational issues relating to managing the process of building web applications and business development issues that relate to selling web projects. The reason is that we're pretty well done with the rocket science of our software product line, and we're now trying to figure out the best way of selling what we can do at SystemsForge . . .

[More]

When you build a consulting practice, one of the big decision points is how to position your solutions. Are you a "web developer" or the "jQuery guru"? All other things being equal, more people need a web developer than a jQuery guru, but if you specialize in something you're much more likely to get such projects compared to someone positioning themselves as a generalist. Some thoughts on making the decision . . .

[More]

Most people who call themselves web developers would never consider building a web application without first finding out the problems it was trying to solve and suggesting an appropriate solution tailored to the problem, yet the same developers will roll out the same kind of quote to each client they meet. Obviously concept like social proof and credibility are relevant to all prospects, but how can you best customize quotes to different clients? The key is an elegant way to segment the classes of clients you deal with . . .

[More]

You're the marketing manager or CEO of SmallCo - a retailer of sporting goods, the office manager of a small to mid sized law or accounting firm or the sales manager for a B2B manufacturer. You know your website needs rebuilt and you've got a $15k-$25k to redo the design and adder richer functionality to the site. What do you really want from a website developer and what proxies do you use to try to select the right firm to use?

[More]

I probably know less than most about precious metals and jewelry. If I was just shown a piece of jewelry without context, I'm pretty sure that just by looking at the metal I wouldn't be able to tell steel from silver from platinum. I'd probably be reduced to guessing based on the price tag.

Often, the same is true when a marketing manager or CEO is selecting a vendor to develop their website. Seldom do they have a deep understanding of what makes a good application (or developer), so they'll typically pick the second least expensive vendor within their budget range (cheapest is risky, but don't want to waste too much money) that they felt comfortable with and go from there.

The immediate responses to this are that (i) website developers would probably be more successful by investing in their rapport skills than investing in their technology skills and (ii) ability to elicit budget is one of the biggest predicators of success in a quotation process (two things I've found over the years to be pretty accurate). But let's dig deeper . . .

[More]

There is a fundamental principle in sales and marketing that risk reversal is a good idea. There is a reason why direct mail marketers (who test offers religiously) all have those cheesy "get double your money back if you don't completely love . . ." offers - they work.

In programming though, what is the right way to handle development risk?

[More]

One of the biggest problems I am struggling with on fixed bid contracts is the difference between build time (which is to some extent under the developers control) and contact time (which often isn't) . . .

[More]

As a developer, I've been known to complain about some of my clients from time to time. However, and interesting question is whether - as developers - we CREATE some of the bad behaviors of our clients. Here are three ways I've personally seen developers create bad clients (and how you can avoid them) . . .

[More]