Four Trips to Midnight

Midnight is a dark time, like a looming deadline which you’re pretty sure you can’t meet. No one is ever sure exactly how they got into the position of running up against midnight, but it usually means long hours late at night – and lots of caffeine. Perhaps it also includes a dose of wistful thinking and wondering about the project plan that seems to be growing like David Banner in a snit. Sometimes it happens, the work load just got misjudged, or the magic of juggling priorities and fate landed a few choice lemons in your lap. Maybe it’s a different problem altogether.

I’ve noticed lots of analysts have trouble with estimating the amount of time it will take to complete business analysis and the elicitation and documentation of requirements for a project. I remember evaluating a team where the most forgiving management stakeholder I interviewed stated they were currently at 300% of the expected time needed to get requirements – and that was just her personal time… not elapsed time (which was months over schedule). Estimating analyst effort is tough because business analysis is inherently about taking a concept that is airy-fairy-fluffy, and turning it into something that is concrete-with-dimension. Here are some ideas to think about late at night – hopefully some of these will prevent you from burning the midnight oil on your next project.

1. Your company might be lousy at scoping… It’s crazy the number of companies that don’t stick a little micro-engagement on the front end of their analyst work effort. The only purpose of the engagement is to figure out how long (with reasonable precision) it will take to do requirements, and to figure out the plan to get these requirements done. Sound silly – a plan to do the plan? On the contrary, it will likely end up as the highest value you offer as an analyst organization. Remember, many companies also spin for months on very early stage projects with little to show for it – this micro-engagement will break that spin cycle. The other added bonus is that high quality requirements plans keep stakeholders engaged, and that makes it more efficient for everyone.
2. Your company might have ambiguously defined process and outputs… This situation is like trying to shoot a bulls-eye while riding a mad bronco while shooting at a bouncing target. Hitting it ain’t going to happen! In my early years, I once had an executive say at the end of an engagement, “can you get some more business context into those requirements?” I said, “we’ve already documented the process flow, data flow, business rules, for every process in the business and used these as the basis for the business requirements, I also have a context diagram, business objectives, and good representation of the issues and interdependencies. What’s missing?” I guess he figured I had his funding plan all figured out too. Get some precision on the expected outcome and what that means before you start committing on timelines.
3. Lousy practices (ouch!)? OK, so this shouldn’t be rocket science, but you might want to try breaking analysis down into Use Cases, Business Events, User Stories, or some other collectively-inclusive-yet-mutually-exclusive bits of work. Then estimate how many of these you have. Start with the business process areas, how many big processes are we dealing with, how many Use Cases in those processes, etc? Here’s the magic bit… keep track of how long it takes you to do one for you and other members of your team.
4. Maybe it’s the review process that needs improvement? Some review processes have very little end in sight. Especially ugly is the organization that expects to get business signoff on very detailed systems specification with lots of techno-babble. I did some consulting for another company that was big on peer reviewing. Peer reviewing is great, but every reviewer at that particular company did requirements a bit different, so it was driving the analyst teams nuts and creating lots of inefficient rework. It will save you lots of time and effort if you get a clear expectation of level of detail, form, format, and maybe even get agreement from the stakeholders on what a good requirements document looks like before you get underway. At least that way, you can show the reviewers what the agreed upon target looks like – or walk recalcitrant stakeholders and sponsors through the templates that worked so well on that other successful project. Then show them how yours provides the same level of detail, and walk them through the process through which that detail was assembled.

Here’s a secret – only a small minority of companies actually produce requirements plans on projects. Yet many of you end up burning the candle at both ends trying to meet a somewhat arbitrary deadline on the requirements preparation. Don’t stay on a train that will keep taking you to midnight over and over. Step back; it might be time to change the process.

What’s your favorite cause for a trip to midnight?

Don’t forget to leave your comments below

---

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.