Managing Product Development

Jim, in his comment on Intuition is Not Enough for Knowing About the Project Portfolio, said:

I am having trouble with the definition of the word “value” in this context. Do you mean showing progress, as in earned value, or value to the customer, such as in ROI or payback period? Value has become a loaded word. Please define your terms.

To me, value is some visible form of progress. I prefer working product. I can live with a demo. I can live with a prototype. In some very small number of organizations, I can briefly live with a document. A document ceases to be visible progress after a very small period of time, such as a few days, maybe a week. Demos and prototypes also lose their value over time, if they do not become working product.

Managers can’t make good decisions about the portfolio if they can’t see visible progress, so they can tell if the money they’ve spent is worth the time they’ve invested.

If I really knew how to calculate ROI (and not make it be a number I can just make work), I would use ROI. But that’s a bigger rant for another time.

My PM students are articulating insights about projects that I’m happy to see. One project team said this in their charter, “The value of the product is moving the paper successfully across the room. The value of the project is in the journey, not the destination.”

Some projects exist to see if the project team can proceed with a project — any project. For example, a Hudson Bay start, where you organize a project team to deliver something, to make sure everyone on the project understands how to do his or her part, is a project-within-a-project. (See here for some discussion on it.) The idea behind a Hudson Bay Start is that you move something through the entire project, from requirements through architecture and design, into implementation, test, and release. By trying everything on something small, the entire project team will see where they are more likely to run into trouble on big things.

Some projects exist to create some form of capability within the team. For the class, each team is learning how to set up and monitor projects — a new capability for some people. This project will be a success for each team if the teams learn how to set up projects for success — not if the team creates the deliverable.

Each project has a specific value to the organization. Sometime the value is in the deliverable. Sometimes the value is in increasing the capability of some or all of the people on the project team. Maybe the value is yet something else. No matter what, the effective and pragmatic project manager will define the value of this project early so that everyone understands it. When everyone has a common value project goal, everyone can focus their efforts on that value and no other value.

I was at the Rational User Conference last week. I took away one significant idea from the keynotes and one of the track sessions: Writing software, according to Grady Booch is a “priviledge and a responsibility.” Systems are becoming more complex because we need them to do more things faster. We need people who can increase their value to the organization by providing these systems, taking their responsibility seriously.

Gary Cernosek gave a thought-provoking presentation in “Evolution of the Developer Role.” His premise was the developers need to turn into architects. I’m not sure about that. I do agree that continuous design a larefactoring is necessary and that developers as do all of us need to continuously increase their value to the organization.

If you’re not increasing your value to the organization every day, you’re becoming less useful and more expensive. And, you’re becoming a commodity. Commodity goods and services move to the cheapest provider.

I wrote about this earlier here, and suggested how you consider your career growth here.

David Anderson has an intriguing post, Lawyers, Unit Tests and Performance Reviews. David says “Individual team members can be set specific goals and behavior objectives…” and gives examples. I prefer that team members set their own goals with input from their managers. But the key here is that a technical person should be looking to increase his or her value to the group all the time, with some way to measure that at performance reviews.

Managers who perform continuous career development with their staff (which means every week in a one-on-one, not just in a yearly performance review) gain benefits for their group and the company. Their group increases its capacity, which in turns helps the company.

If you’re a technical person, consider improving one of the four areas of technical skills (See this post for one idea about how to think about it. And any improvement you make in your non-technical skills such as verbal and written communications, influence, negotiation, or facilitation skills will certainly improve your value. If you’re a manager, review your management skills and think about how you can improve them.How have you provided more value than you did a year ago?