Newsletter December 2018


Newsletter December 2017


Newsletter December 2016


Newsletter April 2016


Newsletter December 2015


Newsletter June 2015


Newsletter December 2014


Newsletter August 2014


Newsletter April 2014


Newsletter November 2013


Newsletter July 2013


Launch Announcement


Test
Newsletters Signup
RiskIntegral Banner

Newsletter December 2015


Welcome to the December 2015 issue of “RiskIntegral” - an occasional newsletter about the analysis and management of risk, mainly in projects, by Risk Integration Management Pty Ltd (RIMPL). Given the topicality of Innovation and Agility being promoted by our new Prime Minister, in this issue our feature article is about applying risk analysis to innovative projects, especially involving IT.


The newsletter concludes with some news of our activities.


Cristmas Greetings

RISK ANALYSIS OF INNOVATIVE AND IT PROJECTS


it project outsourcing

Source: www.mymanagementguide.com




Introduction


A number of trends have been emerging in IT projects and projects with strong IT content


• Mobile phone usage for collaboration is becoming increasingly dominant. In 2014, mobile internet usage exceeded PC internet usage for the first time. Project Management (PM) and other collaboration software need to be optimised for mobile integration).


• Agile PM methodology continues to gain popularity in IT projects due to its cost-effectiveness, reliance on self-organising teams and recognition of human nature in its design, as described later in the article.


• Risk Management (RM) is becoming more of a focus for IT Project Managers for several reasons:


Ο With the growth of Agile methodology, RM competence is becoming more desirable;


Ο The need to improve ability to identify potential scope, budget or team threats; and


Ο As we have seen through the media, the incidence and severity of cyber security problems have continued to increase.



Efforts to Apply Monte Carlo Method (MCM) to Innovative projects


A couple of methodologies that depend on MCM have been developed in fields with strong IT involvement:


1. NASA’s Joint Confidence Limits (JCL)


After years of serious time and cost overruns to its projects, NASA developed a methodology to produce realistic forecasts of time and cost outcomes for its projects named “Joint Confidence Limits”. Use of the methodology since August 2012 is mandatory for all projects exceeding $250m. It requires that an integrated cost and schedule risk analysis be performed using a detailed resourced schedule with significant cost and time impact risks events mapped into it and that funding for the project will only be approved for submissions proposing 70% probability levels of both budget and schedule (70% Joint Confidence Limits). This approach is extremely close to RIMPL’s IRA methodology


Recently the US Congress, which has over the years made withering criticism of NASA’s blown budgets and date forecasts, congratulated NASA on the accuracy of its estimating for the top 10 projects they were submitting for ongoing funding approval – overall their actual costs were at 1% under budget. This was stated by Congress to be “a marked improvement”.


2. Schedule Compliance Risk Assessment Methodology (SCRAM)


SCRAM is a process for reviewing a project to identify issues and threats to the schedule. It combines Root Cause Analysis to find the causes of schedule problems and Parametric and Monte Carlo Modelling to forecast outcomes. Developed with the Australian Department of Defence and Australian and US Software consultants, it handles projects with significant software development content. SCRAM incorporates the Schedule Risk Analysis component of IRA.


SCRAM is being used to good effect on a number of major Australian Defence sector projects, to identify delay drivers and improve their schedule performance. These projects usually include significant levels of innovation.


Agile methodology inverts the usual priorities


Conventional projects follow what is referred to as the “Waterfall Model”, in which design is followed sequentially by procurement, construction and commissioning. This is appropriate where design, once committed, is hard and expensive to alter. Initially this approach was applied to IT projects, as shown in the following schematic.


WaterfallSchematic(Kemp_Smith)

Source: “Waterfall Model of System Development” by Peter Kemp / Paul Smith


It was found inappropriate for software development where requirements could change frequently and rapidly and where the environment into which the project deliverables were to be delivered might also be changing quickly.


Under waterfall, it was time-consuming and expensive to “go back up the waterfall” to change the requirements and design and then re-perform the code-writing and testing.


Agile methodology was developed to produce the software in “potentially shippable code” modules, written, tested and documented, during rigidly time-boxed “Sprints” (usually 2 weeks long). Instead of scope being fixed and time and cost being variable, scope becomes the variable, with time fixed. An Agile project consists of a series of Sprints, assessed at the initiating stage of the project and reviewed and revised during the subsequent sprints. In each sprint, a series of “storylines” are coded by the programmers, with each storyline covering a required part of the project scope. The scope is initially defined in the planning for the sprints, then update throughout the sprints. The approach can be understood from the following diagram.


Traditional Vs Agile Methodology

The team created to perform the Sprints is multi-disciplinary, including programmers, testers, business representatives and a specialist in facilitating sprints. There are many other details beyond the scope of this article.


From a Risk perspective though, how can the uncertainty of how long the project will take and how much it will cost be modelled?


RIMPL has modelled an Agile software development project in which the quality and productivity of the sprint team is assumed to be high, but in which there is a corresponding threat that the productivity and quality of the programmers may not be as high as assumed due to market competition, resulting in slower writing of code and a higher error rate in the code (known as “Technical Debt”). This threat can be treated by paying a premium for proven, high quality programmers who have been previously personally employed or assessed by trusted associates of the team.


The impact of this treated threat on the Agile project is to increase the cost of the project (due to paying higher rates for quality programmers), increase the number of sprints required to complete the project and increase the effort required to validate and test the code (because they treatment is very unlikely to be 100% effective).


The probability and impact of the threat and the effectiveness and cost of the treatment determine the treated impact on the project. By engaging with Agile Subject Matter Experts (SMEs) and evaluating scenarios varying these threat and treatment parameters, the project owner can forecast the outcomes of such projects with significantly improved confidence, based on time and cost risk outputs such as are represented in the Agile project simulation outputs below.


Example Agile Histogram

This approach can also be used with hybrid projects (part Agile, part waterfall) such as projects involving implementing Commercial Off The Shelf (COTS) software and hardware plus web interface development using Agile.


RIMPL NEWS


Quantitative Risk Analyses


Since our last RIMPL Newsletter in mid-2015 the following activities have kept us active in our core business:


• An IRA for Santos GLNG project on an expansion of their upstream Coal Seam Gas fields in the Wandoan area of central Queensland;


• Undergoing a tender process culminating in RIMPL’s recent appointment to two panels by the Australian Department of Infrastructure and Regional Development (DIRD):


Ο A panel to review and assess cost contingencies for infrastructure projects being submitted to the Australian Government for funding;


Ο A panel to provide theory and policy advice on contingency estimation (probabilistic / quantitative risk analysis)


• We have entered agreements to perform further IRAs early in 2016:


Ο A natural gas and condensate plant in PNG;


Ο A bankable feasibility study for a new gold and copper mine in the Philippines


Project Controls Services


We have also been continuing to provide project planning and forensic scheduling advisory services for manufacturing and commercial building companies:


• Ongoing provision of planning services for multiple Australian food manufacturing facility projects.


• Planning and Forensic Scheduling Advisory Services for a Commercial Construction company.



CONTACT US

18 Cottesloe Court
Doncaster East VIC 3109
AUSTRALIA
+61 412 031 161
info@riskinteg.com