The Fuzzy Front End, and Why It Kills Projects

Katie Lauren Lucas

Introduction

The fuzzy front end of a project is the often large period of time between the project "starting" and the project actually starting. In large companies this can take up easily half of a project's lifetime.

Staff Issues

Staff shortages contribute to the fuzzy front end in the following ways:

Hiring contractors for working on projects takes an ill defined amount of time. Often people are not "allowed" to conduct interviews before projects are given the go-ahead, meaning they can only start looking at the point at which the project is supposed to have started and the clock is running. If the right people are not available, the project must now wait. In a way this reflects a problem caused by a solution to a problem - departments are forbidden from hiring contractors until the very last minute because, due to other aspects of the fuzzy front-end, the actual start date of a project simply isn't known, which leads to a reinforcement circle.

Worse is the situation where a number of contractors with complementary skills are required: in the time it takes to interview the remainder of the team, the first possible hire may well be unavailable..

Some companies solve this situation by simply engaging in on-going interviewing, so that the minute someone OKs a project they have a list of people to hire who they've interviewed recently.. this is somewhat unpopular. It's like entertaining yourself by test-driving sports cars on the weekends, so that should you win the lottery you know which one to buy without needing to hesitate. Like car dealers, contract staff and agencies talk to each other and a bad reputation for this doesn't make for good hiring prospects when demand is high.

Permanent staff too will inevitably arrive late for the project, because their last project will have a "fuzzy back end" - the trail off as customers call up repeatedly for one last set of changes, acceptance dates come and go and customers admit that they haven't bought the machines to run the system on and hence can't accept it because they haven't tried it... or in fact that the project overran.

A result of this is that hiding project overruns in the budget of the "next thing" is rampant in the IT industry. It stems from a failure to account for employee's time in any meaningful sense. While most companies /gather/ information on which projects an employee works on, usually by having them complete time-sheets, most of them cook this data in one or more ways - by insisting that projects do not overrun and forcing employees to hide extra hours by misclaiming them, or by recalculating the hourly costs of employee's time so that the project runs "over-time" in the number of hours, but not actually "over-budget" (this option only really works where the people paying employee time are decoupled from the people accounting for the costs of the project), or the company simply collects broken information: forbidding employees from recording the time spent filling in time-sheets or queueing to use equipment which is in limited supply or arguing with accounting over trivial paperwork nit-picks. The usual way to do this is to insist that all time is billed to a valid job-code, but limit job-codes to only external work. This has the side effect of reducing the companies internal costs - the costs of doing business - to zero. Unsurprisingly, it seems rather favoured by accountancy practices where the common sense reasoning that you cannot have a zero-cost of doing business, because doing business doesn't require zero activity also doesn't apply.

A perfect example of this is to fire the entire reception staff and feed phone calls directly to the engineers. Since they are forbidden from recording anything but valid job-codes for their time, the cost of a morning spent answering the phone to misdialled incoming fax calls, for example, is hidden from view within a contract's costs. The opportunity costs of losing potential customers who are now talking to probably irritated engineers who have no idea who to transfer them to is also invisible. There is, however, a "saving" from not having to pay for reception staff. The author has actually worked at a company which employed this logic...

The final option is the one picked by most companies: They gather the data but do nothing meaningful with it. The time-sheets are piled up somewhere, or they are actually entered into a database and the resulting totals ignored or, best of all, the totals are looked at, compared to the project costs and someone sighs at the overruns. It is a rare company that wonders why all it's projects overrun. Usually the people asked are the engineers, or their managers, and not the sales department..

The underlying issue with tracking usage like this is the discontinuity that occurs between sales and production. Ford makes very sure that each and every car makes money. They can do this because they know how much metal goes into each car, and how much that costs. They know how many they can make a day, so they know how much each car represents of the plant's daily operating costs. The only unknown is how many cars they will sell in total and how fast they will sell them. The latter can be predicted from which car is being replaced by a new model, and the former by experience about how the life-cycle will change. In any case, this is important only because the car also represents a portion of the design cost of the model, which also needs recouping. Car companies solve this problem by over-estimating it. The model will pay for its design far before it runs out of sales life. (In fact, it's design will usually have been paid for by the end of the sales life of the model it is replacing. It needs, in effect, to pay for the design of its successor.) For the rest of the sales life after that, the model is a "cash cow".

