I often address the problem of email overload in this blog. Recently a colleague pointed out to me several high-profile articles focusing on the same problem.

A NY Times blog post in December 2007 asks "Is Information Overload a $650 Billion Drag on the Economy", describing it as follows:

The information-overload toll is largely a byproduct of workers grappling with the growing tide of e-mail, instant messages, cellphone calls, wikis, blogs and the like.

... while technology investors bemoan the lack of decent solutions:

• 2,433 Unread Emails Is An Opportunity For An Entrepreneur


• Did Darwin Skip Over Email?

E-MAIL has become the bane of some people’s professional lives.

The NY Times article goes on to describe the new wave of tech startups that attempt to address the problem by tinkering with your inbox (ClearContext, Xobni, BoxBe, RapidReader, et al), and then dismisses them all by pointing out that:

None of these services really eliminates the problem of e-mail overload because none helps us prepare replies.

Indeed. The true problem here is not the email protocol, or current email clients, both of which serve their purpose reasonably well. The problem is what I call network overload, which refers to the increasing volume of human interaction in the workplace. This interaction manifests itself not only as email, but also as phone calls, conference calls, text messages, instant messages, face-to-face meetings, and in many other ways.

To solve the network overload problem, one must first ascertain its cause. In this case, the root cause is not due to easier communication via technology such as email. Rather, the root cause is the increased amount of collaboration that most people are expected to participate in.

To deal with this, one first needs a means of sorting the wheat from the chaff - distinguishing messages (of any kind) that are part of an ongoing collaborative activity from messages (of any kind) that are simply informational.

Only then is it possible to fix the real problems of email:

• Discussions that fizzle out, fragment among different colleagues, or
  lose their purpose


• Attachments scattered all over your file system


• No way of ensuring use of a specific version of an attachment, or even
  of knowing what version your colleagues are using


• Actions that cannot be tracked, or for which you are not sure if anyone
  has even taken responsibility


• Doing work without knowing what value anyone is getting from it


• Having to spend too much time assembling audit trails for work carried
  out

TAKE AWAY

The next generation desktop productivity tool cannot possibly be a clever Outlook plug-in that endlessly re-organizes the messages in your inbox, hoping thereby to discover hidden nuggets of gold. This is fiddling while Rome burns! Rather, the next step forward in workplace technology is software based on a robust theory of human interaction: a Human Interaction Management System (HIMS).

A HIMS helps you understand the collaborative work processes (Stories) in which you are engaged, and makes it easier for you to execute your part in these Stories. As the NY Times would say, a HIMS eliminates the problem of e-mail overload by helping you prepare replies.

If you are interested to try out a HIMS, the reference implementation of a HIMS is the free HumanEdj, available now in beta.

Posted by keithhb in Email | Permalink | Comments (0)

Recently a lot of attention has been paid to the book Wikinomics, by Tapscott and Williams:

Today, encyclopedias, jetliners, operating systems, mutual funds, and many other items are being created by teams numbering in the thousands or even millions. While some leaders fear the heaving growth of these massive online communities, Wikinomics proves this fear is folly. Smart firms can harness collective capability and genius to spur innovation, growth, and success.

A brilliant primer on one of the most profound changes of our time, Wikinomics challenges our most deeply-rooted assumptions about business and will prove indispensable to anyone who wants to understand the key forces driving competitiveness in the twenty-first century.

Based on a $9 million research project led by bestselling author Don Tapscott, Wikinomics shows how the masses of people can participate in the economy like never before. They are creating TV news stories, sequencing the human genome, remixing their favorite music, designing software, finding a cure for disease, editing school texts, inventing new cosmetics, and even building motorcycles.

This is hype, of course. Less breathless appraisals of the book than its blurb above point out some of the book's shortcomings:

A review of this book in the Harvard Business Review states "like its title, the book's prose can fall into breathless hype." A review of this book in Choice recommends the book for "general readers and practitioners," but cautions that the authors "present an optimistic overview of successful collaborations and business ventures", "use unique terms (e.g., marketocracy, prosumption, knowledge commons)", should have given "more consideration [to] the darker sides of human motivation as well as groupthink and mass mediocrity", and "primarily draw on their own observations of businesses and trends for the ideas presented."

Nevertheless, it seems clear that blogs, wikis, et al are helping to bring about a fundamental change in the workplace. They accelerate the process started by the Web itself, namely democratizing the publication of information. One could view such technologies as enablers for the Community of Practice idea that has been hovering on the fringes of business life for the last 2 decades.

