Every time I participate in initial discussions of proposed enterprise application with business process owners, the same phrase keeps popping – “We want this system to be flexible”. I used to ask for clarifications, and usually they would respond with extremely ambiguous definitions of flexibility. We usually place positive value on the term “flexible”, but let’s face it, it is very easy to produce very negative, unintended results when the systems allow relaxed approach to processes and practices. The root of the current financial crisis is bringing too much ambiguity into definition of credit worthiness. How meaningful would Sales Forecasting system be, if expected dates of sale be defined as “sometime next year”?
We all have experienced messages that are so ambiguous the actual meaning of the message is completely lost. Most people I know function a lot better when they operate with a set of clear and consistent instructions, but yet when faced with a requirement to communicate in a structured data, they demand “Comments” field.
I grew up in a family that practiced very strict “cause/effect” approach to reward and punishment. Since ADD was not invented at the time of my childhood, the only “medication” I got was a belt. It took me a few decades to learn how to appreciate a concept of Accountability, and since outright denial is rarely believed, the ambiguity of our communications may be the best method to avoid and deny accountability without “losing a face” – “That is not what I meant”.
So here is an inherent and potentially “deadly” conflict for those of us, who want the systems we implement to be used AND to bring positive ROI:
Humans resist communications unless certain amount of ambiguity is present (i.e. use of structured data), but Humans, Organizations and Systems do not operate effectively when input is ambiguous.
That is moderately interesting (I hope), but not particularly helpful, however 12 steps program assure that acknowledgment of our problems is the first step to resolution. I can see two potential approaches to be taken, and I promise neither one involves changing human addiction to ambiguity.
The first approach is to take very patient and academic approach to dissection of desire for “flexible” system with the goal of listing every element which requires “flexibility” in business process owners opinion. Then each and every element listed has to be looked at from the perspective of the end result the application suppose to yield.
A few years ago I was involved in implementation of SFA application to a global sales force to accommodate, foster and support team selling regardless of geography. The software vendor was pestered with requirements to support multiple language sets within single data base instance with the intensity that brought tears to their eyes. The fights went on for weeks until it occurred to us that team members communicating within the system in their own languages could not possibly produce any value for each other since their content contribution could not be understood by each other. Remember Babel Tower? We almost built one. So going with the single language was not very popular to the proponents of “flexibility” and local operations managers denounced the decision until they realized an upside, and we found the way to accept their requirement to work with native language characters in contact records, which were mirrored in multiple instances of the Contact database. The solution was reluctantly adopted at first, but within a year a target of this implementation, increased average sale amount by extending the sales team efforts across geographies, was successfully realized.
The second approach is to use technology for converting “comments”, emails, wiki’s, and other free format content into structured data. The evolution of Natural Language Processing and Machine Learning technologies seem to approach the stage of commercialization and there are a number of companies which sell various tools that have a promise. Since it takes some serious skills to maintain clear vision in heavy “vaporware” conditions, I would suggest to limit experimentations only to very focused projects, severely limited in scope.
Relationship – relatively long-term association between two or more people or social entities (?) (italic part is mine). These can be voluntary and cherished, or forced and resentful. Wikipedia does not provide generic definition for Customer Relationship outside of CRM concept, but I bet that if it had, it would not focused on involuntary and resentful associations. And yet modern organizations keep investing billions of dollars (and other monetary units) in creating such emotions among their customers.
Doc Searls wrote about this disconnect
For evidence, look no farther than two of the most annoying developments in the history of business: 1) loyalty cards; and 2) the outsourcing of customer service to customers themselves.
Never mind the inefficiencies and outright stupidities involved in loyalty programs (for example, giving you a coupon discounting the next purchase of the thing you just bought – now for too much). Just look at the conceits involved. Every one of these programs acts as if “belonging” to a vendor is a desirable state – that customers are actually okay with being “acquired”, “locked-in” and “owned” like slaves. Meanwhile, “customer service” has been automated to a degree that is beyond moronic.
Can technology replace care without destroying “long-term” association between social entities? I would imagine in a context of involuntary association it could work just fine – automating prisons without diminishing security is a reasonably good example.
The technology is a “channel” for delivery of ..fill in the blanks, product, service, care or any other “content”. Although some would argue that all of these are the same and is the reason of why this associations (relationships) has formed on the first place. So from this perspective the strategy of more channels with less content, can be cheaper to construct and maintain, but ultimately leads to erosion of relationship, and as such based on very bad economics of reducing cost per transaction at the expense of Total Customer Value.
All the chats were 99% unhelpful and in some ways were comically absurd. The real message that ran through the whole exchange was, You figure it out.
Sez one commenter on a Slashdot thread,
There’s a Linksys cable modem I know of that has a recent firmware, and by recent I mean last year or so. Linksys wont release the firmware as they expect only the cable companies to do so. The cable companies only release it to people who bought their cable modems from them directly. So there are thousands of people putting up with bugs because they bought their modem retail and have no legitimate access to the updated firmware.
What if I pulled this firmware from a cable company owned modem and wrote these people a simple installer? Would the company sing my praises then?
The real issue here is that people frequent web boards for support because the paid phone support they get is beyond worthless. Level 1 people just read scripts and level 2 or 3 people cant release firmwares because of moronic policies. No wonder people are helping themselves. These companies should be ashamed of providing service on such a low level, not happy that someone has taken up the slack for them.
It shows that Customer Care, for these organizations, really is an unavoidable evil, rather than an opportunity to build relationship and as such the cost is primary consideration. In other words they don’t want association with you, they just want your money – and this is a very expensive way to build business considering the cost of Customer Development.
The British Computer Society Project management website published a well researched study in project failures by Dr. John McManus and Dr. Trevor Wood-Harper.
Research highlights that only one in eight information technology projects can be considered truly successful (failure being described as those projects that do not meet the original time, cost and (quality) requirements criteria).
The study covered 214 information system projects between 1998 and 2005 across European Union and various industries from manufacturing (43 projects) and retail (36) to logistics (9) and agriculture (6). The largest group of projects (40.65%) is quite large in budgetary size (10-20 millions EUR).
Prior research by the authors in 2002 identified that 7 out of 10 software projects undertaken in the UK adopted the waterfall method for software development and delivery. Results from the analysis of cases indicates that almost one in four of the projects examined were abandoned after the feasibility stage of those projects completed approximately one in three were schedule and budget overruns.
It is unfortunate that the latest study did not look at a split between waterfall and Agile methodologies applied in these projects, and whether there was any solid trend in terms of success and failures depending on the methodology choice.
I also wonder if a number of projects completed (76.2%) is inflated as the study did not follow through with measuring user adoption without which no ROI is not achieved. That very fact underscores, in my opinion, the very reason why IS project failures are so prevalent – these projects should not be led by enablers (IS), but by process owners who should be responsible for holistic approach to organizational transformation.
Key reasons why projects get canceled
- Business reasons for project failure
- Business strategy superseded;
- Business processes change (poor alignment);
- Poor requirements management;
- Business benefits not clearly communicated or overstated;
- Failure of parent company to deliver;
- Governance issues within the contract;
- Higher cost of capital;
- Inability to provide investment capital;
- Inappropriate disaster recovery;
- Misuse of financial resources;
- Overspends in excess of agreed budgets;
- Poor project board composition;
- Take-over of client firm;
- Too big a project portfolio.
Management reasons
- Ability to adapt to new resource combinations;
- Differences between management and client;
- Insufficient risk management;
- Insufficient end-user management;
- Insufficient domain knowledge;
- Insufficient software metrics;
- Insufficient training of users;
- Inappropriate procedures and routines;
- Lack of management judgement;
- Lack of software development metrics;
- Loss of key personnel;
- Managing legacy replacement;
- Poor vendor management
- Poor software productivity;
- Poor communication between stakeholders;
- Poor contract management;
- Poor financial management;
- Project management capability;
- Poor delegation and decision making;
- Unfilled promises to users and other stakeholders.
Technical reasons
- Inappropriate architecture;
- Insufficient reuse of existing technical objects;
- Inappropriate testing tools;
- Inappropriate coding language;
- Inappropriate technical methodologies;
- Lack of formal technical standards;
- Lack of technical innovation (obsolescence);
- Misstatement of technical risk;
- Obsolescence of technology;
- Poor interface specifications;
- Poor quality code;
- Poor systems testing;
- Poor data migration;
- Poor systems integration;
- Poor configuration management;
- Poor change management procedures;
- Poor technical judgement.
The bolding is mine. let me know in comments what you think.
Every time I participate in initial discussions of proposed enterprise application with business process owners, the same phrase keeps popping – “We want this system to be flexible”. I used to ask for clarifications, and usually they would respond with extremely ambiguous definitions of flexibility. We usually place positive value on the term “flexible”, but let’s face it, it is very easy to produce very negative, unintended results when the systems allow relaxed approach to processes and practices. The root of the current financial crisis is bringing too much ambiguity into definition of credit worthiness. How meaningful would Sales Forecasting system be, if expected dates of sale be defined as “sometime next year”?
That is moderately interesting (I hope), but not particularly helpful, however 12 steps program assure that acknowledgment of our problems is the first step to resolution. I can see two potential approaches to be taken, and I promise neither one involves changing human addiction to ambiguity.
A blog about experiences, curiosity and the never-ending search for ways to do better things better