Monday, May 20, 2013

Meetings are for making decisions not for hangouts

Author: Rajesh Patil (PMI-ACP, CSM, CSPO, MS in Engineering Management and Leadership)
LinkedIn: www.linkedin.com/pmrajpatil
Email: pmrajpatil@gmail.com


Meetings kill Projects
Meetings kill Time
Meetings kill Budget
Meetings kill People (Not literally)
Meetings kill Companies

If not planned well and if they have no clear purposes, meetings are over-kill.

According to me, meetings are for making decisions and decisions only, they are not for educating, discussing or solving problems.

In one of the organization I consulted before, meetings were burning cash and the project was going no-where.

  • Teams from multiple remote locations are jumping on a call one after other just because their calender asked them.
  • Every meeting is attended by 40 participants and has no prior clue on what's discussed in these meetings.
  • Every participant is multitasking , browsing emails,  chatting, socializing and in-between raising unrelated concerns just to show involvement.
  • Participants are not looking for commitments but involvement so they have their name on the project and they feel engaged.
  • Decisions are never made but a decision for another meeting is made after every meeting.
  • All employees were busy, super engaged and had no capacity left to do real work because they have to attend meetings.
  • Productivity was at the lowest and confusion with lack on knowledge about any project was all time high.

Looking at this situation,  my job was to stop this madness and change the way meetings are attended and organized.

To address this problem, I implemented two rules that were immediately effective:

1. All meeting attendees will complete a three questionnaire survey before attending any meeting

-  Do you understand the purpose of this meeting? yes, no
-  Do you agree with the agenda of this meeting? yes, no
-  Can you help solve/improve the discussed problem? yes, no


If the attendee answers "no" for any one question, then its advised to not attend the meeting because he/she  will be wasting his/her and others time

Normally, people who answer "no" are the trouble makers and they constantly put roadblocks to decision making; as mentioned before meetings are for making decision and its better to remove all roadblocks.

2. All organizers should maintain a "Meeting Cost Chart" by calculating an average cost of every meeting they organize, just to make sure that the meeting is really needed and is worth the time and money spend.

This will make the organizer think twice before he/she invites attendees and he/she will understand the value of the meeting.

By just introducing these two simple rules, the company started to see a outstanding positive shift in productivity and big cut-back on unnecessary meetings.

Some of the positive changes in the organization were:
 
- Employee Engagement
- Knowledgeable Staff
- Cost Savings
- Increased Productivity
- Less Gossips
- More Focus
- Quicker Decisions
- Products Faster to Market
- Less Stress

Next time when you attend or organize a meeting, try this and see how a simple changes can make huge positive impact on you.

Disclaimer: My blog is my personal opinion and not connected to my employer or employees. Everything I write is wholly my personal experience and opinion that's not been validated or certified by anybody.
If you have concerns or questions regarding this article, please contact Rajesh Patil at pmrajpatil@gmail.com

A non-Agile train headed towards an unknown destination

Author: Rajesh Patil (PMI-ACP, CSM, CSPO, MS in Engineering Management and Leadership)
LinkedIn: www.linkedin.com/pmrajpatil
Email: pmrajpatil@gmail.com



After 5 months in a project the whole team and the project manager are gathering in a room at 8:00 AM on a Monday morning to kick-start their re-alignment session for the next 8 hours.

Does it sound painful or familiar?

I am sitting in the same room as an Agile leader to surface the problems and help the executive team understand why I think the project is in RED.

All participants were nervous and eager to know who will be blamed for loosing track and what will happen next. I started the discussion with a short story to set the tone.

"We are a tour company and we just announced an awesome destination , excited tourists board the train and the journey begins. Before the train catches its speed, two concerns are raised:

1. Technicians discovered that the train engine has some mayor glitches that might lead to a train wreck
2. Tour guides discovered that the planned destination is not a real tourist place

While the technicians and tour guides are raising these concerns, the train driver has no clue and is headed towards disaster.

It's our job to halt the train and put our heads together to decide whether we fix the problem and continue our journey or board the tourist on a different train or just announce the failed journey early in the game.

After my small story a "blame game" begins, blame it on "no communication", "no collaboration", "no process", "no skills", "no control", "no command","no detailed project plan", " no ownership" but the traditional teams would not think on why the project is in this situation and how could we have prevented being here. The traditional teams next action was to replace "yes" to all "no's" listed above.


As a Agile leader I just wished we were using Agile from the beginning. Agile is not a silver bullet for every problem, but the basic principles of Agile are built to prevent this type of situation.

My strong belief in Agile principles and methodologies forced me out of this project originally, since the believers of traditional project management had taken over the control of this project.

I am not comparing one project management method with another and not saying which one is better,  instead I am saying that we have to make smart choices. If a project has many unknowns it's a perfect candidate for using Agile methodology.

The concept of showing a progress of a project with a working software is very powerful, it does not give any opportunities to assumptions and imaginations on the progress of the projects; it will sow the status in black and white to all stakeholders, true status of the project will be revealed in just 2 weeks.

User stories, story points, and burn down charts will show scope and risks early in the project.

Daily standup's will clear all confusions everyday instead of waiting for a meeting next week.

Continuous Risk Management method in Agile reduces long-term risks and increases confidence in the project as we progress.

In today's constantly changing environment traditional way of doing things does not do a great job because of  long cycles and its command and controlled style. Problems are hidden until they become too big to handle.

After all my "Agile talk" and 4 successful projects, the team took a step back and discussed to add more processes in-place as a solution to solve the problem and hopped back on the same train which I feel is headed towards disaster.

Agile adoption is difficult until the organization believes in it and executives fully supports it, otherwise an Agile teams are always seen as a no-process, no-documentation, and a chaotic team; but in reality it's opposite.
Agile teams are self-organized, well-documented wherever needed, and follows a strict process that's monitored very closely on a daily basis.

My quest to bring Agile in every organization continues by educating and exploring other ways of bringing visibility to the proven concept of Agile in a traditional organization.



Disclaimer: My blog is my personal opinion and not connected to my employer or employees. Everything I write is wholly my personal experience and opinion that's not been validated or certified by anybody.
If you have concerns or questions regarding this article, please contact Rajesh Patil at pmrajpatil@gmail.com