Further, the widespread use of such powerful communication tools is helping people realize that communication is not the same as collaboration. In fact, many of the people spearheading this recognition are those keenest to promote the existing communication tools. They seek new collaboration tools to go with their wikis and blogs, since they know that for their beloved wikis and blogs to succeed long-term, there must be a way for organizations to manage the explosion of communication that is resulting from large-scale, one-to-many information publication.

Without some form of control applied appropriately at each level of the organizational hierarchy, the "wiki workplace" will simply descend into anarchy.

TAKE AWAY

The authors of Wikinomics are sponsoring the creation by the general public of an "unwritten chapter", via a wiki that will be transformed into a document for publication at key points. This wiki has some interesting ideas. In particular, the vision espoused therein for Enterprise 2.0 offers a compelling vision for the next generation workplace, suggesting that a "People-Oriented Architecture" (POA) is needed to go with today's SOA.

Regular readers of this blog will recognize a similarity between the "Enterprise People Bus" described therein and the knowledge bus concept outlined in some of my previous posts.

There is no doubt that wikis, blogs and the whole panoply of social software tools are changing the workplace. Whether or not this change is for good depends on how fast organizations take up the collaboration tools needed to bring order to the chaos.

Posted by keithhb in Management | Permalink | Comments (0)

Regular readers of this blog will be used to my promoting free and/or open source solutions to enterprise software problems. However, there is one area in which I struggle to do so - namely, databases.

Given the ubiquity and importance of relational technology in the workplace, and the array of features offered by open source databases such as MySQL, this may seem a bizarre statement. Yet for many organizations, the primary concern is no longer flexibility or performance, but security:

Many organizations struggle to find a sustainable way to meet global GRC requirements around financial reporting, data security, records retention, risk management, and more.

FACT: Industry analysts AMR Research expect organizations to spend nearly $30 billion this year alone, grappling with questions such as:

• How can we stay on top of increasing regulatory demands while controlling cost?


• How can we better manage risk to prevent business and compliance failures?


• How do we achieve better performance while ensuring accountability and integrity?

Oracle Security Solutions, p.4

In my experience, such concerns are becoming more and more important to CIOs. Yet, in this area, there are few offerings, and little indeed that is free and/or open source.

In particular, if you wish to secure data at row level - so that each row has different access permissions, a normal enough requirement in an enterprise environment - options are few. The best approach appears to be an optional Oracle database feature known as Oracle Label Security (aka OLS). Here is how OLS works:

• First, security policies are established to identify how the data needs to be secured by specification of security components for the policies.
• Next, user labels are established that define what row-level security policies are possible for each user.
• For each table that needs to enforce row-level security, a special column called a label column is built and populated.
• During data access, a process called access mediation determines which permissions are required to access the row, and what actions can be performed on the row once it's accessed.

OLS uses three sets of criteria to define both the set of user's permissions to access data in a row as well as the row's accessibility: levels, compartments, and groups.

Levels. As the first security dimension's name implies, a level defines increasing data sensitivity. A typical example includes the standard security levels (Unclassified, Classified, Secret, and Top Secret). Another example for most companies is human resources information. Just about everyone needs to know everyone else's first and last name and e-mail address (i.e. company-wide access). However, only the employee, her supervisor, and the Human Resources department should know salary information about the employee (hopefully!) only the human resources coordinator should know about an employee's participation in a company-sponsored anger-management class.

Compartments. The second security dimension, a compartment defines the areas to which data access is restricted. In other words, compartments can be used to classify data. Typical examples of compartments include functional divisions within a company (Sales, Accounting, Human Resources, Information Technology).

Groups. A group is the third security dimension. It typically defines who is the owner of the data and provides yet another way to classify what type of access is permitted. However, groups have one important difference: They can be used to restrict access to data based on the owning organization's hierarchical structure. Business rules appropriate for group enforcement within a group include geographical areas (localities within states/provinces, and states/provinces within countries) and sales forces (regions that encompass several districts that themselves encompass territories). What's really great about this feature is that OLS allows me to restrict row-level access to specific nodes of the hierarchy. For example, I can grant a sales force's regional manager access to only sales generated within his region's districts; a district manager access to sales generated only within her district's territories; and a salesperson to only the sales generated within his territory.

