Richard W. Woolridge

Stakeholder Risk Assessment: An Outcome-Based Approach

Managing software projects can often degrade into fighting fires lit by the embers of unrecognized and unmanaged risks. Stakeholders are a recognized source of significant software project risk, but few researchers have focused on providing a practical method for identifying specific project stakeholders. Furthermore, no methods provide guidance in identifying and managing project risks arising from those stakeholders. We developed the outcome-based stakeholder risk assessment model to provide this practical guidance. OBSRAM offers the project team a step-by-step approach to identifying stakeholders during requirements engineering, identifying stakeholder influences on the project, identifying the projects impact on stakeholders, and assessing the risks that their potential negative responses pose. We illustrate OBSRAM using a case study of a simulated airline-crew-scheduling system project that aims to reduce aircraft ground turnaround time to 30 minutes or less

Software project scope alignment: an outcome-based approach

DecaDes of eviDence reveal a shockingly low success rate for software projects. In their first CHAOS report in 1994, The Standish Group reported that 16% of IT projects were successful, 31% were failed, and the remaining 53% were challenged. In their 2004, reported ratios improved to 29% (successful), 18% (failed) and 53% (challenged). Although the record is slowly improving, much work remains before software project success becomes the norm rather than the exception. Glass 2 and Field, 1 among others, cite inadequate project scoping as a major contributing factor to project failure. Scoping is a project initiation activity that defines the projects boundary, by identifying the problem domain needs to be met and the software elements expected to be delivered. In addition to identifying the product (problem domain needs and software elements), scoping also sets out the projects value and quality met-rics and resource (such as schedule and budget) requirements. 7 This article is grounded on the premise that effective scope definition will reduce the impact of scope changes and increase the resource estimate accuracy , thus reducing the likelihood of scoping-caused project failure. The Outcome-Based Scoping (OBS) model is proposed to reduce the likelihood of scoping-caused failure. Using OBS, project leaders develop a more complete understanding of how to meet the problem domain objectives, not just deliver a working software solution. OBS recognizes , as did Vessey and Glass (1998), that much of the software engineering process is better characterized as domain problem solving. Thus, OBS first defines the problem domain scope model; from that foundation, the software domain scope model is then developed. The OBS model further structures the scoping effort by decomposing the concept of scope into two dimensions: intent (representing the goal) and blueprint (representing the resources required to meet a specified goal). The remainder of this article develops the OBS model and provides a case study illustrating its use. OBS defines the relationships within and between the problem and software domains to include (as shown in Figure 1): The Problem Domain Intent (PDI) ˲ defines the intended problem-domain outcomes that provide the boundary for the following model component (the Problem Domain Blueprint). The Problem Domain Blueprint ˲ (PDB) identifies the stakeholder-specific changes and resources required to enable the PDI-expressed intent and drive the following model component (the Software Project Intent). The Software Project Intent (SPI) trans-˲ lates the PDB candidate solutions into software scope elements …

Co-adaptive processes of stakeholder networks and their effects on information systems specifications

Information Systems (IS) requirements inadequacy and volatility are major IS project risks leading to failed, over budget, or over schedule projects. Within requirements determination, an area of focus for the inadequacy and volatility issue is the application domain (i.e., business domain). One step towards better requirements determination methods, techniques, and tools for the application domain would be a theoretically-grounded model for specification emergence and evolution. This paper presents a model of specification emergence and evolution that is confirmed using a case study.