External disturbance control for software project management

White, Anthony S.

doi:10.1016/j.ijproman.2005.07.002

Cited by 16 publications

(8 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…One of the reasons that the project management discipline focuses on the control of changes is based on empirical studies showing that changes can negatively impact project costs, delay, and ultimately project failures regardless of the quality of the project plans (Construction Industry Institute, 1995Dvir and Lechler, 2004;Midler, 1995;Williams et al, 1995). The software product development literature also covers change management as a component to improve efficiency (McGrath, 1996(McGrath, ,2004White, 2006a (Ashby, 1956;Beer, 1959;Kuhn, 1986;Wiener, 1948). In cybemetics, the feedback loops are most often negative (in the case of a thermostat, this would correspond to tuming off the heating system if the tempe rature is too high) but might be positive (this is called an explosion or run-away system) or might include shut-down processes (i.e.…”

Section: Scope Controlmentioning

confidence: 99%

Project portfolios in dynamic environments: Organizing for uncertainty

Petit

2012

International Journal of Project Management

182

153

View full text Add to dashboard Cite

Section: Scope Controlmentioning

confidence: 99%

Project portfolios in dynamic environments: Organizing for uncertainty

Petit

2012

International Journal of Project Management

182

153

View full text Add to dashboard Cite

“…As such, the inclusion of a large number of co-creators becomes not merely desirable but essential. This is an example of the Law of Requisite Variety [50]. Exogenous actors working together with staff from service providers inevitably co-create or co-provide service value.…”

Section: Measurement Of Service Valuementioning

confidence: 99%

A Control Theoretical Model of Web Service Value Development

White¹,

Nielsen²,

Censlive³

2019

OJMSi

View full text Add to dashboard Cite

This paper describes a control theoretical model of collaborative value development. This model is designed to assist managers in choosing parameters that are critical to the development process in service design and support their Business Model. This methodology uses control system modelling of web-based service value generation implemented in SIMULINK/MATLAB. An application based on public domain Wikipedia data is used to validate and develop the model. A control theoretic model applied to the creation of Wikipedia articles shows very good agreement with Wikipedia published data for the time dependent growth in articles produced, and editors used, well within the variability of parametric data listed publically justifying the principle equations used in the model. This development and fine tuning of the model has been limited by the publically available data. To obtain a more accurate model in this area would need the cooperation of web service organisations to reveal confidential data. This modelling procedure can produce a decision support process for service design and could, with modification be applied much more widely to other choices in service design/implementation, even allowing for user contribution to be evaluated. This work shows how subjective judgements on value and other intangibles need to be continually re-evaluated. Such methodology has not been applied elsewhere to value generation applications. It could be used to rank contributions from co-creators for reward sharing.

show abstract

“…There are papers originating from different fields of science, among others agriculture, biomedicine and astronomy, stating that requirements creep is inevitable and that excessive requirements creep is a turbulence or even a failure factor for IT projects. In those papers it is advocated that requirements creep should be avoided or managed [4,78,43,50,6,19,42,79,30,82,43,46,58,70,25,24]. However, these papers fail to state how much requirements creep is actually occurring or how much creep is unhealthy and excessive or even how requirements volatility should be monitored.…”

Section: Related Workmentioning

confidence: 99%

Quantifying requirements volatility effects

Kulk

Verhoef

2008

Science of Computer Programming

View full text Add to dashboard Cite

IT portfolio management Quantitative IT portfolio management Volatility benchmark IT dashboard Requirements metric Requirements creep Scope creep Requirements scrap Requirements churn Compound monthly growth rate Volatility tolerance factor π-ratio ρ-ratio Requirements volatility dashboard a b s t r a c t In an organization operating in the bancassurance sector we identified a low-risk IT subportfolio of 84 IT projects comprising together 16,500 function points, each project varying in size and duration, for which we were able to quantify its requirements volatility. This representative portfolio stems from a much larger portfolio of IT projects. We calculated the volatility from the function point countings that were available to us. These figures were aggregated into a requirements volatility benchmark. We found that maximum requirements volatility rates depend on size and duration, which refutes currently known industrial averages. For instance, a monthly growth rate of 5% is considered a critical failure factor, but in our low-risk portfolio we found more than 21% of successful projects with a volatility larger than 5%. We proposed a mathematical model taking size and duration into account that provides a maximum healthy volatility rate that is more in line with the reality of low-risk IT portfolios. Based on the model, we proposed a tolerance factor expressing the maximal volatility tolerance for a project or portfolio. For a low-risk portfolio its empirically found tolerance is apparently acceptable, and values exceeding this tolerance are used to trigger IT decision makers. We derived two volatility ratios from this model, the π-ratio and the ρ-ratio. These ratios express how close the volatility of a project has approached the danger zone when requirements volatility reaches a critical failure rate. The volatility data of a governmental IT portfolio were juxtaposed to our bancassurance benchmark, immediately exposing a problematic project, which was corroborated by its actual failure. When function points are less common, e.g. in the embedded industry, we used daily source code size measures and illustrated how to govern the volatility of a software product line of a hardware manufacturer. With the three real-world portfolios we illustrated that our results serve the purpose of an early warning system for projects that are bound to fail due to excessive volatility. Moreover, we developed essential requirements volatility metrics that belong on an IT governance dashboard and presented such a volatility dashboard.

show abstract

External disturbance control for software project management

Cited by 16 publications

References 13 publications

Project portfolios in dynamic environments: Organizing for uncertainty

Project portfolios in dynamic environments: Organizing for uncertainty

A Control Theoretical Model of Web Service Value Development

Quantifying requirements volatility effects

Contact Info

Product

Resources

About