Why should we hire you?
This blog entry is going to be a bit of a departure from the norm. Tech people spend their time and effort creating a product or service. Sales people spend their time and effort defining the value of the product or service. I am in sales. Therefore, it is in that vein that I am posting this.
As much as we would love to have a prospective client look at us five minutes into our meeting as say, “You had me at hello.” (or maybe more appropriately, “You had me at requirements”) the more realistic expectation would be for them to ask, “Why should we hire Seilevel?”
That’s exactly what happened the other day. A very sharp, experienced gentleman turned to us early in our meeting and said, “What you do…eliciting and documenting the right requirements for software development, is something we do very well. And even if we didn’t we can outsource the development overseas for a fraction of the cost and they can send us a BA here to handle the requirements. Or we could hire one of the Top 25 Tech Consulting Companies and have them handle our requirements AND development. Why should we hire Seilevel?”
As confident as my co-worker and I are in Seilevel…as many times as we’ve seen our company wow our clients…we had no great answer. “We’re better!” or “Hire us and you’ll see!” wasn’t going to cut it with this guy.
Fortunately for us, he gave us enough time, and we were able to relate enough information such as client success stories, etc., that by the end of the meeting he actually had a list of reasons why his company would consider hiring Seilevel.
1. We’re local. Bringing in others from out of town adds to the cost…and eats up time.
2. We are process agnostic. We’re not going to force you to follow our process. The models we use are applicable to any process. In fact, he said because we’re process agnostic we would have a fresh perspective and we may see things that aren’t obvious to them because they’ve always done things the same old way. We wouldn’t come in with preconceived notions.
3. We have no “dog in the hunt”. We’re not here to push a product since we aren’t selling a requirements tool.
4. We specialize. Sure some may feel it would be more convenient if we were a “do it all” consulting company. But the fact is that if we were, we wouldn’t be as good at requirements. The bottom line is that software requirements are all we do.
Now while we are thrilled he saw value in out company, we are disappointed that we didn’t have a better, more compact answer for him when he asked. So that’s the point of this blog entry: It’s actually a challenge. To Seilevel’s employees, to Seilevel’s clientele and to anyone else that can answer the question, “Why should we hire Seilevel?’
After all…”You had me at hello” doesn’t really happen in business, unless it’s the movie business.
As much as we would love to have a prospective client look at us five minutes into our meeting as say, “You had me at hello.” (or maybe more appropriately, “You had me at requirements”) the more realistic expectation would be for them to ask, “Why should we hire Seilevel?”
That’s exactly what happened the other day. A very sharp, experienced gentleman turned to us early in our meeting and said, “What you do…eliciting and documenting the right requirements for software development, is something we do very well. And even if we didn’t we can outsource the development overseas for a fraction of the cost and they can send us a BA here to handle the requirements. Or we could hire one of the Top 25 Tech Consulting Companies and have them handle our requirements AND development. Why should we hire Seilevel?”
As confident as my co-worker and I are in Seilevel…as many times as we’ve seen our company wow our clients…we had no great answer. “We’re better!” or “Hire us and you’ll see!” wasn’t going to cut it with this guy.
Fortunately for us, he gave us enough time, and we were able to relate enough information such as client success stories, etc., that by the end of the meeting he actually had a list of reasons why his company would consider hiring Seilevel.
1. We’re local. Bringing in others from out of town adds to the cost…and eats up time.
2. We are process agnostic. We’re not going to force you to follow our process. The models we use are applicable to any process. In fact, he said because we’re process agnostic we would have a fresh perspective and we may see things that aren’t obvious to them because they’ve always done things the same old way. We wouldn’t come in with preconceived notions.
3. We have no “dog in the hunt”. We’re not here to push a product since we aren’t selling a requirements tool.
4. We specialize. Sure some may feel it would be more convenient if we were a “do it all” consulting company. But the fact is that if we were, we wouldn’t be as good at requirements. The bottom line is that software requirements are all we do.
Now while we are thrilled he saw value in out company, we are disappointed that we didn’t have a better, more compact answer for him when he asked. So that’s the point of this blog entry: It’s actually a challenge. To Seilevel’s employees, to Seilevel’s clientele and to anyone else that can answer the question, “Why should we hire Seilevel?’
After all…”You had me at hello” doesn’t really happen in business, unless it’s the movie business.
posted by Anonymous at 5/05/2006 12:21:00 PM
7 Comments:
But, you are process specific, because you think that requirements management actually works the way Weigers talks about it, the way it was taught in school.
Sure that's how everyone does it. But, what if everyone is wrong!
I'd rather hire a person that understood the domain being elicited, than somone very good at elicitation.
The next question I'd ask is what if the functional units didn't agree on say "the single definition of the customer?" What does requirements elicitation practices tell us to do?
Anonymous, actually we have been doing requirements analysis for many years. Fundamentally it is about planning and frankly planning just isn't that hard. That being said, most people are too lazy to plan. In the same way that most project managers are bad, most people acting as business analysts/product managers are simply in the wrong job.
People sometimes use the excuse that the business requirements are constantly changing. We find that this is only appears to be the case when the actual business requirements have not been sufficiently understood and you get too deeply into design rather than requirements.
David, this is a really good point and I agree. The way that we have seen it work is to have very smart people that get to a good (but not necessarily perfect) understanding of the domain.
The problem is that the people who understand the domain may have been doing it for 10 or even 20 years. However, they are business users and have literally no concept of how to develop software. If the business users are tasked to write the requirements, eventually the developers end up writing the requirements. This usually means that the requirements are quite poor.
A domain is a culture containing meaning.
IT systems are meaning free. IT systems contain data stripped of meaning. As the number of stakeholders increase, this becomes increasingly apparent.
How would an elicitor resolve this inherent conflict?
In the todays competitive world the answer of this perticular question has lots of important even in the interview also these question is one of the most favorite bquestion of hr manager.
Even i have to face these question many times and i am somewhat uncomfortable to give satisfacory answer inspite of we are trustworthy name in IT outsourcing.
Post a Comment
<< Home