First off, we need to clear the air with a dose of reality. Everyone one of us in technical project management has been involved with “THAT” project…. You know the one… we need to get something in front of the client now that shows we are doing something, whether it’s a price, timeline or resource estimate. If we don’t produce SOMETHING, the client will believe we are billing without producing. Or… it’s a matter of sales and marketing folks wanting to get a jump on the sale, so we’re forced to put something together that hopefully resembles the tasks we will actually perform.

I think this comic sums up that type of situation:

For the most part, project requirements actually are provided initially in the form of an RFS, RFQ or RFP. Granted, they are not always clear, but you at least have some sort of road map to go by. Between the initial request document(s) and discovery meetings, you can detail out project requirements.

An issue arises in what I term “drive-by projects.” These are projects which arise out of hallway conversations, golf games, lunch conversations and the likes. The project manager receives the project, and there is so little detail that it is difficult to discern what is actually wanted. Now, keep in mind, I’m writing this post from the perspective of reality, not from scenarios presented during our project management training. I’ve not worked in a single company which did not have these types of projects occurring on a regular basis.

Projects fail many times because of lack of requirements, or bad requirements and “drive-by’s” are notorious for having both of these characteristics. Without some good effort to drive the requirements out of the client, there is a high probability that the wrong thing will be delivered to the client. These outcomes not only create negative perceptions of the project itself, but also of the project management team/office.

That being said, my approach in drive-by situations is to write down a few notes about the discussion, then immediately call a meeting to develop a business case and flesh out high-level requirements. I always receive push-back for this, often with phrases such as, “It’s just an <insert technology here> – can’t you just do it?” Generally, I try to respond to these types of comments carefully and ensure the client that I just want to ensure that we deliver what they are expecting and that when we are complete, they will be satisfied with the solution.

So, make sure in all cases of shallow or no requirements, you make a concerted effort to loop in the client and pull their needs out of them. Doing so will save time, cost and most of all frustration.