Earlier this week Scott Wright of Streetwise Security Zone and I got together and created a podcast exploring security issues that product managers wrestle with when they transition to a SaaS model to deliver their product. Scott in this podcast offers some great tips and advice on the following topics:
I highly recommend product managers visit Scott’s website and blog to expand their knowledge in security. Thanks Scott!
Your release plan is done (or as done as it’s going to be at this stage). Your best estimates indicate that the development team can probably implement the top 10 to 15 items to meet an acceptable window of opportunity. The team has committed to implementing the top 3 or 4 items in the backlog in the first iteration. So now what? Well, open Word with your trusty, well-used, highly refined requirements specification template and begin writing requirements. Right? WRONG! This template probably started with great lean-ness to it; but over time more sections were added to make it “complete” … until the next new section is added. I see this so often that I wonder why we do this. We essentially are asking our product management team to write full requirements specifications within a short period of time. If you have a small PM team, then it’s virtually an impossible request. The result is that requirements are late, incomplete, not at the right level of depth, maybe even all of the above. Which means that the development team will usually “wing” it, and the PM task turns into a retro-specing exercise. Whether using an Agile methodology or a Unified Process methodology, our development teams develop iteratively (at least they should). They focus in on the next iteration and “grow” the release as they move from iteration to iteration. They tackle the high risk items early in the project. Etc. Etc. So why are requirements managed differently? Maybe because the template was approved some time ago in response to some botched feature and no one took a step back and asked how this can be better performed.
The goal of documenting requirements is to record the needs of the users in terms that development can build from. In other words the spec translates what the user needs to solve one or more of their problems into a format that development can use to design and build from. The underlying goal is that the development team needs to understand what it is that needs to be built so that they can come up with a design and an estimate for effort and risk. Collaboration between product management (representatives of the customers) and product development is essential … throwing a fully-baked requirements spec over the wall does not constitute collaboration. Presenting the requirements in layers is a better approach to achieving the goal.
So let’s break this process down into three essential layers where we present information in ever increasing depth and amount until development understands what they need to do … and no further!
By managing your requirements iteratively you can put the appropriate amount of effort into your requirements that’s needed to achieve the goal (i.e. develpoment understands what’s needed from them). Do not waste your time writing requirements that do not add value to achieving this goal. In other words, once you have reached your goal, stop and move on to the next item.
Quick survey, show of hands … How many reading this post use email? 1, 2, 3, 10, 100 – ok everyone! Question #2 … How many use email for sending documents? 1, 2, 3, 10, 100 – ok everyone! How often have we seen email used as a means of sending a document over the wall – far too often. I’m sure you are thinking the same thing. Your email goes bing; you read it and think where did this come from. Email is supposed to be a communication tool; but it sometimes just doesn’t work.
What happens when product managers send their requirements document over the wall to the development team? In some cases, the designer interprets the document properly and the resulting design document properly reflects those requirements. However, in more cases than we’d like to admit to, the design does not even come close to aligning with the requirements. What happened? The product manager wrote everything correctly, but the designer didn’t interpret it the way the product manager intended. Something was lost in the translation.
The goal of a requirements document is to convey what the feature or capability must do. When things go awry, it’s most likely caused by misinterpretations. In other words, the product manager and the designer (or developer or analyst) need to be on the same page. The product manager must convey his thoughts and knowledge to the designer. In many cases a document attached to an email does not do this.
Here’s what I suggest …
Try it … I think it will help you to ensure that your development team truly understands what you want them to build. And please, don’t throw the document over the wall.