Method for producing on-time, on-budget, on-spec outcomes for IT software projects

• US 20080133293A1
• Filed: 07/05/2007
• Published: 06/05/2008
• Est. Priority Date: 07/05/2006
• Status: Abandoned Application

• Current Assignee: Gordon K. Scott
• Original Assignee: Gordon K. Scott
• Inventors: Gordon, K. Scott
• Application Number:
  US11/825,380
• Publication Number:
  US 20080133293A1
• Time in Patent Office: Days
• US Class Current: 705/7
• CPC Class Codes: G06Q 10/06 Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Abstract

Industry statistics show that there is a persistent and high rate of IT Projects that fail to meet their goals in terms of budget, schedule, or user satisfaction. My invention is based on the observation that the software development process produces undesirable outcomes when there are inconsistencies between certain process artifacts. I refer to such inconsistencies as breakpoints (or alternatively as breakage points). Breakpoints cause there to be an undesirable divergence between what was expected as the outcome and what actually transpires as the outcome.

My invention consists of a method for preventing undesirable outcomes in the software development process by: identifying the potential breakpoints within a specific instance of a business process; applying a set of procedures to detect the existence and severity of actual breakpoints; and applying curative measures to remove detected breakpoints and applying proactive measures to prevent the development of breakpoints.

Claims

1. I claim a method for preventing undesirable outcomes in the software development process by:

A. identifying the potential breakpoints (as defined in Section 1 above) within a specific instance of a business process using a catalog of process artifacts augmented by human inspection (sec FIGS. 1 and 2 for illustrative examples);

B. applying a set of procedures to detect the existence and severity of actual breakpoints;

C. applying curative measures to remove detected breakpoints and applying proactive measures to prevent the development of breakpoints.

I have described my invention and how it can be used to produce improved outcomes in IT Software Projects. There are other ways in which my invention could be used.

For example, my invention could be used on other business processes in which specifications or rules (artifacts of the process) are used to guide the process to produce the desired outcome. Breakpoints associated with these specifications and rules could be detected, prevented, and removed with my invention.

Although my invention describes an environment in which specifications and rules (i.e. artifacts) often have a dynamic nature, being created during the project, often with parent-child relationships, my invention would also apply to situations where the process is subject to relatively static specifications and rules (sometimes referred to as Methods and Procedures, or M&

P'"'"'s).

Although my invention describes a method in which skilled human inspectors perform much of the work, computer programs could also be used to perform such tasks by embedding in them sufficient logic to assist, or even replace, the skilled human inspector.

IT Software Projects sometimes requires coordination with other IT Software Projects to ensure a successful outcome. Although my invention describes a method for detecting and removing break points within a single IT Software Project, the method could also be used to detect and remove breakpoints between one or more IT Software Projects. For example, two projects could be have inconsistencies in the requirements they are placing on the same computer system.

2. I claim a method for inferring whether breakpoints are present in a process environment that does not require the actual measurement of artifacts. This method is not an alternative to the method in claim #1, but rather supports that method by providing, by inference, a preliminary rapid assessment of where breakpoints might exist, and their relative severity. In this method, a human inspection is made of the process environment for the existence and effectiveness of process controls that would prevent breakpoints. If the process controls for preventing breakpoints are deemed weak or insufficient, then one can infer that breakpoints are likely in that process environment. For example, one might determine that there is no procedure for the authors of dependent (i.e. parent-child) documents to verify that the child document faithfully renders the intent of the parent document. In such a case, there is a likelihood that there will be inconsistencies between the two documents, and hence a breakpoint is inferred. One might use inferred breakpoints to prioritize the attention given to potential breakpoints in the method of claim #1.