to come up with better estimates of how much it would cost? Were you able to come up with some sort of functionality size, kind of like the size of what each of these systems would be before you get started?
Paul: Right. The beauty of function points, actually is you can get a fairly good estimate of the size or how big the application is, early on in your requirements phase. So you actually have a good idea of how big this animal is before you start wrestling it. Then what I've done is ask people what's really important to them from an IT delivery stand. Speed, for example, was of utmost importance. Deliver it fast. There was obviously a quality piece to that. But then also I added the part about percent growth to the bottom line. How much is this application really going to provide growth to this company? If that was a major goal of ours.
Carol: Something like, potentially, say, automating a spreadsheet. If somebody just wanted a whimsical type of application, where they wanted to automate a spreadsheet, it might cost them $800,000 to just automate what they would do manually. You were able to start taking a look at that compared to some of your mission-critical things, and say, well, mission-critical things will deliver higher value to the company?
Paul: Correct. And you can play with those metrics, in terms of understanding what's important to the business at that time. Company goals will change over time, so you need to be able to be flexible to understand if you're measuring the right stuff to do the right stuff. We also go through a process called a Waterline process, where projects are prioritized based on the need to the business. And you only have so many dollars as an IT function, and you literally draw the line of where the projects stop and where the projects start. And if things below the waterline need to be done, literally you move it up on top of the line and take something off of the top. So you kind of swap things out as well, based on that.
Carol: It sounds like you actually gave something back to managers, who were not necessarily IT savvy, who were not necessarily in your department, to be able to set some priorities themselves and to be able to see and have some control over which projects that they think should get done first.
Paul: Yes. Absolutely. We just had that happen a couple of weeks ago. We did it with a roomful of vice presidents and functional leads, where literally we went through the 2001 operating plan, and based on priorities and needs, actually worked it out as an organization of priorities for projects to be funded for the next year.
Carol: Now, I'll play devil's advocate for just a minute. It seems to me like this is the way that every company should do it. That every company should have the measures, they should be able to figure out how big their systems are, how much value it should be before they get started. But, I have a feeling that what you're going to tell me is this isn't the way that most companies actually go about doing their priorities. And it doesn't sound like this is how you would have done it last year or the year before.
Paul: You're right. And it's not common…The problem is common, by the way, to every company. And not everybody is addressing it. And we tend to fall into our