Archive for October, 2008

Product Management vs. Project Management

Oct 26th

Posted by John Peltier in Requirements

4 comments

A frequent topic of confusion among software development organizations is the proper role of a project manager as compared with that of a product manager.  Let’s start by defining the terms:

A product manager is responsible for the marketing strategy, direction and features of a product throughout its lifespan.  A project manager is responsible for the success and progress of a project on behalf of the project sponsor.  The confusion in part can be alleviated by confirming that project != product. A product by definition lives beyond individual versions; whereas in most organizations, a specific version of a product is a project.  This is articulated in more detail at How To Be a Good Product Manager:

Project managers are responsible for the successful delivery of a project — a one-time endeavor with a goal, scope, deadline, budget, and other constraints. A project manager will work to align resources, manage issues and risks, and basically coordinate all of the various elements necessary to complete the project. As they relate to products, projects can be undertaken to build a product, to add new features to a product, or create new versions or extensions of a product. When the project is complete, the project manager will usually move move to a new project, which may be related to a different product.

Product managers are responsible for the overall and ongoing success of a product. Once the project to build the product is complete and the project manager has moved on, the product manager remains to manage the product through the entire lifecycle. Other projects related to the product may be initiated, with the product manager being the one constant stream throughout, defining the project goals and guiding the team to accomplish the business objectives that have been defined.

As a product moves through its life cycle, changes are often conceived and added to the project roadmap.  The product manager, interested in delivering the very best product to the consumer, is an advocate of adding features that will make the product better or fix oversights regardless of the schedule.  The project manager, on the other hand, is interested in specifying an agreed-upon set of requirements and working towards their completion within budget and on schedule.  These interests are inherently in conflict.

The answer?  In my view, the project manager should be provided a list of stories or requirements for a release (or scrum) that are prioritized by the product manager, so that the project manager has the authority and the knowledge to add and remove stories/requirements as needed in order to come in close to deadline and budget–after all, everything will NOT go as planned, and not all of them will be done on time.  What isn’t handled in release 1 is simply held over or deferred for release 2.

In theory, over the course of several releases, as the product is able to meet more and more of the original set of requirements, that product has the chance to succeed in the marketplace.

, , ,

The Economic Downturn

Oct 25th

Posted by John Peltier in Requirements

No comments

What impact does the economic downturn have on your enterprise, and on the products you manage? The answer to that, truthfully, is unknown.

The product manager, as representative of the market, may be the role best suited to finding out what the market’s changes mean to your products. Calling customers to find out what effect the market’s turmoil has on their budgets and their short and intermediate term plans is probably a wise idea for all businesses, and the answers can only help to reduce the uncertainty.

What you do with the information is, of course, up to you and depends on the product and market. But don’t go unarmed into a battle of information.

, ,

Start with the Problem Statement

Oct 25th

Posted by John Peltier in Requirements

1 comment

For all the talk about bad products and poorly designed features, many companies don’t spend enough time listening to the market. Some think they do, but they listen passively and only hear feature requests. What really helps drive a great product is to listen actively and hear problems.

Working within the problem-solution paradigm inherently demands that we accurately understand what the problems are. If we start from the incorrect starting point, following the correct path to a solution will cause us to solve the wrong problem.

This interesting article goes into linguistics and considers not just the language of problem statements in terms of the words we choose to write them in, but from the broader perspective of the framework in which we think about them. Abstracting the problem to the correct level is essential in solving the problem, which is what we are all trying to do.

, , ,

Agile Modeling

Oct 25th

Posted by John Peltier in Requirements

3 comments

One of the challenges I encounter with producing customer requirements for consumption by a development team is overcoming the barrier of understanding. My company does not have dedicated business analysts, so the role of translating customer needs to development needs and architecture is typically handled by our developers. What if they don’t see the big picture of what the user wants, but instead only see a large collection of unrelated detail?

Organizing requirments in categories can help to provide a mental framework, but navigation becomes difficult past 2-3 levels. It’s becoming apparent to me that in order to bridge the gap, some diagramming and coalescing of requirements into pictoral form must be provided. The question is, of the tens of possible types of models, which types are most effective and therefore worth the time?

I’ve found a site that details numerous types of models and diagrams, and provides handwritten examples of each. The silver-bullet takeway from this site is the following:

“know a wide variety of modeling techniques … apply the right artifact(s) for the situation at hand.”

My current problem is that I’ve been away from my brief studies in UML during my Master’s program for six years, and I don’t have command of that wide variety of modeling techniques. I have, therefore, just shared with you the newest item on my personal to-do list…

, , ,

User Stories

Oct 25th

Posted by John Peltier in Requirements

No comments

My team is doing an experiment with user stories; I’m currently gathering requirements for a global licensing module to support multiple applications and regions in my company, and for that project, all goals and customer requirements are being written in the user story format.

User stories are loosely defined as a concise explanation of a need, the person with the need, and the objective that can be achieved by meeting the need. This provides context that a simple “The system shall…” statement cannot. On the other hand, because of the “As a ____, I need ____ so _____” format, user stories are conducive to wordiness. One suggestion to mitigate this risk is to write them initially on index cards–presumably if you’ve filled up the card, you know you’ve written enough or too much.

As for what to write on the card, following the format makes it relatively clear–however, analysis still needs to be applied so that the “I need _____” is completed with the “what,” rather than the “how.” I find it difficult sometimes to step out of the “how,” and sometimes find more “how” than I like to admit when I read old requirements, but the less of it, the better!

An idea that’s new to me is the acceptance story; this is a template that allows the analyst to designate how a requirement shall be deemed satisfied, with the following syntax:

Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…

This may be cumbersome to write for each requirement/story in a requirements document; my first thought, without having tried to implement these, is to write them for selected user stories only–presumably, those that could benefit from additional clarification. Any thoughts?

, ,

Non-functional Requirements Checklist

Oct 25th

Posted by John Peltier in Requirements

1 comment

When developing a new software application or working to architect a new platform, the realm of non-functional requirements poses a challenge to creativity. What *should* the system requirements be?

If your new application is to be built to integrate with older software, you must keep an eye towards the languages and frameworks used–because your new application may demand resources totally foreign to the older software you integrate with, which might demand a significant investment on the part of the users of your older application to move up to the new one.

Beyond that, what kind of performance metrics should be considered “ideal”? For an application that steps into new territory for your organization, is a response time for a particular operation of a particualr number of seconds (i.e. measurable) defensible, or even feasible? Is the proper definition of a response time more useful if it is generic, without reference to a particular number of seconds? Perhaps crafting measurable numbers that are derived from the measurements of competing software or similar applications is the answer.

More food for thought about areas to consider within the category of non-functional requirements can be consumed here.

EDIT: If you’re really in the mood for a load of categories to consider, here’s Wikipedia’s list of 70-odd Ilities for you to consider!

, ,
12»