Ceterum censeo…

The software process here has a distinction that I quite like. Instead of a single requirements phase, there are two separate requirement phases, each covering different types of requirements.

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.

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.