This book has the word application in its subtitle for a reason. Its about writing programs to be used by people, which is what applications are. The implication is that the success of your application development is entirely determined by whether people are satisfied with it.
Thats right. Even if your database is in third normal form, your PHP is object oriented, your HTML uses CSS (Cascading Style Sheets) to separate form from function, you use the latest Agile processes, and youve chased down all the bugs, it wont matter if the people for whom you built the system arent satisfied with it. It goes the other way around, too: if they are satisfied, theyll call your work successful even if you know it comes up short technically.
So, given that people determine success, its obvious that there are two things you absolutely need to know: who these important people are and how to satisfy them.
Who Are the People?
The people are your applications stakeholders: whoever hired you, direct users, recipients of reports, the CFO whos expecting cost savings, the CEO whos expecting better efficiency, IT (information technology) people running systems you connect with, and anyone else who has a stake in the success of the project. Its a mistake to take too narrow a view of users, probably encouraged by todays emphasis on usability or user friendliness. Those are important, but many of the constituents you need to satisfy will never use the application directly, and may not even ever see it running.
For example, when I started working on a student information system for the Richardson (Texas) School District, I first met with the IT director, who sketched the project for me. The next day I met with his immediate staff of three people who had been struggling with an outside vendor since the start of the school year, when they first started using a new system. Months later, at a meeting that included the assistant superintendent of elementary schools, it turned out that what they wanted from me was a simpler system just for elementary report cards, which, of course, I said I could build for them. We called it Rgrade (R for Richardson). As I got into the design for this new application, I met with more IT staffers, some teachers, two people who ran the servers in another building across town, another assistant superintendent in charge of assessment (a very big deal in Texas), and a few other people whose names and titles I never quite got.
Who in that list had to be satisfied to make my project a success, in priority order? You need to prioritize, because, of course, you cant satisfy everybody, at least not completely. Who had to be satisfied first, second, third, and so on?
Well, the first rule is that you most need to satisfy whoever hired you and pays you. (In Latin class years ago I learned that Roman soldiers were always paid directly by their general, never by the politician-controlled government, so the general could be sure they would be loyal to him.)
But, what would satisfy the IT director? He didnt give a hoot about any of the features of the system, how easy it was to use, how much it cost to run (within reason), or anything else technical about it. I dont know if he even cared whether the kids got graded. What I gathered from that meeting with the elementary school assistant superintendent was that the teachers were upset with the existing vendors system, and she wanted peace. The IT director wanted peace with her, since hes the one who had put in the current system they disliked so much.
So, the next constituency to satisfy would be the teachers who would be using the system. My list ended there; there was no third or fourth priority. The server people didnt matter, as long as I didnt bug them too much. The IT staff members were irrelevantthey would be happy if they never heard of elementary report cards again, ever. As long as the report cards got generated, the assessment guy was happy.
The point of the story isnt to present a formula for how to prioritize satisfaction or explain how school districts in Texas work (probably impossible anyway). The point is that, for any project, you have to come up with a complete list of all the people and understand what each of them wants, how their wants connect (IT director is happy if assistant superintendent is happy, which she is if teachers are happy), and how to maximize satisfaction.
Another example: I was vice president of engineering for a company that made a system for optimizing supermarket checker schedules, called SuperSked, which was sold to large grocery chains, such as Safeway and Kroger. This was a mostly off-the-shelf product, not a custom job like Rgrade. All of our customer interaction was with the operations department at the headquarters of the chain. The system was used by someone on the store managers staff, but we never met any direct users. Grocery profit margins are notoriously slim, so the labor savings provided by SuperSked were significant. Thats all operations cared about. Of course, the system had to be usable, but ease of use made no difference. If it saved money, the stores were going to use it, even if it meant entering data with the tip of their noses. Who did we have to satisfy? The operations departments.
Each case will be different, so you have to dig deep. Dont guess.
How to Satisfy?
Knowing who to satisfy isnt enough, though. You need to know how to satisfy them. Computer people call that how the requirements . Its simple: if the requirements are right, and you meet them, the people you need to satisfy will be satisfied, and the system will be a success. If the requirements are wrong, youll satisfy the wrong people or no people, and either way youve failed.
Ill talk much more about requirements in , so Ill just discuss them at a high level here. For Rgrade, they were easy to articulate: the teachers wanted to have a single, easy-to-understand form that they could put the grades into, choose teachers comments from a list (the district didnt allow free-form comments), and have report cards pop out in English and Spanish. The report card format was already defined, as were the Spanish translations of the comments. The output requirements were obvious: same report cards as they had last year and every year before that. As long as it did the job, what mattered most to the teachers is how quickly they could get the grades in. They usually did this work late in their workday, or even at home, and every minute spent on it was a minute taken from something else theyd prefer doing. Maybe lesson planning or helping students, or maybe watching football and drinking beer. But never Rgrade.
