Ceterum censeo…

Consider this problem: Why are some processes are deeply unpopular?

For the sake of argument, I’m going to make some assumptions about the process under discussion:

• The process has a credible justification.
• The process is clearly defined.
• The process is not unreasonable.

If a process fails these assumptions, then there’s probably no great mystery about why it’s unpopular.

Objection 1: Why should I do this?

While I’ll assume that a process has a credible justification, and therefore has some benefits, that benefit may not always be clear. Which is to say: the workers who comply with the process may not see any positive results from complying with the process.

Benefits might be unclear because:

• The benefits are received by other people.
• The benefits have a long payback period.
• The benefits only occur in rare cases.
• The benefits only have an opportunity cost.
• The benefits are trivial at an individual level, but are significant at an organizational level.
• The worker is personally predisposed to not perceiving the benefit.
• The worker has no good will to those who benefit

Objection 2: This is too much to do.

While I’m happy to assume that a process is not unreasonable, that doesn’t mean it’s not difficult. The difficulties associated with complying with a process are the costs of the process. In particular, since I’m thinking about individual perceptions, I’m also thinking about costs to the workers.

A process might be considered costly because:

• The process is a poorly designed process.
• The process is inconvenient to follow (e.g. poorly supported by tools).
• The process assumes certain skills or experience.
• The process requires a certain temperament, and is deeply frustrating without that temperament.
• The process presents a significant opportunity cost, either preventing other activities, or by causing process lock-in.

What counts as a ‘high cost’ is clearly a subjective consideration. For now, I’ll leave it as a qualitative consideration. However, I see no reason why a process shouldn’t be subjected to a rigorous cost-benefit analysis, and be required to achieve a suitable ROI.

Acceptance matrix

Now, if an idea gets divided into two dimensions, each with two elements, it’s inevitable that the space will get mapped into a matrix. It’s just one of those things.

Let’s consider the quadrants:

• The first quadrant shows Obvious processes. These are easy to do and have a clear purpose. This is the target state.
• The second quadrant shows Indifferent processes. I suppose this is acceptable, and the matter could rest here. Activities that have no benefit might lurk here, though, so examination is worthwhile.
• The third quadrant shows Adverse processes. The people would be willing, but the system is thwarting their goodwill.
• The fourth quadrant shows Troubled processes (or more likely non-compliance). People generally don’t like spending significant effort without returns.

Strategies

Here are some general strategies for moving between quadrants.

1. Clarifying the benefits will move a process to the left. By assumption, there is in fact sufficient organizational benefit to the process to justify the process. Moving to the first state is therefore a matter of communication. Some approaches are:
   • A clear explanation might do the trick.
   • Ongoing visualization or quantification of the benefits would help.
   • Spend some personal capital and convince people the benefit exists, without actually explaining what it is.
   • Bargaining for additional benefits (especially for dealing with the more political objections).
2. Reducing the costs will move a process upwards. This means identifying what cause costs, and managing those. Some ideas:
   • Process redesign can eliminate unnecessary or expensive steps.
   • Clarify ambiguous steps to make the process easier to follow.
   • Train, educate or hire so that the workers have a more fitting frame of mind
   • Use tools to reduce the costs - either simple tools like tokens on a board, or complex tools that automate the process.
   • Look for opportunity costs caused by organizational factors like timelines or budgets.
3. Compulsion is an ongoing option, although it’s hard to like it. At best, this will have no effect (especially for Indifferent processes). At worst, this will move the process to the Troubled quadrant, burning goodwill and increasing costs (enforcement time).
4. Change the perception of the process. This would be highly dependant on circumstance, but has potential to completely relocate the process perception.
   • Giving new and desirable responsibilities might mean the benefits accrue to the worker, and make the process benign, even necessary.

I actually find the last idea of reworking an individual’s roles to be the most intriguing. Difficult to pull off, but wins all around if it works.

Meta-critiques

Here are some meta-considerations about this theory.

Firstly, maybe this isn’t the problem that I think - I might be projecting, I might have a poor sample size, or maybe I’m just completely off-base. Certainly at times I’ve been resentful of incoming processes, so I’m mindful of not being a perfect observer.

Secondly, my conclusions are pretty much a priori. There’s no chance in the near future of actually testing these ideas, so I guess it will remain a priori.

Finally, this could fall into the camp of the bloody obvious. I’m really not sure.

For reasons that escape me, December has been Karaoke month at work. (I’ll hazard a guess that the reasons have to do with this “fun” thing I keep hearing about.)

Every day this month, three acts get up during lunch time and sing to the diners. It’s all in Thai, of course, and I’m not familiar at all with the original versions, but I’d say the acts ranged from passable to good.

For added fun, the singers are ranked at the end of each session.

