Spec Reviews (Functional Specification Reviews)

Spec reviews at Microsoft are handled differently across the various product groups and teams but they all have some commonalities. In my 10 year tenure at Microsoft, I have participated in spec reviews for Windows, Word, Excel, Access, SQL, SQL Reporting Services, Visual Studio, numerous MSN offerings, various other Microsoft products in limited fashion and now Exchange Edge. Each of the spec reviews that I've been in have had their own flare, personality and style. Some spec reviews that I have been in were dominated by one person thus stifling the creativity and input from the others there and rendering the usefulness of the review to nil. I have also been in spec reviews which were non structured with seemingly no primary agenda other than just being able to check off the exit criteria of having a spec review.

The most productive spec reviews that I have attended have giving way to some of the best products that Microsoft has to offer including the spec reviews here in Exchange Edge. These spec reviews have active dialog discussions between the participants; a focused direction to achieve the goal of clarifying the functionality of the features, resolving open issues, defining the feature set while keeping the customer's best interest in mind.

A productive spec review cannot happen unless there is a well thought through written functional specification (spec) that has been created with feedback from the feature's architects leads and management from test, development and program management. After the spec includes the feedback from the team's leadership roles, feedback from partners and dependencies need included once the spec has all of the major details and issues covered relating to them. This interaction of the spec owner with the team's leadership roles, partners and dependencies keeps the key people involved and active in the creation of the spec and is essential to the review of the spec being productive and successful. The review of the spec will be randomized without having a well written spec with feedback from the key people. This is because discussions during the spec review will not come from a sense of ownership with prior knowledge with understanding of the spec's content and direction being taken.

Skip to main content