As a tech lawyer, I've been doing contracts for the custom development of software for years. As the Net took off several years ago, I started to do agreements for the development of websites. In many ways, these types of deals are similar. At the highest level, they both involve programming and can be mucked up quite easily.
When you begin to examine the literature on computer-related development projects, you can't help but detect a pattern. Projects routinely come in late and cost more than expected.
You'll see studies that say things like two-thirds of all projects come in substantially late and that the average large project misses its planned delivery date by 25 to 50 percent.
All too often, companies jump into outsourced development projects in a haphazard way. When they need speedy development, they choose high-risk practices, like signing a contract that hasn't been thoroughly reviewed, which actually reduces the likelihood of on-time completion. When the overriding goal is saving money, they often look to speed as a key to reducing cost. That's a fallacy. Speed usually drives costs up.
If you want your project to be the one that breaks the late and over-budget pattern, you have to have the guts to begin to do things differently. There is a better way. It starts with the five ``p's.'' ``Prior planning prevents poor performance.''
Consider this: If you're late for an appointment, is it better to take a few minutes to chart your course, or should you leave the house and figure out your route along the way? Common sense says that you should take the time to chart your path, but many development projects seem to follow the latter method.
Speed is often an overriding goal. You have an illusion of speed if you jump right in and have a flurry of development activity happening.
You feel good having skipped niceties like achieving a consensus within your own organization as to what the software or website will do, how it will do it and other related issues. You're downright heady about having cut lawyers out of the process so that they didn't have the time to nit-pick at silly issues like warranties, performance standards, and a clear statement of work.
The project is moving! Details like performance and maintainability can wait until the next project. As for testing procedures -- you'll know if it works.
But wait! There are better approaches.
One methodology to consider is what's called Joint Application Development (JAD). This methodology takes end-users, executives, tech lawyers and developers off-site, and away from distractions, for meetings where they work out the details of what the developers will create. The focus is on business objectives rather than programming details.
While these meetings do take time, they will generally shorten the entire process because a clear definition of requirements reduces change requests and haggling later.
An important aspect of JAD is that it requires top executives to be intimately involved in the planning process. This helps insure organizational buy-in and reduces the approval process for the contract that comes from this process.
JAD also shortens the requirements-gathering stage which, with some projects, can seem to go on endlessly. ``What do we want the software or website to do'' can lead to endless rounds of e-mails, meetings and political infighting. JAD gets the key players together so they can get it all on the table and quickly resolved.
Yet another way JAD can shorten the development cycle is by eliminating features of questionable value. A typical ad hoc requirements-gathering process often leads to lots of junk creeping into the project to satisfy the needs of various constituencies.
JAD can provide an effective forum for a full and frank discussion. The more you remove items from the project, the faster it can move and the less it will cost.
To make this process work, you need certain key players involved throughout. I emphasize throughout because JAD should be an intensive process, not a ``come and go as you please'' meeting.
It starts with the executive sponsor who ultimately will bear the go/no-go decision at the end of this process. Others include the end-user representative, developer, others with required specialized knowledge and the lawyers.
Lawyers who are skilled and experienced with these types of deals can help facilitate accurate and clear communication and minimize the likelihood of misunderstandings, which can only serve to slow the process.
JAD may seem like it makes work, but it doesn't. It's a time saver that you should try with your next significant project.
|