That’s what Sam Beckett used to say when he was leaping about from life to life, striving to put right what once went wrong, not entirely in a dissimilar fashion to project management. Except without the time travel, body swapping and lecherous holograms, of course. But like Dr Beckett, most PMs are driven by an unknown force to stop projects crashing into giant underwater icebergs and bring it all in on time, on budget and with a satisfied team and delighted client at the end. It’s a tough gig though as a huge part of it relies on managing the expectations and scope of what you can deliver in the time you estimated at the cost they accepted. Oh, boy.
I imagine the challenges faced by web companies are no different from any other business in the service industry. Lacking a physical product to sell, we only have ourselves, our experience and our repertoire of tricks to hock to, well, anyone we can find. You can show people examples of what you’ve done, you can talk about what you’re going to do, they can describe in detail what they want, but until you actually start to invest a serious amount of time, none of you know exactly how the final product will turn out. No matter how good the brief, there is always an element of speculation involved.
The bigger the project, the tougher things get. With smaller stuff you tend to know what to expect, what bullets to dodge and, more importantly, how to reasonably accurately estimate costs and define scope. Pitfalls will still crop up but they’re manageable (usually) and worst comes to the worst, sucking up an overrun won’t cripple your business (he says confidently). More importantly, it’s easier for everyone to picture what’s being delivered.
Larger projects tend to be different kettle of mutated fish. Costs rocket, expectations increase exponentially, the scope of work becomes much harder to define and contain, and the final vision of what you’re trying to achieve is far more obscured. When looking down the barrel of 100 days plus of work spanning six to nine months (we have a couple of these on the go), it’s difficult enough to anticipate how the final product will look like halfway through let alone before you’ve even started and are merely writing a proposal.
The spec before cost
There are varying solutions, specifications being an obvious one. In counter productive fashion though they usually come after the job is commissioned and costs have been finalised, not really doing much to negate that difficult moment when you realise the thing in your clients head that they bought is completely different from the thing in yours. “But I want the equivalent of Microsoft Access online!”, when you’re delivering a simple CRM is no fun. And yes, someone did say that to me once, long ago.
One of our buddy web companies in Norway, Apasje, uses a clever technique whereby they charge for a scoping exercise on larger projects before submitting final costs and estimates. It’s a great approach and not unlike paying an architect to design your house before commissioning contractors to build it. Some would argue that a good tender should negate this though by providing the specification in the first place. Likewise, it still requires dealing with rising expectations and creeping scope during the course of the project as normal but the huge benefit is that everyone is kicking-off from a well-informed and clear foundation.
Charge by the hour
Lawyers and accountants have it right by charging by the hour instead of committing to fixed costs. This approach makes me jealous as it completely foregoes the management of expectations by simply charging for everything that’s requested. “Yes, sir, we’ll start on building your online version of MS Access right away, sir!”, when every nanosecond can be billed straight to the client kinda takes the fun out of things.
From a customer perspective too, charging by the hour is a dangerous undertaking and most would sensibly object to the idea of being presented with an open costed solution. I know I would. It could be balanced with an initial quote and then running charges afterwards but this also doesn’t do much aside from encouraging tender lowballing.
The agile methodology is rather potent in handling scoping issues and our new solution of choice. Have a gander at it’s three core truths:
1. It’s impossible to gather all of the requirements at the beginning of a project
2. Whatever requirements you gather are guaranteed to change
3. There will always be more to do than time and money will allow
These truths lead into the basic principle of breaking down projects into phases with clear objectives and then allocating time against each phase. Working through requirements in descending priority means you are certain to deliver a fundamental solution although the exact minutia of functionality and operational ins-and-outs will vary depending on available time. Everyone’s happy as that moving target of viable solution is achieved within the limits of finite time and money.
Some people criticise agile, to be fair, because it places more of an emphasis on trusting the supplier and doesn’t guarantee a fixed quote solution to every unimagined vagueness. Obviously, I see neither of those as being bad things. Even on fixed budgets and timescale – particularly on fixed budgets and timescales – projects can’t be open season for features and unlimited expectations.
While I’m starting to love agile like the child I don’t have, it’s not a silver bullet, however, and still requires a strong understanding of its principles by all involved and the constant discussion of the possibile and the feasible, backed up by solid specs, wireframes, plans and designs.
In the end
Just a few ideas, these are all great ways to manage scope, deliver practical solutions and, to a good extent, manage expectations while bringing everyones visions in line. The latter is always going to be incredibly hard to achieve though and why web companies go through numerous designs and plans, all with an aim to try to describe as fully as possible what’s going to be built. Ultimately, I suppose bringing together a requirement and a speculative cost in a viable, happy solution for all is never going to require anything other than degrees of experience, trust, honesty and compromise on both sides. That’s part of the fun though.
Anyway, I’ll go back to falling in love with The Agile Samurai now.