More than any year since 2000, this has been a year of intense growth for me, both personally and professionally. Its end brings with it a shift in what I’m doing with my life, and 2010 brings with it two big steps that frankly scare the shit out of me, but in the best possible way.

And we’re still only in the first week of January.

So, big things. Those things have names.

Fresh Monkey

I’m a web construction worker. As Jough Dempsey said recently, “I make the Internet. Not all of it.” I’ve been doing that in various ways since 1998, and it’s still fun. I still can’t imagine doing anything else.

A lot of projects that I’m proud of made it out the door this year. Has 2009 been my most successful year? I don’t know how I’d measure that. Financially, the year ain’t over yet, and there’s still 4 or 5 projects that should ship within the month, so let’s reserve judgement on that for now.

For me, though, it’s the year I’m happiest with since my son was born, and that’s worth something.

A big contributing factor to that was managing to haul my lazy, self employed ass out of the dressing gown and into a proper office. Those of you who have visited us at cmdcentral may dispute the use of “proper”, but hey, it’s not a box room in my flat, which means I can leave work at work and “go home” at the end of the day.

Also helping along my mental health had been my move away from using a combination of Blinksale and Billings for invoicing. FreeAgent hasn’t saved my life yet (more on that in a moment), but it certainly meant I stopped waking up in a cold sweat wondering when the money was going to run out, and that’s a good thing when you’re self employed.

So what’s next for Fresh Monkey? Big things. We just went limited, and Anisa’s stepping in as project manager and co-director. Frankly, there’s too much work for just me any more, and I’d rather bring in more people than hand the work away to dreamweaver pilots, so watch this space. If you’re interested in knowing what I’ve got in mind, you should drop me a line.

So that’s big. What else?

FreeAgent

I’m not sure there are enough superlatives. Where else do you see support tickets like this one? Seriously, if you’re self employed, go and check it out. Even better, go and try it out using my kickback code and get yourself 10% off for life!

If you’re at all like me, you’re going to put off moving your accounts system over to them. You spent a long time setting up those spreadsheets, and they’re working just the way you like them. Why abandon that?

If rolling year-in-progress tax calculations, bank statement uploads and automatic invoice reconciliation, automated overdue reminders, recurring invoices, estimates and basic project management functionality doesn’t persuade you to at least try it out, how about this: I don’t know a single convert who has moved back.

Since day one, Ed, Roan and co have been obsessed with making an app that people like me want to use, and it shows.

Of course, there’s always room for improvement, and a quick glance at their Get Satisfaction community shows there’s no shortage of suggestions and requests from their rabidly enthusiastic users. So what’s a growing company to do?

Keep growing, seems to be their answer. They’ve got a new developer starting tomorrow, someone who I’m sure is going to be as fanatical about building a fantastic app as they are already, and will hopefully let them expand at an ever increasing rate.

I’ve been pestering them to let me help out for ages, as it’s been clear they needed and wanted more hands on the wheel, but they were adamant that they wanted to make a permanent hire, to have a senior developer on board 9-5, someone who would be in a position to really make a difference.

So when they said they wanted that developer to be me, I did what all gibbering fanboys do: I cried, and asked when they wanted me to start.

They said “How about the 6th of January?”.

Then they said “Oh, and if you want to keep your Fresh Monkey stuff running too, we don’t have a problem with that. Just try and get some sleep once in a while”.

Then I cried some more. Me, a respectable salaryman. Who’d have thought?

2010

So 2009 was awesome. Let’s look at the list for 2010:

• Working for a company I respect, on a product I love
• Growing a business I’m passionate about, working with more people I’m in awe of

And let’s not forget all the shiny new toys.

Welcome to 2010. It’s looking like a fun one.

I’m not sure I’ve ever known my gut to be wrong. In the past seven years, whenever anything has gone wrong, I can look back at a comment made to a friend or colleague saying, in effect, “I have a bad feeling about this”.

And I’m not just a scattergun pessimist. I know when I’m naysaying for the sake of it, and that’s not what I’m talking about here. I’m talking about that moment when you walk into the first client meeting, and something about the client, or the project, or the atmosphere in the room creeps you out. Or the way you find yourself sitting, uncomfortable, fidgety, looking for an excuse to get out, to leave, or to kill the meeting dead as fast as possible so you can get your team in a room and say “guys, really? We think this has an end?”

