Was that Tactegic or Stractical?

You’ve been assigned to a project. The requirements are well understood and they make sense. The team is capable and the project manager reasonable. The one thing you don’t have, because we never do, is time. This is a project with a David Beckham date.

The David Beckham date is a term I use for an immoveable launch target. I once worked on a project where David Beckham had been booked to do the release publicity. That pretty much fixes when you need to be done. Firstly, he isn’t going to be able re-arrange international football fixtures to accommodate a project slippage and second he’s not likely to be happy promoting something that doesn’t work properly. PR is a two-way thing.

You can call it something else, but we all know that projects have David Beckham dates more often than not. In fact I’m struggling to recollect any time when the business authorised an initiative with a hearty slap on the back and an agreement for IT to toddle off and enjoy itself without some constraints on time.

Faced with some fixed expectations of when you will be done, it’s common for there to be disagreements about the most appropriate solution. Typically the two warring sides are the architects who want something strategic (a solution backed up with words about standards, total cost of ownership, alignment, ease of change, etc) and the developers who want something tactical (a solution backed up with words about reality, previous experience, ability to deliver, skills available, etc).

I left off last time with a promise to talk about sizing projects. Unfortunately (and I can’t help noticing the bitter irony in this) writing up my notes on sizing projects is taking longer than I expected. There are some good reasons for this which will, I hope, become clear once I’ve published them. But, one aspect that kept coming up was the example where the sizing, at least in terms of the due date, is already done. If the end date is fixed you already know how long the project needs to take, you only need to answer the question of whether it’s possible. Or, perhaps more commonly, identify the risks, scope changes, and short-cuts involved in squeezing the project between its allotted start and end points.

If there’s a David Beckham date it will affect the solution options available. But in communicating back to the business what those risks, scope changes, short-cuts, etc are, there is still the need to know how long the project would take without constraints, because the formula for how long any project should take is something like this:

:what_the_business_really_needs + :solution_with_optimal_maturity => :how_long_the_project_takes

It may be a bit idealistic, but surely nobody disagrees with the idea that you want to deliver what the business really needs (i.e. all the things that make a difference and none of the things that don’t) and you want to base this on a platform that can elegantly respond and react to their changing needs for as long as they need it to (i.e. far beyond the David Beckham date). And if we agree on that we can also agree that you can rarely, if ever, have both.

Which is where the conflict begins. And however uncomfortable or awkward this conflict feels, we should always be conscious of the fact that it is a healthy and good thing, because both parties are fighting a noble cause, they just represent different faces of the business’s fractured personality. A personality which not only wants it on time, and effortlessly strategic, but also gets very irritated at the idea that there may be a conflict in this.

A popular solution to this conundrum dangles itself temptingly when someone says something like this:

OK. Both sides want the best for the business. The architects are just doing their job, but we have a date to meet. The schedule just doesn’t give us the kind of room for taking on anything strategic right now. If we don’t deliver we’re all for it, so what we’ll do is go with the tactical solution proposed by the developers for now and once we’re in production and the business is happy we’ll migrate to the strategic option.

Only later, to quote Edmund Blackadder do you realise “there was a tiny flaw in the plan .. it was bollocks”.

So, please please please, if you ever find yourself in this situation do not take the bait. Yes, I know it’s seductive. I have, I am embarrassed to say, agreed to a plan like this in the past. More than once I think. Everyone looks to be getting their way and the business would, I am sure, be happy if this ever, anywhere on this planet, at any time since the dinosaurs, ever, ever, happened.

It. Just. Doesn’t. Work. Like. That.

There is no tactical or strategic solution. There is only what you do. If both sides don’t hammer out a workable answer you get the worst of both worlds because the project is free to go hell for leather for the date, casting aside any pretence of solution longevity (I have done this too, it’s a reality of delivery, not a criticism) and the architects go hell for leather for a design so strategic that it can only be deployed onto technology that humans haven’t invented yet, casting aside any pretence of practicality (I haven’t quite gone that far, but it is tempting when you don’t have to actually deliver anything).

The inconvenient truth in this is that businesses don’t stop what they are doing to allow working software (even if it’s a bit clunky) to be rewritten just so that the architecture can be re-factored. They will ask for changes and improvements of course, but these will have a deadline too. They simply don’t care whether the diagram that explains how it works has too many lines on it, not enough dependency injection, or alignment to some enterprise abstraction. They’ll happily tear you a new one if you later say it’s going to take three months to make a minor change because the diagram has too many lines on it. But that’s business. Capricious, demanding, unreasonable, intractable. Bless their cotton socks.

A final concern is that agreeing to go ‘tactical’ then ‘strategic’, weakens the working relationship between the teams that deliver projects, and the teams that try and make each subsequent project just that bit easier to deliver. The developers become viewed as a bunch of cowboys, slowly killing off the business, and the architects as a bunch of blatherers, slowly becoming irrelevant to daily reality. Not a great place to start the next project, which this time has a Barack Obama date.

The Zone of Plausibility

The answer, such as it is, is first to recognise and accept the pull on both sides and to aim for a solution that has with it some sense of plausibility.

Region 1 is the Amstrad Emailer zone of cruft, and represents a solution that, while functional, will not stand the test of time, because it goes to market too quickly, cuts too many corners and ultimately fails to recognise the environmental requirements within which it will operate. Designs for throwaway prototypes may usefully be found here.

Region 5 is the Philippe Starck Lemon Squeezer zone of impracticality, and represents a solution that while beautiful and elegant in all regards is ultimately useless once any real world constraints are applied to it. Ironically, designs for throwaway prototypes may also be found here, because often when you attempt perfection (assuming an indulgent sponsor, of course) you learn techniques that can be applied in other zones. Typically, though, this is research and development territory.

Region 2 is a good place to start, though it comes with an agility risk: meaning that opting for a few just-do-it approaches may make later pre-launch changes more time consuming. Region 4 is also a good place to start, though it comes with a date risk: meaning that opting for a bit too much richness in the way of frameworks, tool support and design patterns may delay the launch. This is especially true if some team members are unfamiliar with the major building blocks and have to learn on the job. Both 2 and 4 have their obvious merits though, and hopefully when the disagreements start the two camps are here and not 1 and 5.

Region 3 is the zone of plausibility and represents a solution that borrows some longer term thinking from zone 4 (plus optionally some research experience garnered in zone 5) and keeps a keen eye on delivery from zone 2 (plus optionally some user-led prototyping experience from zone 1).

It’s not a compromise, but a resolution to adopt different thinking in different areas and to work to a date that makes sense for everyone. Ideally this is the David Beckham date, but sometimes it’s better to go back to the business with a more reasonable target if it can be shown that failure is pretty much guaranteed otherwise. They may not like it, but it’s far better to have that debate than to bicker internally while useful delivery time continues to tick by.