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.