Some particularly popular acts received small cash tips from the audiences. Groups would chip in a little here and there, and send someone up for payments. I’m unable to say whether this was driven by personal popularity, performance quality, or aspirational attractions.

UPDATE 30/12:
I found out some more about the awards. The winning singer each day gets 400 baht, and is invited to compete again the next day.

I’ve two further points to add to my estimation post.

First, most estimation methods I’ve seen in Australia are bottom up estimates, produced by a group producing individual effort estimates. In contrast, a function count estimate is a top down approach, produced by a single person familiar with the scope and the process creates the estimate, with little collaboration.

This allows the attractive characteristics of function point estimates. A single person is faster, cheaper, and more readily available than a group. That means a better estimation experience.*

(There’s another way of producing quick and cheap estimates. Find a relevant guru, and ask them. Such a person could probably give a pretty strong estimate quickly. More power to you if you have such a person, and can spare them to produce estimates.)

This brings me to my second point. The popularity of the group estimation is a reaction to a pattern of unreasonable estimations. Group estimation is seen as a method of getting better estimates, and to get the team to stick by a poor estimate (a.k.a. buy-in - does this really work past (say) 2 weeks?).

The thing is: those poor estimates probably weren’t a result of function point counting. They were more likely a result of not using any estimation method. Therefore, both function point and group-based methods are viable alternatives. In which case, I’d value the speed of an established function point count more than the buy-in factor of a group estimate. Not that the two approaches are necessarily oppose each other.

Building the evidence to establish a function point count method remains a significant task. Group estimation has a significantly lower cost of entry, which may explain its popularity. It may also explain some selection bias in my own experiences… I’ve never really worked in a place with sufficient focus on process to produce the required data.

*I’m assuming that both methods are equally accurate, although that’s a subject that could bear some empirical investigation.

I’ve been involved with some estimations recently. The method in use here is a formal function point count, which has been codified into a spreadsheet. It’s the first time I’ve seen a function point estimation method in use. I’m sufficiently impressed by it that I think it’s worth sharing. So here’s a rather lengthy description.

Overview

Thanks to it’s spreadsheet nature, the estimation process is clear, largely automated, quick to implement, and reasonably accurate. Someone familiar with both the application and the estimation process (i.e. a BA or senior developer) can put together a reliable estimate within a few hours (at least, an estimate as reliable as the requirements).

The estimation method is a four stage process:

1. Design review
2. Effort calculation
3. Allocation calculation
4. Quote (mostly used by vendors)

The estimations are done multiple times throughout the course of the project, each time with tighter requirements creating a tighter estimate. Each estimate is contained within a single workbook, which allows for straight forward version file-based control of estimations.

Design review

Using whatever requirements are available, the estimator reviews each function in scope, and records the required design elements in a design review matrix.

Each function is classified as a Screen, Batch or a Report. The estimator considers a number of standard design elements, and whether the solution would require that particular element. There are about 30 design elements, which cover all the things a system might need to do (e.g. retrieve data from table,validate user input, display a report, read a CSV, and so on). It’s all in a neat matrix, so it’s harder to overlook some aspect. The estimator notes these decisions as design comments.

The design comments are specific but brief. For example, tables are named, but no further description given. This is because the comments are stylized so that a) they are easy to produce, and b) they are well formatted for the estimation calculation. Here’s a small subsection of a matrix as an example:

Function	Retrieve data from table	Write data to table
1.1.1	TBL_CUST_ORDER_HEADER	TBL_CUST_ORDER_HEADER
1.1.2	TBL_CUST_ORDER_HEADER, TBL_CUST_ORDER_DETAIL	TBL_CUST_ORDER_DETAIL

The end result is a listing of development work required to implement a function.

Effort calculation

The spreadsheet takes data entered in the design review matrix and calculates a total effort value.

The effort calculation sums the design for each function and work type, and then performs a calculation to determine a function point total. In addition to the function points, there is also the ability to add in a flat rate effort for any particular task (e.g. a one day task to set up a version control server), if required. The effort calculation is set up to include unit and system testing effort as well as development.

The estimator can control the calculation as follows:

• Functions are either a screen, a batch process, or a report.
• Functions may be; New, Modifications, Regression test only, or Excluded.
• Functions may be marked in or out of scope of the estimate

The effort calculation can be configured as follows:

• each design element may produce more or less function points (e.g. validating one user input is a different amount of work to creating a PDF).
• different platforms (e.g. SAP, JSP) may have different productivity rates (by Screen, Batch or Report).

The end result is an estimate of total development effort, going from detailed requirements through to system testing.

Allocation calculation

The spreadsheet takes the total effort calculation, and allocates that effort across different resource types and different project phases.

