Have you ever wanted to define the feature list for Active Directory? TEC Europe 2009 might be your best chance to do just that. Robert deLuca (Microsoft Senior PM for Identity and Access) and Dean Wells (Senior PM for Directory Services) will host a “Customer-Focused Design” session at TEC Europe September 14 in Berlin.
Microsoft has developed a very structured process for gathering products requirements. I’ve been through the process a couple of times in Redmond (and I’ve used something similar for my own products), and it is pretty effective for figuring out what requirements you want to focus your product team’s efforts on.
The process starts out with a bottom-up approach, where the people in the room just write down all the requirements they think are important on Post-It notes. The key thing here is volume, and for people to focus on the problem-space not the solution-space. Developers and IT Pros are predisposed to solving problems and invariably come up with ideas like “move the user account control bits to separate attributes” or “prune and graft the directory tree”. These are solutions to problems, not problems per se. The problems should be more like “I can’t control the access rights on the individual user account control bits in Active Directory”, or even better “I need to separately delegate the ability to set the No Password Required flag and the User Account Disabled flag”. See the difference? The first is a possible solution to a requirement the IT Pro has in the back of their mind. The second is the actual requirement. It’s really important to get everyone writing down problem-space statements, not solution-space statements. Otherwise the next step doesn’t work.
Once the moderator makes sure all the problems are legible and understood (IT Pros are not known for their high-quality handwriting), the second step involves sticking the Post-It notes on a wall and organizing them into affinity groups, i.e. grouping the requirements in a way that “seems to make sense”. This is a group activity, and can be really fun to participate in (and to observe!) Basically, you start moving the Post-Its around and inventing categories that seem to fit a group of them. The goal is to organize the requirements (perhaps more than a hundred of them) into a manageable number of higher-level topics. It’s always surprising how, given the vague instructions, people seem to instinctively organize things in pretty much the same way. Sometimes it takes a few attempts to get the categories right, but I’ve never seen a real argument in this process.
Now the drama begins. In the third step you need refine the categories you developed in the preceding step into full-fledged problem statements that reflect all of the requirements in that category. So everything that you grouped under “Schema” is now covered by something like “I need to manage the schema without special consideration like review committees and or replication latency and be able to provide a complete audit report of all schema changes.” Honing the requirements statements takes a lot of back-and-forth discussion between the participants to make sure the problem statement reflects all of the requirements, and that it is reasonably coherent. Sometimes you have to go back to the board and re-categorize some of the requirements, and occasionally someone will decide their particular requirement just isn’t worth the effort.
The process I’ve described so far is one I’ve used for years in developing product requirements, and was taught to me by my friend Jared Spool at User Interface Engineering about 20 years ago, and it works pretty well. One of the problems with the process is that you end up with way more problems to address than you have time or resources. How do you prioritize them? Microsoft has added two steps where the participants rank how important each problem statement is to them, and how well or how poorly each problem statement is currently addressed by the shipping product. The first ranking gives them an idea of which problems they should focus on, and the second ranking gives an idea of how much effort they should expend on addressing the problem.
Normally this sort of thing can take most of an entire day, but for TEC, Robert and Dean are developing a skinnied-down process that should provide some meaningful results in the hour or so we have available. I think they are also going to use some of the birds-of-a-feather time to work on the problem statements. In any case, it will be a lot of fun.
So if you’ve ever found yourself completely frustrated because Microsoft didn’t fix your specific issues in Active Directory, come to TEC Europe 2009 and make sure your problems are heard and make it into the queue for the next version of Active Directory.