The Problem

Creating a Web Application has all the same pitfalls as any other software project:

  • Unclear Specifications:
    Standard design documents leave a lot of room for error. The best images and textual descriptions still do a poor job describing dynamic applications. Add in the possibility of outsourced developers in other locations and the possibility of miscommunications is huge.
  • Missed Deadlines:
    Software projects are chronically late. Time estimates are often off by a factor of two or more. Changes to the scope and detail of the specificaiton during implementation only add to the problem.
  • Too Many Changes Too Late in the Schedule:
    Stakeholders always include their latest great idea after the specifications and estimates have already been made, resulting in the dreaded "feature creep". Late changes often require deep adjustments to the architecture of the application. Quality Assurance schedules are compressed and the worst problems are discovered very late in the timeline.
  • Cost Overruns:
    The direct costs of delays and rework are obvious - more time and more programming means spending more money - often a lot more. But the indirect costs are probably even more expensive: the stress of long hours on your team, delays getting to market means lost revenue, and bugs or other deficiencies adversely affect your reputation.
  • Failure to Meet End User Expectations:
    Market Validation, User Interface evaluation, and other reviews by stakeholders and end users typically happen at Beta Release, if at all. The result? Functionality no one wants, user interfaces that are awkward, or worst case - a product with no market.

The impact of these problems are large. You probably already know what its like to spend thousands of dollars more than you planned and hundreds of hours beyond what you scheduled. You may know what's is like to have lost customers due to a delay. You may have seen your competition beat you to market with a similar product.

Organizations that develop web applications need the following:

  • A "visual specification" to actually show dynamic application behavior rather than just describing it.
  • To do Market Validation as soon as possible, to ensure the application makes business sense.
  • To allow stakeholders to fully realize the scope and functionality of the application early in the project.
  • To perform User Interface focus groups before underlying architecture has been designed.
  • To clearly communicate expectations to development Teams, especially outsource partners.
  • To effectively start pre-sales and marketing well before the release date.

In short, there needs to be a way to cost effectively and time effectively simulate the web application before it has even been written.

The WARP Solution