Requirements Management Please!
Developers everywhere are in terrible pain. Why has it come to this? What can we do to make the world a better place for software developers and their children?
This sobering video clip was put together by devshop, and it has me fired up to help these poor souls! So, what can project managers do about these important issues? Let’s take a shot at them. This post is part of a series, addressing each of the pain points from the video.
Pain #1

We're 4 months in to a 5 month schedule and I just received the final requirements yesterday (and they've changed again!)
Requirements management please! This poor soul desperately needed a good business analyst or project manager a long time ago to flesh out the requirements in advance. Even in an iterative approach, the high-level requirements should be clear before any developer starts coding.
In my experience, project teams are very productive when you have a business analyst or project manager who knows enough about the actual work being done by the project team (usually used to do it themselves) that they can completely free up the team to work on tasks. Optimally, the team trusts the BA or PM to get the customer needs well defined, and elicit requirements in such a way that most of the normally unstated desires and ideas are captured.
Visuals are great when it comes to this. Personally, I have taken the approach of using visual tools like modified use case scenario diagrams, GUI mock-ups (for software) and simple functionality graphics to understand and capture user needs (usually creating these on the fly with a projector and the stakeholders in the room, this way you get instant feedback, check for understanding, etc.) I can use the output from this process (in addition to more formal documented requirements) to help the project team understand what is required, and often I am able to provide visual representations of suggestions for how things might work at a high level (high-level ERD’s for database structure, an outline for documents, etc.)
Furthermore, eliciting quality requirements is an art form, and is best done by a specialist. There are many schools of thoughts on gathering requirements, but the point is that you want someone who really cares about good requirements to be doing it. Many of the project team members are simply too busy with their own work to put much focus on this. I wrote about how good requirements ARE SORTA NUTS earlier, if you want to check it out.
Developers everywhere are in terrible pain
- Requirements Management Please!
- Help Your People Escape Meeting Hell
- Project Change Management



Oct 1st, 2008 at 10:23 pm
I totally agree about a picture being worth a thousand words. In my mind, it makes things a lot easier to draw out a process or a relationship, for all parties involved.
I’ve noticed that it seems to be an exercise for most people to actually sit down and talk out how the requirements will perform within the system being developed. That’s where the good Analyst/PM comes in, as you allude to above.
I’ve linked to this article in my post on .
Reply
Oct 1st, 2008 at 10:29 pm
I’ve linked to this article in my post on reviewing requirements in two easy steps.
Reply
Jul 22nd, 2009 at 2:55 am
Simple, adopt agile methods, which incorporate self organizing teams. Just like that, no PM needed.
Now I am studying PM, but its only to make me a better member of modern agile self-organizing generalist teams.
Reply
Josh Nankivel Reply:
July 22nd, 2009 at 5:09 am
I wish you the best of luck Anon. Sounds like a nice dream.
I love agile (my particular experience is with scrum). In my opinion, if you do agile right, you are doing project management. A LOT of people get agile completely wrong, and unfortunately it sounds like you might be one of them.
Reply
Nov 16th, 2009 at 10:33 am
Got a real kick out of the clip … can identify somewhat with those folks! We’re in the midst of developing a PMIS and efforts to identify requirements, at a detailed level, so that our developer/programmer can know exactly what to do is like nailing warm jello to a wall.
We recently hired our a developer, after spending a ton of money on a consultant who, like the one mentioned in your film clip, spent all the budget and didn’t come close to completing the work. Lesson learned: ensure the consultant knows what all has to be done, and how you want it done … then ensure that there’s a fixed-price contract that spells out what will be done, and by when. Also identify the “punishment” if not completed on time and within budget.
Reply