I have just started supporting a new client. We’ll call this client Client B. Client B did a pilot of DOORS, then a few months later hired a some consultants a month or so before they had a deliverable due. They did not, however, hire a consultant from the beginning. They learned DOORS themselves.
As Client B was starting up their DOORS pilot, I was starting up at Client A, setting up a full DOORS implementation for them. Client A had just performed a DOORS proof-of-concept, but they knew that they would need someone who had used DOORS before. They were migrating from another requirements management software package, and they didn’t want a repeat of what happened with that package.
Client A knew they were in over their head and they hired me to help them out.
Client A is in great shape as far as their DOORS database and requirements go today. Sure, there are still some battles to be fought and some decisions to be made, but the company knows where all the current requirements are and more importantly what all the current requirements are, and they didn’t know that before I started.
I created targeted DOORS training for Client as well as listened to their needs and structured the database so they would be successful. I also wrote processes tailored to what they were trying to do, and together we came up with attributes and levels of documents.
There were some arguments with Client A. Client A did not always understand why I was suggesting to do things a certain way. But in the end, they trusted my experience and judgement, and I believe they are very satisfied with their current RM processes and tools.
As I said above, Client B did a pilot, and they read the DOORS manuals and even went to some Telelogic training. But they never stopped their proof-of-concept. Instead, the POC just became their process, without a formal review. A few months into work they hired some consultants on a temporary basis, and as happens many times, these consultants were more interested in customizing the client’s DOORS needs (triggers, unnecessary attributes) rather than assessing what the client actually needed. For instance, this client had MS Word documents with huge, complex tables that they imported into DOORS. DOORS turned them into native DOORS tables and now Client B is trying to get them to look professional upon export to Word.
Client B has quite a bit of rework in their future, and more importantly they weren’t set up to be successful. There is no clearly defined schema. There are no clear processes. There are no definitions for what goes into DOORS and what doesn’t. They do have a doc tree and they have an idea of what they want, but they didn’t know all the correct questions to ask, and because they didn’t have an expert come in right away, there is quite a bit of cleanup to do, both in the database and in the users’ heads, as there are also some misconceptions about DOORS.
I believe if Client A had tried to figure things out themselves, Client A would be totally dissatisfied with DOORS and think that they wasted their time, effort, and budget. And that would have led to more resources wasted in fixing their implementation.
To be a great DOORS administrator and requirement manager, you need to know what your customer needs better than your customer. You don’t have to know every nook and cranny of every project, but you do need to know the project’s goals and their specific RM needs. The customer may tell you that they want an attribute for requirement priority, but do you know what they hope to get out of it? Do they want it just because it would be nice to have, or do they want it for budgeting/safety, etc, and is there a better solution for their need?
Many DOORS Administrators come from a SW Engineering or other database background, where they are simply told what to do and are used to just doing it without asking too many questions. (I don’t mean to pick on SW folks here and I don’t mean to be disparaging–I’m just going by what I’ve seen in my own personal experience!)
My customers sometimes hate me for it, but I ask lots of questions. Nobody just tells me to create an attribute and expects it to be done. They have to follow the process, and that process dictates that they need to justify the attribute’s existence. They also need to define the attribute clearly. With requirements, and especially DOORS schema, not having an admin to constantly ask “Why” is a sure-fire way to get a database that has little value.
Requirements exist to document and even sometimes to elicit the customer’s needs. As a DOORS Administrator, you have to elicit your customers’ needs to ensure a quality database. If you’re a project manager who wants to use DOORS, it is
critical to have an DOORS and Requirements Management expert on board from the very beginning. I think many DOORS Admins get so caught up in customization, writing DXL, and being told what to do by management/users that they sometimes lose sight of the true needs of their customers.
In any case, it’s very interesting to see how critical DOORS expertise is to a successful DOORS implementation. Anyone thinking about purchasing and deploying DOORS would do well to keep this in mind. The main difference between Client A and Client B is that Client A knew that they needed an expert, and they made obtaining an expert a priority from the very beginning. This greatly improved their chances for a successful DOORS implementation.