Features and Requests (So you want to be a Domino developer - Part 1)
My little graphic drew a bit of attention. Patrick seems to be particular interested in Project Management and Prototyping (which I labeled "Software Lifecyle" and "Features & Requests"). So I start off with Features & requests. I will focus on the initial gathering of features, not on the tracking and change management (that will be covered in "Software Lifecyle" at a later point in time. We all have seen this:
Since Notes and Domino is a rapid development environment asking the right question, the right way, at the right time to the right people is essential. Changing functionality gets exponentially more expensive with the implementation progress of your project. You should so a reality check in your environment: how long does the initial feature set on a new rollout survive before it is "amended until you can't recognize it anymore" (this is a fancy expression for saying: "Thrown away and rewritten").
Depending on the time and intended scope you have different courses of action. When you think big (both time and scope) it is very smart to use a tool like ideaJam to collect features and feedback. When you are closer to the users, getting them into a room (buy them lunch) and brainstorm ideas there. Very important: talk to the actual (or future) users. Talking to the IT guys doesn't cut it. Sometimes, especially when you are an external consultant, that is hard. Nevertheless insist on it. It will bite you later on. When you only listen your project is at risk too. You need to watch what your users are doing. Collect some work artefacts. Watch out for the stickers that go with paper based processes (and all the handwritten notes on the margin), they show where processes are incomplete or broken. Users might not be comfortable being watched what they do, so reassurance and dialog are critical. If you take notes without sharing what you noted down you create suspicion and risk to alienating a potential supporter.To get the permission of the users to watch them you sometime need a fancy word for it. Luckily there is one. This approach is called Contextual Inquiry. There is an excellent book written by Karen Holtzblatt and Hugh Beyer. Ten years old this book is a classic and fits well into a Domino design approach. I'm always puzzled how little this approach is used (at least in this part of the world).
Once you got a collection of request and features you can use card sorting, affinity diagrams etc (see the book) to prioritize features. How to deal with moving requirement targets is part of a later post. Never commit the basic sin of feature tracking: a word processor or an email folder are no place to keep features. If you get a feature list in a word processing format (or an Excel table): Rip it apart. Feature tracking is a database task, full stop. You don't track them in a database: feature creep will kill you. The bare minimum is to use a standard notes template (Discussion, Teamroom or something from OpenNTF) for tracking. Make sure the users have access (at least reader, better author and some workflow behind it). If your customer is techie or a digital native, you could consider TRAC or one of the commercial offerings (Rational has some). Make sure your target users are OK to look and contribute.
Collecting good requirements is an art. If you are totally lost, read Alistair Cockburn's Writing Effective Use Cases. Things to watch out: Collect business requirements, not steps what to do. While it is good to know how the users currently work, this is not a requirement. A software system is supposed to change the way users work, not enshrine it. Of course it has to empower users not enslave (otherwise resistance will form). So ask for the intent: Why are they doing it, what is the purpose, who needs to know, what can go wrong, what is cumbersome, how would your dream system work.
So you need to get from: "I want to click a yellow button and then an eMail is sent to all these people with return receipt so I can chase them if they don't reply within 2 days" to "The system will notify the process participant of the required action and track completion of the action for all individuals" (and somewhere in the assumptions you might have: "all participants have access to the corporate intranet"). Only the later requirement allows you to propose something else instead of eMail (e.g. a RSS feed, a Instant Messaging ping, a user defined notification etc.). Also don't fall for commonplace "killer" requirement. "The system must be user friendly". So it has to say "Good morning and thank you"? A little wartime story here: I was designing a reporting system for accounting. The initial requirement was: I need to enter the account numbers to be included in the report. I felt entering a seven digit account number is pretty user-unfriendly and suggested to select the account name from a list in a dialog. I learned very fast (while paper prototyping) that picking the account name from a list actually was very user-unfriendly. At least for the intended users of this system. They were all professional accountants and lived in numbers. They could enter a column of 100 numbers faster than Jessie James could pull his colt. So back to a number field and an optional helper buttons for the apprentices in the first week (after that assimilation usually was complete and breathing numbers kicked in. Moral of the story: User-friendly comes with the constraints of: specific users, specific context, specific task (which is actually defined in ISO 9241-11): " Usability is the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.".
Now you have requirements, business intent, workplace artefacts (of how it is done now). Typically, looking into the textbook this would be the point where you prioritize and define the implementation sequence (asking your users of course). However this is the best phase to step back and (using an IBM stereotype) think outside the box. Most users appreciate when you come back with questions: "If the system would do x and y, how would it change the way you work?, Would something break?" Of course you need to have users who are not phobic to change. Careful wording is essential and never ever let this slip out of your mouth: " Aaaah.. that is so stupid, why do you do such complicated thing, my granny would be more efficient than that" Take that extra round and go back to your users with questions and what-if scenarios. Remember changing functionality at this point is cheap. You either really find an improvement or at least get a better understanding of what is important in the system.
Now you are good to go. Are you? Domino makes it very tempting just to whip up a few forms and views to verify design with users. When an application is small and you have an established practice that will do. One of the tricks I learned: I design a form completely without fields (but field labels). Then I show that to the key users to get feedback: everything is there, nothing is missing etc. Saves the time to edit code that is moving. For bigger systems you want to try Paper Prototyping. Ideally you revisit (on a higher and higher level) your requirements every iteration and adjust them to the unfolding reality of users' needs.
The good, the bad and the ugly of these skills: The good - it is 100% platform independent, the bad - you need to practice a lot, the ugly - you need to do quite some selling to management for this approach.
Since Notes and Domino is a rapid development environment asking the right question, the right way, at the right time to the right people is essential. Changing functionality gets exponentially more expensive with the implementation progress of your project. You should so a reality check in your environment: how long does the initial feature set on a new rollout survive before it is "amended until you can't recognize it anymore" (this is a fancy expression for saying: "Thrown away and rewritten").
Depending on the time and intended scope you have different courses of action. When you think big (both time and scope) it is very smart to use a tool like ideaJam to collect features and feedback. When you are closer to the users, getting them into a room (buy them lunch) and brainstorm ideas there. Very important: talk to the actual (or future) users. Talking to the IT guys doesn't cut it. Sometimes, especially when you are an external consultant, that is hard. Nevertheless insist on it. It will bite you later on. When you only listen your project is at risk too. You need to watch what your users are doing. Collect some work artefacts. Watch out for the stickers that go with paper based processes (and all the handwritten notes on the margin), they show where processes are incomplete or broken. Users might not be comfortable being watched what they do, so reassurance and dialog are critical. If you take notes without sharing what you noted down you create suspicion and risk to alienating a potential supporter.To get the permission of the users to watch them you sometime need a fancy word for it. Luckily there is one. This approach is called Contextual Inquiry. There is an excellent book written by Karen Holtzblatt and Hugh Beyer. Ten years old this book is a classic and fits well into a Domino design approach. I'm always puzzled how little this approach is used (at least in this part of the world).
Once you got a collection of request and features you can use card sorting, affinity diagrams etc (see the book) to prioritize features. How to deal with moving requirement targets is part of a later post. Never commit the basic sin of feature tracking: a word processor or an email folder are no place to keep features. If you get a feature list in a word processing format (or an Excel table): Rip it apart. Feature tracking is a database task, full stop. You don't track them in a database: feature creep will kill you. The bare minimum is to use a standard notes template (Discussion, Teamroom or something from OpenNTF) for tracking. Make sure the users have access (at least reader, better author and some workflow behind it). If your customer is techie or a digital native, you could consider TRAC or one of the commercial offerings (Rational has some). Make sure your target users are OK to look and contribute.
Collecting good requirements is an art. If you are totally lost, read Alistair Cockburn's Writing Effective Use Cases. Things to watch out: Collect business requirements, not steps what to do. While it is good to know how the users currently work, this is not a requirement. A software system is supposed to change the way users work, not enshrine it. Of course it has to empower users not enslave (otherwise resistance will form). So ask for the intent: Why are they doing it, what is the purpose, who needs to know, what can go wrong, what is cumbersome, how would your dream system work.
So you need to get from: "I want to click a yellow button and then an eMail is sent to all these people with return receipt so I can chase them if they don't reply within 2 days" to "The system will notify the process participant of the required action and track completion of the action for all individuals" (and somewhere in the assumptions you might have: "all participants have access to the corporate intranet"). Only the later requirement allows you to propose something else instead of eMail (e.g. a RSS feed, a Instant Messaging ping, a user defined notification etc.). Also don't fall for commonplace "killer" requirement. "The system must be user friendly". So it has to say "Good morning and thank you"? A little wartime story here: I was designing a reporting system for accounting. The initial requirement was: I need to enter the account numbers to be included in the report. I felt entering a seven digit account number is pretty user-unfriendly and suggested to select the account name from a list in a dialog. I learned very fast (while paper prototyping) that picking the account name from a list actually was very user-unfriendly. At least for the intended users of this system. They were all professional accountants and lived in numbers. They could enter a column of 100 numbers faster than Jessie James could pull his colt. So back to a number field and an optional helper buttons for the apprentices in the first week (after that assimilation usually was complete and breathing numbers kicked in. Moral of the story: User-friendly comes with the constraints of: specific users, specific context, specific task (which is actually defined in ISO 9241-11): " Usability is the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.".
Now you have requirements, business intent, workplace artefacts (of how it is done now). Typically, looking into the textbook this would be the point where you prioritize and define the implementation sequence (asking your users of course). However this is the best phase to step back and (using an IBM stereotype) think outside the box. Most users appreciate when you come back with questions: "If the system would do x and y, how would it change the way you work?, Would something break?" Of course you need to have users who are not phobic to change. Careful wording is essential and never ever let this slip out of your mouth: " Aaaah.. that is so stupid, why do you do such complicated thing, my granny would be more efficient than that" Take that extra round and go back to your users with questions and what-if scenarios. Remember changing functionality at this point is cheap. You either really find an improvement or at least get a better understanding of what is important in the system.
Now you are good to go. Are you? Domino makes it very tempting just to whip up a few forms and views to verify design with users. When an application is small and you have an established practice that will do. One of the tricks I learned: I design a form completely without fields (but field labels). Then I show that to the key users to get feedback: everything is there, nothing is missing etc. Saves the time to edit code that is moving. For bigger systems you want to try Paper Prototyping. Ideally you revisit (on a higher and higher level) your requirements every iteration and adjust them to the unfolding reality of users' needs.
The good, the bad and the ugly of these skills: The good - it is 100% platform independent, the bad - you need to practice a lot, the ugly - you need to do quite some selling to management for this approach.
Posted by Stephan H Wissel on 04 May 2008 | Comments (1) | categories: SYWTBADD