< Zurück | Inhalt | Weiter >

11.6.1 Monday Morning, 10 A.M.

Bob gets called in to the office of his manager, Ellen. The conversation goes something like this:

Bob: Yes, Ellen, you wanted to see me?

Ellen: Come in, Bob. Yes. We’re just about to enter another budget planning cycle. We’ve got to propose our next year’s budget to the VP by the end of the quarter, and I got to thinking . . .

Bob: Uh-oh.

Ellen: . . . on my way to work today, I got to thinking that we ought to be able to develop a software tool that would help us do a better job of this process.


image

2. We’re avoiding giving Bob a title because titles vary so much within our industry. Call someone an analyst and it may mean that they never code. Call someone a programmer and it may mean that they only code and never deal with requirements or even designs. Some use those terms interchangeably. We’ll just call him an IT guy.


Bob: We’ve used a spreadsheet these past few years to do our budgets. You want us to develop another spreadsheet application?

Ellen: No, I want a whole new application.

Bob: You want us to reinvent the spreadsheet?

Ellen: No, I want something simpler and more specific to the budgeting process.

Bob: Tell me more. What are the key features that you see in this

application?

Ellen: Well, first of all it needs to be able to work concurrently with all the users. With our spreadsheet, we’d have to take turns with the data entry or we’d risk loosing each other’s changes.

Bob: It may just be that we’re not using our spreadsheet’s advanced

features. Shouldn’t we investigate that first?

Ellen: No, I’d rather have us invest our time in building the tool we know that we need. At the end of the day your investigation may only show that we still need the tool, and by then it might be too late to build it.

Bob: I hear you saying that the deadline is rapidly approaching.

Ellen: Yes—I want to be able to use it for the budget planning at the end of this quarter. How long do you think it will take you to build it?

Bob: Build what?

Ellen: Haven’t you been listening? The budget tool!

Bob: I know that you mean the budget tool—but you haven’t really given me enough requirements upon which to base an estimate. Tell me more about how you envision this tool being used.

Ellen: Well, in the past we’ve taken last year’s numbers and just bumped

them up by a few percent. Then we look at each category and tweak them. I want a different approach this year. I’m going to take our department’s budget, give it a bump, then assign a chunk to each of my reports. I want you to take those discretionary dollars and spell out how you would spend them.

Bob: Shouldn’t we be providing you with estimates of what we need for

the coming year, rather than you telling us what we have to spend?

Ellen: In theory, perhaps so. But in practice we can only grow the budget by so much. I’d rather skip the charade and jump right to allocating the dollars we will likely be able to spend. Then as the year progresses, I’d like to use this tool to track our spending against this plan.

Bob: But isn’t that why we have that big SAP application?


Ellen: Have you ever tried to use it?! Please! The CFO thought it looked great—and on paper it did. But that user interface makes it almost impossible to be productive. And it’s as slow as molasses.3

Bob: But back to this new application . . . I’m assuming you’ll want a GUI

on this?

Ellen: Of course. Give it a standard, simple GUI. Something like this.

(She begins to draw on her whiteboard.)

For any given department there will be a “pool” of money. Those dollars are displayed and can be subdivided into smaller pools of money by creating subaccounts.

But as the money is subdivided those new accounts and associated dollars should become visible by others. And as dollars are spent during the year, we’ll want to track those dollars, so those amounts should be visible, too, and subtracted from the overall pool of available dollars.

Bob: Wait . . . back up. What needs to be entered to subdivide an

account?

Ellen: The user just picks an account, then chooses to subdivide it, enter- ing the amount to put in each account . . . or even just a percent of the larger pot of money.

Bob: So if he picks one account to subdivide, does it split into two, or

three or how many?

Ellen: Let the user choose, but maybe two as a default.

Bob: OK, but we may need to take a harder look at that interaction.

Ellen: So how long will that take? Can you have it ready by the end of this month?

Bob: I’d like to try the “spiral” approach on this project. I can have

something for you by the end of this week— from which you can tell me if I’m heading in the right direction. It will just be a beginning, but you’ll be able to see something run. By the way, is this tool only for our group?

Ellen: For now it is, but I could see other departments wanting to use it

some day. Who knows how far it could go?


image

3. Remember, this is a fictional account. We are providing justification for why they can’t use the corporate application. Anyone’s use of such a tool can be less than optimal, reflecting more on themselves than on the value and usability of the tool.