Comments on: What Are Requirements? http://pmstudent.com/what-are-requirements/ Helping new and aspiring project managers reach their career goals! Thu, 18 Mar 2010 04:40:22 +0000 http://wordpress.org/ hourly 1 By: TheJudge http://pmstudent.com/what-are-requirements/#comment-11391 TheJudge Wed, 22 Jul 2009 21:27:16 +0000 http://pmstudent.com/?p=3045#comment-11391 Requirements gathering should be a collaborative effort. Granted I've only worked in IT projects but the ones that worked well the requirements were good as a result of back and forth communication. Excuse me business owner, what do you mean by X or Y? Do you possibly mean Z? Could we get clarification on A? Stuff like that. I know it sounds basic and I guess it is but so important. Though unfortunate the talk of blame is real in every situation. Sure the business owner may take the brunt of the blame but the IT department can also take credibility hits when the fit hits the shan. Teamwork, communication, clarity. Good things. Requirements gathering should be a collaborative effort. Granted I’ve only worked in IT projects but the ones that worked well the requirements were good as a result of back and forth communication. Excuse me business owner, what do you mean by X or Y? Do you possibly mean Z? Could we get clarification on A? Stuff like that. I know it sounds basic and I guess it is but so important.

Though unfortunate the talk of blame is real in every situation. Sure the business owner may take the brunt of the blame but the IT department can also take credibility hits when the fit hits the shan. Teamwork, communication, clarity. Good things.

]]> By: ejly http://pmstudent.com/what-are-requirements/#comment-11183 ejly Tue, 14 Jul 2009 18:59:41 +0000 http://pmstudent.com/?p=3045#comment-11183 A necessary precursor to requirements gathering (of whatever sort) is clarifying the objective. A solid objective makes project success much more likely, and requirements naturally flow from it. Engaging in requirements specification without a stated objective is more often associated with failure - and too often in the rush to show project progress via GANTT, this objective-making step gets paid too little heed. A necessary precursor to requirements gathering (of whatever sort) is clarifying the objective. A solid objective makes project success much more likely, and requirements naturally flow from it. Engaging in requirements specification without a stated objective is more often associated with failure – and too often in the rush to show project progress via GANTT, this objective-making step gets paid too little heed.

]]> By: Glen B. Alleman http://pmstudent.com/what-are-requirements/#comment-11180 Glen B. Alleman Tue, 14 Jul 2009 15:25:20 +0000 http://pmstudent.com/?p=3045#comment-11180 Sarah, To answer your question - "who gets blamed" - needs to look at the organization of the Project. In successful IT and other complex programs, the management team must be structured in for success. The Book Project Delivery System: Fourth Edition, http://www.amazon.com/Project-Delivery-System-CH2M-Mangers/dp/0965261611/ref=sr_1_2?ie=UTF8&s=books&qid=1247584942&sr=8-2 provides good insight into how to make the connection between all the participants in a project. Without these connections the only person(s) to blame are the business owners. It was their money and they didn't organize the project correctly. The same answer (the business is to blame) would be for a "store opening failure," a merge and acquisition failure, a new product line failure. The notion that IT projects are somehow different from store openings, M&A's, new product launches is the core source of failure. Sarah,
To answer your question – “who gets blamed” – needs to look at the organization of the Project.

In successful IT and other complex programs, the management team must be structured in for success.

The Book Project Delivery System: Fourth Edition, http://www.amazon.com/Project-Delivery-System-CH2M-Mangers/dp/0965261611/ref=sr_1_2?ie=UTF8&s=books&qid=1247584942&sr=8-2

provides good insight into how to make the connection between all the participants in a project.

Without these connections the only person(s) to blame are the business owners. It was their money and they didn’t organize the project correctly. The same answer (the business is to blame) would be for a “store opening failure,” a merge and acquisition failure, a new product line failure.

