Two new reports are available for download on the Seilevel main website Resources page. Both were written for IT executives and senior BAs/CBAPs, and both focus on scenarios common in enterprise IT organizations. The first report concerns Commercial Off The Shelf (COTS) projects, and ways to reduce the risk of IT project failure in these [...]

The IT side of M&A integration involves much more than an integration of IT systems; due to the business risk involved, and in the effort to create value from the M&A, it will demand complete, accurate, consumable software requirements. Done properly, it should really start with a negotiation of business needs, with the system integration [...]

In my last post, I outlined What Complexity Science Tells Us About Requirements. This post will focus on one of the key findings in complexity science: since complex adaptive systems are fundamentally unpredictable, an evolutionary strategy has a higher probability of success than a strategy that relies on prediction. In order to be successful, your [...]

Many, if not most, software shops prefer to use Agile instead of Waterfall. That makes sense, right? Short cycles where you see progress quickly that allows you to make changes without the sky falling; I like that too! Agile also affords a close environment where the team is co-located, so that communication can move freely, [...]

Call me crazy, but I’m of the opinion that all software projects need clearly defined requirements. This includes one-person projects. An aspiring, enterprising developer has just as much need for requirements as a large company implementing a global release. Now I know what you’re saying. Requirements are a way to communicate the business needs to the development [...]

They didn’t know the product development manager would quit one week into the project due to a disagreement over the correct pronunciation of agile. They did not know that top management was working on a secret merger, so the scalability requirements have doubled. They did not know that the business process analyst would elope and [...]

This is the second part of a two part series on the impact of software requirements on technical debt. Part 1 defined technical debt, delved into its importance, discussed its symptoms and summarized some strategies for paying it down. Part 2 discusses the specific impact that software requirements can have on technical debt. Brief Summary [...]

As consultants, sometimes we have clients that need many hours of training and help understanding what they should be doing in order to make the end product successful. Although we are hired to make a difference, to change the way our clients do requirements and make products, sometimes we encounter people or teams that are [...]

Conclusion to the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.” Short-change Time Spent on Software Requirements or Don’t do Them at All Don’t Listen to Your Customer’s Needs Don’t use Models Use Weasel Words Don’t [...]

Number 6 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.” Short-change Time Spent on Software Requirements or Don’t do Them at All Don’t Listen to Your Customer’s Needs Don’t use Models Use Weasel Words [...]