Definitions / ROI

Definition of payback period

Posted on:

We’ve talked previously about using ROI to determine which projects to fund. This isn’t the only way to make those decisions, as Ski points out with the concept of flush. Payback period is the measure of how quickly an investment returns the invested amount, or the break-even point in the investment.

Foundation series / Software development / Test Automation / Testing

Software testing series: Pairwise testing

Posted on:

Very large and complex systems can be very difficult and expensive to test. Often, we inherit legacy systems with multiple man-years of development effort already in place, in the field and of unknown quality. With these systems, there are frequently huge gaps in the requirements documentation. Pairwise testing provides a way to test these large, existing systems. And on many projects, we’re called in because there is a quality problem.

Marketing / Requirements / Software development

We must sell the software first

Posted on:

We write a lot about value-driven prioritization of software requirements. It’s easy (when defining requirements) to forget that we have to sell the product before anyone gets any value from it. With internal use software for large companies (like enterprise software, intranets, erp systems), “sell it” means “get high user adoption rates.” High user rates are key to getting ROI when process-improvement is one of the targets of the software.

Project Management / Requirements / Software development

Managing scope creep is not a zero-sum game

Posted on:

We’ve never had a project where we didn’t have to address scope creep. As a supplier, we prioritize loyalty and relationships above incremental profitability. Project management techniques for addressing scope creep do us a disservice by starting with the presumption that resources have to be managed in a zero-sum game (every new feature must displace an existing feature). In this post we will talk about the opportunity to strengthen the relationship with our customer as part of addressing scope creep. It is not a zero-sum game.

CMMI / Process Improvement / Software development

What CMMI level should we use?

Posted on:

The CMMI (Capability Maturity Model Integration) of a software development process is the measure of that process’s capability. The goal of the measurement is to provide an assessment of the capability of a process with respect to creating software. Our foundation series post on CMMI provides background information, while this post focuses on the danger of misusing CMMI ratings.

CMMI / Foundation series / Process Improvement / Software development

Foundation Series: CMMI Levels Explained

Posted on:

CMM is a numeric scale used to “rate” the maturity of a software development process or team. In this context, maturity can be thought of like enlightenment. An immature process is not much different from the old “infinite monkeys” yarn – maybe we get it right, but probably not. A fully matured or enlightened process not only does it right, but improves itself over time. The Software Engineering Institute (SEI) at Carnegie Mellon, my alma mater, created the CMM model in the late 80’s and early 90’s. In this post, we will understand what each level represents.

Requirements

Software requirements for migration projects

Posted on:

A very common enterprise software project is the replacement of a legacy system – migrating functionality to a new system. This type of project usually has very different constraints than a “new application” project. We will look at the characteristics of migration projects to understand how we should approach them to assure success.