Security Component Combinations. For each of the label security components, up to 10,000 different values may be established. OLS requires that, at a minimum, one value for the security level must be stored in each label column, even if it indicates unrestricted access is permitted. Note, however, that compartments and groups need not be included in the label column's value. Also, each row and each user can be assigned multiple access permissions for compartments and groups.

Oracle Label Security, Part 1: Overview, By Jim Czuprynski

Functionality such as OLS should really be part of every database that claims to be enterprise-strength. Perhaps I have missed something, but I cannot see how to achieve equivalent results using (say) DB2, let alone open source alternatives such as MySQL. I believe DB2 has some sort of equivalent to Oracle's Virtual Private Database (VPD - the technology underpinning OLS) in its mainframe edition. But, to my knowledge, that's it, although I have not done proper comparative research in this area.

Further, OLS has been around since 2003, and still has major weaknesses - for instance, support for use of J2EE, since use of OLS via TopLink is currently broken.

TAKE AWAY

I am bemused by the weakness of database offerings with regard to security - especially given the current worldwide focus on combating terrorist threats, the rise of cyber-crime, and the general acknowledgement that the most common threat to organizational security is from insiders.

Your comments are very welcome on this topic! If you have expertise in this area, please share it. I'd be very interested to know your thoughts.

Posted by keithhb in Open Source | Permalink | Comments (0)

Recently I have been doing some consultancy work around requirements analysis - in particular, for a large project that decided halfway through to postpone a large swathe of requirements until a later stage.

This move, intended to reduce risk, in fact replaced one set of risks (that the requirements could not be implemented as intended) with another set of risks (that the resulting system was not fit for purpose). Hence I have been attempting to de-risk the project by analysing the implications of the move - not only on users of the initially delivered system but also on the project itself at a later date. It is quite possible that, in order to deal with the absence of certain capabilities in the short-term, it may be necessary to introduce design features into the technical architecture that turn out to prevent successful retro-fitting of the missing capabilities later on.

This heart of this work is to analyse the patterns of behaviour that humans will adopt to work with each other via the system. As a result, it has an interesting synergy with a paper I wrote a few weeks ago, for the Requirements Networking Group. Here is the abstract from the paper:

In the end, software applications are only there to support human work. Even a low-level, highly automated software application for (say) car numberplate recognition or payroll calculation is only there to meet the needs of the police officers or HR staff who ultimately set its initial parameters and use its output.

Yet most approaches to understanding and modelling human work have a major weakness – they offer reasonable support for capturing H2S interactions (between humans and systems), but are extremely weak when it comes to capturing H2H interactions (between humans and humans). Further, mainstream modelling techniques provide little of the context required to understand what truly goes in knowledge work.

You can find the paper online. You have to join the RNG to access it, but membership is free.

TAKE AWAY

It is really quite startling that issues such as the above are still a problem for software requirements analysis, when you consider how fundamental an engineering task it is.

As another illustration of the immaturity of this aspect of software development, the open source movement is only just waking up to the need for a general requirements management framework (see Open Requirements Management Framework aka ORMF) and an enterprise-oriented application development framework to encompass it (see Open System Engineering Environment aka OSEE). Both these frameworks are only just getting off the ground.

Have you ever noticed how a root cause of software project failure lies in poor requirements engineering? If so, you may like to read the paper referenced above, and check out ORMF/OSEE for yourself.

Posted by keithhb in Requirements | Permalink | Comments (0)

If you have been following my recent blog posts, you may be interested to know that a consultancy client recently evaluated the effects of applying the techniques described in the post on hyper-productivity to fault fixing.

Their conclusion was that when using my techniques for fault fixing, faults were fixed in approximately half the normal length of time, or in other words, that developers were twice as productive as usual.

TAKE AWAY

Most literature on fault fixing estimates that the average developer spends over 50% of their time fault fixing. So if you are looking to improve the efficiency of your development staff, it must be worth considering techniques that double the productivity of this time.

Posted by keithhb in Management | Permalink | Comments (0)

Following my last post, on Hyper-productivity, I thought I should add some remarks about staff levels.

Budget and resource constraints often mean that, even if too many faults are appearing in a software project, it is not always possible just to add staff. However, even if it is possible, it is often not a good idea.

Adding staff works on the seemingly common sense principle that if 10 developers can fix n faults per week, 20 developers can fix something not too far from 2n faults per week. Software project managers often seem to believe that having more people are working on the job will inevitably lead to an improved delivery rate.