The notion that IT projects are somehow different from store openings, M&A’s, new product launches is the core source of failure.

]]> By: Sarah Runge http://pmstudent.com/what-are-requirements/#comment-11110 Sarah Runge Thu, 09 Jul 2009 17:59:07 +0000 http://pmstudent.com/?p=3045#comment-11110 And this would be why there are so many failed IT Projects? When convoluted and technical terms are introducee into a requirements document, the business people glaze over and relinquish ownership to a technical person to write the requirements document. Consequently the specification document is technically sound but lacks business requirements. I have rarely seen a project fail because the tecnical specifications were inaccurate. I have however, seen many projects fail due to poor business and user requirements (specified by the wrong people), inaccurate success metrics (performance metrics)and poor choice of Vendor selection. Business specifications or requirements are exactly that - business and user requirements and should be specificied ONLY by those pertinent people/parties. Not by a self appointed person that believes that he/she knows what the business and users require. Project specificiations or technical requirements are specified by the technical team, systems architect etc and detail technically what is required for the system to work and how. Question. Who gets the blame when the system doesn't deliver what the business thought it was going to deliver? Answer? Not the right person/people/party. Not the business person/people that should have specified their requirements. Perhaps the Project Manager, techie or Vendor? Why? Kind regards Sarah And this would be why there are so many failed IT Projects?

When convoluted and technical terms are introducee into a requirements document, the business people glaze over and relinquish ownership to a technical person to write the requirements document. Consequently the specification document is technically sound but lacks business requirements.

I have rarely seen a project fail because the tecnical specifications were inaccurate. I have however, seen many projects fail due to poor business and user requirements (specified by the wrong people), inaccurate success metrics (performance metrics)and poor choice of Vendor selection.

Business specifications or requirements are exactly that – business and user requirements and should be specificied ONLY by those pertinent people/parties. Not by a self appointed person that believes that he/she knows what the business and users require.
Project specificiations or technical requirements are specified by the technical team, systems architect etc and detail technically what is required for the system to work and how.

Question. Who gets the blame when the system doesn’t deliver what the business thought it was going to deliver?
Answer? Not the right person/people/party. Not the business person/people that should have specified their requirements. Perhaps the Project Manager, techie or Vendor? Why?

Kind regards
Sarah

]]> By: Glen B. Alleman http://pmstudent.com/what-are-requirements/#comment-11109 Glen B. Alleman Thu, 09 Jul 2009 16:58:26 +0000 http://pmstudent.com/?p=3045#comment-11109 Josh, IEEE 1220-1994 is a good starting point for requirements. I'd suggest that the requirements elicitation paper at SEI is another "must read." http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html These approach seperate the business domain - construction, IT, defense - from the principles of requirements management. That way we can move away from anecdotal approached and get to the foundations of the problems with requirements. Here's a quicj post with some more resources. http://herdingcats.typepad.com/my_weblog/2009/07/baseline-magazine-it-project-survey.html Requirememts engineering is some domains is a profession - conducted by Systems Engineers. In other domains it's an afterthought. And many example in between. Most project failures - according to the research in all domains can be attributed to requirements failures in some way. This is pretty much universally agreed. So now what? How can this situation be improved. In our domain, the requirements elicitation is moved to the Systems Engineering discipline. Josh,
IEEE 1220-1994 is a good starting point for requirements.
I’d suggest that the requirements elicitation paper at SEI is another “must read.”
http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html

These approach seperate the business domain – construction, IT, defense – from the principles of requirements management. That way we can move away from anecdotal approached and get to the foundations of the problems with requirements.

Here’s a quicj post with some more resources.
http://herdingcats.typepad.com/my_weblog/2009/07/baseline-magazine-it-project-survey.html

Requirememts engineering is some domains is a profession – conducted by Systems Engineers. In other domains it’s an afterthought. And many example in between.

Most project failures – according to the research in all domains can be attributed to requirements failures in some way. This is pretty much universally agreed.

So now what? How can this situation be improved. In our domain, the requirements elicitation is moved to the Systems Engineering discipline.

]]>