How to improve project requirement understanding skills (1 Viewer)

[SachAccess]

Hi Experts,

Need your help on this topic. How do I improve my project requirement understanding skills.
Since this is a public platform, I will write it other way round.
I have observed that I have seen people who understand the exact requirement in less time than me.
If those guys are taking 2X time to understand, I might take 3X for more than 2X.

What type of questions should I ask.
Typically how many meetings we should have to understand the project, am aware this depends on the project.
But is it a good habit to draw the conclusion in one meeting only. Is there any rulebook, agenda to be followed for the meetings.
Sometimes, it might happen, the person explaining you requirement, does not reveal all the problem areas.
Or hides few challenging scenarios and this comes up during UAT and involves re-work.
How to avoid this, that is why the question, What type of questions should I ask.
Can we have a meeting with different POC at different time, simply to validate the information or will it be seen as trust issue.
How much to rely on BRD (SOP), it happens that the actual flow and flow mentioned in the document is different.
There are less number of steps mentioned in the document, how do proceed with such scenario.
Should we demand the correct document before starting any work.
This questions might look silly or too basic for you. But answers from you will be very helpful for me.
Please help if you get time.

 

[CJ_London]

suspect you are talking about project management. There are a number of techniques out there. They basically create rules/schedules as to how the project should progress.

'Agile' is a common one - here is a link

What is Agile? | Atlassian

Learn agile software development, agile methodologies and industry best practices from beginner tutorials to advanced topics.

www.atlassian.com

A technique I often use is what are called 'user stories' which can form the basis of the specification for the project which your client can then sign off as meeting the requirements of the user stories.

User stories are a number of short statements from everyone who will be impacted by the final application e,g,

'as a director I want to be able to see a summary of all transactions on one page'
'as a director I want to be able to see the summary on my smart phone''
'as a data inputter I want to be able to select a customer from a dropdown list'
'as a data inputter I want to be able to create a new customer on the same form as the dropdown list'
'as data manager...
'as a sales person......
'as a sales manager......
etc

can be as many or as few statements as required.

Sometimes to get this going you need to provide some examples for each user to amend or add new ones.

You should not start development until the specification is agreed and signed off - although you might put together some example forms/reports to give users some idea of look and feel. Thing to avoid is users who say 'I know what I want, I cant explain it but I'll know it when I see it'

 

[Minty]

As CJ has stated although it sounds odd to start at the end, it's often best to start with what each user expects out of a system initially, as that will drive what you are required to store and then the methods to get that data into the system in a rational fashion.

Where you can really come a cropper if you aren't very diligent, is legacy data that a client might want to be imported into your shiny new system. Unless you are careful you can end up cleansing their old data for them, or having to perform a lot of data manipulation to get it to fit a nice normalised structure.

 

[SachAccess]

suspect you are talking about project management. There are a number of techniques out there. They basically create rules/schedules as to how the project should progress.

'Agile' is a common one - here is a link

What is Agile? | Atlassian

Learn agile software development, agile methodologies and industry best practices from beginner tutorials to advanced topics.

www.atlassian.com

A technique I often use is what are called 'user stories' which can form the basis of the specification for the project which your client can then sign off as meeting the requirements of the user stories.

User stories are a number of short statements from everyone who will be impacted by the final application e,g,

'as a director I want to be able to see a summary of all transactions on one page'
'as a director I want to be able to see the summary on my smart phone''
'as a data inputter I want to be able to select a customer from a dropdown list'
'as a data inputter I want to be able to create a new customer on the same form as the dropdown list'
'as data manager...
'as a sales person......
'as a sales manager......
etc

can be as many or as few statements as required.

Sometimes to get this going you need to provide some examples for each user to amend or add new ones.

You should not start development until the specification is agreed and signed off - although you might put together some example forms/reports to give users some idea of look and feel. Thing to avoid is users who say 'I know what I want, I cant explain it but I'll know it when I see it'

Thanks for the help.
'Thing to avoid is users who say 'I know what I want, I cant explain it but I'll know it when I see it'
You are spot on.

'although you might put together some example forms/reports to give users some idea of look and feel.'
Good idea. Will keep this in mind. This will certainly help. Have a nice day ahead.

 