Unfortunately, however, this is not true. In fact, adding staff may well lead to a reduced delivery rate.

Many readers will be familiar with Fred Brooks' seminal book on software project management, The Mythical Man-Month: Essays on Software Engineering. The concept of "The Mythical Man-Month" refers to his principle that "Adding manpower to a late software project makes it later". Brooks says this is because adding people to a project has 2 primary knock-on impacts.

First, the newcomers have to be trained in the skills they need, and familiarized with the project itself. This takes up not only their time but the time of other people - often the people who know most, and who are hence most productive. Induction also takes up other resources of various kinds that can then bottleneck the overall work being done by the project.

Second, the number of communication channels increases dramatically with the number of staff. Brooks' formula is that for n developers, there are n(n - 1) / 2 communication channels within the group. For example, 50 developers implies 50(50 - 1) / 2 = 1225 channels of communication.

This second point is a simplification, of course. Many people would argue that careful management can reduce the number of communication channels. However, from my experience, Brooks' formula is useful whether or not it is exactly correct, in that it indicates the scale of the problem. If you observe any large project from the floor you will see that there is a great deal of human interaction taking place, of all different kinds - not just formal meetings, but emails raising issues, questions asked over the cubicle wall, casual discussions by the coffee machine, and so on. It is very hard indeed to quantify this interaction and even harder to assess its value.

TAKE AWAY

It is possible to add staff to a late-running software development project and gain value. However, it must be done very carefully. To be specific, first you must design the collaborative work processes in which the new staff will engage, using the techniques of Human Interaction Management.

Only by this means can you find out what bang you will get for your buck - what improvement in delivery rate you can expect from purchasing extra staff. In fact, only by this means can you be sure you will actually get an improvement, rather than the deterioriation expected by Brooks.

Further, a moment's thought will show that designing collaborative work processes for new staff is no use unless you have already designed the collaborative work processes for current staff - and ensured that current staff are actually engaging in these processes. Otherwise the structured interactions of the new workers will dissipate into chaos as soon as they start working with people already on the project.

It is possible to improve a late-running project by adding staff, but you can't do it by building a house on sand.

Posted by keithhb in Management | Permalink | Comments (0)

In the last few months I have been approached several times for advice about large software projects in which the fault rate is out of control. This is not as simple as saying that faults are appearing much faster than they can be fixed - at certain stages of a project, one expects this. The real problem is more complex, and relates to the nature of large software projects.

It is important to understand in what ways a large software project is unlike a small one. As I often suggest, one can gain understanding here by comparing software engineering with traditional heavy engineering. For instance, engineers who deal with extremely large and complex systems in fields such as aerospace and the military have always been used to projects that go live with a high number of faults, many of which will remain open throughout the entire lifetime of a system. Fault control in such systems is as much about managing faults as about fixing them.

However, this is not to say that one can take a relaxed attitude towards fault control. There are well-established metrics available for the "defect density" one can expect at each stage of large software projects of certain types in certain fields. These metrics allow software project managers to use the current number of faults, the current fault rate, and the current fix rate to predict where their project will be in the future - and understand whether or not these predictions are worrying.

The situations about which I was asked were worrying. Predictions showed that build deadlines would not be met, and that by a certain point in the future, the number of faults would escalate beyond the managers' ability to control. What should one do in such circumstances?

Taking another leaf out of the military's book, there are 3 approaches that should be used in combination: operational, tactical and strategic. If you prefer, think of these approaches as short-, medium- and long-term. Taken together, they provide a means for even large software projects to become "hyper-productive" - a phenomenon well-recognized in certain small teams, but rarely achieved on the biggest projects.

Operational

One needs to do something in the short-term, not only to stop the situation getting further out of hand, but also to raise morale. Developers do not like to work on failing projects, and once your developers start leaving (or just giving up), you are really in trouble. Even if management somehow conceal the true situation from developers - which is never easy - there is the morale of managers to consider as well.

So in the short-term, it is advisable to set up an emergency room - a lab environment in which some of the best developers can work free from disturbance to knock some of the worst faults on the head as soon as possible. It is often surprising how much progress can be made by reducing the amount of interruption people are subject to. People should not be allowed to enter the emergency room without permission, and if the lab fault fixers need to talk to someone from outside, that person should be brought into the room specially.

