It's All About the Tasks . . .

How do you handle the specification, acceptance and measurement of the web apps you build?

It's All About the Tasks . . .
What should a website do? When do you know that it's finished? How do you agree that it is working correctly? In the past, these questions have often caused disagreement between clients and developers, but there is an easy approach that allows clients and developers to agree on and create strategically valuable websites as quickly and cost effectively as possible. It's all about the tasks . . .

A website can most useful be though of as an application that allows various users to complete specific tasks. An e-commerce site might allow prospects to find and purchase products, existing customers to check their order status and site administrators to manage the product catalog and orders received online. A content management system might allow site administrators to maintain and update site content and allow site visitors to find out more about a company's offerings. In practice, the tasks that define a website are often more numerous and granular than in the examples above, but the basic concept holds: the goal of a website is to allow certain groups of users to achieve specific agreed tasks. When you define a website in this way, specifying it, agreeing that it is complete and measuring its success all become much easier.

With this approach, the initial specification process becomes a matter of brainstorming tasks (many software engineers will call these "use cases" or "user stories"). For each task you want to describe what it is (e.g. check order status), what type of user might do it (e.g. existing client), why you want them to do it (e.g. cut down on customer service cost while providing 24x7 order status information) and where it seems relevant why THEY would want to do it (e.g. to be able to easily check order status even when you're closed). You'll probably find a number of roles that come up time and time again (e.g. prospects, existing clients, site administrators and employees) and may find you can come up with more tasks by brainstorming other things that users in various roles might want to do.

Once you have a list of roles, the next task (often best done using index cards) is ordering or grouping them by order of importance. The more accurately you can order them, the better. However, the key thing is that you distinguish between essential tasks and "nice to have's". The question to ask is: "would it be worth launching the website if it supported all of the other essential tasks but not this one?" If the answer is yes, then the task isn't essential - however much you might like to have it.

A good rule of thumb for any programming project is to keep the scope as small as possible consistent with it being worth building the application, so once you've agreed the essential tasks, the best next step is to build an application supporting just those tasks. A website isn't a brochure - you can always add the other tasks once the essential tasks are up and working for you, and then you'll have the option of doing them immediately while your new website is working for you or waiting if you're not sure how important those other tasks really are.

Once you've agreed the essential tasks, the next step is to design those tasks. Allowing a user to check his order status could be a couple of hours of programming or it could be a couple of weeks, so your developers will lead you through each task, asking the questions they need to be able to build a "good enough" first cut of each task for your review. If you are looking for a fixed bid, they will have to spend much more time specifying each task and you will have to be careful to explicitly describe everything you want, because anything not included within the agreed spec will not be included within the agreed price (this is why most responsible software companies now recommend an Agile development approach as it allows you to get the maximum value from your budget).

The process of specifying the tasks is all about going through the tasks screen by screen. What is the first screen the user sees? What do they click on? What happens when they do that, and what do they see? Doing that for the main path (what most users do), alternate paths (other options the user has - like setting advanced options) and error paths (what happens if the user fills out a form incorrectly, asks for an order that doesn't exist, etc.) allows the developer to get the best possible understanding of your requirements as quickly as possible.

Bear in mind, this process is hard and takes time. Sometimes clients want to leave this process to the developer. In our experience, while a good developer can guide you through this process and provide advice and suggestions based on their previous experience, it is essential that you be involved in the process otherwise it's like getting a custom designed house built without looking at the plans and then going in and asking the builders to change what you don't like! It is always easier and cheaper to be involved in the planning than to pay for developers to rebuild something that doesn't match your preferences. Also, the process of thinking through the tasks almost always brings up business rules ("well, some users can check orders for multiple companies and others only for departments within their companies") that the developer would never have caught without your input.

Once you've agreed the tasks, the developer will estimate the effort required for each task, clarify any dependencies, and at this point you might want to review your priorities. Sometimes you'll find a task more expensive than the value it will provide. Also, don't be surprised if some tasks have an estimated "discovery cost". If you want to integrate with a third party system or do something that is technically novel, the developer may have to invest anything from a couple of hours to a couple of weeks just to be able to estimate that task accurately. Typically you'll want to do those tasks (if you do them at all) as soon as possible, so you can plan an alternate approach if the final estimate doesn't fit within the budget.

If you see stories that look too expensive, also feel free to ask the developer for ideas on solving the problem less expensively. There is often a way of simplifying requirements that might not make much business difference but could substantially cut the effort required.

Once the tasks have been designed and the priorities reviewed, the development team will then start to build out the tasks. With an Agile process, the focus is on building whatever you want, so rather than comparing to the original spec, the developer will work with you to build whatever your changing needs dictate to get you the best site possible with the time available. If you chose a fixed bid, the developer will build tasks that meet the original spec and will then log the time for any revisions and will advise you when additional changes will affect pricing and delivery.

By taking a task based approach to website development, it is much easier to come up with a site designed to solve real business problems and to know when it's done. It is also easier to manage development priorities and make sure that the site provides the maximum ROI.