One of the biggest problems you’ll run into with IT projects is something called scope creep. Scope creep is when the client changes their mind about the project or figures out that something is missing from the project after it’s already started. You’ll find lots of books on how to curtail scope creep, but the fundamental idea is to get clear on what the customer really wants before you begin the development process. So how do you do this?
First, you need to have an in-depth conversation or two with your client – or as many as it takes to get clear on what he or she wants. Spend enough time with them to talk about how the system will be used, what it will be used for, who will use it, the interfaces to and from this system and what it will produce. You’ll need to structure you thinking around these topics and then expand the discussion around each topic until you have series of testable statements (requirements) that reflect what the client wants.
There are a couple of good websites you can review to see how to move through this process. The first is the Software Engineering Institute website (www.sei.cmu.edu, search on “requirements”). Here you’ll find papers and processes describing the software development process and specifically the software requirement s gathering process. You can also find some good information on www.wikipedia under the topic of “requirements analysis”.
You might be interested to know that the Project Management Institute’s ANSI standard, the Project Management Body of Knowledge (PMBOK® Guide), 4th edition, has completed its pre-publishing review process. I had a chance to review it and there is a new process called “gather requirements”. The entire project management industry has come to recognize the importance of product requirements in the success of all projects, not just software related projects.
The Leader in Network Knowledge
Requirements - not again?
First thing I learned 35+ years ago and it's still new? Seriously - I think that we have a cycle here, seen that 4 times since then. Requirements get attention, then some vendor comes out with a "wonder tool or toy", companies think that it solves all their problems and start lacking in requirements and analysis until.. Or there comes a "new" requirements method, book, acronym, etc.. which is "supposed" to cover everything. And the cycle starts from beginning.
I have done some full projects, and when I say full, it means everything from site locations to customer acceptance tests and support over years, for banks, insurance, governments, manufacturing, etc. Every time the requirements collection and analyze was done "right" the projects were smooth as silk and ended everyone being happy - a lot of work, sitting with (internal/external) customer management, end-users, lawyers, unions, HR, accounting, telco, city, county etc representatives, own PMs and development managers and groups, software houses, sw/hw vendors, blah, blah.. and creating detailed AND signed requirements, not just some RFPs/SOWs witch often are more wistful thinking than facts. But worth of it - every time one phase was skipped, it has come back biting us and/or customer, sometimes very badly.
Probably many reasons why this happens but some I have noticed are people getting promoted to more responsibilities but can't grow / can't learn. The attitudes - not my/our problem, egos - this is my job but I don't have time for it and can't give it to someone else, inexperience - I'm specialist and there is nothing important outside of my specialty, greed - trying something when there just isn't enough resources, or the old, old problem which has killed many projects and even companies - we are the best and don't have to adapt to changing world, technology, economy, business, etc.
Yes - books, methods, courses, etc help to start but then it is up to people. No checklist or method can ever cover even the majority of the requirements collection and analyzing, they just change too much all the time. It is like saying that PCI, SOX, whatever solves all security problems or that Java, .NET, whatever solves all development problems or .. - dream on.