There can be no project without a customer. That customer can be internal, external, your boss, yourself. But there is always a customer…someone the project is being run for – someone is ultimately the end user of the solution that the project implements.

 

 

 

 

Customers Often Lack Proper Requirements

 

 

 

 

And with the customer comes requirements. If there were no requirements, there simply could be no project. 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 keep my 15 yr old daughter from sending 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 critical. 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 rarely are willing to put anything on hold. For those customers, you must get out the change order pad and start documenting and estimating. They need to know up front – as soon in the engagement as possible – what it’s going to cost them to have your team extract the detailed requirements for them if that wasn’t priced/estimated as part of the project.