The Other Side of Product Investment

If you are a project manager that does software projects, you deal with the “top side” of product investment all the time. Whether your teams are running agile like scrum or kanban, or whether they are running a phase-gated cycle (waterfall), you are focused on the decisions about organizing the investment into packages for release or deployment. You are running the factory which takes requirements in one end and (hopefully) spits working features out the other. You are working with the analysts or product people to ensure that there are enough requirements, stories, or ideas “ready to start” to keep the team occupied.

But what about the other side of product investment? We often talk about return on investment or ROI, but most organizations only use an ROI project to justify the investment. Some will go as far as to attempt to measure “hard” ROI numbers, but frankly even that is missing half the boat because it is hard to measure the impact of software capability on your organizations top line or bottom line. Without a body count, the best we can do is to infer the correlation of software capabilities to a movement in profitability and assume that the relationship is causal. When it comes to softer benefits like risk reduction, customer satisfaction, or employee retention, there is no reasonable way to measure “hard” ROI dollars.Continue Reading

Progressive Requirements Elaboration

In my former post about progressive elaboration, I promised some “examples” from different domains of software development. This is the first of these. As I said before, progressive elaboration is about acknowledging that we can’t know everything we need to get to done before we start.

One of the difficulties of requirements elicitation is to maintain a consistent level of detail, both in documentation and in our conversation with practitioners, subject matter experts, and individual contributors. Another typical difficulty is understanding whether requirements are sufficient to begin some subsequent activity like design or coding.

While some methodologies have made recommendations, most merely call out the need. This leaves it up to the requirements analyst to build their own practice. In fact, most analysts do not subscribe to any specific methodology that they practice. I have often used these interview questions for analysts that I expect to elicit and organize requirements for software applications.Continue Reading