The Other Way
Your first encounter with the development group is through a sales guy and a glitzy marketing website that promises to deliver a business-centric solution that will empower your resources to help you better leverage your synergy. The sales guy will say “yes” to everything you want, simply because he doesn’t really have a clue what you’re asking.
A solution architect gets attached to the project; it’s her job at this stage to try and decipher the real requirements of the project from the sales guy’s vague statements. She’ll begin to formulate the framework that the application will use. Will this be a three-tiered app? Will it need web services? Is it going to be browser-based? A standalone client app? What platforms does it need to run on? She’s got a million questions at this point, but even if she asked them all she still wouldn’t have a good handle on the project, because there are just some things you don’t even know to ask until you’ve started in on it.
The developers, by the way, haven’t seen the specs yet.
While the architect is setting the framework in stone, the sales guy has put you in touch with their graphics department to do some screen mock-ups. These will be very pretty, certainly, but they will have almost no consideration for any of the technical constraints implied by the requirements that the architect is formulating. Thus they may bear little relation to what is even within the realm of possibility for the developers to create, or may require such a time investment in the UI that the rest of the project suffers.
The developers won’t see these screens yet, or possibly ever.
The sales guy tells you that it’s time to start drawing up a contract. In order to do that, you’ll need to get an hour and/or cost estimate, so a project manager will come on board. From this point forward, you may never talk to the sales guy again. The project manager draws up a project plan based on the nebulous requirements from the solution architect, and the sales guy turns that into a budget and puts it into a formal proposal. If you do, he’ll rarely tell you the same thing as the project manager, and they’ll both say different things than the solution architect. Generating the system specification is like a corporate game of ‘Telephone’ run amok.
The developers haven’t seen the timeline yet, and it’s possible that the solution architect hasn’t, either.
It’s almost certain that the proposal is going to take too long or cost too much, so you’ll enter into negotiations, in which steps 1-3 are iterated. The requirements may be pared down, but it’s more likely that the solution architect and project manager will just become more and more optimistic (architects, having once been developers, are an innately optimistic breed). Eventually, everyone comes to an agreement.
The timeline and the specs are handed over to the development team.
And they look like deer, staring right into oncoming traffic.
But developers, as I said, are an innately optimistic bunch, and they’ll plunge headlong into your project. There’s an air of excitement about it – it’s got that “new project” smell to it. "This time," they think, "it’s going to work. Yes, it’s an aggressive timeline, but we’ll meet—no, we’ll BEAT it!"
Meanwhile, the graphics department keeps churning out glitzy screenshots.
You’re meeting once a week or so with the project manager, and he keeps painting a rosy picture for you. And he’s not entirely lying. Although the project isn’t going that great, the over-enthusiastic developers are over-communicating their optimism to the project manager, so he has no reason to suspect that the project is a train wreck unfolding in slow motion.
But something’s not quite right. The specs are kind of vague on a few critical points. The different teams aren’t communicating well (and there are so many of them). You actually, as it turns out, need a bunch of new hardware to run the application. The sales guy should have mentioned that. Oh, he didn’t? Well, we need to increase the budget, then. You needed the application to be highly-available? Yeah, actually that is a pretty big change.
Imagine trying to build a house while the blueprints are changing, without changing the foundation. Now imagine that all the various subcontractors each have completely different tools and measurement standards. And, as for testing, the building inspector has to do his job from the outside, and he’s got about five minutes to certify that the house won’t completely collapse.
It’s almost certain that the project will be over-budget, buggy, underperforming, late, or any combination of these things. And everyone will be left scratching their heads and wondering exactly what went wrong. There’s no one thing to point to, however. Things went wrong one little detail at a time. People got bogged down in process. Teams got bogged down in (mis)communication. Developers had to wait to get clarification on the requirements. No testing was done until the end, when it was too late.
Obviously this is a caricature of the entire process, but if you’ve ever had custom software developed for you, you may have recognized some parts of it. We’ve seen this happen time and time again, and we’re determined not to go down that path, for your sake and ours.