Payment by results – a solution that creates a wicked problem

A story on the UK Guardian site: Payment by results – a ‘dangerous idiocy’ that makes staff tell lies http://www.guardian.co.uk/local-government-network/2013/feb/01/payment-results-staff-fictions Some quotes from the article: The evidence is very clear: if you pay (or otherwise manage performance) based on a set of pre-defined results, it creates poorer services for those most in need. It is the vulnerable, the marginalised, the Continue reading Payment by results – a solution that creates a wicked problem

Can UX save enterprise IT?

On a recent Harvard Business Review blog they posed the question: Can UX save enterprise IT? – UX is a trendy term for User Experience. The poster ranted on about how wonderful new technology is and how it can save enterprise IT. The assumption seemed to be that information is like water. It streams, can be easily aggregated and never changes Continue reading Can UX save enterprise IT?

Problem oriented strategy

IMHO, a strategy should define an approach that identifies the problems that need to be solved in order to achieve one or more goals. The very first question that should be answered is “what is the best approach to adopt when developing and implementing this strategy?” The approach to any problem solving activity is crucial, as I said here and Continue reading Problem oriented strategy

Another (useless) Government ICT strategic plan

The Australian State Government of Victoria has released its Victorian Government ICT Strategy 2013 to 2014 To me it looks like almost any other mid-size enterprise that wants to use ICT to run business applications and to engage with external users. There’s very little in it that says “The Victorian government has particular and specific business requirements which has resulted Continue reading Another (useless) Government ICT strategic plan

Systems Engineering is not problem solving

This is taken from http://spacese.spacegrant.org/ “Systems engineering is the art and science of developing an operable system that meets requirements within imposed constraints. Systems engineering is holistic and integrative. Systems engineering is first and foremost about getting the right design – and then about maintaining and enhancing its technical integrity, as well as managing complexity with good processes to get Continue reading Systems Engineering is not problem solving

Australia’s Personally Controlled eHealth Record

I’ve been following the PCEHR for quite a while and commenting on David More’s blog on http://aushealthit.blogspot.com.au/ This is most of what I posted to the Link list.http://mailman.anu.edu.au/mailman/listinfo/link The first is that IT is just a solution, what really matters is the problem. When governments talk about implementing things like the PCEHR, it would be really nice if they explained Continue reading Australia’s Personally Controlled eHealth Record

The UK mandates paperless hospitals by 2018

This was posted on the Guardian government computing website. Are paperless hospitals achievable by 2018? Published 04 February 2013 http://www.governmentcomputing.com/features/are-paperless-hospitals-achievable-by-2018 Here’s what I posted. (Quote) What is it with the arrogance of politicians and their close advisors? Making hospitals paperless is a difficult and challenging problem with many unknowns. It also has an unknown cost and value. When a minister Continue reading The UK mandates paperless hospitals by 2018

Audit, Assurance and Assessment

Audit is where you assess a project/company/activity against what it is required to do according to the law, rules and regulation. These are usually non-negotiable and compulsory. Audit is about compliance. Assurance is where you ask a company/project the question “what did you say you would do?” and then compare what they said they would do against what they did. Continue reading Audit, Assurance and Assessment

Solution architect – an oxymoron

IMHO an architect is one who understands and solves problems. An architect who only comes up with a solution, without understanding, challenging and addressing the problem, is a designer, not an architect. Vendors often have solution architects. That’s because vendors work in the solution domain. Sort of makes sense. However to call these people architects is stretching the word beyond Continue reading Solution architect – an oxymoron