We’ve all had those moments, but we ignore them. “Be professional”, we tell ourselves, and then what do we do? We throw professionalism out the window and ignore what it is we’re selling in the first place: our skills and talents.

My gut knows a lot. It can pick up a lot of undercurrents and misgivings, a lot of warning signals that I’m too polite to admit to. And you know what, in a lot of cases, those misgivings aren’t about the client, they’re about me. My gut isn’t saying “this is a bad situation”, it’s saying “this isn’t a good fit”. It’s warning me about overpromising myself, or about taking on more than I can handle.

And in every one of those cases, it’s been right.

These cases aren’t just about not being “good enough”, either. Most of the time, it’s much more subtle: my gut most often warns me when a client is outwardly asking me to do one job, but implicitly requires me to do another job, which is far from my pool of talents.

Abstract sucks, let’s get concrete with a simple example:

Client asks me to produce a shopping cart, my mind applies itself, examines the technical issues, and it seems simple enough to handle. No big deal. Complex, yes, but doable, technically. Still, my gut is nagging at me, telling me something’s wrong.

What’s wrong? I’m up to the project, I’ve built similar apps before, why is this one tripping my early warning system?

Turns out the client didn’t really understand WHY they wanted the cart they asked for, and that, really, their business model isn’t really up to online sales. Suddenly, I’m a sales and business development advisor, and friends, I suck at sales and business development. The client’s getting frustrated at my lack of “web development” talent (remember, they don’t actually realise they’re asking me to do the wrong job), and I’m getting frustrated that they keep changing spec.

Looking at that initial meeting, I can see all the assumptions being made on both sides of the table, and my gut was well aware of them.

Further down the line, I end up backing out of the project, scars on all sides, and everyone’s wondering what went wrong.

What went wrong? I ignored my gut.

You do that at your peril.

The first one to yell loses

There’s a reason that yelling is often called “losing it”. Yelling shows you’ve lost control, it shows that you’ve lost sight of what it is you’re talking about. Yelling means that you’re trying to beat the other person, not win the argument or express your point.

If you start to feel yourself lose it, just:

1. Smile
2. Breathe
3. Go slowly

There’s something much more compelling about a whisper than a yell. This wallpaper might help you remember.

Picking the engine itself, though, has taken about 2 years, and was based on one thing: immediacy.

Choices, choices

Choice is good, right? Competition is even better. I’ve recently become jaded with my own erstwhile approach to site management systems. That approach could be boiled down to two simple statements:

• Content Management Systems are simple
• Given enough projects, I can incrementally build my own while getting paid for it

The implication being that “my own” will be inherently better than any of the off-the-shelf systems that are already out there, because I’ll understand it from the ground up.

What really happens can be summed up by these parallel statements:

• CMS is as “simple” as word processing: easy to describe, easy to prototype, hard to perfect
• Clients are not software designers, and I’m a scorched-earth perfectionist

All of which results in me, having idealised the first two statements, but followed the second two, writing this post two years later.

Build it in increments -> (step 2) -> profit!

If you are planning on building an in-house CMS, I’m assuming that you’ve already come up with all the rationalising arguments about why it will be “better” than off-the-shelf. It doesn’t matter whether you’ve convinced yourself that the client’s requirements are beyond the scope of any existing system, or whether you’re just full of “Not Invented Here” Kool-aid, the point is that you and your team are committed to delivering a CMS to fulfil your client’s spec.

Of course, what I’ve just described is a bespoke CMS for a single client. Everyone knows that’s not scalable to larger projects, so how do we get around that?

All together now:

We write the core of the CMS for this client, and build it modularly so that we can just give them what they asked for, but reuse the core on the next project!

Bingo. Sounds great, doesn’t it? You make a bit of a time loss on this project, but it’s an investment, because next time around you’ll be mainly writing modules for the next client’s functionality. If the next client has the same spec as this client, it’s instant profit! What can go wrong?

This is where reality creeps in. You build your CMS nice and modularly for the first two weeks. You then realise that you’re not quite finished the core yet, and you’ve only got two weeks left to implement the various bits of functionality as modules. You panic. You know what modules you need, so you start building the remainder of the core with those modules in mind. You maybe even start building some modules into the core, promising to refactor them out on the next project, because you finally remembered your Pragmatic Programmer, and suddenly it’s all about “just get it working”.

