Whether you're launching a new Web-based application, extranet, intranet or Web site, your mission is to build something that meets usability, functionality, marketing and measurability requirements to generate positive returns.
In fact, according to a survey of technology buyers conducted in May 2002 by Dell Computer Corp., a majority of respondents said they regarded return on investment as their most important criterion in spending decisions.
With little room for error and finite budget and resource limitations, your projects demand attention to detail and granular specifications to keep them on time, on target and within cost estimates.
 |   |
| Seth Miller is president, CEO and founder of Miller Systems Inc., a technology consulting and award-winning Web development and engineering firm in Boston. He can be reached at seth@millersystems.com. |
Performing a proper project discovery and assessment can be a daunting and frequently avoided exercise, but the ROI can be exponential if the right strategic and tactical decisions are made early in the process.
What kinds of projects need detailed discovery?
Most horror stories about "feature creep" and budget explosion are usually the result of overlooked, under-researched, or underestimated requirements. The devil is in the details.
It's probably a fair statement to say that a static Web site with fewer than 50 pages doesn't require the kind of discovery process that this article focuses on. Sites of this nature typically just need a well-thought-out site content outline and design standards to be built on time and on budget. However, if your site or application meets any of the following criteria, there's a very strong chance that you'll need to go through a detailed discovery process:
- Your site or application involves an external or legacy system.
- Your site or application needs to be Web services-compliant (these projects are typically performed in Java 2 Enterprise Edition or the Microsoft .Net Framework).
- You are building or deploying any content management application (especially if you are building a browser-based administration interface).
- Your site or application employs e-commerce (however simple).
- Your site or application involves a database that is read from or written to by a Web-based interface.
- Your project is a complex multimedia piece (e.g., Macromedia Flash) that involves data-driven components (and is therefore programming-intensive, for instance, using ActionScript).
Projects that involve features or components as listed above are true software development projects and must be treated as such by beginning them with a detailed discovery phase.
What are the deliverables of a properly executed discovery phase?
All applications should be built from the user experience backwards. The point of discovery is to minimize unknowns from all angles. That means drilling in to each component of what's going to power the site or application.
The first phase of the process includes
- An executive summary of the business application.
- The major obstacles/challenges presented by the project.
- Mock-ups of critical use cases (preferably most screens in the application if at all possible -- to determine what every screen, button and control does and to map out all the permutations and combinations of the user experience) -- using tools like Visio, Inspiration or HTML, depending on the available skill sets of the discovery team.
- Well-documented site maps or workflow diagrams.
Once these top-level deliverables have been developed and signed off by the stakeholder(s) and/or client, technical deliverables, including database schemas (if part of your application includes the design of a new database or an enhancement to an existing one) and very granular business-object definitions, with descriptions and time estimates down to the function and method level, should be developed and delivered.
There's no sugarcoating this -- it's a lot of work. In a moderately complex development project, this is man-weeks of time. However, consider the costs of not producing these deliverables.
Making feature and specification changes during development negates the value of your original time and cost estimates, throws off all your development schedules, affects your plans for resource allocation and, perhaps most importantly, introduces new unknowns.
Although the concept is simple, the execution is not. You must know what it is you are building before you actually start building it. There's a marked difference between getting a team to agree on the overall goals and functionality of a project (this is easy) vs. actually getting the team to agree on every control and component that comprises the user experience that achieves those goals (very subjective and difficult).
A few pitfalls to look out for -- signs that you might be falling victim to a lack of discovery
Every project is different, but there are a couple of activities or signs that are probably good indications that you're likely to have time and budget overruns due to a lack of discovery:
Quick and dirty estimates. This is a classic first step on the road to feature creep. A client or stakeholder asks a project manager or engineer for a rough estimate on a small application or feature enhancement that seems simple and innocuous enough.
The project manager understands the general gist of the request, and in a few minutes, gives the stakeholder/client a ballpark estimate on what it will take to build it. No in-depth discussion has taken place; no drill-down has been performed into the back end implications of the request. No screen mock-ups are made, no changes to the object definitions or database architecture, however minor, are considered. Yet the product manager has now set a time and cost expectation that will be difficult and painful to change.
The bottom line? Estimates, no matter how small they seem, need to be very well thought out, documented, and signed off by the requestors.Caving in to schedule pressure. It's not uncommon for a product manager or engineer to allow a superior or client to bully them into committing to a date that they may not be comfortable with.
Frequently, the discovery part of the process is the first thing to be surgically removed from the project plan. Ironically, the discovery portion of the project is the only part of the project that can actually keep the project on track after it's completed; removing discovery is likely to increase the time and cost of the project in the long run.
In Summary
If a project estimate includes discovery, and the discovery phase takes as long or longer than the actual programming, there's a good chance that you have an excellent project plan. Assuming you have good programmers, discovery frequently takes as long as or longer than the coding itself.
Many project managers -- and more frequently, stakeholders/clients -- find this maddening and counterintuitive. For better or worse, it's just the way it is. Be an evangelist for this process. If you perform discovery correctly, it's natural for that process to be more time intensive than the programming.
The difficulty in this approach is selling the idea of discovery as part of the project as a paid engagement, especially if you're a contractor or service firm. The hard part about this for business-development people is that it's difficult to qualify an engagement if you really don't know how much it's going to cost, and it's hard to get a client to commit to a project if they don't have a true cost in front of them.
Smart clients will understand that paying for thorough discovery is essential to their own survival -- because they can't control costs if they don't understand the true scope of their own projects. Discovery ensures that they get that opportunity.