As a project manager, my job is often to bridge the gap between the business or client on the one hand, and the development team on the other. Business users define what functionality or features they want in software, and developers are tasked with building it. The business wants it all — NOW! — and developers want time to think carefully, to build strategically, and to approach challenges flexibly.
They’re both right, of course. Software needs to move at the speed of business. And, good quality software takes time and effort to build.
I can make the process simpler by generating detailed, high-quality requirements. I force the business to really think through how they want the software to work, to put their needs into a broader context, and to always “ask the next question” until there aren’t any more questions to ask.
Requirements written this way help ensure developers have full information before they begin designing solutions. Good requirements take a long time to document — but they shorten the development cycle and result in less rework and higher-quality code.
Still, business users want to know when they’ll have access to all the great stuff they’ve conceived. They want predictable timelines, understandably, so they can plan their own work including all the tasks that surround deploying new software, like process change, training, and, oh yeah, revenue.
Geeking out this evening with the top-notch blog written by the folks at Assembla, I came across this quote:
“The best that has worked for us is that we say we’ll do something and then we start doing it – as it gets closer to completion, we know if it’ll be out this month or next. It may sound funny but in reality, that’s how it always ends up! Bugs are different – but with features, the reality is that you don’t really know until 80% into the task how long it will take to finish it.”
This really does sum up the developer perspective on the issue, and I think it may be something I’ll use regularly with business users to help them understand why I’m so…squishy…when it comes to committing dates, especially several releases down the timeline. Software development is as much an art as it is a science, and great art doesn’t deliver on a schedule.
When Michelangelo was painting the ceiling of the Sistine Chapel,
“…he was hampered by the urgency of the pope, who asked him one day when he would finish that chapel, and when Michelangelo answered, ‘When I can,’ the pope, enraged, retorted, ‘You want me to have you thrown off the scaffolding.'”
While it’s generally the business users who are paying the bills, I have to admit that my heart generally lies with the developers.