Recently my wife has been trying to pay for the milk that, like every other child in her class, our daughter is given during the morning break at school. Parents have to settle the charge for this before the end of the previous term.

A simple enough matter, surely - a couple of clicks on a Web site should sort it out. Yet (so far) making this payment has required a series of telephone calls and dealings with four separate individuals at the organization who supplies the milk to schools, since the computer system that handles the payment was "acting up" in some unspecified way.

I wouldn't mention this if it was a one-off - an exception far from the rule. Yet a similar Kafkaesque scenario ensued when I tried to buy my son a new trombone. Arranging for him to use the school bus is a saga that will run and run. And after a recent experience with the UK government's online VAT service I may need counselling.

Is it just us? From the tales told by everyone else we know, ranging from health care to legal proceedings, I don't think so. The take-up of automation in our society is like the Emperor's take-up of new clothes - we're all just pretending it works.

I have learned the hard way to distrust any information generated by a computer. I have also started questioning the value of automation per se - especially of process automation. The interactions above would have been simpler, quicker and cheaper for everyone concerned before the organizations concerned installed workflow/BPM systems.

Pareto's rule tell us that the 20% of exceptional cases that require human attention result in 80% of the costs. Personally I would guess that the number of such cases is higher than 20% - and other commentators put it far higher. For instance, the Chief Strategy Officer of a major BPM company estimates that exceptional cases are 50% of all cases. If this is true, is the automated process helping or hindering people's efforts to get work done?

TAKE AWAY

Since first writing about Human Interaction Management, I have positioned the associated technology as complementary to mainstream BPM tools. I have always said that you need two forms of process software, in order to provide support for both human-driven and mechanistic processes. I am now starting to wonder about the efficiency of the latter - especially given the continually decreasing cost of human labour, and the desperate need for work among people in developing countries.

Why are corporations giving their millions to BPM/workflow vendors, when they could be building a committed and flexible workforce to deal with routine work by hand?

Is it an outlandish thought, that people might actually be better than machines at routine work?

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

I often write about the problems of poorly organized knowledge work, and recently have had the opportunity to derive the financial costs of these problems. So here are some figures for your amusement.

Regular readers know what I am talking about. If you're not familiar with the knowledge work problem, you can find a summary of it in my latest column for bptrends.com.

First, how many knowledge workers are there?

It is hard to estimate this in many parts of the world, particularly in developing countries where the rate of societal change is fast. So for estimation purposes I focused only on the US and Europe, calculating numbers of knowledge workers in these regions as follows:

• Estimates of the proportion of knowledge workers in the US economy vary from 59% (“The Growth of Information Workers in the US Economy”, Professor Edward Woolf, New York University, published in Communications of the ACM, October 2005) to 80% (”Management Information Systems For the Information Age”, Haag et al, McGraw-Hill, 2006). I assume 59%. The size of the US workforce in 2004 was 138.5 million, giving 81 million knowledge workers in the US.
• A report prepared for the Knowledge Economy Programme in November 2007 (“Knowledge Work and Knowledge Workers in Europe”, November 2007, Katerina Rüdiger and Alana McVerry) concluded that “in 2005 just over forty per cent of the European workforce was employed in knowledge based industries as defined by Eurostat”. I assume 40%. The size of the European workforce is given in Eurostat figures for 2007 as 235 million (the “Active population” out of a “Total population” of 487 million), giving 94 million knowledge workers in Europe.

This gives 81 + 94 = 175 million knowledge workers in the US and Europe.

Now for the money. In late 2007 the research firm Basex carried out market research on the average time per day lost to "distractions" - in other words, to the inability to control collaboration with colleagues (“Information Overload: We Have Met the Enemy and He Is Us”, Jonathan B. Spira, David M. Goldes, March 2007, basex.com).

They found that:

1. The typical loss of time due to distractions is 2 hours per day;


2. The average salary cost per hour of a knowledge worker is $21;


3. Hence the average cost per person per month of distractions is $21 * 2 * 20 = $840.

In actual fact, the true cost of distractions is likely to be far higher, since every interruption breaks the flow of concentration. Recent case studies based on my consulting work (documented in previous postings to this blog) showed that allowing software developers to work without interruption doubled their productivity.

However, let's keep it simple and use Basex's figures.

Finally, suppose that a platform based on new techniques could remove just half of this cost - i.e., $420/worker/month.

What would you pay for such a platform? At least $20/worker/month, surely. Perhaps you would pay $100/worker/month - even, at a pinch, $200/worker/month, which would still provide over 100% ROI.

TAKE AWAY