[SachAccess]

As CJ has stated although it sounds odd to start at the end, it's often best to start with what each user expects out of a system initially, as that will drive what you are required to store and then the methods to get that data into the system in a rational fashion.

Where you can really come a cropper if you aren't very diligent, is legacy data that a client might want to be imported into your shiny new system. Unless you are careful you can end up cleansing their old data for them, or having to perform a lot of data manipulation to get it to fit a nice normalised structure.

Thanks for the help. I agree. Have a nice day ahead.

 

[jdraw]

Further to the good info you have received, there are some free, humorous "knowledge-nuggets" videos from BA_Experts that convey key concepts and approaches. All are related to gathering and using business facts. I recommend you watch a few --they are short.

 

[SachAccess]

Further to the good info you have received, there are some free, humorous "knowledge-nuggets" videos from BA_Experts that convey key concepts and approaches. All are related to gathering and using business facts. I recommend you watch a few --they are short.

Thanks for the help. Will surely watch, have a nice day ahead.

 

[sonic8]

'Agile' is a common one - here is a link
[...]
You should not start development until the specification is agreed and signed off - [...]

This statement, particularly the words "specification" and "signed-off", is the definition of Anti-Agile!

Agreed, you need a definition of requirements and it should be written down. However, this is not a (technical) specification!

Thing to avoid is users who say 'I know what I want, I cant explain it but I'll know it when I see it'

If users say that, ask questions!
Examples:

• What data should be displayed in that form?
• How should it be displayed? As a list/data sheet? A single record? A hierarchy (tree)?
• Which controls do you want to edit during the process?
• What data do these controls contain?
• What is mandatory for a record to be valid?
• What should happen after data entry is complete?

In essence, you need to gather all the information you need to build a form/report/whatever.

There will be areas, where the user genuinely cannot give you a definitive answer right away. In the context of the above example-questions, these will be things like "Checkbox or OptionGroup?", "ListBox or ComboBox?", "Single-line or multi-line Textbox", but these should be rather small compared to the overall task at hand.

In bigger projects, you need enough information to get started, but the details deferred to a later point in time can be quite substantial, like entire processes not defined in any detail yet. You need to iterate and refine the requirements until these things become clearer for you and the user.

 

[SachAccess]

T

This statement, particularly the words "specification" and "signed-off", is the definition of Anti-Agile!

Agreed, you need a definition of requirements and it should be written down. However, this is not a (technical) specification!


If users say that, ask questions!
Examples:

• What data should be displayed in that form?
• How should it be displayed? As a list/data sheet? A single record? A hierarchy (tree)?
• Which controls do you want to edit during the process?
• What data do these controls contain?
• What is mandatory for a record to be valid?
• What should happen after data entry is complete?

In essence, you need to gather all the information you need to build a form/report/whatever.

There will be areas, where the user genuinely cannot give you a definitive answer right away. In the context of the above example-questions, these will be things like "Checkbox or OptionGroup?", "ListBox or ComboBox?", "Single-line or multi-line Textbox", but these should be rather small compared to the overall task at hand.

In bigger projects, you need enough information to get started, but the details deferred to a later point in time can be quite substantial, like entire processes not defined in any detail yet. You need to iterate and refine the requirements until these things become clearer for you and the user.

Thanks a lot for the help. Have a nice day ahead.

 

[gemma-the-husky]

Personally I think it makes a great difference if you really understand the business, as well or better than the people hiring you.

 

[The_Doc_Man]

The way I was brought up through the world of software engineering, you had to break it down into phases. It was the Divide-and-Conquer approach so ably explained by Julius Caesar when he chronicled the Gallic Wars.

First, what is the goal (or goal set)? I.e. what is the project going to do? What will you make? What will you hope to accomplish. Without a well-defined set of goals, you can NEVER identify success. This is inherently non-technical but you absolutely cannot get technical without it.

Second, what will it take to reach the goal or goals? What kind of program or activity will further the progress towards these goals? You CANNOT leave this step until you have defined a path from the starting point to achieving the goals. You CAN selectively begin this step if you have multiple non-intertwined goals. I.e. Divide and conquer can start even in this phase. Agility cannot begin until you at least start this step and identify those opportunities to show agility.

