Gathering Requirements BEFORE a [Document Automation] Project

So, you’ve decided your organization could improve the way it creates documents. Or, as an ex-McKinsey mate of mine would say, there are ‘development opportunities.

You’re even convinced that document assembly is the way to go. So far so good.

But there are lots of options. What’s the difference between them all? How much is it going to cost? How much is it going to save me? What do I need to do to make it work? Fundamentally, you want to know: Which solution is right for me?

The answer of course is: It depends. It depends on exactly what your problem is. Or, if you prefer jargon, it depends on your ‘requirements.’ As you may know, working out your requirements is hard. In fact, it’s the hardest part of any project. It’s a slow process. It requires consultation with all the stakeholders (jargon for ‘affected people’). And most of all it involves lots of uncertainty. People hate uncertainty.

That’s why it’s so tempting to find out what Similar Company X did. Just copy them and skip the whole requirements gathering/analysis bit altogether. Much easier!

Unfortunately, ‘easy’ and ‘successful project’ are pretty much mutually exclusive. (That means they can’t happen at the same time.) First, it’s unlikely that Similar Company X has properly assessed its requirements – most organisations are just not good at it. And second, even if they have, your requirements really are unique. The fact that the two companies are in the same industry or are of similar size doesn’t mean they’re trying to solve the same problems. (I’m not suggesting that you go with a vendor that has no experience in your industry – that’s still important. Just don’t substitute size or industry or some other shared attribute for actual requirements.)

Your requirements are dependent on so much that’s unique to your organization – strategy, organizational structure, leadership, culture, priorities, and project management capabilities for starters. These things are just as important as specific departmental pain points in understanding your ‘development opportunities.’

The reason there are so many different document assembly solutions is because organizations have so many different requirements. That’s why the first thing you need to do is work out exactly what problem(s) you’re trying to solve.

In a future post I’ll discuss some considerations when trying to work out your specific requirements.

Write a Reply or Comment

Your email address will not be published. Required fields are marked *

Achieve 100% Contract Certainty™