I've been thinking a lot about project requirements lately, both because I've been working on them and reading about them. Requirements are what you want your product to do, and the more time you can spend identifying the requirements, the more successful your project will be.

Here at the Interactive Services side of Horn Group, we're working on fine-tuning our processes so that we can develop web applications and other creative projects within scope, budget and at the highest level of quality and customer and project team satisfaction. I don't consider myself a process fanatic, but over time I've seen the value of specific process at the appropriate time. The process of gathering, defining and solidifying requirements in the beginning of a project is a critical to the success throughout. It's easier for project teams to rush into development assuming that there's no time to gather and define requirements and that a rough idea of what needs to be done is enough. It's only further along that the team and stakeholders realize maybe things should be done differently, and then it's that much harder to go back and undo what’s already in place.

I like using this chart below to demonstrate the importance of defining and clarifying requirements early and often, to ensure that all project stakeholders understand exactly what is being delivered. This chart shows the costs of repairing defects at different stages of the project. I like to use a wide interpretation of defect to include a programming error, an error in design when specifications don’t match original requirements, and also a customer-created defect when that customer doesn’t fully understand or accept what the product is and decides to change course mid-project. A defect can be introduced just as easily in the beginning of the project as it can at the end, and the slope shows how much work is involved in fixing those defects later rather than earlier.

 
[ Image courtesy of Construx Software Development Best Practices ]

A gardening analogy: Seems unnecessary to map out the backyard and plot where the plants will go, since in your head you know exactly where you want things. So, you start digging holes and putting plants in the ground. After everything is in, you realize that you don't like the layout. To move plants around now will require pulling everything up, digging new holes and filling the unwanted ones. If only you had evaluated after making the holes and before putting plants in the ground, you could have saved the step of pulling everything out. Even better, if you had spent the time charting out the area before any holes were dug, how much easier would it have been to change things then!

When you take the time early on to figure out exactly what you want, and make sure to review that list regularly throughout your project, you can avoid the unpleasant task of going back and undoing and redoing, whether that's digging holes or designing and developing a web application.

TrackBack

Comments