This is the first in what will probably be an irregular series of dispatches on the lessons of 28 years of software development, sales and marketing and small business ownership.
Firstly I need to say that I have a very big fan of the Object Management Group for a very long time and believe that the concepts that make the Model Driven Architecture approach to systems analysis, design, implementation and maintenance/enhancement should drive all systems development. Of course, in practise they don’t. The reasons that the approach come in many forms, mostly there is little or no commitment to trying to understand business modelling (UML 2, etc) rather than a financial model (Excel).
After at least 15 years working for, driving and generally trying to actively promote the idea of a single set of terms, tags and nomenclature generally within the stakeholder community. But again, the daily stresses and to be blunt the vested interests of stakeholders can easily run the endeavour off the rails. these interests can be of a budgetary nature (vendors, sub-contractors), or more personal, less tangible matters.
We (hpfm) have been working with a national, geographically extremely diverse organisation as they have migrated their daily activities (membership management, education, patrol rosters) from a combination of disparate databases, paper and informal arrangements to a uniform, national information framework that support some 300+ organisations, over 300,000 individuals that allows each agent the degree of flexibility required to ‘get things done’.
The user population is regularly surveyed by an independent party and for the past 3 years has gained 85 % acceptance rates by the largely volunteer group.
So, why is that so different to corporate experiences?
In the past 14 years, I have worked as a senior consultant to some of the largest organisations in Oz. I have seen at least 5 “Enterprise” IT initiatives, each budgeted well over $100 million. Each managed to spend several million IT dollars, achieving nothing and finally dying an inglorious death. WHY?
Well, mostly its because they are realiy poorly thought out.
And I think it stems from the popular name or industry has: IT. We don’t often stop to remember that this means Information AND Technology.
Information is a very long term volatile asset. Technology as Moore’s Law informs changes on a very rapid cycle.
I know of very few projects, including all of those above, that proved to be either terribly technically risky or infeasible. I saw a $5 million (AUS) project management tool become a time sheeting system. Not because it couldn’t be integrated, but because the budget was cut after the technical work was done. For the sake of less than $2 million dollars, that organisation has condemned a project to ridicule, paid millions of dollars for a time sheet tool. But most distressingly it would already have missed out on 10’s if not 100’s of millions of savings on major projects. Let alone the opportunity cost in not having the in detail practical data available for decision making. I met one poor chap managing a $450 million dollar equipment roll-out with a 5,000+ line Microsoft Excel spreadsheet. I don’t care who you are that task is impossible.
This is a failure to understand that the information to be managed in the ’system’ is far more valuable than the piece of technology that is lives in.
I have used the example of the Roman Colosseum, the technology used is ancient but available in huge supply. After all there are more humans on the planet that can lay bricks that ever before. Of course we’d need the plans, blueprint, the information that tells us what to build. Otherwise its just a pile of bricks.
The other ingredient in systems are people. Those pesky social animals we need to get things done. Ignoring the requirements, likes, dislikes and communication mechanism of these folks is the singularly largest mistake we can make. Falling into the trap so many managers/execs do of thinking they know how everyone will use the new system is common and fatal. The extreme negative (and realistically common) response to the imposition of system change from above was, at least in my presence, first coined by Dr Dave Abel as “malicious compliance”. We’ll fill in the forms bur no more. My time sheet example above died this way.
The past few years have been an ongoing learning experience, we have developed our own methodology for working with organisations to work at two very distinct levels and on two independently assessed set of criteria. These are determination of the business objectives, rules and constraints, the other is to work with the community of those affected to build consensus.
In short (and I’ll expand on this process in the series), we need to work with the business owner to identify both root causes and immediate opportunity to improve. This is a structured process that is directed to a strategic assessment of the business requirements for information. This takes the form of a very concise set of framework principles that govern the assessment, design and implementation of systems change. This then defines the language used to describe the proposal and has been fully socialised with stakeholders.
In a parallel stream, a range of techniques is used to the above we work with the business to identify immediate action to build the community buy in to adopt the new system. At this stage we focus on the people most affected by the proposed modifications. In these sessions we find out what makes sense in terms of delivering the benefits available. Through experience we have come to understand the concept of “desire-lines” , and how they affect a systems adoption in the target social network (employees, customers, vendors, the state). That is people will find there own way to get the job done, after all you employed them because they have skills. Our method says, if we know that this is going to happen, why not help that process and get a better result all round.
The worst question you can ever ask is what brand system is best for [CRM,ERP,B2B,Web,etc]?
Until you really understand both what you are doing and why, the next thing is to develop a shared concept. Normally you need to work on a 5-10 year cycle to deeply embed strategic, high value, flexible, robust and scalable system change. Every $1.00 you fail to spend on truly understanding and sharing that system vision, is billed back to you at $100 when the technology is delivered and reduces the value of your endeavours.
If you get this bit right, the technology become a true enabler, not a cost centre.
Next: Turning it into SDLC
Recent Comments