Managing the Requirements We Don't Know

When we come into an engagement as an outside consulting project manager or consulting technical resource, we often come into the project cold. We are without any background knowledge – at least without significant background knowledge - of the situation at hand because we are rarely, if ever, part of the sales process. We don’t have the knowledge advantage of being part of the customer’s corporate culture, part of the day-to-day life of the organization. We don’t yet know its business processes. What makes it tick? And we probably only know the tip of the iceberg as to what doesn’t make it tick – meaning what the need is that we’ve been brought in to solve, or improve upon.


Getting started


So where do we start? Obviously there’s been a point person, or sponsor who has asked for our services. This is always our best first point of contact because the enthusiasm for the engagement comes from this person. They are probably also the person with the funding – at least access to the primary funding – for the engagement. We get as much information from this individual as possible about what problems are being experienced, what the needs are, what the vision is for a solution, and who they think are the right people to talk to next.


I never ever condone taking initial requirements and stated needs with anything more than a grain of salt because I will always contend that many clients don’t really understand their true issue. They may only be discussing a symptom of the real issue. But if you let this person go into great detail about all the information they’ve gathered on their perceived problem, the solution, and who else should be involved then at least you have a good starting point for digging around in an unfamiliar organization. Without this information, you’d have no idea where to start.


The end users


The next step is to go to those who the sponsor says are the users – or will be the users – of the planned solution. I was once asked by a VP to identify and implement a CRM system for the three separate divisions of one company. He had his own vision of how things should go and what solution to implement, but he did explain that each division was using their own out-dated and homegrown CRM software and no one system talked well to another.


My next step was to meet with several users of each system in each division to find out what they liked about their own system, what they didn’t like, and what their ‘ideal’ system would look like….because each division really had different data capture and reporting needs than the other divisions. By doing this, I was able to get nice list of requirements and some good common denominators to look at as I gathered information about CRM solutions available and the features of each.


Summary


The basic reality here is two fold:

1. We can’t assume that our first point of contact really sees the entire big picture. They know there’s a need that we can fill, but they may not be looking at the real problem or at least the whole problem.
   
2. We basically must come into a situation like a little child because we don’t know the organization…and that’s ok. We must be wide-eyed and clueless – and ask lots of questions of those people who have been doing the work.
   

The sponsor in my example above saw the real problem, but without the outsider – me – coming in and asking questions without any previous knowledge then anything someone else would gather could be biased. And if I come in with some preconceived notion of what they need then I risk the possibility of missing the mark, too. We must come in planning to manage the unknown. Clean slate. Don’t assume anything – at least not until you’ve got a good base of knowledge or the problem from the people who actually need the solution.