Scheduling a meeting. Oh God!!!! Save me.

Now a day, scheduling a meeting is one of most burdensome task in software industry in India. If you planned a meeting at (let’s say) 10:00 AM, 80% of the attendees will come at 10:15 AM or 10:30 AM. And for some of them, you have to bodily go to their seat (or call them) to join.

To resolve this commitment or attitude and time wastage problem, I decided to arrive before the scheduled start time. I encouraged other participants to get there early. I worked to become a meeting leader; and, when I became a leader, I demanded that people appear on time.

A meeting that doesn’t include the following characteristics is not likely to help your project or your team move forward:

1. It starts on time.
2. It ends on time or early.
3. You can leave the meeting if you are not needed.
4. Action items come out of the meeting.
5. The meeting has an agenda and minutes.

So the first agenda for all my meetings became “Hang around for people who turn up late”. All the agenda items in my agenda have durations.

So this agenda item looks like following:

1. Wait for people who arrive late. 10 minutes

Now, after seeing this agenda, I think some definite reactions would be:

1. Some participants will say that the agenda item started the meeting out on a sour note
2. Some participants will think starting late is unacceptable and they wanted to do something about it.
3. And definitely no reactions from most of the participants. They think it is nothing, just a joke of the day.

Publishing the names of the late arrivers in the meeting minutes is also a great idea. But this will again create a knotty situation for the team.

I think if the people who participate in a meeting can't cooperate to start their meeting on time, what chance is there they will cooperate to start a project on time? The same people who participate in meeting are the same people who are responsible for the tasks in a project.

I believe that a person who is not planning his things in a better way can’t join the meeting on time. Most of the time, people plan their schedule but not planning their schedule.

Does starting meetings on time truly matter? I believe it does. I read it somewhere that “If people are the organs of an organization, then meetings are the organization's lifeblood. The more healthy a meeting, the more healthy the organization. And, conversely, the sicker the meetings, the sicker the organization.”

In one of my earlier organization that I worked, we always started meeting on time. There were hardly some late attendees in the meeting. But one thing that was going on there. We started meeting at right time but the meeting ends late. I mean if the meting timings were 10:00 AM to 11:30 AM, it will start at 10:00 AM sharp but ends at 12:15 PM or 12:30 PM. Now what is going on here? Lack of agenda and lack of reformation of the discussions. Actually, what was happening that after the official discussions in the meeting, the team was discussing something else and 80% of times, they were discussing cricket. That is also not a good deal. That is the reason that agenda and end time is also very important.

Profitably starting the meeting with all of the participants required the cooperation of all the participants. If we are not planning our meeting timely and in a proper way, we are just playing in this IT industry and befooling ourselves.

-- Sanat Sharma

Levels of Requirements

Recently I joined a new company. I switched from an US giant MNC to an Indian giant MNC. So everything was new and that is the reason I am publishing my new blog after a long break. I was busy with those shifting activities and other stuffs to make me comfortable. So, let's come to business.

I will start this blog with one of my latest encounter. This time not with the development team (as usual) but with my test team member. Some times back, I asked with one of my tester a very basic question. The question was - What are the documents that you required to start the testing or at least start writing test cases? The answer was - Requirement documents. Then I continue my questioning and asked further -which type of "Requirement documents". I got the answer - "Requirement Documents, Sanat. You don't know what a requirement document is". I keep smiling and said "There are three types of requirement documents - Business Requirements, User Requirements and Functional Requirements. What do you want?” No answer from my counterpart.

Now the key point is that in today's business environment, the requirements can be (or should be) divided into three parts or you can say three phases:

1. Business Requirements
2. User Requirements
3. Functional Requirements

Business Requirement: What is the business perspective of this requirement? This requirement can be a single line also. For example: There is an attendance system in an office where each and every employee has to enter in a register placed in the security. Now I want to automate this process or make it convenient for the employees. In that case, the business requirement would be "Need to automate the attendance process and make it convenient for the employees". This is a single line Business Requirement that is required in this scenario. This requirement can also be elaborated depends upon other matrices.

User Requirement: How the user will interact with the system or what are the user requirements as compared to the business requirement? As the example goes on. In User Requirement, the things that should be covered are - "How the employee will enter the attendance automatically? How the user will interact with the proposed system? What are the most convenient ways to exchange the interactions between user and the system?". And lots of other things also.

Functional Requirement: How the system will be made? What are the functions required to fulfill the user requirements? In this phase, everything related to the development of the Business requirement and user requirement is mentioned.

So to start doing testing, I think Business Requirements should be clear in your mind and based on User Requirements and Functional Requirements, testing can be started.

-- Sanat Sharma