Third, once you have the broad-brush approach, start breaking down that approach into achievable steps. This IS an iterative process if the steps in question are complex. Here is where Divide-and-Conquer REALLY needs to be understood and observed.

Fourth, once you have the achievable steps identified, start work. Note: This CAN overlap the third step if the process is complex enough and yet some of the steps aren't that complex. In essence, you can start implementation (#4) as soon as you have implementable steps (#3). I.e. if there is an individual step that condones agility, it goes here, too.

Fifth, quality control has to fit in there somewhere, because individual tasks in step 4 aren't finished until each one works, and step 4 overall is not finished until it all works together.

Sixth, and depending on the goals, you should be documenting as you go, to help remember the steps you worked on, the decisions you made, and the factors of WHY you made that choice, since we all know that in the software world, there is no such thing as a complete product that is still in use. If it is a "live" product, it WILL eventually need a version 2.0 and someone will need to understand what was in version 1.0 in order to upgrade.

 

[Pat Hartman]

Sometimes, it might happen, the person explaining you requirement, does not reveal all the problem areas.

They don't always know or they don't know the importance of what they are skimming over. You need to understand the warning signs. "we never have more than 3 items on any order". Don't let that trick you into making a schema design mistake. You still need an Order header and order details. Later you could ask if you want the user to be given a warning if he adds a fourth item or just accept it?

The others have given you good ideas on how to question users. You start at a very high level. If you have some personal experience in the working world and have paid attention to what goes on around you, you will have a basic idea of what an order entry system is or a general ledger, etc. When I was hiring people, I always preferred people who had worked for a few years and then gone to a technical school. The technical school was more likely to have teachers who were moonlighting by teaching evening classes so the student was more likely to get real world experience than the average college student who learns in a perfect bubble but ends up with no usable experience.

The most important skill a project manager has is the ability to listen and filter out what is important and then drill down with rational questions. Depending on the scope of the project, you could spend weeks gathering information. If there is an existing application, you need to review it. Look at the tables and the outputs and ask about what it does that they like and what it is missing.

 

[The_Doc_Man]

Pat used a very important phrase that is the heart and soul of "Divide and Conquer" strategies. You must "Drill Down" to the core of the problem if you are to have any hope of solving it.

 

[gemma-the-husky]

Going on from what I said about you knowing the business, there is a corollary. Don't really listen to what the users say they want.
They will suggest what they think they want, coloured by the way they use their existing system (in the way that @Pat Hartman and @The_Doc_Man mentioned above). As well as not understanding or appreciating how a new improved system can improve their experience, they will also forget to mention things that THEY take for granted, so when the system built to their specification doesn't do something it should, you get "we assumed you knew that".

So, in my opinion, start with the data. Analyse the data. Get a normalised table structure to represent the data, and then the program structure will flow naturally from the data.

 

[Pat Hartman]

I had a very embarrassing situation a few years ago regarding assumptions. I was building an application for a client whose business was painting lines on roads and in parking lots. The application managed the paint and sparkles inventory as well as calculating the amount of paint used each day so we could use the miles traveled to determine if the paint was laid thickly enough. Anyway, when the trucks came back every day, someone had to measure the paint use. My assumption was that they were recording the paint remaining but they were actually recording the paint used. So all of my calculations were backwards. It was easy enough to fix because all the calculations were localized so it wasn't hard to find what needed to be changed. But the mistake was embarrassing. I should have realized that they would use the same method that is used to measure oil. It's been 20 years since I've had to check my oil (my car tells me when it is low or needs changing) and I forgot that the dipstick showed how many quarts you were down NOT how many were in the tank.

 

[Thales750]

What everyone else said, plus

I start with a web chart of the decision maker's goals . That's easy enough, they mostly only want the same thing. The entire knowledge of the worlds in a single page.

Then it's on to work flow.
What is your job?
How do you get it done?
What's the most broken part with how you have to do it now.
How would you do it differently?