A manager should be appointed for the lab, a person who is able to create a team atmosphere as well as maintain a sense of urgency. A key part of the manager's role is to ensure that work is allocated in the most efficient manner possible from hour to hour - sometimes from minute to minute. Everyone should be fully loaded, the whole time, and distractions such as checking email discouraged. The aim is to maintain a sense of flow.

Lab work of this kind is exhausting, so the participants should be rewarded with overtime payments and pampered with free, luxury food and drink. However, the work is also rewarding due to the awareness of visible progress and the team spirit that should be engendered. Further, such a lab is a powerful means of knowledge sharing - after working in the lab, a developer will not only have more system knowledge but may well have acquired new ideas and techniques that will be useful going forward.

Nevertheless, this approach is not intended to be a normal part of the project. If it is necessary to carry it on for more than a month, the participants should change regularly - weekly, for example - to avoid burn-out. Lessons can be learnt by both developers and managers from such a lab, but the emphasis should be on carrying these lessons into regular daily practice rather than on sustaining the lab itself.

Tactical

In the medium-term, there are various means to reduce pressure on a project, with which most project managers are familiar. Deadlines and the content of deliverables can be renegotiated with the client. Workarounds can be developed for areas of fault. End-user expectations can be managed, such as when to expect the introduction of particular aspects of system functionality. Training can be planned so that end-users acquire system knowledge gradually, in order to allow time for the corresponding functionality to be released. Easy-to-use techniques can be developed for end-user fault reporting and control.

When proposing such measures to the client(s), one should take care to present a positive picture. Don't emphasize the trouble the project is in! Rather, explain how your advanced project management techniques have identified potential problem areas well in advance, and prepared a range of compensating solutions. The client(s) should come away from such a meeting feeling glad that you are in charge, not someone who might have let the problems go unnoticed until it was too late.

Strategic

However, it is only fair to admit that, if the project has got to this state, someone has slipped up - even if it was your predecessors. Clearly the scope of the work was misjudged, inadequate development techniques have been used, project management has not been optimal, and so on. So it is necessary to take remedial action to get the project properly back on track in the long-term.

There is a wealth of advice available here, particularly with regard to "Agile" techniques. I recommend Jim Coplien's book Organizational Patterns of Agile Software Development. If you can't face a long read, here are some summaries of "the ten patterns that research has found most strongly correlate to business success": PDF HTML.

One should take the time to understand what Agile project management is all about. Unfortunately, though, Agile techniques work much better with small projects than with large ones. In my experience, agile techniques typically have most success in projects with less than 50 staff, and projects with over 100 staff need something else. So here are some techniques that I have found useful in getting large projects back on track.

1. Food
   Provide ample, high-quality food free to all project staff daily. A small investment in pampering of (say) £10 per person per day pays huge dividends in morale and commitment. Don't be mean! The aim is to make people feel valued.
2. Team ownership of code
   You can't act responsibly if you're not responsible for anything. Coders must own their bugs and work as a team to reduce them. Develop continuous integration practices and put up highly visible flags in each team area every morning: green, amber, red to indicate code quality for that team based on automated testing of last night's build. Institute a daily trawl through all open faults by each Work Package Manager with a view to escalating or delegating faults or actions as appropriate. Introduce a weekly quota of fault fixes based on size of team.
   Careful synchronization with the emergency room is clearly necessary here while it is running.
3. Knowledge management
   Build system knowledge. Black box: give developers a user's perspective - terminology, operation, concerns, etc. White box: make sure they understand what all the different parts of the system do. Do both these things as early and as widely as possible to get maximum benefit. It doesn't take as long as you might think - lunchtime seminars could be the way to go, for instance.
4. Testing
   Give developers a means to test the system as a whole (not just to run unit tests). In particular, they need a framework with which they can construct and run end-to-end tests themselves, for example to reproduce informal user fault reports or check particular behaviour relevant to a fault. Helping develop such a framework may be one very useful output from the emergency room.
5. Pair programming
   Pairs of roughly equal ability but mixed knowledge work best. Change the pairs often. Check to ensure that both people are contributing rather than having one driver and one passenger. Convince people to give it a go - nearly everyone finds they like it. In general it is more than twice as productive - i.e., worth doing.
