I get this question all the time because, let’s face it, it’s a significant decision. For example, an Enterprise Agreement (EA) renewal for an enterprise with the main desktop suite on, say, 10,000 PCs could cost around $1,500,000 per year. So what do you get for this outlay? You’ve already purchased a perpetual license for the relevant Microsoft products via your original EA, so the renewal is merely an extension of the maintenance element, which Microsoft calls Software Assurance (SA). Like most terms in Microsoft licensing, SA looks like an industry standard concept, but has sufficient Microsoft-specific nuances that confuses customers. The key differences from most vendors’ software maintenance offerings are that SA:
Is not tied to product support. Customers that aren’t paying SA still get access to patches, and can purchase additional support services from Microsoft or its partners on a time & materials basis.
Delivers upgrade rights that live on after the agreement expires. Customers earn rights to any version that Microsoft releases while they are on SA. So, for example, a customer paying SA on Microsoft Office for the next 12 months will earn the right to the next version, Office 14, due out at the end of 2009, even if it doesn’t intend to actually upgrade to that version for another 3 or 4 years
Includes many additional benefits that, though hard to value, are far from worthless. For example, the extra training, online e-learning and rights to use the same version on a home PC will certainly translate to more effective use of the software and enhanced user productivity, but it's very hard to give that a dollar value.
What we're doing The research into a research piece on best practices for requirements documents is underway. As anyone who has ever been responsible for requirements knows, there are two sides to this question:
The requirements process. The overt part of requirements is the process of writing them. The subtler part of the process is figuring out the information needed for the audience. Development (including QA and documentation) might be the primary audience, but they're hardly the only ones.
The work product. In other word, the actual requirements document. Or, in many cases, documents. For example, while there might be a template for feature requirements, it may link to related or supporting documents (personas, customer feedback, etc.)
How you can help As with any type of research, the larger and more representative the sample, the better. Which means that you, Dear Reader, can help make this research project all that it can be. In this case, we need your help with that second aspect of requirements, the work product.
Speaking of social media, one of the two research documents now in the editing queue looks at using social media as a source of product requirements. Using Forrester's POST* methodology as a starting point, how can product managers harness the enormous amount of potentially useful information transmitted in the clear through blogs, forums, Wikis, and similar technologies?
The other document in editing is the "Agile company" piece, covering the results of the survey and interviews we conducted to understand how Agile development changes technology companies. To foreshadow the results, I had to divide Agile adoption into two stages. To date, Agile aficianados have focused on the first, Agile within the development team. Clearly, for the story of Agile adoption, that's only Chapter One.
* In this approach, the steps for analyzing social media involve people, objectives, strategy, and technology (POST).
Forrester colleagues Laura Ramos and Oliver Young have posted some initial conclusions from the big "Social Technographics" survey for this year, which details how social media inform and influence people buying technology. You can read about the survey on Oliver's blog and Laura's blog.
Needless to say, this is fascinating stuff. The survey looks at each kind of online behavior (content creation, critiquing content, joining groups, etc.), and then tells you how much people in different segments of the population engage in these behaviors. Here's an example:
For product marketers, these data tell you how to reach your target audience. For product managers, the same information is critical for tapping social media as a new source of requirements data.
One of the hot topics during my visits with Forrester clients this week was requirements. How do other people do them? How do they change when development teams go Agile? Why is it so damn hard to re-use the information written for the development team for other purposes, such as training the salespeople? And so on.
I'll be starting some research on requirements in a month or so. Meanwhile, as busy as my writing agenda is, I can't help but ponder the topic. To complete the distraction, I was also reading some of Tyner Blain's recent posts on the topic, such as this interesting discussion about user stories and use cases.
To a large degree, requirements have to conform to the peculiarities of an organization. While there might be some Platonic ideal of requirements, manifested incompletely in this imperfect world of ours, there's no escaping the regular back-and-forth between the authors of requirements and their readership. Development teams have their own preferences for information, both quantity and format. You'd be a very bad product manager (and probably not employed for too long) if you were to ignore that reality.
During his press conference about the stimulus package the other night, President Obama sounded tired. The source of his fatigue didn't seem to be the size of the bill he was proposing. Instead, Obama sounded burdened by the changes to American society that were required to make $800 billion worth spending. Here's a representative quote:
We are going to have to work with the banks in an effective way to
clean up their balance sheets so that some trust is restored within the
marketplace, because right now part of the problem is that nobody
really knows what's on the bank's books. Any given bank, they're not
sure what kinds of losses are there. We've got to open things up and
restore some trust.
Now, maybe philosophically you just don't think that the federal
government should be involved in energy policy. I happen to disagree
with that; I think that's the reason why we find ourselves importing
more foreign oil now than we did back in the early '70s when OPEC first
Obviously, it's important to handle customers deftly when you can't comply with their requests. You'd like to keep the conversation friendly, but sometimes, the situation gets confrontational. Your diplomatic skills will face their toughest challenge.
All politics is local I might have been unusually blessed with reasonable, understanding customers, but I never found the "foreign policy" part of saying no to be that difficult. The real headache, at least where I've worked, was "domestic politics"--what happens within your own company when you have to say no to a customer.