Tag: Scope Definition

Scope Definition Seminar for INCOSE ChicagoLand Chapter

Scope Definition Seminar for INCOSE ChicagoLand Chapter

On May 11, 2019 we presented our 1-day Scope Definition seminar for the INCOSE ChicagoLand Chapter Spring Seminar offering to their membership.  This was a natural follow on seminar to the Writing Good Requirements seminar we presented at the 2018 Spring Seminar.  Feedback from the attendees indicated the seminar was very well received!  One of […]

Scope Definition Seminar in Chicago

Scope Definition Seminar in Chicago

Hi all, I will be giving a 1-day seminar on scope definition for the ChicagoLand INCOSE Chapter on May 11, 2019 for their Spring Tutorial. Last year I gave our 1-day Writing Good Requirements seminar which was very popular and sold out quickly.  That seminar focused on writing requirements that have the characteristics of well-formed […]

Join us for our upcoming LIVE Webinar

Join us for our upcoming LIVE Webinar ArgonDigital - enterprise automation experts

Case Study: Vasa Warship Project The Vasa was a Swedish warship that was built over a period of four years, 1625 – 1628…it sank on its maiden voyage sailing all of 1300 meters before being toppled by a small gust of wind.  Sadly, the factors that lead to the Vasa project failure are many of […]

Developing Agile Systems

Developing Agile Systems ArgonDigital - enterprise automation experts

In previous blogs we talk about Why do my requirements keep changing and Controlling and Managing Change during product or system development.   Change can also be addressed from the perspective of change that happens after the product or system is put into operations.  From this perspective the question to be addressed is: “Can the product […]

Baseline Your Scope Before Writing Requirements

Baseline Your Scope Before Writing Requirements ArgonDigital - enterprise automation experts

A major issue that contributes to cancelled projects is a failure to establish a shared vision of the final product at the beginning of the project. The reason for a new product or upgrade must be clearly understood before writing requirements, or divergent requirements will be written and important requirements will be missed. This vision […]

How Do I Know When My Requirements Are Sufficient?

How Do I Know When My Requirements Are Sufficient? ArgonDigital - enterprise automation experts

This question was asked recently on a popular discussion group. Maybe a better question to ask: “How do I know when the requirement set for the system of interest is “done enough” to give to the development team?” Where “done enough” is the point of time in the development process where the cost of potential […]

Agile and Requirement–Driven Product Development

Agile and Requirement–Driven Product Development ArgonDigital - enterprise automation experts

My previous blog described “Requirement-Driven Product Development” (RDPD). One of my readers asked a very important and well-formed question: “Lou, nice article. Are there any specializations to the approach for software systems? Would you say that Scrum process is consistent with RDPD? I expect that everyone agrees that requirements must drive development. The controversy is […]

How to Avoid Accumulating Technical Debt

How to Avoid Accumulating Technical Debt ArgonDigital - enterprise automation experts

In a popular online discussion group the following question was asked: “Why does technical debt accumulate? “Why do technical and functional project team members let that happen? What is technical debt? Personally, I had not heard the phrase “technical debt” before. Interested, I looked it up on the internet. What I found was that technical […]

Why are we doing what we are Doing?

Why are we doing what we are Doing? ArgonDigital - enterprise automation experts

A common problem we see on new projects is people jump into writing requirements without first answering the question “Why are we doing what we are doing?”  Many challenged projects (e.g., over budget, behind schedule, not meeting quality standards) can trace their difficulties to the very beginning of the project where there was a failure […]