Software, however, is effectively designed after deciding how much it will cost. Worse, its cost is often decided by sales people whose motivation is to close the sale. The author has heard salespeople telling a customer "well, if six days is too much for you to pay for, I'm sure they can do the job in four.." in order to get the customer to say yes.

The net result of this is that the software industry is peculiar in that it firstly allows its sales departments to sell things for less than it costs production to make them, and secondly it continues, year after year, to fail to notice this is the case and to make sales accountable. The lack of coupling at this point means companies cannot make judgements about their software. If sales are repeatedly selling contracts at only 75% of their break-even, they need to put prices up. If this makes the company uncompetitive, the company needs to ask why that is the case. Changing the way they account for the hours spent is sweeping the problem under the carpet, not solving it.

In addition, there is a failure to learn that projects are taking longer than people think. Simply insisting that the projects take six weeks when every previous equivalent project has taken twelve is not useful. (The author has worked for a company that did this as well...) If projects take longer than someone thinks they should they have to consider that either there's a reason why, or that they actually do take that much longer. Insistence to the contrary and book-cooking will not solve this problem.

Management Issues

The largest contribution to fuzzy-front ending, however clearly seems to be over-management and unclearly defined management. It is not unreasonable for companies to require budgets of over a certain threshold to need board-level discussion. It is not unusual for this level to still be set at the same level as when the company was small, and buying a new PC was a major financial burden. Committees or "steering groups" often take this role on in large companies. While there often appear to be "rules" about which committees need to debate proposals, these rules are rarely written down, and even less often can be found to be written down by someone other than the committee themselves.

Groups of people debating things adds hugely to the fuzzy front end for a number of reasons:

Holidays. The average employee gets 4 weeks holiday in a typical 50 week working year (Christmas and New Year account for a two week gap in most proceedings). This means that there is almost a 1 in 12 chance that any given committee meeting will be missing someone - a 11/12 chance that person will be present. It takes only an 8 person committee for the chances of everyone being there to drop below half, assuming holidays are evenly distributed. Of course, holidays are not evenly distributed. Bad times for getting committees to approve things are the summer (when many people will be way at the same time), Christmas (when committee business needs to be cut short so people can organise parties) and at the end of the holiday year (when people need to use up holidays or lose them).

Approvals. Even those that do not require group discussion, seem to require an inordinate amount of "approval". A large list of people need to be sent the proposal, the requirements, the amended requirements, the spec, the amended spec, the budget, the amended budget.. and each of those people represents a bottleneck. It's not unusual for specifications to be distributed to more non-technical staff than technical staff, who then need things clarifying and have their own political agendas to enforce on the proceedings. (The author worked on a project where the non-technical "reviewers" kept coming up with new XML tag names that they felt were more appropriate given the politics of the project. Every version of the XML file specification had alterations to field and attribute names.)

Signatures. Documents come with the company "standard" header on them. This means they need sign-offs and confirmations and approvals from various roles. The roles themselves may not be assigned or the people filling them unclear. Filling the roles can take a significant amount of time. In addition, documents discussing spending money (in the sense of actually having to write a cheque, rather then spending money by wasting time...) need signing by more people. Often the documents are simply left in their in-tray and get delivered back signed some time later. Often quite later. Businesses could do a lot to streamline their processes by asking whether this is necessary. In a Victorian world, purchase orders required approval to ensure company costs were controlled. In the modern era, the purchasing decision is complex. The signer is often a director, often some levels divorced from the purchasing decision. In this circumstance, one should really wonder if they are qualified (in the context) to make the decision on whether the purchase should happen or not. If they are not, then the decision is random - and one's business practices really should not be random. If the signature just happens, automatically one should wonder why so much "rubber stamping" is going on...