Pick a figure between $20 and $200 and multiply it by 175 million. Then add a bit for the world beyond the US and Europe (which is hardly insignificant). And remember these are monthly amounts.

Clearly the market for knowledge work tools is huge - potentially hundreds of billions of dollars per annum. Surely this dwarfs any other software market - even dwarfs them all put together.

The reason, of course, is that structuring knowledge work is not an IT problem at all, but a business problem. So improving knowledge work directly improves business, and hence is worth a fraction of global GDP rather than a fraction of total corporate IT budgets.

Of course, every software vendor on the planet claims this for their tools! However, they only get away with it (when they do) since they are selling to people who already believe that better IT means better business! Talk to a few knowledge workers, and you hear a different story - a story along the lines of, "well, IT hasn't improved my life".

Most knowledge workers are now doing longer hours, and suffering more personal stress, than ever before. Unfortunately, their human right to a better deal doesn't come into corporate accounts. Fortunately, the financial reality is that a better deal is on the way.

The current crop of knowledge worker tools (basically, shared workspaces with no process context, or process tools based on software design techniques) may not deliver the goods. But with a market this size, it won't be long before real-world techniques such as Human Interaction Management, aka HIM, and corresponding new tools such as HumanEdj, find their way onto your desktop - and you get your life back.

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

A harsh reality of the modern workplace is that people are often hired for their purely mental qualities - analytical faculty, strategic skill, creative ability, and so on - then penalized for using them.

In particular, there is a general perception that managers judge time spent "just" thinking as time wasted. Whether or not managers actually think this is almost beside the point! The culture of many workplaces is such that people feel they have to "look busy", which often means sacrificing the valuable thought they could be putting into their work for the sake of filler activities whose outputs can at least be measured.

Of course, many managers are sensible enough to understand that their staff are not always daydreaming when they sit staring at the wall. However, without a simple and effective means of planning, supporting and measuring mental work, managers are caught in something of a double bind. This is captured perfectly by an old cartoon in which 2 managers of the Acme Soap Company walk past the open door of an office in which a man is sitting with his legs up on his desk, staring out of the window. "That's Jones", says one manager to the other, "one of our best thinkers." "Yes", says the other manager, "but how do we know he's thinking about soap?"

Human Interaction Management (HIM) helps deal with this problem, by explicitly recognizing the need to support mental work as the third of its 5 basic principles:

Organizations must learn to manage the time and mental effort their staff invest in researching, comparing, considering, deciding, and generally turning information into knowledge and ideas.

HIM sets out a notation including the necessary elements to support its principles, and provides guidelines on use of this notation by identifying a number of patterns characteristic of human work. Of particular relevance to mental work are the REACT pattern and its sub-pattern AIM:

Discussing the stages of REACT in turn:

1. Research
   Map out the terrain, investigate the principles, talk to those in the know, locate potential threats, and so on, in order to gain information from external sources, and turn it into personal knowledge. The external sources may be close at hand - members of a "community of practice," for example, as discussed below. Alternatively, information may be acquired from an impartial expert in the field, a textbook, or a search on the Web. The details are different every time, but the principle is the same. Before you can start to work on something, it is only common sense to find out what you are getting yourself into.
2. Evaluate
   Step back and consider the knowledge thus acquired. Internalize it, in a sense, by making connections between different opinions or facts. Once you have discovered the general lay of the land, you then need to familiarize yourself with it. You may need to carefully read a pile of papers on your desk, or to mull over some advice that you don't yet understand. This stage may take minutes or years, but it is crucial - there is no point doing an investigation unless you make an effort to take on board the information you gathered.
3. Analyze
   On the basis of your new-found understanding, decide on an approach to the problem. In general, the approach you settle on may result partly from applying logic to reduce the problem to more manageable sub-problems - and partly from an intuitive judgment on what feels "right." The balance varies both with the type of problem and with the type of person trying to solve it. However you arrive at a conclusion, though, the decisions made at this stage are not necessarily a final say on the matter - they are simply a way forward for now; enough to let you proceed further with the work in hand. Sometimes it is hard to be sure whether you are doing the right thing, so you might choose a way forward that hedges our bets - following multiple paths at the same time, in the hope that at least one will work - or decide only on the first few steps, and leave decisions about other steps for later. But you have to make some kind of decision at this point, at least on how to start.
