Leading Projects: Balancing Rational with Emotion

A start-up or a fledgling organization relies on individual heroism of their people to successfully deliver projects. These team members are enthusiastic, engaged and willing to see the project succeed. They are emotionally connected to the purpose of project/organization. Emotion is the basis of how they operate.

Then the organization starts growing. To manage growth, processes are introduced. New tools are implemented and an org chart with hierarchy is established. Slowly, layers of processes and people are added and focus shifts to processes and practices. So far, so good. The problem is when focus shifts only on processes and practices. When rational takes over the emotion.

Processes and practices are absolutely important for an organization to grow, learn and sustain. But often, project managers focus too much on the planning, scheduling, managing risks and watching the metrics that they forget to focus on people. This results in disengagement (or in other words, dispassionate compliance) where people do the minimum required to get a task done.

Consider this: A study published by Harvard Business Review found that average overrun on IT projects is 27% and one out of six projects had overrun of over 200%. Another study revealed that IT failure rates results in loss of $50 billion to $150 billion to US economy alone.

The cost of an emotionally disengaged team to a project is huge. Organizations have thousands of hours of project management experience. Processes standards are getting better and more mature. Why then are projects still in a problem?

The possible answer, according to me is: we need to balance rational with emotion, process with empathy and practices with people. We need processes for sure, but we also need a strong culture of consistent engagement. We need a project charter for sure, but people also need a compelling vision to subscribe to. We need to understand the requirements of customer for sure, but we also need to understand the emotional needs of our team members. We need skills of our people to go up along as the bars in project progress chart go up. We need experience, but we also need to experiment. We need communication and we need engagement.

Every project we execute is a glorious opportunity to practice leadership, to make a difference in a customer’s business, to nurture the talents of our people. As a project manager, you can make that happen only when you focus on the emotional aspect as much as the rational one.

That, to me is what makes a great project manager and a team great!

– – – – –

Related reading at QAspire Blog:

Have a Process? Make It Visible

Many years back, when I ran a web development shop, I once visited a customer who owned a flooring tiles manufacturing unit. Since they were one of the leading players in their industry, I was curious to see how they worked. Our customer took us to visit their manufacturing plant where I could “see” a number of interlinked processes in action when a piece of tile moved from one stage of production to another. The product was tangible and most of these processes were executed by sophisticated machines.

Many years later, I started working on business process improvement for an IT company. Things were getting done here as well, but processes were not “visible”. I could not see how knowledge about the product got transferred from one step to the another in the development process. Processes were not documented and different people understood the process differently. Since process was not visible, it was difficult to see the gaps and improve, unless the gaps  were obvious and huge.

One of my key learning from this first experience was:  If you have a process, make it visible.

You may be a business leader who is working on improving your processes, a project manager who wants to improve team’s outcomes or an individual who is looking forward to improving personal process, making the process visible is important.

How do you do that? Here are the most basic steps (and the ones that many small or mid-sized organizations ignore):

First step is to document the process. It could be a formal process manual or a simple bulleted list of steps to be performed. In any case, keep the process steps simple.

Better yet, represent the process visually through diagrams. This is the best way to show a process in action.

Once you have visibility, you will be able to see the gaps more effectively and see what can be improved.

Finally, share the process understanding via trainings, one to one facilitation and via tools that make it easier for people to access the process.

Whether your work is blogging, writing, graphics designing or software programming, you invariably have a formula, a method and a few steps to get the work done. You can only improve upon your work when patterns of your work are visible to you.

– – – – –

Join in the conversation: What tools have you used to generate awareness (and visibility) of your processes? What process have you employed to ensure that your work patterns are visible to you?

Teaching, Improvement and Change: A Few Parallels

12 years back, I started my career as a tutor who taught Oracle and PL/SQL to students belonging to different age groups. One thing I realized very early in my career as a tutor is that everyone of us has a different rate of learning – the speed with which we grasp new things, accept changes and change our own thinking.

Another important realization was that however good the tutor is, students only learn when they actually practice the lessons and apply them in the real world.

So what does these lessons have to do with process improvement?  A lot!

In my view, implementing an organizational change is pretty much like teaching, because just like teaching, it changes people/teams/organization for better. It involves creating an impact on how other’s see their work. It involves implementing change. It involves communication and connection.

We make a big mistake when we expect everyone across the organization to accept change at an equal rate. People learn and adapt at a different rate and it is important to “facilitate” change than to “push” it. My first lesson in teaching still holds true.

Change involves lot of training and counseling, but real acceptance of any significant change only happens when people actually apply the new practices and experience the tangible benefits of the change. This also means that when people implement change in their day to day work, there will be a lot of realignment and fine tuning in the process itself. My second lesson from that brief teaching experience comes in handy here.

I also saw that students learn the best when they see relevance of the subject with the real life. Ditto with the improvements, because ultimately, people will only implement an improvement action when they are convinced with the purpose of improvement.

Bottom line: Teaching, process improvement and change initiatives – they all involve people. Knowing how people learn, change and adapt helps when implementing significant organizational changes/improvements.

