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.

Are the new hospitals in Denmark really really super?

The press has named the new hospitals in Denmark to super hospitals. It is a very ambitious word - super – to be using and it rests heavily on everyone's shoulders to deliver on these high expectations. However, is it actually super hospitals we are building? Let us first define what the word actually means super.

According http://www.denstoredanske.dk/ means SUPER following:

super, (lat. 'above'), Latin and international prefix denoting location, extent or amount, see. superpower, which is a particularly powerful superpower; is also used with reinforcing intention in everyday terms like super good.

We are dealing with a concept that can be compared to top-notch and great (maybe even unique according Gyldendals dictionary. Super has a reinforcing effect and it increases a given value of the word it attaches to. As in the example above, then super good, is better than just good. Let us take two examples

The first is from space:

nova (from Lat. (stella) nova 'new (star)', feminine form of novus 'new'), star whose brightness in a matter of days, from a thousand to a million times greater. During months, for slow novas years, the brightness decreases gradually to a normal for the star.

A supernova is a stellar explosion that briefly outshines an entire galaxy, radiating as much energy as the Sun or any ordinary star is expected to emit over its entire life span, before fading from view over several weeks or months.

This first is a slow increase in intensity and brightness to eventually return to its original strength. A supernova is a doomsday explosion in a short time that can outshine an entire galaxy. See that is truly super.

The second example is the word man and superman. Superman is characterized by the fact that he has (super) powers, x-ray vision, is invulnerable, can manipulate time and has a super moral that helps him, he fights evil and saves the world again and again. Superman is not any man - no, he is a superman because of his superb qualities.

So a super hospital must be something much more than just a hospital. But as with Superman and his forces, sight, etc., what characterizes a super hospital and are we actually going to build them or are we building minimally improved hospitals that does not deserve the title of super. I can often be in doubt. Especially because the press in Denmark has focused on the lack of founds, the decrease in the amount of beds and overall quality in all the hospital construction projects. I guess the politicians are right, when they say that you cannot judge the future hospitals superpowers by the amount of beds. The clinical area will change much within the next 8 years, so to talk about the design, architecture and the correlation to the future healthcare delivery is just not possible.

But then it is also obvious that the argument goes both ways – you do not know the healthcare sector of the future – and therefore you do not know if your future hospital will be super!

The only real fact is, that the hospital will be new, shining, white, single patient rooms etc. But if super is new way of delivering healthcare, new ways technologies that supports the healthcare of tomorrow – you don’t know. Super in that equation is new as in a new building – the rest is pure speculation.

So what is a super hospital is the million dollar question that everybody assumes they know – but none articulate it in detail. The. Expert Committee has identified areas they believe characterizes a super hospital. You must increase the hospital operation efficiency by 8 per cent , build single man patient rooms, increase productivity and convert treatment towards more day surgery, thereby allowing the closure of almost 20 per cent beds. Very practical but probably not the full picture of a super hospital

New OUH's vision is trying to define the super hospital, but if you are going a step deeper: what characterizes it in detail - no one knows - but everybody says it - super!

It would be interesting, now that politicians are the fathers of the super hospitals', to hear their views on what is a super hospital for them? And also what is it for the patients, the employees and of course the general Dane – we are paying for the party through taxes and we expect a super hospital. I guess we all fail if super is not defined.  It is difficult – maybe it is because it is not super at all.

What is a super hospital for you?

Leadership mindsets for IT success

I have recently started teaching University students in IT, Communication and Organization. Basically it is a subject regarding basis IT skills (What is cloud computing, how is the internet designed etc) and secondly it’s about strategy and aligning IT with business objectives. As I have previously mentioned in this blog I find the subject of IT and business fascinating, and I hope to at least empower my students with the knowledge about how it can be done and how hard it actually are to achieve.

Anyway, during my research for the class. I came by a very interesting and accessible little piece regarding the leadership mindsets in business. The article is written by Professor Donald Marchand and Professor Joe Peppard and was released in The European Business Review in March-April 2014 issue.

What I like about the article is, that it focuses the main points and arguments in a short form and in the end; it points the reader to the future by some practical advice.

The authors main point in the article is basically that with different mindsets on IT and information within the business, the role of IT will change: "…these differences in mindsets and thus perceived roles and responsibilities of senior managers and CIOs, the implications for how information recourses, IT, and knowledge are managed in the company will differ.. dramatically."

So the mindset of senior management and the CIO will affect how the company will use and regard IT investments. No new knowledge in that. However, the article suggest a Matrix where the business manager roles on on Axis and the CIO on the other.

http://www.europeanbusinessreview.com/?p=302

An excellent matrix, that gives the necessary input to a discussion on how we regard IT today and where would we like to be. A strategic talk about IT and business.

In the end, the authors suggest two key questions that should be explored during the strategic discussions senior management and IT have. They are as follows:

Where are your group or business unit management teams and CIOs today in terms of mindsets, behavior, and shared language?

Where should your business unit management teams and CIO be in the future related to the strategic management of information, IT and knowledge resources.

I can only recommend the small 4 page article to all management teams – both business and IT – It’s a great start for further elaboration and discussion on how will we regard and ultimatly use IT in our business to gain for example a competitive advantage.

The planning of IT – is it a necessary evil ?

What if you are in charge of a centralised IT department with infrastructure architects, solution architects, business consultants, account managers etc. And lets say the company is huge and has large departments all over the world. Again lets imagine that the departments are in charge of implementing and administration of the It systems for the entire organisation. So they have, so to speak, divided the systems and projects among themselves leaving the centralised IT department with architectural consulting and Infrastructure as their only areas of responsibility. To govern the IT they have established a kind of Architecture board, where decisions of a strategic level are made as well of decisions of how and which projects to proceed and fund. An important board that if respected and used have the ability to align the decentralised organisation in and around a common business strategy.

I guess with the above organisation,  IT is closer to the business it is supposed to support, it might get the process of funding to run more smooth, because the local management knows exactly where it hurts. It is very agile and can react to imminent issues that may arise as small or medium business can do. The problem, or positive people would say challenges, are of course, to align all the IT initiatives, IT management and operations, IT projects and the overall IT planning process, of the organization as a whole.

When power and decision making are decentralised people tend to decide and use that power. Often not for the greater good of the whole organisation and not for the long term planning – actions are often isolated decisions based on local knowledge, local challenges and therefore short term IT planning.

So no system or organisation is perfect – but maybe we have a solution where we can have both local knowledge and business integration at the same time as long term strategic IT planning.

It is called Enterprise architecture – and it fucking rocks if it is implemented and respected by all the participants in the organization. The video below quickly explains the concept of enterprise architecture way better than I can, so please take four minutes to watch it.

I am certified in TOGAF 9.1 Enterprise Architecture and that is just one out of a handful methodologies regarding enterprise architecture.  The real issue with the TOGAF framework or more precise the Architecture development method (ADM)

The open Group (opengroup.org)

is to gain enough speed in the administrative process, that implementing EA will not result in a standstill of the IT within the business.  If that happens, the business units will just circumvent the EA processes and acquire the IT themselves. The more the individual departments operate on their own – the more short termed and individual are the IT planning – but then again it is closer to the business needs. On the other hand the more centralised IT is planned, the more administrative and bureaucratic everything can tend to be and then it will of course be further away from the eminent business challenges.

I guess I don’t have the answer except that short and long term planning is necessary. The TOGAF EA is a great way to handle it – It just need all to respect the processes established and it needs to be tailored to the organisation it is supposed to support – otherwise the resources are lost and we might even be further away than when we started to plan for IT in the first place.

By the way - good people will leave in all the parts of the organization if you do not respect the craft of doing IT properly. Especially the enterprise architects will not tolerate that business and IT is done with no planning and with a little or no respect to strategies, business needs and the processes that have proven best. TOGAF calls that capability based planning - how the overall EA capability of the organization is established and maintained -  don't ever ignore that in your organisation either.

There is no such thing as a pilot in the healthcare sector

I often wonder why IT projects within the healthcare sector, always takes a lot of time or end up so big, that the project management cannot handle them and the project schedule is delayed.

Often in IT projects there are a clear understanding of the business case, the goals and purpose of the system. But people never the less does not talk about what a pilot is for and why they have chosen that particular method and for example not a lab test instead. In healthcare there are no such things as a pilot, because we need to focus on patient security and a high quality of the delivered treatment. Pilots with less functionality or even simulated data flows, do not go well within that paradigm.

In my time in IT management in a big university hospital I heard more than the opposite doctors and nurses argue, that a pilot project would be ok, but not until that integration or that functionality is implemented as well. If project management give in, the project is growing and the pilot will not start until the entire system is in place, and that can take a lot of time. Low hanging fruit slowly ascends into the three tops so to speak, and are harder to reach.

Projects in the healthcare sector can be illustrated with one of my personal favourite Gifs. Everything is lined up, the field is well described and marked, the goal is clear and in sight and you has even implemented some organizational and functional routines to help the system into implementation. But quick the project gets to big and crashes half way towards a milestone.

 
I guess one way to solve the above paradox is to really understand and communicate the purpose of the pilot and not let the project grow out of its initial scope. Furthermore, always make it clear, that the system after ending the pilot might get shut down, so you will not make severe adjustments for a lot of money on a system that might not be implemented fully within the organization.

So my I guess my point is, that be careful with your health IT projects, get it aligned exactly with the business needs and don’t overdue the functionality. Keep the fruit low and don’t let perfect be the enemy of good.