Path to Nowhere

Path to Nowhere

If you don’t know where you are going, every road will get you nowhere.

Henry A. Kissinger

60% of IT projects fail to deliver the promised functionality, run over budget, slip or get cancelled (Oasis)

Unfortunately the odds are not on our side to make IT projects successful. Projects can fail in many more ways than they can succeed. If the probability of success is Pi, failure  Pj, Σ(Pi+Pj)=1 and O[j]>>O[i], then Si>>Sj where S=-KΣPln(P), where K is the Boltzmann Constant.

Entropy (S) in closed systems loves to grow, so IT project failure is natural. Fortunately IT projects are not closed systems. We can pump-in money and effort to create local entropy minimums.

OK, it is totally silly to apply Statistical Thermodynamics to IT projects, but regardless of the lack of a scientific proof, IT projects are hard and often lead to surprises:

Top three reasons for IT project failure (Chaos Report):

  1. 12.8%  Lack of User Input
  2. 12.3%  Incomplete Requirements & Specifications
  3. 11.9%  Changing Requirements & Specifications

 Relative cost of fixing failed IT projects (Effective Methods for Software Testing):

  • Requirements Development                                            1
  • Design                                                                                3-6
  • Implementation                                                                  10
  • System Acceptance Testing                                             15-70
  • Operation                                                                           40-1000

It is best to catch problems while the investment is still moderate. This is after the design is fairly solid, but before the implementation has started. As the famous architect Frank Lloyd Wright wrote, “You can use an eraser on the drafting table or a sledge hammer on the construction site.”

The previous data suggests the following approach to reduce the IT project failure rate:

  1. Formalized stakeholder involvement (Governance, Portfolio Prioritization and good IT Project Management practices)
  2. Methodical approach to Requirements Development (Agile, Scrum etc. require a somewhat different approach)
  3. Process to review design elements and assure traceability to requirements (Technical Design Review)

Methodical approach to Requirements Development

This little write-up is focusing on anti-patterns related to requirements. Requirements development is a structured way of listening and developing of common grounds, a sort of IT Glass Bead Game of Hermann Hesse’s Nobel winning novel.

What can go wrong with listening to IT stakeholders before providing a solution?

1.    Gathering the functional requirements (WHAT) but missing the non-functionals (HOW):

These include Performance, Capacity, Security, Scalability, Reliability, Availability, Supportability etc.

2.    Not capturing important attributes and establishing requirements change management:

  • Unique Requirement ID and version history
  • Description
  • Source (use case, stakeholder, constraints, rules and regulations etc.)
  • Priority (Must Have, Should Have, Could Have, Won’t Have)
  • Type (Functional, Non-functional)
  • Traceability (related design elements)

3.    Bad Semantics, writing requirements which are:

  • Unnecessary              ”Solution shall fulfill  customer requirements”
  • Ambiguous                 ”User friendly interface is needed”
  • Too wordy                  ”Popup should have a button. The button of the popup should be clickable ”
  • Inconsistent               “Import data from legacy system”<-> “Discard legacy data”
  • Incomplete                 “The application shall interface with some of the asset management databases”
  • Unreachable              “The system shall provide good response time”
  • Non-verifiable           “Solution shall improve the procurement process”

4.    Bad Syntax, using language constructs that make the requirements fuzzy:

  • Passive voice             “The software could have built-in role based security”
  • Compounds               “Report shall provide overview of  inventory and deliver it to  buyers”
  • Negatives                    “The system shall deny access to users without a valid ID”
  • A/B statements          “The system shall record user login in an audit/history table”
  • Adverbs                       “Transaction shall complete in a timely manner”
  • Omissions                   “Create good solution for customer problem”
  • Synonyms                   “The server config shall be documented. For each node set up a separate folder.”
  • Pronouns                    “System shall record error in log. It shall store for at least 60 days.”
  • Abbreviations            “Shall provide the DoD DIB information sharing MOU”
  • Open ended lists      “Employees, contractors etc. shall have read access”

On Monday set up your listening device and apply a methodical approach to requirement development. It can take you one step closer to successful IT project completion.

Recent Posts