The first phase deals with how the system under consideration will fit into the wider business environment. This phase focuses on things like:

• high level functional requirements
• business flows
• common usage scenarios
• confirm the business case
• identification of major constraints and risks

The second phase deals with the nuts and bolts of what the system has to do to achieve its purpose. This phase focuses on things like:

• detailed functional requirements
• non-functional requirements
• data dictionary
• screen layouts

To put it another way: The first phase focuses on why the project should be done, while the second phase focuses on explicitly stating what has to be done.

I like the division for these reasons:

1. It promotes a clear division between requirement and solution.
2. It causes a specific discussion about scope, at a time where scope decisions are still being made.
3. It separates documents of interest to stakeholders outside the project team (i.e. how the system will interact with the rest of the world) from documents of interest to the project team (i.e. the implementation requirements).

Sidenote:
I’ve listed two levels of functional requirements, so that probably needs some clarification. “High level” functional requirements means things like ‘Submit Customer Order’ or ‘Produce Compliance Report’, with a (very) quick sketch of what that means. This could be done with a lightweight use case, or a flow chart, a text paragraph, or sample output. On the other hand, “Detailed” functional requirement are specific about fields, validations, calculations, and the like.

Caveat:
This takes place within a strongly waterfall software development process, which simply has to be accepted as a constraint of the wider organisation. Applicability to iterative processes is left as an exercise to the careless bystander.

Dead or Alive, you’re coming with me.

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.

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.

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.

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:

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…

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.)

In addition to the government effort to protect the city, many of the individual buildings are working to protect their own weak spots. Most of the larger commercial enterprises around the city have been setting up their own sandbags. Some look effective, some… less so.

As part of a general preparation knowledge, I got sent instructions of how to build effective sandbag dikes: “Since a dike will fail if not built correctly, training people on proper procedures for placing sandbags is very important. In the rush, volunteers will do something, but the result frequently is a dike that performs poorly or fails.” A dike is a piece of engineering, with some serious failure points… you can’t expect a win from simply piling bags at the front door.

When I arrived at work last week, I found that the sandbags had been deployed around the warehouse, ready for trouble.

All entrances are guarded with sandbags, which means we have to climb over the entrances.

The server room got some extra protection, which is reasonable, but I do wonder whether the interior walls would be effectively waterproof.

Everyone at work has been busily planning how to respond. Various assessments, plans, responses and actions have been put in place. The preparation is well needed… there are bodies of water all around the work centers. I’ve never been sure exactly where this water comes from. It’s clearly artificial, but I haven’t seen any crops being set up. But it must be fed from somewhere, and that means the water get out of control.

Attendance at work has been down somewhat. Everyone was told to stay home if needed, without having to worry about leave issues.

So far, though, I’ve personally seen very little actual flooding. The biggest disruption has been a roadside diner that got washed out. (Actual damage is not clear… do these places have electricity or plumbing?)

There are others who aren’t in the city, who are quite understandably upset that the floods are being sent through their slice of home. So, the floods are causing real damage, but not in our circle of awareness.

I get an hour commute to and from work. It starts out fairly industrial…

… becomes less urban…

…and even downright rural…

…until work comes into view.

On the way home I get less scenery…

…and more lights.

There’s two work sites which I regularly attend.

The first is the parts warehouse. It’s handy that the project is based here, because we’re installing a parts warehouse management system. Plus the customers are here, so it all works out nicely.I spend most of my time here.

I’ve a cubicle of my own…

…with a view of the depot (sort of - can’t see the shop floor when I’m sitting).

There’s also the option of the project room. It’s crowded and cramped.

The thing is, the project room is were everything happens. It’s full of charts, and vendors, and people in charge… the buzz is here.

(EDIT: It seems I need to point out this photo was taken during morning stand up. It’s not like this all day.)

By comparison, the cubicle is a cone of silence. Since I’m not actually involved in that particular buzz, I opt for the cone of silence. But if the buzz is still here when I need to get things happening, I’ll set up in here.

The second location is the corporate head quarters. IS management is run from here, as well as the rest of the organisation (except manufacturing). Whenever there’s a high level meeting, or some sort of presentation, or a need to talk to someone other than the immediate project team, I make the trip across to here. which turns out to be about This comes out to two or three times a week, at intervals I’m not good at predicting.

I have another desk here, in an open space that feels far too big. It’s pretty peaceful, though.

Working out where I should be is an ongoing puzzle. Mostly it involves working out whether or not I’ve been told about meetings. There’s nothing like finding out you should be 30 km away and no one told you to get the paranoia flowing.

Apparently, though, four years just isn’t long enough. So I’ve come to Thailand to help with the installation here, and in related countries… first India, and then half a dozen others. After all, the system is intended as a global system, and there’s a list of about 30 different countries that will eventually install and receive the system. For the next two years, it’s my jobs to work out how to make these future deployments work.

I’ve been briefly introduced to the Thailand project already, and it’s clear they face many similar problems to Australia. There’s unique problems as well, because of course every case is a special case. But the problems of organisation, of planning, of management and oversight are common. Plus, it’s the same system, so many technical problems are repeated as well. A rich, well documented framework for deployment offers definite benefits; checklists for required tasks, shared context between organisations, reporting frameworks, guidance on past approaches, and even some degree of reuse.

Now, when you’re deep in the creation of a project, there’s no time to think about what’s helpful for other projects. (Hmm… this feels similar to the Tragedy of the Commons, but that’s not quite right - it’s not taken from a common resource, but failing to contribute to building a new resource.) Anyway, the company has recognized this, and I’ve been brought over specifically to create the needed framework.

That’s the business case. I started last week with a couple of days orientation. This week is my first day on the job. A couple of months to learn the local ropes, and not get in the way to much, and then I start… well, writing I suppose. I’ll have to see. I’m sure it will work out for the best.

More to my immediate interests, though, it’s the chance for another overseas posting. New places, new people, new experiences and view. It’s daunting, but the experience of an overseas posting is hugely rewarding. If you ever have the opportunity for one, then I highly recommend taking it.