We were going through a small project that we’d just completed for the purposes of getting sign-off. We had built in the functionality they wanted, using the designs that they’d agreed to, so it was plain sailing.

And then the spanner.

Part of the project is a news article page with a sidebar listing other news articles. The client decided that he wanted to be able to filter these. “Could we add a couple of dropdowns listing the article categories?”.

That was the point when my anticipated reality and real reality diverged:
- anticipated reality: AM says “Sure, we’ll have a think about the best way to implement filtering, and present a couple of options back to you”.
- real reality: PM says “Right, we’re going to add a couple of dropdowns below the list, one for ‘projects’ and one for ‘countries’ and they’ll alter the article list you see”.

After the phone call, the PM asked me to go ahead with it. Eh? Shouldn’t we get a designer on the job – someone who knows about usability and interface design, perhaps?

I thought I’d won that little spat when the PM sloped off, but she got a tester who wants to be a designer to photoshop exactly what the AM had suggested on the phone. Bang went any hope of getting an expert in human computer interaction on the job.

The Account Manager’s defense is that we’re doing what the client wants. Well, I counter, that’s not good enough – despite my previous post saying that we “pretend the client knows what they want”, we shouldn’t allow them to define the solution. Yes, sure that’s what the client thinks they want, but we are being paid to know better.

I may know what I want to eat when I go to a restaurant, but I still like to hear what the specials are, just in case there’s something even more exciting. I may even know how to cook the dish, but that doesn’t mean they’re going to allow me to roll my sleeves up and get to work in the kitchen. I am paying for the chef’s expertise, and for the satisfaction of delegating a whole bunch of thinking and labour so that I can enjoy the fruits.

Yes, the client should be right in there defining the problem. Then we should check it and redefine it, and again and again, until we’re absolutely clear about it. Then we should get an expert  (maybe a few, even, bringing different viewpoints together) to draw up a solution or two, and present those back to the client. “But it’s just a simple change” the AM cries, except that it isn’t, because it hasn’t been fully defined.

The wannabe-designer did a great mock-up, but couldn’t tell me how the functionality should work – there were different colours of text indicating selected states, but she didn’t know how that would work between the two dropdowns. In short, the solution wasn’t a solution. Meanwhile, the developers aren’t clear what they should be building, the project manager’s frustrated because she thinks that the project is now in development (well, she got us the designs, didn’t she?), and the account manager’s having to deal with an increasingly impatient client who thought the solution was defined over the phone.

If the client’s paying good money for our services, we should provide those services. That’s the clearest thing, isn’t it? We are digital experts: strategy, user experience, design, technical development. The client is an expert in marketing and sourcing quality work (I hope). One side should be bringing a problem, the other a set of solutions. Now, which is which?

If you haven’t read It’s not rocket science yet, please do first, as this article is a continuation of that theme.

I’ve said that key to a successful project is not just having everyone involved do their best, but having them work out what is the best thing to do, and then do their best at that. Anything else is at best a waste of effort, and at worst will doom a project.

I’ve also said that a sucessful project, just as any other system, needs a systemic view, rather than a bunch of local team views (new business, project management, creatives, developers, etc.).

So, how on earth do we go about finding out what’s best from a systemic perspective? A good place to start may be looking at some of the gripes that sit uncomfortably between teams involved in a project.

For example:

Project Manager (PM): developers’ estimates are always wrong.
Developer: PMs treat our estimates as promises, and thus can’t handle it when they turn out to be inaccurate.

Let’s think about lines on a graph: x axis denotes time; y axis denotes understanding. At the very start of the project, my understanding of what’s involved is minimal. At the end of the project, I know all there is to know about it (ah, the beauty of hindsight!). Between those two points, the line rises in a sloping curve, with most altitude gained in the first half of the project.

Where does estimation take place? Early on in the project, where understanding is incomplete (often requirements are incomplete too).

And that’s only the first problem. Here’s a second: when we estimate towards the start of a project for the length of a project, we’re looking far ahead into the future. The further we peer, the poorer our seeing, and the harder it is to a provide realistic estimate.

Estimating a project from the start requires long-distance lenses, so we may pad with a buffer because that protects us slightly. But, as the project progresses, problems arise, change requests come through, and the specification that we’ve been working from changes (or it doesn’t, even though the functionality does, but that’s another problem). This is how reality departs from our estimates. Towards the end of the project, we’re dealing with bugs that we couldn’t foresee and test results have come in, which frequently mean lots of change requests now that the client’s seen the proposed release version.

Two problems: estimating when our knowledge about the project is less than complete; changes arising that throw the project off schedule. Now what could solve them?

We want our estimates to be more accurate, so they can be considered commitments; and we want to be able to handle changes and problems that arise.

Imagine that, as a developer, you were asked each morning how long it would take to perform the single task you were about to tackle. Your response would be in hours, and probably more or less accurate. Imagine now, that you were given the whole list of tasks up front and asked to estimate on them – the answer would be in days, and a lot less accurate.

Firstly, say it takes 10 hours to complete a task, and you’re 10% out: it takes 11 hours. We’ve lost an hour. Say it takes 10 days, with the same margin of error, and it’s taken 11 days. Say it takes 100 days, and it’s taken 110 days. Thus the same margin of error, when affecting differing timescales, has very different ramifications. And just in case you think I’m being unfair by swapping from hours to days: if you think something will take one hour and I think it’ll take two, we have room for a discussion – the difference is clear; if you think something will take 30 hours and I think it’ll take 31, it’s a lot harder to explain the difference and decide which is a better estimate.

