In an earlier post on requirements for migration projects, we defined a continuum of migration projects, ranging from completely new business processes to identical processes. In this post we will look at why companies approve identical-process migration, or duplication projects, and provide some tips on how to organize these projects.
Marketing / Requirements / Software development
Posted on:
We must sell the software first
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
Posted on:
Managing scope creep is not a zero-sum game
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
Posted on:
What CMMI level should we use?
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
Posted on:
Foundation Series: CMMI Levels Explained
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
Posted on:
Software requirements for migration projects
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.
Process Improvement / Requirements / Software development
Posted on:
Prioritizing software requirements across releases
When prioritizing requirements for the first release of our software, we’ve stressed the importance of including 100% of the ‘must have’ requirements in the first release of the software. We’ve also used Kano analysis to categorize requirements as ‘must be’, ‘surprise and delight’, and ‘more is better’ requirements. In this post we’ll talk about an approach to allocating these requirements across releases.
Agile / Interaction design / Requirements / Requirements gathering / Software requirements specification / UX
Posted on:
Interaction design explained by Alan Cooper
There’s a Clash of the Titans joint-interview posted at FTPOnline between Kent Beck and Alan Cooper called Extreme Programming vs. Interaction Design. It’s 10 pages of back and forth. In short, these icons agree on objectives, and disagree on how to achieve them. They also spend some time (mis)characterizing each other’s positions and defining their own. In this post we will look at how Alan Cooper explains Interaction Design. We would say that he defines interaction design more as a requirements than a design activity.
Consulting / Lists / Process Improvement / Project Management / Software development
Posted on:
Top ten tips for preventing innovation
At a recent presentation in Austin by Seilevel about the goals and methods of requirements gathering, a member of the audience asked “What can we do with our requirements to assure innovation?” That’s a tough question with an easy answer – nothing.
What if the question had been “What can we do to prevent innovation?” That’s a better question with a lot of answers.