You complete the project on time, and what do you have? A half-bespoke, half-modular monster that is going to require a serious refactoring job to make usable for the next project.

However, you’ve learned a lot. This is a key realisation, and often missed. You’ve learned a hell of a lot, and this is where the rot starts. You’ve learned so much that you convince yourself that, on the next project, it would be insanity to try to reuse any of what you’ve just coded. What you decide to do instead is to reuse the knowledge. Oh yeah, baby – we salvaged something after all!

So you start coding again from scratch. This time it will be better, you say, since you know how it all went wrong last time, and you’ve come up with five great new ways of modularising from the get-go. Then client number 2 rolls along.

One of these kids is kinda different

So with your newfound “I get it now!” knowledge, you start implementing The Plan again. Client 1 was a false start – client 2 is the real deal. Now you know how to make it modular, you’ll do it right this time.

Except the same thing happens. This time, because you’re having so much fun coding, and because you’ve convinced yourself that last time you caved and started coupling the core to the modules too early, you hold out to week three to produce the core CMS. But again, week three rolls around and you’re still not done. With only one week left to implement the functionality that took you two weeks last time, you start panicking and even more coupling happens. Worse, your project runs over time and is late.

So far, with two projects in the bag, you’ve overserviced both, pissed off one of the clients by being late, given each a rushed bespoke system (with all the attendant maintenance overheads), and have precisely zero reusable code. Not exactly the outcome you’d hoped for.

So what went wrong?

Addiction is curable

What went wrong is that you failed to notice that your stated goals were not really your goals. Worse, you actually got what you wanted all along.

Huh?

Your implicit goal in building an in-house CMS was to reduce the amount of work you do. You’ve noticed that servicing your clients is boring, because you’re constantly writing the same stuff. To fix that, you decide to consciously write that stuff in a way that you can reuse next time.

The logical next step of that is to write an entire system that you can reuse next time. This is where the logic breaks down, because there already are systems that you can reuse. Right now. You can download MODx right now and be at precisely the point you say you want to be at in four weeks.

So why didn’t you? You didn’t because your goal isn’t to reduce the amount of work you do, it’s to increase it. What you secretly want to do is build a bespoke CMS for every one of your clients. You hope that maybe, one day, you might hit upon a pattern that you can reuse, but you don’t really care about that. You love coding, you love tweaking and refining and burning it down and starting again. You love it, and you got it.

Step zero is realising you’re addicted

So what are you addicted to? Coding? No – you’re addicted to the knowledge you’re learning, to the experience, to “figuring it out”. That’s why it’s so difficult to locate the source of the problem. When I said “you wanted to increase your workload”, you balked, because to you the work is becoming more and more painful.

The knowledge isn’t, though. You’re putting up with the pain for the rush of having refined your perfect plan for next time.

And the truth is that your CMS prototypes are getting better all the time. After 5 or 6 more clients, you might have a really solid platform.

Too bad for your first half-dozen alpha and beta testing clients, though.

Where’s the exit?

So how do you break this cycle? You decide which of these is more important to you right now. Do you want to:

• Build a CMS; or
• Streamline your client servicing?

You don’t get both, not right now. If you want to build an in-house CMS, you’re going to have to commit 6 to 9 months of development time to it, and the client has to be your company, not some real-world project you’re using to guinea-pig your sketches on. You need to take yourself (and perhaps another developer) off paid work and become software developers, with the attendant investment and payoff cycles that don’t exist in direct-to-client sales.

That’s the price. Once you have your CMS, you can start flogging it to people. At that point you can start to “Streamline your client servicing”.

Of course, by then, I’ll be in your sector, stealin’ your clients, because I chose to “Streamline my client servicing” straight up using WordPress and Expression Engine, with MODx in there for the really tricky stuff, and have been having a whale of a time developing modules, plugins and extras for those mature platforms you’re only starting to catch up with.

Your CMS had better do something unique.

To do this, I use OmniPlan from The Omni Group. I love Omni’s software (OmniFocus runs my life, and OmniOutliner stores most of my most important notes), and OmniPlan is built with the same attention to detail as the rest of their apps.

Outlining the effort

