Has this ever happened to you? A senior manager asked me if a software application could be ported from Microsoft Access to Salesforce.com. The business unit workflows are partly automated and partly manual today. I did a top-level analysis and suggested that the current application could be ported fairly quickly.
The project got approved and the business unit expects delivery in a few months … but there’s a catch. The business unit wants to automate everything they do. They want automatic reminders, dynamic workload balancing, background assignment changes, spontaneous customer mailings, etc. — none of which they do today in Access.
What started out as a simple software migration has turned into a major business process reengineering effort. Of course, the original projected time line and the staffing level haven’t changed from the original guesstimate. Now what?
Let the Games Begin
My preferred approach to almost every project is to prioritize the feature set, define a deployment date for the first release, and get to work. Whatever gets done in the time allowed gets delivered. Whatever doesn’t get done, moves to the next release. Simple right? It goes along with the concept of a minimum viable product. Do just enough to create real value and deliver it.
Unfortunately, not everyone agrees with my preferred approach. It seems that some managers like to play games of chance. The senior manager running this project likes documents (especially thick ones), meetings (lots of them), and Gantt charts (Did I mention that I hate Gantt charts?). In my experience, all that project overhead merely provides the illusion of control. Even if some time or cost savings are found, they’ll be offset by all the administrivia.
My approach with these old-school managers is to break down the problem space into a set of smaller problems. There are many ways to do this. For example, the application can be decomposed into user stories, group workflows, feature sets or software modules. Ultimately, it’s whatever you’re comfortable with. The key is to break the application up into small units of work — the smaller the better.
Take Your Best Shot
Then, estimate each unit of work using a point system such as 1 point is 3-4 hours of work. (This is what I like to use. The range includes time for administrivia.) 2 points is twice as much work as one point, 3 points is three times as much work as 1 point, etc. (I like using a Fibonacci number sequence because it does a good job of reflecting uncertainty and risk as work units become larger. Anything over 8 points usually carries significant unknowns and risks.)
In the end, I have a total number of points translating to a range of work hours from 3x points to 4x points. So, for example, if I have 300 points, I have a work estimate of 900-1200 person hours or 22-30 person weeks. This accomplishes two things. One, the level of detail provides a feeling of comfort that the analysis is thorough. Two, the final estimate is a range, not a single value, leaving some wiggle room.
Of course, some managers will pick the 22-week number in my example and try to make that the goal. I push back. Software estimates are an exercise in probabilities. When I say I can deliver an application in 22-30 weeks, I mean I’m confident — but not certain — that I can deliver somewhere in that range.
Will it be closer to 22 weeks or closer to 30 weeks? I have no idea. Could it be less than 22 weeks or more than 30 weeks? Yes. If everything comes together nicely, we have a shot at delivering early. If we encounter major unexpected problems, we could deliver later — possibly much later.
I’ll let you know how this turns out. I’m hoping that the project is split into phases and delivered in chunks because it’s the right thing to do. If you have any suggestions, please let me know.
photo credit: Vanessa Pike-Russell via photopin cc