– – – – –

Stay tuned to QAspire Blog: Subscribe via RSS or Email, Connect via Facebook or Follow us on Twitter.

The Best Time To Think About Processes…

… is when you are still small. That is when implementing process is easier and less risky. In the growth phase of the organization, business leaders get overly obsessed with growth (numbers, targets, team size etc.) without thinking how growth will be sustained (culture, processes, tools). The more you wait for your processes to be defined, the more damage it does. It is difficult (and costly) to implement process after you have attained a certain size – for two reasons:

  • Implementation takes more time, more training, more people, more friction and hence more costs.
  • Implementing processes is less about implementing robotic procedures and more about forming habits and changing the culture of the organization.

The bigger problem: In absence of processes, people will work according to their “personal” process (which is based on their past experiences).  What may be “right” for one person may be absolutely absurd for the another – because they see things through their own personalized lenses. This also happens when dealing with customers, managing people and approaching the work. There is a lot of disparity between performances of teams – and most of the time, performances of teams are governed by who is managing the team (and who all are a part of the team). Success is largely a result of individual heroism.

As a start-up business, you need to think about your processes when you are still small. When habits are still forming. When culture is still taking a shape. That is where, processes help you shape the culture and mindset of your core team. Thinking of processes while you are still small may sound little overwhelming for a moment – but if you take a long term view, the benefits are obvious. (Isn’t leadership all about taking a long term view?)

Bottom line: Have processes as an integral part of your business plan – even before you start up. If you want to build a sustainable and high-performance organization, you cannot ignore the power of processes. Processes help you build a culture on a long run.

Announcing my new book: #QUALITYtweet – 140 bite-sized ideas to deliver quality in every project

Writing a book (at least one in my lifetime) was my dream and I am glad to announce that my dream is finally coming true with my first book titled #QUALITYtweet – 140 bite-sized ideas to deliver quality in every project”.

QUALITYtweet_cover_l

This book is a compilation of 140 ideas on quality management. Each idea is in form of a tweet – no longer than 140 characters. Twitter’s popularity has proven that you can indeed say a lot in 140 characters.

The inspiration for this book came from Rajesh Setty – my mentor and a very good friend. This book is a part of Rajesh Setty’s #TH!NKtweet series. I cannot thank him enough for his generosity.

The basic premise of this book is that Quality is still a very heavy subject with lot of focus on models, frameworks and theories. With limited time to read, people want short and practical insights on how quality can be managed. This is a book you can read in less than 30 minutes. You can read it over and over again, because each tweet will prompt you to think.

The foreword of #QUALITYtweet is written by Dr. Pankaj Jalote who is an accomplished author, academician and a veteran in the field of Software Quality and Processes. You can read more about him here. Many thanks to him.

I also thank Lisa Haneberg, Skip Angel, Phil Gerbyshak and Michael Wade for their kind words of advance praise. They have been great teachers for me over past few years and they continue to enlighten me. Utpal Vaishnav is a cool friend who reviewed the book with lot of love and care. I thank all my peers at Gateway TechnoLabs who have been extremely supportive and encouraging. Readers of this blog have never failed to inspire me.

The book will hit the stands on 11/11/2009, my daughter’s third birthday! Stay tuned for more updates on #QUALITYtweet in the time to come.

Expectations and Processes

Most theories in Quality revolve around customer satisfaction. For each purchase customers make, they have a specific expectations. In process of purchase, these expectations keep changing. For organizations (specially software organizations), key is to know these expectations and deliver the product/service accordingly.

What if you do all the expectations management and client still does not like the product? It happens that your processes were executed really well and you think you delivered quality in line with client’s expectations. Still, the client would not like the product. Can we conclude that this was a problem with client’s expectations and not with your processes?

Read the story below and found it interesting: (Courtesy: Gantthead article “Building a Better Post Process“) –

Bob Mackie, a famous clothing designer known for his work for Cher, was once asked about the process he used for making her gowns, which each cost tens of thousands of dollars. The process went something like this:

  1. Meetings are held to discuss Cher’s expectations
  2. Conceptual drawings are made of Cher in the gown and redone until she approves
  3. A mock-up (fake gems, lower cost fabric) of the dress is made and modeled by a person matching Cher’s measurements; again redone until Cher approves.
  4. The actual dress is made and fitted to Cher; Job Done.

The interviewer asked Mackie, “What happens if Cher doesn’t like the dress after all that?” Mackie replied (and I am paraphrasing), “I guess she bought a dress she doesn’t like.”

The lesson here is that Mackie did extraordinary due diligence and vetted Cher’s expectations every step of the way, so if the outcome failed to please, at least he knew the issue was with Cher and not with the process or the competence of the designer. (One last note, Cher was rarely disappointed, nor her fans.)

Doesn’t this sound very familiar if you are working in software development?  Most of the times, if you manage expectations really well, you are leaving very few reasons for clients to get disappointed. But exceptions are always there – and there may still be a few who would not be happy. You have no choice then but to accept that client bought something they did not like.