Telerik blogs

The importance of requirements

Requirements are the lifeblood of the project.  I need to establish first and foremost. Good, detailed requirements will carry the project team through to the end of a successful project more times than not.  And that’s a good thing because more projects actually fail than succeed.  However, weak or incomplete requirements will not – resulting in countless hours of rework, scope creep that can drive any project manager crazy trying to manage and maintain control over, and the potential for many change orders that will upset the most satisfied project customer quickly making them wish they had never brought their project needs to you in the first place. 

Yes, requirements – good or bad – can definitely make or break the project. And it’s up to the project manager and delivery team to really make that call as to when requirements are in the proper order and detail so that the project can move on to the next phases of design and development. Starting too fast – before the requirements are ready – can be disastrous.

Testing – a major hurdle for the customer

Likewise, testing – the periodic testing throughout the engagement and the final user acceptance testing by the customer which, in most cases provides the final acceptance of the final solution just prior to deployment – is also critical to the project.  Properly prepared for and carried out, it can run the solution through its paces and ensure that the constructed product or solution meets the functionality that the customer and their end users want and need and are expecting.  If poorly prepared for, the customer may end up signing off on a solution that, when deployed to the masses, misses the mark and becomes a little used, expensive dinosaur for the customer to look at and maintain and remember a bad project experience with your team and your organization.  And the finger will be pointed at you even though that testing preparation and follow through was really their responsibility.

Ensuring that the testing is done right

What happens in between?  How do we get from good, detailed requirements to a successful user acceptance test that ensures the customer is signing off on a solution that works for them and that they will be able to use and be happy with in the long term? Well, the delivery team could do the test prep for the customer – but that would be a conflict of interests, wouldn’t it?  The problem is, most customers are ill-prepared to really test out a solution.  Most don’t know how to do it, how to prepare test cases and test scenarios, and lack the dedicated personnel to have them sit down for a week or however long it takes to run the solution through it’s paces and make sure it is truly what they are expecting and needing.

The key is to construct the testing so that it is verifying that the solution matches those nice, detailed, complete requirements that you and the customer meticulously documented early in the project.  If you can do that, then you know you’ve won – you know you have a solution that is ready for deployment.  But you must resist the temptation to do the testing for the client or to create all of the test cases and scenarios for them. 

What you can do

While you can’t do your client’s testing for them, you can build the proper time and project tasks into the schedule prior to testing to work with and train the customer on how to create those – and actually dedicate project staff to walking them through the activity of writing those test cases and scenarios.  In the end, you didn’t create them for the customer, but with your help you’ll ensure that they are in the proper detail to truly test the system out to the point that they’ll know it’s done and they’ll be able to acknowledge whether or not it’s ready for deployment.  I’ve actually had to assign my team to assist with test prep for the customer and to walk them through the user acceptance testing process on more than 90% of the projects I’ve managed.  It’s not uncommon, but make sure you’ve planned for it and it’s budgeted into the project or you’ll be spending free hours taking your customer through this tasks to make sure it’s done correctly….and completely.

Brad Egeland
About the Author

Brad Egeland

A Business Solution Designer and IT/PM consultant and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. Brad is married, a father of 9, and living in sunny Las Vegas, NV.


Comments are disabled in preview mode.