The effort calculation estimates effort from detailed requirements through to system test. In addition to this effort, there are other effort estimations to be recorded:

• Effort for developing user requirements.
• Effort for support during user test.
• Effort for PM support (added as a percentage of total effort).

These effort estimates would typically be decided at a project level, with a mandate that a given amount of time would be spent in these activities, and effort follows from that.

There are also a series of calculations using standard resource rates to produce a total cost.

Quote

The total cost is mapped into a printable invoice, along with some extras like a payment schedule and terms and conditions. Obviously, this is more important for the vendors using the form than for in-house development.

Analysis

Estimation methods can be assessed as follows:

• how accurate is the estimate?
• how consistent is the estimate across projects?
• does the process allow people to get better?
• how long it takes to produce an estimate?

Accuracy

The biggest concern in an estimation process is accuracy. This process is as accurate as the requirements. The process is used in different stages over the course of a project:

• Mid term plan estimation (i.e over the next 4 years) are, of course, wildly inaccurate. These estimates are based as much on experience with similar projects as the specific project being estimated.
• Initial estimation (i.e. while the project is still being scoped) is still pretty inaccurate. These are based a combination of conversations about the project and stated assumptions. There’s still plenty of scope for scope change.
• Estimation based on user requirement are mostly accurate, but there may still be some design issues that cause variations.
• Detailed requirements are claimed as 100% accurate. This may be a little self fulfilling… the vendors have trouble charging more than they estimate.

Of course, a detailed CR process is needed to explicitly track the changes, and to avoid confusing the actual results. This estimation method scales to estimating CR as well as a full project

Consistency

The estimation process takes experience to use effectively. Work area names are somewhat cryptic at first glance. I’m willing to bet there’s a clear documented definition of each area which is familiar to the estimators, because of course there is. Also, there’s a particular style of development favored here, and experience with that style is also needed.

The good thing is that if estimation requires this sort of experience, it will end up getting consistent outputs. Which in turn means that it doesn’t matter too much who does the actual estimation.

Another side effect is that (possibly) it would allow comparison of project complexity between platforms, which in turn would allow an quantitative comparison of the productivity of those platforms.

Learning

I really like that the basis of the estimation is explicitly recorded as part of the estimate. It means that an estimate can be reviewed after the fact, and the cause of variances determined. If there’s a suitable environment, this can lead to people learning from mistakes, and getting better at estimation.

Compare this to other estimation methods, which tend to come down to ‘that looks like about 3 days/weeks/months’. ‘Oh, it turned out to 4 days/weeks/months? Oh well. I’ll try to remember next time.’ there’s no where else to go.

(Note: variations that have nothing to do with the estimator are always possible.)

Estimation time

I’ve seem estimates for 5 month effort made within a couple of hours. This is much better than I’ve ever seen before using group estimation. Also, the estimates are made by one person, rather than a group of 4 or 5, which is a further reduction of effort.

Also, I’ve seen this method used to give weekly feedback on how requirements from the previous week have changed the overall development effort, feature by feature. The users were then able to reflect and change scope, on the basis of clear information. That’s a powerful tool for scope control.

Other comments

It’s worth noting that this estimation process is really designed to support outsourced development. The process uses a mutually understood method to create an acceptable price. Any dissatisfaction with the method would require either quantifiable evidence or a change to daily rates.

I’d like to see whether the Screen/Batch/Report triumvirate is sufficient. In particular, I wonder if there should a category for “Service” (direct interactions between systems). This isn’t a common style here, but is more common in Australia. Here, a service would probably be considered a batch… analysis of actuals would tell if this was sufficient.

There’s no effort being made to create buy-in of the estimation among the development team. Instead, it relies on a well established and accepted process. Both methods are better than the alternative, which is a arbitrary target date created without reference to the actual work.

Finally, there are a number of points in the process where work is multiplied by a particular factor. These factors are based on the particular productivity in the area of estimation. Determining the appropriate values needs an investigation of actuals from a variety of projects. Of course, collecting actuals is a saga in itself…

(This is probably more ‘distracts Michael’ rather than ‘actually interesting’, but I’m going to share anyway. Tough.)

I quite like this banner. It has been set up in the project room long ago (but presumably less than 80 weeks ago). It’s highly visible, and (from a distance) looks quite solid.

Closer up, though, you can see that it was put together after spending 20 minutes in an arts and craft store. It’s some sort of laminated cardboard, with some high contrast paper (or maybe paint) on one side, elastic bands threaded through the weave, and judicious use of sticky tape when all else failed.

Sadly, those aren’t the most durable materials…

Fix one was to balance it in place, which worked for a few weeks. Fix two was more sticky tape.

(I’d have used toothpicks on the back to hold the elastic in place, rather than weaving them all together, but no one asked.)