The key thing for me is the fact that it uses an outline view for building up your project. Just like OmniOutliner, you can happily drill down deeper and deeper into each “node” in the outline. Each node has a number of attributes, the key one being “Effort”. The amount of effort assigned to each node then translates into a bar on a Gantt chart, and also an addition to the project cost, once you’ve told OmniPlan who’s working on that node, and how much they cost per hour.

Over the couple of years I’ve been doing this, I’ve developed a standard “web development” template that stubs out most of the tasks I carry out during a project. Just like any good outliner, the nesting facility means that I can group the project into discrete blocks, which is great for being able to produce a “top line” summary of what each area of the project will cost.

Where do all these top line numbers come from? Let’s expand out all the items in Core Development outline:

As you can see, the project timeline can now start to build itself from the bottom up. Every task starts out with one hour assigned to it. My first task at the start of a costing is to go through the default outline and prune what isn’t needed for this project, before adding in what *is* needed. I then go through and start to apply time estimates to each task based on previous experience and “best guess” work.

Bubbling up the costs

The great thing about OmniPlan is that it tends to remove the best guess factor from most tasks. Let’s say, for example, that in my first pass I reckon that I’ll need 4 wireframes:

I reckon each layout is going to take me half an hour to do, so in they go, and suddenly my Site Wireframes budget sits at 2 hours. If I realise I need more wireframes as I plan the project, in they go and bump up the cost in a fully justifiable way.

Let’s say, though, that I reckon one of those wireframes is particularly complex because there are lots of variations. I might not have a good handle on how long, say, a progressively enhanced “personal content aggregator” might take to wireframe. No worries – I can nest the various sub-tasks to come up with a proposal:

I now have a better feel for how easy or hard that’s going to be. This is all the kind of stuff you do when planning a project anyway, but the fact that you can make simple changes to subdivisions of tasks and have them percolate up your estimates automatically is a real boon for tracking complex projects.

Show me the money

Once I’ve gone through and assigned time estimates to each part of the project (practically writing the spec as I go, incidentally), I can then use OmniPlan to build timescale estimates and cost them up.

First I switch to the Resource view:

By selecting me (or creating a new resource) and viewing the inspector panel:

I can set hourly rates, and how “available” I am for the project. No, I don’t charge £100 per hour for development. I wish I did.

Back to the Task view, and I expand all tasks, select all, and choose Structure -> Assign Resource -> Jonathan. This hammers through all the hourly estimates and gives me a cost based on my hourly rate, as well as displaying a project total in the status bar at the bottom of the window. By selecting View -> View Options then enabling “Total Cost” in the Outline Columns pane, I can now see how my top line works out:

Awesomeness!

Time keeps on slippin’

Next up is to get a timescale plan. To the right of the outline we get a Gantt chart. The Gantt chart is smart enough to build up a timing plan automatically based on how many people you have working on the project, how available they are, and what dependencies you build into the project.

Since we’ve only got one person working on this full time, we can’t have any concurrency, so it’s all about the dependencies. As you can see, there are some black arrowed lines running from the end of each task group to the beginning of another:

Each one of these arrows represents a dependency, and we set those up quite simply by selecting the task which depends on another one, opening the dependency inspector, and dragging in that task’s pre-requisite and dependent tasks:

This ensures that our Gantt chart never schedules anything before its pre-requisites are completed.

Once all THAT’s done, we select all the tasks and choose Project -> Level Resources. This rebuilds the Gantt based on what we’ve said about the project, and gives us a good estimate of how long the project will take to complete.

All you do is write code, right?

The final super-smart thing about OmniPlan is the ability to restrict a Resource’s availability. Go into Calendar view, and select your resource. By default, that resource is made available to the project full time. Let’s say we only want to spend half of each day on this project, the rest of the time left for maintenance, admin, phone calls, email, and other freelance stuff. Simple – just make sure that the “Normal Work Week” for your resource is set from 8am to 12noon (just drag on the calendar like in iCal).

Now if we go back to the Task view and run Project -> Level Resources again, we’ll see that we now have a much longer looking Gantt chart:

Even better, we can see that the Duration of the project (see the status bar, and click on that to cycle through the various bits of info this can display) is over 2 weeks, but the actual effort involved only spans 4 days.

Now all we need to do is write up our proposal document based on these timings and specs, send to the client, and wait for approval so we can bill them their deposit.

You do charge your clients deposits, don’t you?

Downloads

• Web Development OmniPlan Template (zip)