6. Systematic fault fixing
   Most developers in the industry as a whole spend over 50% of their time fault fixing. Yet they never learn how to do it properly - probably because there is no standard methodology or even practices. I have compiled a systematic fault diagnosis procedure based on the research papers and books that are available, and found that for faults that take more than 2 hours to diagnose, it makes a dramatic difference. It has enabled faults to be solved in hours on which experienced developers previously spent weeks and got nowhere.
7. Reduce distraction
   The BBC reported on 13 August 2007 that "Workers are 'stressed out' by e-mails". Regular readers of this blog will be aware of my view that this is a pernicious problem across the board in the modern workplace, and that the solution lies in new Human Interaction Management tools such as HumanEdj.

TAKE AWAY

It is often tempting to push problems under the carpet when they seem to huge too solve. Large software projects that have gone out of control can seem like a many-headed hydra - as soon as you solve one problem, ten more problems appear. However, there is always a way through the labyrinth.

The key is to be systematic - in particular, divide remedial measures into operational, tactical and strategic.

Further, take care to explain what you are doing to others and get them on board - this is key. Developers as well as managers should understand what is going on and what you are doing about it. A typical but very unhelpful approach to managing crisis situations is to take everything behind closed doors. Resist this temptation! People are surprisingly good-natured, even in times of stress, if they are made to feel a valued part of something - as opposed to being excluded from important discussions.

There is a route to hyper-productivity, and it is not hard. You just have to take it in stages.

Posted by keithhb in Management | Permalink | Comments (0)

Regular readers of this blog will know of my view that the next significant step in both IT and management is to improve the way that people do collaborative knowledge work (what I call "interaction work"). You can find all sorts of evidence for this view on the Human Interaction Management Web site. However, most people know from their own experience that action is needed, and the sooner the better. In particular, working hours are getting out of control, a trend that is not helped by the current expectation that everyone is "always on" via their mobile phone.

A typical factor in people's inability to control their workload is the necessity to use inefficient workplace software, the main culprit being email. Across the board in industry there are major problems resulting from use of email. It is not at all clear when emails should be sent, what they should contain, who should be included, the validity of requesting actions from people, who has committed to do what, the correlation between different email streams, the accuracy of data included, etc. Almost daily, this lack of clarity causes material problems in organizations of every kind.

Problems such as email usage are complex to resolve, relating as they do to process awareness, new approaches to management, new forms of software, and more. Hence solutions for such problems can be expensive to implement in large organizations. How can one justify the expense? In other words, what is the basis of a business case for the introduction of more efficient human collaboration?

It is necessary to find a quantitative means of evaluating the impact. One can list ad nauseam aspects of organizational life that will be improved by rationalizing the way people work together, but the board have a duty to consider the bottom line in any major decisions they make. However swayed they may be personally - e.g., from experience of mobile phone calls at ungodly hours - they will not be acting with due diligence if they approve a programme that has no means to demonstrate Return On Investment (ROI). So it is necessary to find a metric that is applicable to human collaboration.

This is non-trivial, since there is a difference between efficiency and effectiveness.

When measuring the impact of process improvement in mechanistic areas such as transaction handling or manufacturing, the outputs of the process are probably going to remain similar after the changes have been implemented. The aim is simply to produce these outputs quicker and cheaper. In other words, one is aiming for increased efficiency.

The same is not at all true for human collaboration. Free people up by helping them work better, and they will deliver more value to the organization. Once people are not struggling to keep afloat, they can help steer. In other words, improving interaction work delivers increased effectiveness. However, in advance one cannot always predict what form the increase will take. Take sales, for example. One might expect a salesperson who works better to make more sales, but it is quite possible that the actual improvement will be customer relationships that are longer-lasting, something that cannot be measured until enough time has passed.

So what metric should one use when proposing a programme to improve human collaboration in the organization?

TAKE AWAY

The simplest metric for human collaboration is very simple indeed. Work out how much you pay people per hour. Then count how many hours they are spending at work, taking care to include work done out of the office. If your staff start taking less time to do their work, you are getting better value for money.

This applies even if you don't pay people overtime. There is a huge hidden cost to working long hours. Tiredness and stress not only make people miserable, but reduce their contribution to the organization and increase "churn" (the frequency at which staff leave the organization altogether). These negative impacts are at least partially offset by paying people decent overtime - and if you don't pay people overtime directly, you can be sure that your organization is paying the price somehow.

So a first step for a programme to improve interaction work in your organization is to find out how much time in each day people are taking to do their work. Cost this time based on salaries, and aim to reduce the total by a specific amount - say 1 hour per day per person. This effectively gives you a budget for the interaction work improvement programme - spend any less than this in total, and you will have delivered ROI.

