The New Odense University hospital into a new phase

We are now officially in the new phase of our project. It is very interesting, and we are now going towards a more detailed level in the project. We are for example going to design and equip all the rooms of the new hospital. The standard rooms and the unique rooms as well. It is a very important period, that has been underway for some months  now. We started last Wednesday with our user involvement process and a kick meeting. During the next 6 months, we will arrange up to 150 user meetings, were the clinicians will guide us, give input and help us with the different rooms. In the end we have touched and discussed up to 1000 different rooms with the users and asked their opinion on the work processes in the room, the functions in the room, the layout, design, equipment, installations etc. In the end, we believe their input is crucial to our common success.

For the rest of the areas in IT and equipment planning, we work on the IT infrastructure of the hospital, the building related IT systems as BMS, redesign a brand new Concept for the Digital hospital, installing systems in our Mock up at Syddansk sundheds Innovation and most important creating a high end project team to work on solutions based on the Digital hospital concept. We use TOGAF and Business process management as our primarily methods, and will end within the year with very specific suggestions on what to buy, what to upgrade and what systems to close. In the IT management and planning we thereby also has to get more concrete on our work and suggested solutions. I very much look forward to the next period, and the team seems great and very diverse in their abilities. More of that later.

If you would like to take a tour of the new hospital, look at the small movie below. Everything is coming into focus, becoming clear and touchable. For a man like me that likes clear and present goals and concrete achievement the following year will be a ride of joy, excitement and big big challenges of course.

Enjoy - its in danish... sorry

Risk management in agile Projects

Sometimes something wonderful happens. A couple of weeks ago I went to Aalborg to evaluate 5 projects at the University. One of them was about risk management in agile projects. I read the thesis at home and one thing was perfectly clear. There are very little academic literature about the subject and therefore project teams usually takes on an approach designed for sequential project models as the waterfall method. So risk management is probably conducted in a manner that are designed for one methodology and used in a total different. The risk that risk management will go wrong are substantial, and therefore will the project overall be in jeopardy. The student who wrote the thesis did it in a very professional manner and it delivers new knowledge to the subject. I was impressed.

So lets start with the beginning and define risk as the literature does. the text below and the figure are from the thesis.

Wallace et al. defines a software risk as ”A condition that can pose a serious threat to the successful completion of an software development project” (Wallace et al. 2004)

Bannermann defines software project risk management as “A set of principles and practices aimed at identifying, analyzing and handling risk factors to improve the chances of achieving a successful project outcome and/or avoid project failure” (Bannermann 2008).

Acording to Boehm (1991) risk management consists og two steps with 3 substeps. The first is risk assessments and the second is risk control. The first is proactive while the second is reactive. How do we handle the risk once it occurs, so to speak.

http://file.scirp.org/Html/6-9900055%5Cd8a5c90b-f616-4af2-a9a2-bf98ab2fd15b.jpg

 Furthermore, a definition of agile projects are needed. The thesis uses this one.

”the continual readiness of an ISD method to rapidly or inherently create change, proactively or reactively embrace change, and learn from change while contributing to perceived customer value (economy, quality, and simplicity), through its collective components and relationships with its environment” (Conboy 2003).

The principles and activities in Scrum and agile methods are able to address a number of risks. Risk management is part of Scrum, as an implicit, simplistic and reactive mechanism that is unable to take care of all the risks associated with IT development.

Agile software development has many strengths that are required in today's development projects. This includes the close cooperation with the customer and flexibility that makes it possible to handle changes in requirements. However, agile methods also have weaknesses, because they don’t handle all the risks in modern system development projects. 

Risk management is part of Scrum, as a mechanism which is implicit in that it merely referred to as "obstacles "to be solved. At the same time the simplistic as it only involves the two steps "identify" and "solution" of obstacles . Not least is the reactive, as they often take care of risks when they become problems.

So it is all about handling and managing risk in a iterative and incremental project. Projects in Denmark that uses this method has been seen to crash rather heavy – probably because you do not know the end or your requirements before you start the project. That will make every manager have bad dreams and sometimes you end with nothing but the fact that all your resources are spent on great individual iterations but it have not amounted to the solution you had in mind. So because agile projects are more dynamic, iterative and incremental the require more management and of course risk management. It is therefore an even bigger surprise, that very few persons have found it relevant to study the field and develop a clear and relevant framework for risk management in agile projects. Well at least until a winter morning in the Northern Denmark.

The student developed a framework for risk management and identified where Agile projects handles risk in a embedded manner related to the methodology. Nice work I must say.