I’ve said this time and time again. Requirements are the lifeblood of the project. Bad requirements = an extremely risk situation wrought with conflicts, change orders, disputes, customer dissatisfaction, budget overruns and missed deadlines. Good, detailed requirements = far less risk, much greater chance for project success, fewer change orders because the project scope is well defined, and a much happier project client.
That project client often comes to the table with an idea of what the project requirements are or should be. But make no mistake, only the foolish project manager takes whatever requirements the customer hands over and starts to build a solution around them. The smart project manager considers these to be a start and builds time into the project schedule to dig deeper – to ask the tough questions to determine the real project, the real need and the real, detailed requirements for the engagement. That’s the first step for the project team on the road to project success…find out what the real requirements are. And take the right amount of time to get there.
Customers Often Lack Proper Requirements
As I said, the customer usually comes to the table with some requirements in hand…they may even believe these are detailed enough to hit the ground running. The problem with requirements is that, as we all know, they are ever changing. Trying to keep a customer from changing their requirements during an engagement is like trying to my 15 yr old daughter not to send text messages. And trying to get the customer to document good, solid, detailed requirements prior to the engagement starting is like…well…impossible.
The customer ‘expects’ you to help them extract the necessary requirements. It’s happened to all of us, right. The customer is paying the price for the project so they naturally think they can go into the engagement with just some high-level requirements drawn up by a few SMEs and the rest will just get extracted during Exploration.
What Good Requirements Can Do for a Project
That’s fine – and that is often how it goes. However, what the customer seems to always be unaware of is that by going into an engagement with well-documented, detailed requirements they can usually accomplish the following:
These are just a few of the benefits…I know there are more. The bottom-line is that the requirements drive the project. Poor or non-existent requirements mean an extended project, budget overruns, and missed milestones. Solid requirements mean a much greater chance for on time and on budget delivery of a solution the customer wants and needs and ultimately greater customer satisfaction. Of course there are no guarantees…and an Agile approach that allows for requirements to shift and for the project to react can help mitigate the overall impact to the project.
Summary
Many things help drive project success, but requirements are that extremely critical piece to the project puzzle that usually is the biggest ingredient to project success. If you head into a project with few or poor requirements, it may be worth the pain and suffering to suggest that the customer go away and draw up more detailed requirements before engaging your team. I’ve done it before – though usually I get the most success and agreement on that approach with internal customers.
External customers are rarely willing to put anything on hold. They want action…now. For them, if you don’t have sufficient dollars in the budget and hours/days in the timeline now to plan for the real requirements, you’ll have to start the arduous process of initiating change orders to ‘make’ the time to extract good, detailed requirements. Without the right level of requirements – without the project scope properly defined – there is little chance for you to deliver an end solution that the customer’s end users will be able to use…and that = project failure.
That project client often comes to the table with an idea of what the project requirements are or should be. But make no mistake, only the foolish project manager takes whatever requirements the customer hands over and starts to build a solution around them. The smart project manager considers these to be a start and builds time into the project schedule to dig deeper – to ask the tough questions to determine the real project, the real need and the real, detailed requirements for the engagement. That’s the first step for the project team on the road to project success…find out what the real requirements are. And take the right amount of time to get there.
Customers Often Lack Proper Requirements
As I said, the customer usually comes to the table with some requirements in hand…they may even believe these are detailed enough to hit the ground running. The problem with requirements is that, as we all know, they are ever changing. Trying to keep a customer from changing their requirements during an engagement is like trying to my 15 yr old daughter not to send text messages. And trying to get the customer to document good, solid, detailed requirements prior to the engagement starting is like…well…impossible.
The customer ‘expects’ you to help them extract the necessary requirements. It’s happened to all of us, right. The customer is paying the price for the project so they naturally think they can go into the engagement with just some high-level requirements drawn up by a few SMEs and the rest will just get extracted during Exploration.
What Good Requirements Can Do for a Project
That’s fine – and that is often how it goes. However, what the customer seems to always be unaware of is that by going into an engagement with well-documented, detailed requirements they can usually accomplish the following:
- Significantly reduce or eliminate the need for change orders, thus reducing the overall cost of the project
- Reduced change orders means reduced timeframe for the project meaning it is more likely to be delivered on time without extending the schedule to accommodate changes
- Test cases can be written earlier in the process due to requirements that are not moving around – meaning better test cases and better prep for UAT
- Better end product – if requirements are well understood early on and are not a moving target, it is easier for the delivery team to deploy the solution that the customer really wants which also means less post-deployment work and likely less cost to the customer
These are just a few of the benefits…I know there are more. The bottom-line is that the requirements drive the project. Poor or non-existent requirements mean an extended project, budget overruns, and missed milestones. Solid requirements mean a much greater chance for on time and on budget delivery of a solution the customer wants and needs and ultimately greater customer satisfaction. Of course there are no guarantees…and an Agile approach that allows for requirements to shift and for the project to react can help mitigate the overall impact to the project.
Summary
Many things help drive project success, but requirements are that extremely critical piece to the project puzzle that usually is the biggest ingredient to project success. If you head into a project with few or poor requirements, it may be worth the pain and suffering to suggest that the customer go away and draw up more detailed requirements before engaging your team. I’ve done it before – though usually I get the most success and agreement on that approach with internal customers.
External customers are rarely willing to put anything on hold. They want action…now. For them, if you don’t have sufficient dollars in the budget and hours/days in the timeline now to plan for the real requirements, you’ll have to start the arduous process of initiating change orders to ‘make’ the time to extract good, detailed requirements. Without the right level of requirements – without the project scope properly defined – there is little chance for you to deliver an end solution that the customer’s end users will be able to use…and that = project failure.
RSS Feed