Of course, this is using the narrowest of measures - a measure that takes no account of the significant improvements you can expect in effectiveness, which as discussed above will be the main benefit of the programme. However, the aim here is simply to get the programme approved by the board. Once you get going, material impacts of all kinds will become evident. It will be much easier to get approval for your second interaction work improvement programme than for your first!

Posted by keithhb in Business Process Management | Permalink | Comments (0)

Readers of my last post on the knowledge bus may be interested in James Taylor's response, to which I added an explicatory comment.

A case study illustrating use of the knowledge bus will be published in my bptrends.com column "Human Processes" in March. When it appears, I'll link to it from this blog.

The case study can be found here:

"What is the next major step in enterprise IT? Keith Harrison Broninski has a fascinating perspective. He argues convincingly that there will be a shift in emphasis from server-side automation application to client-side human interaction. Read his Column for the details of why he’s convinced this change will occur. "

Posted by keithhb in Business Process Management | Permalink | Comments (0)

Had a fascinating conversation yesterday with Jim Sinur, someone who understands very well what is coming in IT - namely, that the emphasis is shifting from server-side application automation to client-side human interaction.

In particular, dominating the desktop is going to mean something quite different in the 21st century. Whether or not Microsoft remains the leading operating system and office application supplier, the current trend towards commoditization of such products will eventually render Microsoft's presence more akin to that of a company like Cisco. Most people with an interest in IT know roughly what Cisco does, but most ordinary mortals don't think of themselves as Cisco customers.

So who or what will dominate the desktop in the 21st century? The increasing pressures on knowledge worker productivity that I often discuss in this blog means that we are all coming to expect more from workplace IT. In particular, we don't need cleverer tools - office applications, for example, have provided more than enough for most of us for a long time now. What we need is a way to join up the work we do using such tools.

Jim refers to this new layer of technology as the knowledge bus, which I think is an excellent term. It certainly describes very well what I have been trying to achieve with HumanEdj. Here are some key characteristics of a bus:

• A bus is a mechanism for crossing boundaries. A server-side business application is typically intended for use within a related set of organizations, since someone must own the servers on which it runs. Knowledge work is not like this, however. More often than not, it spans organizational boundaries - typically since both customers and suppliers are involved, but more generally due to the trend towards outsourcing and other forms of collaborative partnership that has come with globalization.


• A bus carries a payload. Transmission of information is the essential precursor to knowledge work, which can be viewed as the process of turning information into knowledge and decisions. This information can be structured (think Business Intelligence), unstructured (think emails), or semi-structured (think documents). A knowledge bus must be able to handle all these and more.


• A bus provides an infrastructure in which routing decisions can be made.. Here things get really interesting. How are routing decisions made in knowledge work? By humans, yes, but to support them and increase their efficiency the bus should allow the use of Business Rules in combination with human decision-making. This is vital for several reasons, not least to reduce the likelihood of uncontrolled rule evaluation leading to business disaster, such as is commonly thought to have happened in the UK Stock Market on "Black Monday" (19 October 1987).

TAKE AWAY

The latter aspect of a knowledge bus - routing - is in some ways particularly interesting.

Looking forward, it may be that we will see a convergence of Business Rule Management and technology support for knowledge work. If human intervention in rule evaluation is to be controlled properly, it must be viewed as a collaborative business process - what HumanEdj calls a Story. Hence, a precursor to safe use of Business Rules in an enterprise environment is the implementation of techniques and technologies for support of Stories.

Further, the creation and administration of Business Rules in the first place is just as much a candidate for control via Stories as their operational usage. Here again increasing competitive demands will force new levels of complexity in business operations, via extended Business Rule support - but without proper safeguards on the implementation of this support, we will only see more disasters like Black Monday,

20th century technology is not going to go away - if there is one lesson that the IT world should have learnt by now, it is the extraordinary longevity of legacy systems. However, it is certainly not going to be enough to meet the demands of the 21st century. The missing piece is the client-side, desktop-based infrastructure that allows organizations to leverage - safely - the enterprise backbone into which they have already invested so much money and effort. Thinking of this new infrastructure as forming the knowledge bus may be an illuminating way to make sense of what is coming.

Posted by keithhb in Knowledge Management | Permalink | Comments (0)