Make a chart and have them confirm it, maybe get their boss to make a chart as well. you can usually get a better 3D perspective that way, binocular vision and all.

Then, if that department agrees, you have something to do. Some design requirements take months, some minutes.

 

[SachAccess]

What everyone else said, plus

I start with a web chart of the decision maker's goals . That's easy enough, they mostly only want the same thing. The entire knowledge of the worlds in a single page.

Then it's on to work flow.
What is your job?
How do you get it done?
What's the most broken part with how you have to do it now.
How would you do it differently?

Make a chart and have them confirm it, maybe get their boss to make a chart as well. you can usually get a better 3D perspective that way, binocular vision and all.

Then, if that department agrees, you have something to do. Some design requirements take months, some minutes.

'Some design requirements take months, some minutes.' Absolutely agree on this.
Thanks for the help. Have a nice day ahead.

 

[SachAccess]

I had a very embarrassing situation a few years ago regarding assumptions. I was building an application for a client whose business was painting lines on roads and in parking lots. The application managed the paint and sparkles inventory as well as calculating the amount of paint used each day so we could use the miles traveled to determine if the paint was laid thickly enough. Anyway, when the trucks came back every day, someone had to measure the paint use. My assumption was that they were recording the paint remaining but they were actually recording the paint used. So all of my calculations were backwards. It was easy enough to fix because all the calculations were localized so it wasn't hard to find what needed to be changed. But the mistake was embarrassing. I should have realized that they would use the same method that is used to measure oil. It's been 20 years since I've had to check my oil (my car tells me when it is low or needs changing) and I forgot that the dipstick showed how many quarts you were down NOT how many were in the tank.

' forgot that the dipstick showed how many quarts you were down NOT how many were in the tank'
Must confess, I too never thought from this angle.

 

[SachAccess]

Going on from what I said about you knowing the business, there is a corollary. Don't really listen to what the users say they want.
They will suggest what they think they want, coloured by the way they use their existing system (in the way that @Pat Hartman and @The_Doc_Man mentioned above). As well as not understanding or appreciating how a new improved system can improve their experience, they will also forget to mention things that THEY take for granted, so when the system built to their specification doesn't do something it should, you get "we assumed you knew that".

So, in my opinion, start with the data. Analyse the data. Get a normalised table structure to represent the data, and then the program structure will flow naturally from the data.

'They will suggest what they think they want' agree with you. Thanks for the help. Have a nice day ahead.

 

[SachAccess]

The way I was brought up through the world of software engineering, you had to break it down into phases. It was the Divide-and-Conquer approach so ably explained by Julius Caesar when he chronicled the Gallic Wars.

First, what is the goal (or goal set)? I.e. what is the project going to do? What will you make? What will you hope to accomplish. Without a well-defined set of goals, you can NEVER identify success. This is inherently non-technical but you absolutely cannot get technical without it.

Second, what will it take to reach the goal or goals? What kind of program or activity will further the progress towards these goals? You CANNOT leave this step until you have defined a path from the starting point to achieving the goals. You CAN selectively begin this step if you have multiple non-intertwined goals. I.e. Divide and conquer can start even in this phase. Agility cannot begin until you at least start this step and identify those opportunities to show agility.

Third, once you have the broad-brush approach, start breaking down that approach into achievable steps. This IS an iterative process if the steps in question are complex. Here is where Divide-and-Conquer REALLY needs to be understood and observed.

Fourth, once you have the achievable steps identified, start work. Note: This CAN overlap the third step if the process is complex enough and yet some of the steps aren't that complex. In essence, you can start implementation (#4) as soon as you have implementable steps (#3). I.e. if there is an individual step that condones agility, it goes here, too.

Fifth, quality control has to fit in there somewhere, because individual tasks in step 4 aren't finished until each one works, and step 4 overall is not finished until it all works together.

Sixth, and depending on the goals, you should be documenting as you go, to help remember the steps you worked on, the decisions you made, and the factors of WHY you made that choice, since we all know that in the software world, there is no such thing as a complete product that is still in use. If it is a "live" product, it WILL eventually need a version 2.0 and someone will need to understand what was in version 1.0 in order to upgrade.

Fabulous!