Situational Application Brainstorm

In my last post, Designing Situational Applications I began to describe how to get started building your first situational application.

In this post, I'll describe a simple customer extranet. Perhaps these thoughts may help you design your own extranet. I will also construct a module based on the resulting application, so you can quickly add the result of these posts to your own Qrimp application.

In the example below, I will indicate some of the items that are People with Bold, Processes with Italics, and Things with Underline. Sometimes the item may be a Person or a Thing and will appear like Customers.

Customer Extranet Brainstorm

I want a system where customers can log in and check on the status of their custom projects. Before the project gets started, they contact us and ask if we can help them solve a particular problem. Different customers have different skill levels when it comes to technology, so they need different amounts of help to get started.

After customers create their project brainstorm, we will break down the brainstorm into sentences that correspond to individual items of work. We describe how complicated each unit of work is, how long we expect it to take, and how much it will cost to implement. The customer should be able to organize the items of work into iterations and prioritize them based on budget and system requirements.

We like to allow the customer to choose in an a la carte fashion which items they want now and which can wait. Like a shopping cart, the customer can add each item to a basket of tasks grouped into different phases of the project. Each phase may have several iterations. A phase could take a month and have 4 iterations for example.

During this time, we may have one or many meetings where the customer where we can ask questions and elaborate on the requirements where there could be confusion.

(Note to the reader: As an exercise, find the People, Processes, and Things in the rest of this brainstorm)

After the customer has chosen which items he or she wants to implement first, we send out an invoice for the first half of the project payment up front. When we receive payment, we begin work. The customer can log in while we are working and check on the status of each work item. The customer may want to know who is working on the item and communicate with the developer via messages.

When the iteration is complete, we should test the functionality and indicate any bugs we find or issues related to the item. Then we notify the customer that the iteration is complete and the customer logs into the application we have built to verify that it works as desired. If it doesn't, the customer can add an issue to a log or a bug report indicating that something needs to be changed. Sometimes the changes are within scope and sometimes they are out of scope, so we need to be able to indicate if something the customer may have thought was a simple change or perhaps we should move it to another iteration or phase.

When the customer is satisfied that all the work has been completed satisfactorily, we send out the invoice for the second half of the payment. We should let the customer see in their view of the extranet which payments have been received.

The customer should use the application for a little while before we begin the next iterations so that any ideas gained or issues found related to the previous iterations can be accommodated in brainstorms for future iterations.

Post Brainstorm analysis

As we dig a little deeper into the project brainstorm, we start to notice different kinds of verbs. For example, in the sentence, "Different customers have different skill levels..." The verb have is not in italics. It is a verb, but it is not an action verb, it is not something customers do, but rather something that describes a customer. These things that describe other things are what we call Properties. Perhaps one customer is skill level 8 and another skill level 4.

In the previous post on Designing Situational Applications, I talked about putting the Things in a chart with their properties. In our extranet, a customer might be in a chart that looks like this:

Skill Level
Email address

You may be wondering at this point, "Why does skill level matter?" Maybe it doesn't. Or maybe if we know the customers' skill levels it will help us communicate with them better. Maybe we can use skill level as a progress meter for our customer to help them see how much they are learning and give them an incentive to learn more. Remember, the goal here is not to be perfect with your description of the system, but to write down anything and everything that you think of.

There may be more users of your system than just you. This brainstorm is the beginning of a conversation between you and the developer (who may also be you). Anything that is left out at this very early stage could be more difficult to accommodate later, so it's best to get everything out as soon as possible.

Let's look at another sentence in detail, "We describe how complicated each unit of work is, how long we expect it to take, and how much it will cost to implement." Can you find the Things and properties for those Things in that sentence? Hint: Describe is a Process. Describing something usually involves typing out a (you guessed it) description of something. Typing out this description is part of a larger Process of Creating a unit of work. A unit of work is also a task, which is a more common and understandable term, so let's use that.

Here is a chart for a Task built from the sentence above:

Can you think of other properties of a task? Reread the brainstorm and consider these questions: Who is the task assigned to? What is the status of the task? Has it been completed? How does the task relate to other Things in the system? Are there any bugs or issues related to the Task? Does it require rework? Is customer satisfied that the task has been completed as expected?

As an exercise, write down all the People, Processes and Things in the brainstorm above. Put the Things in a chart with their properties. In the next post, we will begin to draw out some of these items and get more detailed.


5/20/2009 7:16:00 PM

In this post, I'll show you the kind of brainstorm that will describe a simple situational application.

Situational Application, building a system, custom system, brainstorm, web application design, requirements gathering

5/20/2009 8:06:03 PM





click to edit widget


+ add...