-
When IT Is Your Company’s “Piggy Bank”
February 10, 2012
-
4 Key Things a Project Manager Must Do
February 10, 2012
-
Essential Project Management
February 10, 2012
-
8 Traits of Top Project Managers - Part 1
February 9, 2012
-
Agile Project Management - Engaging Your Customer!
February 9, 2012
-
9 Tips to Avoid Traps in Project Planning
February 9, 2012
-
Why Projects Succeed - Executive Sponsorship
February 8, 2012
-
On Customer Participation in Agile Projects
February 8, 2012
-
A Project Charter for Lazy Teams
February 8, 2012
-
The Power of Process: How Bad Project Management Kills Great Ideas
February 7, 2012
On Gathering the Right Project Requirements
September 25, 2009 | Author: PM Hut | Filed under: Requirements Management
On Gathering the Right Project Requirements
By Alora C. Chistiakoff
In order to gather good project requirements, it is important to separate out the “what” question from the “how” question. Confused? Here’s an example:
- Bad requirement: Provide a drop-down list of choices.
- Good requirement: Provide the user the ability to select from pre-determined options.
Why not just go with the first choice? Because telling someone to just use “a drop-down” list is dictating both design and functionality. And if you are providing your functional requirements to a provider – who is presumably an expert – then part of what you are asking for is to create the best, and more technically appropriate solution possible.
Now, we could spend weeks going round and round on the different type of requirements: business requirements, functional requirements, non-functional requirements, user requirements, etc. There are plenty of good analysis breakdowns online for what constitutes which one, who uses which type and why. But the key thing for a good Project Manager to know is which type of requirements are appropriate for the type of project and the audience — because, I promise you, a non-technical business client isn’t going to know the answer to that themselves. Part of what they are paying you for is expertise on what they need to be providing. In this case, we are dealing with a non-technical client for the purposes of finding them a technical vendor to deliver a solution that will meet the needs of their new business. So, in effect — and my apologies to the purists out there — what we were looking for was a combination of business requirements and functional requirements.
In a world of increasingly vital cross-platform applications (iPhone apps, Blackberry apps, etc.) and new UI-driven technologies (Flex/AIR, Ruby on Rails, etc.) this distinction becomes increasingly vital, because different technologies handle these issues natively in different ways. And while a drop-down menu may just be a drop-down menu, there are other design elements that can inadvertently limit your technology if you aren’t clear on the line between the “what” and the “how.”
Another thing to keep in mind is that — again, in a world of prolific cross-platform application development — wherever possible, you’re going to want to get the most bang for your buck out of requirements documents. This means that, while today you may only be building a website, next month you could need to recycle that requirements documentation out to an iPhone developer to build you an app for that platform.
The design logistics of different platforms are inherently different. Unless you want to have to re-write everything to be platform-specific, cut out the “how” all together and keep the requirements platform agnostic so that you can send them to any vendor for any platform built on any technology.
As a project manager or business analyst the goal is to capture the business’ need in a way that gives a web team the ability to provide the critical functionality with the least amount of unnecessary restriction. The biggest danger in that role is to unintentionally impose potentially costly restrictions without realizing it. By including the “how” instead of just the “what” in your requirements, you are potentially limiting solution options — dictating that X needs to be placed over here, or that the page needs to be subdivided a certain way may not be the best or more logical way for a particular technology to work. As a result, you could be giving your potential solution providers a mixed message. Worse yet, it can be a mixed message that hurts the project.
Alora C. Chistiakoff has spent a decade managing projects, leading change initiatives, developing teams and implementing technology solutions in startup and entrepreneurial environments in the Bay Area, NYC and now Austin, TX. She blogs regularly on business, leadership and career management at The Pragmatic Contextualist.
Related Articles
- Successfully Interviewing Your Project Customer and Gathering Project Requirements - Part I - Introduction
- Successfully Interviewing Your Project Customer and Gathering Project Requirements - Part VIII - Asking the Questions
- Successfully Interviewing Your Project Customer and Gathering Project Requirements - Part V - Requirements Interview Process
- Successfully Interviewing Your Project Customer and Gathering Project Requirements - Part IV - Customer Interview Funnel
- Successfully Interviewing Your Project Customer and Gathering Project Requirements - Part X - Model of Interview Questions
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
2 people have left comments
You are absolutely right, the way you ask a question definitely impacts the answer you will get. To take an example in another field, sales, here is an example that could add some light to it. If you work in retail and a customer comes up to the counter with an item to pay for and you the salesperson asks, “Is there anything else?” you’ve give the customer all but two choices, a closed ended “No”, or a semi-closed ended ” Yes, but…”, which often does not lead to more sales. If you ask the customer, “What else can I get for you today?” you’ve now opened up their way of thinking to a positive light, thus taking the “No” out of the question, even just for a moment and makes them think a bit more.
Approaching projects is much the same way, and you’re right, it’s very easy to add cost to any job without going in with the right questions to get the requirements you truly need to complete it or by making the requirements too specific to a given foreseen solution that might not be the best one.
[...] to succeed, when they need it, and for the right budget. Your project is bound to fail no matter how well requirements are gathered if you don’t have a good process for managing change. A good process will be effective in [...]