4. Constrain
   Divide the work into separate chunks, and organize them. This may be simply a matter of deciding an approximate order to do them in, or it may be a huge task involving all the techniques of project planning: dependency and impact analysis, critical path definition, resource allocation, budgeting, contingency planning, and so on. However, you are dealing with human-driven processes here - in which people rarely do things in the order laid down, and rightly see it as part of their work to determine how things should proceed. So this stage is not about defining "workflows," in the sense of ordering activities into strict sequence - it is about laying down the constraints that govern the chunks of work, insofar as they can be understood at this point. Typically, constraints are of rather vague form: "before you can promise a delivery date for a product, make sure the component suppliers can meet it," or "it is okay in principle to take on contract staff, as long as you've made a reasonable effort to resource the project internally first."
5. Task
   You have determined how to break the work into chunks, and handed out these chunks to appropriate people (including yourself, perhaps), so now all those concerned can get on with the tasks at hand. For a small job there might only be one chunk, and you might do it yourself. For a large one, this stage may involve many different people and organizations working together to deliver a product or service.

Of the 5 stages of REACT, the first 3 are entirely mental. The first stage of REACT, Research, can be further broken down into a sub-pattern AIM, which describes any research activity:

1. Access discovery services
   Decide where you will go to obtain information, and obtain any necessary authorization. This might be permission to contact someone, login details for a database, or funds to use some kind of finder agency.
2. Identify resources required
   From the service(s) above, choose resources likely to be of interest. At this stage, you will have only cursory understanding of their content - what matters is that they seem likely to be useful.
3. Memorize information obtained from particular resources
   It is important to focus on committing information to memory, even if the information is only the outline of an idea you will use later on. Unless you have memorized information gathered at this first stage of REACT, it is no use in the following stage, Evaluate - you cannot synthesize ideas you have forgotten, or need to look up in order to understand. This stage is all about internalizing the ideas in question.

Similarly to the way REACT describes human work in general, AIM describes the particular activities of information discovery.

Taken together, the REACT and AIM patterns describe all human working behavior. The patterns capture the way that people respond to an assignment, fulfill a responsibility, achieve a goal - the way they react to the work they take on. REACT and AIM help simplify complex situations, since the patterns can be repeated, overlapped, and nested in order to reduce any work assignment to the same fundamental stages.

TAKE AWAY

For many organizations, one of their highest costs is their knowledge workers - for which I prefer the term interaction workers, to indicate the degree to which knowledge work is dependent on collaboration. Yet such work is usually poorly managed, in that little or no place is formally allowed for the mental activities of which it consists. Managers plan and measure on the basis of concrete outputs, not mental inputs.

To get value for money from your interaction workers, this has to change. Adopt HIM principles and give your interaction workers the space to do what they do best! The first step is to plan and execute human-driven business processes using a HIMS such as the free HumanEdj. However, this is only the beginning. Once work processes have been put in place that actually reflect what people are trying to achieve, managers can then start doing their real job, which is to support the efforts of their staff by enhancing their workplace environment.

For instance, new and interesting software tools are emerging to support the process of information discovery - finding, assembling and writing up information in order to transform it first into knowledge and subsequently into decisions. These tools often emerge from academia, but are highly relevant to a world in which Google is everyone's de facto home page.

Wikipedia provides a useful Comparison of reference management software. My personal favourite is Zotero, which is free and so easy to use that I can see it dominating the space before very long.

Give you interaction workers what they need: plans that allow for them, tools that help them, and (most important of all) official recognition for the effort they put in with their minds, as well as with their hands.

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

Have you been following recent posts to this blog about the "$650 Billion Drag on the Economy" caused by what I call network overload?

If so, you may be interested to know that a tutorial is now available for the reference implementation of a Human Interaction Management System (HIMS) - a PDF that walks you step-by-step through basic usage of HumanEdj.

The tutorial is equivalent to a training course - if you want to do all the exercises, it takes a few hours to complete. Upgrade to the latest release of HumanEdj, and the tutorial will be available from the Help menu (choose Tutorial).

However, if you have limited time, you can get the document online (see link below) and in an hour or so read it without doing any exercises to gain a better understanding of what a HIMS is - and why you need one! The document includes hundreds of screenshots, to illustrate in full every action described.

TAKE AWAY

I believe that a step change is coming to the workplace.

In a few years, most people will no longer be locked in the endless nightmare cycle of globally CCed emails and mobile phone calls at ungodly hours. Neither will they be selecting programs from the Start menu or double-clicking on desktop shortcuts as the prelude to carrying out work using a computer.

Rather, they will be negotiating next steps with colleagues in their own and other organizations, using a clear visual representation of everyone's responsibilities and commitments, then executing their part of the "Stories" they have agreed with the help of intelligent software tools.

HumanEdj is the reference implementation of a HIMS (and it's free). If you want a glimpse of the future, check out the walkthrough at http://humanedj.com/faq#Tutorials

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

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)