REQUIREMENTS MOTHERFUCKER, DO YOU GATHER THEM?

Before your hands even touch a keyboard, a repo or a database, the first thing any project manager/developer/designer needs to do is to get good requirements. You have to sit down with the user/client/ and talk over with them what they want the application to do. I wish I could just ask them

What do you need the system to do?

Who will be using it?

How will you be using it?

What are some use cases?

Though as must people would know, this is impossible and doesn't work the first time. It is very hard to assign blame to either party for the disconnect during this part. The user/client doesn't/can't know exactly what they want since requirements change and the developer/managers have to be semi-flexible in their approach.

Software and IT development is NOT a simple process. Although many people see it as such, there are many variables to take into consideration and problems will happen. Each party needs to understand this.

There are a few things you can do to hopefully mitigate this problem.

Sit down with user/client and go through use-cases
You need to sit down with the user/client and go through use-cases of the project. I'm not talking about a simple statement 'of what do you need it to do', I'm talking about walking everyone through everything a normal user using the product or system. This helps each party figure out the details for each action throughout the system. Actually going through using a product helps everyone understand how it is used. It also makes it easier to figure out who the stakeholders are in the project.

Have regular meetings Figure out a time each week to sit down and just talk about how the project is going. This helps stop last minute changes and allows everyone to be on the same page throughout the whole project.

Draft up a development contract Anytime you are dealing with services or a product, you should draft up a contract that specifies certain things for each party. Rules, timetables, and accepted practice should all be figured out so that there is no misunderstanding later in the process. This helps protects both parties from the other incase something comes up. Contracts also help define a set course and guidelines for how the project is going to be managed. These items can easily save anyone time and money.

Be realistic with each other Sometimes, either party can get a little ahead of themselves. The client can want way too much with not enough time or resources and the developer can promise a lot and be in over their heads. If you have realistic expectations, then this can help solve a lot of confusion and headaches down the road.

Those are just a quick overview of some aspects of requirements and contracts. I'm going to be making a separate post for each of them later.

Anyone in project management or developing or anyone that deals with clients will appreciate the following clip. It definitely helps illustrate what each party can go through if they don't understand each other. (Or are just unrealistic)