Scope or Generality

In a discussion with a colleague this week, I was trying to articulate how writing business capability requirements can help guide both development and software acquisition processes.  My explanation apparently was not very good, because he definitely got the impression that I was talking about some super strategic high level requirement that was not really

When Scope Is Variable

I have been working on an "Agile" product with our IT Project Standards and Governance group at work. When analyzing the values and principles that are espoused in our "gated" product, I realize that the difference between agile and traditional (waterfall) project methodologies is singular. There is all kinds of hyperbole around why agile solves

Software Capability Requirements

As stated in Business Capability Requirements, software capability requirements are correlated with a business capability requirement that answers the key questions why and how much. Systems designers, architects, and developers are better equipped to propose solutions, when they are aware of the benefits or value that a requester is expecting for their investment. They are

Practice, Rehearsal or Exercise

As leaders, we need to better distinguish between these three activities. In three domains that are "performance" domains, these words have somewhat different connotations. Professionals: Doctors and Lawyers practice – that is they perform their profession. They do not rehearse, nor do they exercise, at least they do not differentiate between the performance of their

Business Capability Requirements

Many times when software requirements are collected, organized and documented, the focus is on the software capabilities needed. But software capabilities are not sufficient to get business value. One must also document the expected pattern of integrating the software capabilities into the business process to understand how the value will be realized. Stating requirements in

Vendor Evaluation Framework

When your organization is a consumer of software capabilities and a producer of software capabilities, every project may be subject to a buy versus build decision. Many organizations struggle to have a rational repeatable process to make these decisions. Turf battles between IT and functional business units, personalities, experiences and emotions often become involved in

The Cause

Causes of problems are sometimes elusive. Symptoms are misleading, reporters expectations are misguided, layers of business process and automation, and years of workarounds and patch jobs render the situation very confusing. The cause of a problem has a category related to it's proximity to the symptom revealing component: Local cause – when analysis reveals that