If we can make our estimates more often and more short-sighted, rather than a single one tackling the whole project, we stand a much better chance of getting the estimates right, we can adjust them based on recent learnings, and we can incorporate changes/problems as they arise.

That may resolve the conflict of PMs wanting commitments and developers not having concrete specs to work from (with no changes, ever ever). Whaddya think?

We now know how some of the mismeasure, frustration, and sometimes despair arises as we try to manage that relatively recent invention; the serial process – the manufacturing process. We recognize, often intuitively, that we are trying to optimize according to some reductionist/local optima approach but that we are actually bound by the process dependency and variation of our system. But what does it mean to optimize? Surely this means to do our very best. In fact, for everyone to do their very best. (From Dr K. J. Youngman’s website.)

In software development, we have a virtual shopfloor – a cyber pipeline – through which all work flows. If we all “do our best”, the pipe soon gets blocked with incoming work (if the account management/new business teams are any good) and the production teams don’t have the room they need to give each project the time it deserves; the creative team never fully hands off designs to the developers, as they always have one final tweak to make (after all, as they see their ideas realised, so they gain more ideas about them).

Organising the pipeline
Given that a chain is only as strong as its weakest link – that a group of boy scouts can only walk in single-file as fast as its slowest scout – any production process can only move as quickly as its slowest part.

If the new business team is fantastic, and concentrate on doing their job to the best of their ability, but define “best” purely in terms local to them (i.e. “I’m doing my best when I bring in most new business”), they will soon swamp the next team in the pipeline. If creatives never fully hand off their work, the next team can never really get started on it.

A brief detour to look at production problems
I’ve recently witnessed a massive project screw up, based on obstacles arising that surely were avoidable. A quick list of the major problems:

• Lack of clarity over what was to be delivered from the outset
• Changing requirements throughout the project
• Deadlines imposed from above
• Frequent personnel changes
• Deceit between different parts of the team over progress
• Command/control behaviour

Wow, where did all those problems come from?

Well – first among equals – the role of the new business and account management teams in bringing new projects into the company is where the rot starts (there are plenty of other places too, but this is the most common, possibly only because it’s first in the line). Their job was to bring this new client on board, and make them so happy with us that they would line up lots of projects as quickly as possible. And they did this job extremely well.

The team did their best, within the limited perspective of their role. But if we judge their work from the point of view of the production system as a whole, we see a markedly different story. One in which their contribution to the project’s failure is clear. Their priority was to ensure that the project delivered was exactly what the client wanted, so they changed requirements and delivery dates throughout the schedule. Nothing signed off was sacrosanct, and work had to be re-done on a regular basis, without changing delivery deadlines.

Although I know this sounds like finger-pointing, it’s not, I promise. I can do this same exercise with every team that played a part in the project, and each and every time doing “their best” will end up contributing to failure.

To prove that point: the development team also did their best, by demanding water-tight specifications. When they finally got them, the deadline was so tight that they worked extremely long hours (like 16 hour days for more than 7 weeks); they coded until they could no longer speak. They were demons!

But they failed to deliver. They blamed uncontrolled change and lack of specs, and late sign-off of designs. They tried to cover up basic mistakes in the bespoke framework (like writing a bespoke framework – anyone heard of PureMVC?), and didn’t test their code as they went.

And again: the project manager tried his best, within the definition of doing his job according to those who employed him. However, nothing was delivered on time; less than a quarter of the project was actually delivered; it was buggy and immensely expensive. It had failed on time, cost, and quality counts. And yet, I’m sure he would say that he did his best.

So, what’s going on?
Consider how we work: we are social animals that collaborate for a common good. Our social network, however, is fluid in terms of strong and weak links and thus we have many strategies for dealing with changes within the network – we can help each other, we can withhold support from each other, we can circumvent weaker members, we can break links and make new ones. Thus, although there is huge dependency in a social network, it is loosely-coupled and dynamic – everyone cooperates, with a few subordinating themselves to others at any one time*.

* by “subordinate”, I mean work to the betterment of others rather than oneself, put others’ needs and desires above one’s own.

Another form of experience also exists, though – our personal experience as individuals: here, we don’t need to subordinate or coordinate; we are free to improve and work to the best of our ability independently of those around us**.

** putting our own needs/desires first, I’ll be calling “maximising” later, and in regard to process, I mean promoting that particular piece of the process.

Now, the industrial mode: well, you might think that it’s a network, especially as workplaces have personal networks, but actually it’s far more linear: there are few if any alternative routes through the process (get new business -> specify the work to be done -> design -> architect -> implement -> test -> deploy -> review, for my industry). There is far greater dependency between the parts of the process – we can’t just ignore or cut out design because the designer’s on holiday. Finally, there is always one part of the process that is weaker or slower than the others. Improving the workflow of the other parts won’t speed up the total throughput because of that bottleneck.

In an industrialised line the only place that maximising adds value is in the bottleneck, and everything else has to subordinate to that bottleneck, which experience is almost the exact opposite of the social and individual experience, where the bottleneck can be avoided. Does that spell doom for our chances of success? Thankfully not, but we do need to change the way we work.

There is much within an organisation that contributes to a silo effect: there’s me, my team, my division, managers, department managers, division managers – all of which put an individual or group focus on working practices. But this can mask the strong serial dependency of the process pipeline. We need to view the system as a system, not as a set of silo’d groups. However, many of our measurements revolve around localised views of parts of the system, including our individual definitions of “doing our best” .

If each team involved in a project does its best, the project still runs the risk of failing (sometimes monumentally), so what should we do? Find out what is the best thing to do, and then do that to the best of our ability.

More anon.