On Team Speed and Work Paces

Projects often comprise of team members and managers who work differently. Diversity in work patterns of team sometimes brings out best and often the worst. For a car to move smoothly all four wheels have to rotate at the same speed. Same might not be fully applicable to software projects, but project teams have to work in fine synchrony to come out with expected results. This is what Jeff on hist post "Life at 33 RPM"  at Thinking Faster calls RPM or workpace.

" Every person has their natural "speed".  Some people are perfectionists and like to work slowly and carefully.  Some people just work slowly, period.  Some people work quickly and are on to the next thing.  It's rare to find a group of people or a team that has the same "RPM" mentality across the team.  This usually becomes a source of conflict, as the speedier ones look at the slower ones as dragging the team down, and the slower ones usually have an argument about completeness of the work and the quality of the work.

Managing others is completely about understanding how they view themselves, their work and their relationship with you.  Constantly hounding someone to work to your preferred RPM will only cause stress.  It will cause impatience to those who prefer to work more quickly, and will cause stress with those who prefer to work more slowly.  What you'll want to do is establish an expectation with each person and manage them accordingly.

Also, I think it's reasonable to set a "team speed".  This sets a single expectation for the quality and delivery times that the team as a whole needs to meet."

In addition to what Jeff says above, it is also very important for a manager to align himself to the “team speed”. Often if a manager thinks/moves fast, even the reasonably fast team will struggle to match up to a manager’s speed and the reverse may also be true. Hence, it is essential for team and manager to make progress at an agreed “team speed”. It even makes sense to involve customer (knowing their expectations) in deciding the team speed.

As Jeff rightly says, its critical for a manager to establish a common “team speed” and dictate the work paces.

Update 31 May, 2006 : On a lighter note, the quote I read on Michael Wade's Execupundit.com goes well with something I wrote above.

"Have you ever noticed? Anybody going slower than you is an idiot, and anyone going faster than you is a maniac.”

- George Carlin

Adaptable Requirements Management

"Adapting Your Requirements Practices" by Ellen Gottesdiener is the current article on Stickyminds.com. Requirements management is core to software development activity and requirements management approach differs from project to project.

Ellen says,

"Some amount of requirements growth and change is normal. The practice of "playing around" with a product is an excellent way to explore and learn about users' real needs. It also helps teams adapt to changing requirements. Using requirements models or partial working prototypes, customers can play with a product early on and help clarify their needs. This practice translates into defining requirements iteratively, whether your project is change or risk driven. "

My comment on Ellen's article as posted on Stickyminds.com

"With emergence of agile methodologies, increased competition and shrinked time to market, software products undergo a lot of changes during the development cycle and adaptive/lightweight requirements and design process go a long way in ensuring that stakeholders gain maximum business advantage by flexibly implementing the changes they require."

Opportunity in crisis

A few years back I was pulled into a huge and troubled documentation project. Since the project involved massive documentation effort and some Liasioning with government agencies and external consultants, no one was keen on taking up the work. Initially I was scared and confused on my abilities to work on such a huge documentation work but as I started understanding different pieces involved in the whole process, I thought I could make a difference and bring this project out of the troubled waters. It was a crisis for the organization and an opportunity for me to make a positive difference. Eventually, we as a team, were able to successfully progress in line with what client had expected.

Many a times, projects do run into crisis situation. Delays from client, unrealistic expectations, poor management, ineffective communication, poor scoping, flawed planning and many other aspects may be responsible for this. But in each crisis lies an opportunity to utilize your skills, manage the situation, communicate, plan, execute, control and finally perform.

There are two things people do when they encounter crisis.

Escape the situation: Team members try to escape the scene when there is a pressure situation on projects. Some may even start the blame game. Taking this path is easy, since it requires putting your hands off and getting away. There is no hard work involved in doing so. Managing people when they aspire to escape the situation is a greatest challenge that confronts a project manager.

Take control: Taking this decision is difficult. There is a pressure from client and the senior management to get things done and show some progress. People are bogged down by pressure and the fact that they are not able to make an active progress. Taking control requires courage, communication, managing expectations on all fronts, sometimes being stern in restricting unwanted noise from client, explaining the facts, getting into the roots of causes and taking corrective actions.

When you escape you are probably safeguarded from the pressures for the moment. But somewhere down the line, the same situation is going to confront you. You will again escape the situation and gradually “escapism” becomes a vice.

When you take control you seize an opportunity to prove your abilities, persist to show progress and make a positive contribution in saving the face of organization and at times, retaining the client.

Raising alarm bells

For members of test team, it is very important to raise the alarm bells at right instances. With right instances, I mean that test team should raise the alarm bells well in advance even if they have slightest of apprehension about the product quality and resolution of bugs therein.

Raising alarm bells is a very important technique for test team since they have a clear perspective of the overall product quality in terms of functional stability and correctness. While project manager’s perspective is largely governed by task orientation and execution, test team has the exact status on the overall quality status. This means, to an extent, test engineers are also risk analyzers. They strive to weed out majority of project risk by identifying most crucial and important bugs.

Raising alarm well in advance helps the project manager to manage client expectations. When client is sitting at the other end expecting a product to be shipped, it really does not make sense to raise an alarm the last moment. This paralyzes the project manager and leaves little time for him and client to manage the delays. Most often, clients become difficult to manage when product shipment is withheld at the last moment and a manageable situation turns into a crisis.

Fatal bugs in history of software

In an overly software dependent world, software quality has been more critical than ever before. Just came across an article in Baseline Magazine listing the "Eight Fatal Software-Related Accidents". Of them, the most devastating has been a software bug which hobbled a radar causing a Korean Jet crash killing 225 people in 1997.

On similar lines, I read an interesting article on Wired News entitled "History's Worst Software Bugs".

The article states,

"Sixty years later, computer bugs are still with us, and show no sign of going extinct. As the line between software and hardware blurs, coding errors are increasingly playing tricks on our daily lives. Bugs don't just inhabit our operating systems and applications — today they lurk within our cell phones and our pacemakers, our power plants and medical equipment. And now, in our cars."

While it is an accepted fact that a software can never be completely bug free, QA and test teams should atleast be able to ensure that the resultant bugs are not fatal to individuals and businesses. And thats where the real challenge lies.

On managers and workers..

Many think management is an easy job. Managers are perceived as people who just delegate, sit back and then monitor. The "real work" is usually done by the team members. Is that really so?

To know what it takes to be a manager, here is a very interesting post by Skip "Management's got it easy!" Skip throws light on importance of "workers" (team members) and "managers" (team leaders) in success of projects, teams and organizations. I like the analogy he presents between composition of a team and that of an orchestra. I agree to Skip that both managers and workers are essential for success.

He says..

"Therefore, the higher you move up into management, the more knowledge you must have, the better direction you must provide, the more coordination you must lead, and the more dependencies you must understand.  Though it takes knowledge and skill for each individual to do their part, it requires management to understand everybody's part.   As for me personally, I found that both the duties and responsibility that came with being a programmer were much less demanding and less overall thinking than it has required of management.   You can't play any composition without an orchestra, but you can play a lousy composition if the orchestra doesn't have good management.  Both are essential for success!

Looking back to my early days, I made the wrong assumption, the ol' adage "Out of sight, out of mind". I assumed that because I didn't see what my manager was doing I assumed he was doing nothing at all.  Instead, what I didn't realize is that I was able to do the work I had because he was doing those things "behind the curtain" to make sure that I could continue working.  He was also making sure that I had what I needed from others and that they had what I was providing."

Thanks Skip, for providing useful insights.

Are your people motivated?

Motivated team members can create wonders for the project. How can a manager, within his reach, keep his team members motivated?

Project Management Digest has an excellent post on "The basic way to motivate". It says, that project managers should focus on three basic goals for providing motivation.

The Three Key Goals:

Equity: – employees usually want to be respected and to be treated fairly in areas like pay, benefits, and job security

Achievement – employees want to be proud of their jobs, accomplishments, as well as their employer.

Camaraderie – employees usually desires to have a good and productive relationship with their co-employees

So how do you, as manager evoke basic motivation on the points above? Another post on Project Management Digest shows you a way out.

Quality of Project Communication

One of the most important traits that a project manager need is effective communication skills. Project managers do a lot of communication with the stakeholders, end users, project team members, senior management, peers, HR people and quality personnel. Sometimes, projects that overcome most of the other technical and engineering challenges run into trouble just because of ineffective communication either with team or with the stakeholders. Good communication acts as a lubricant to smoothen the processes and sometimes as catalyst that just facilitates project activities.

Effective Project Communication should :

- be transparent and accurate
- be complete (covers all information to avoid surprises later)
- be bi-directional (a lot of PM's do a unidirectional communication)
- manage expectations (of client and from team on deliveries, timelines, costs etc.)
- be simple and formal
- be focused
- be specific, linear and logical (to ensure easy understanding and common perception of what is written/said)
- proactively manage risks (things that will impact project)
- share insights and experiences
- be receptive to ideas
- build trust through positivity
- pay attention to people issues
- focus on solutions
- provide accurate status of project from time to time

Technical projects will have issues and poor project communication creates more of them. Proactive communication helps project managers to execute smoothly, manage expectations and hence deliver on time, as agreed, with less uncertainty and without any surprises.

As a project manager, how much attention do you pay to the "quality" of project communication?

On Constructive Criticism

One of the most important traits of a good manager is the ability to criticize constructively. Criticism keeps us all on edge and helps us to perform better. 

I had a manager who never allowed me to be content with what I did. Even when I thought I did a great job he would always come up with a few opinions (criticism is nothing but an opinion) of how if could have been better. As usual, I did not like it most of the times. But when I reflected on the reasons behind his criticism I realized that he criticizes because he does not want me to be content. Complacency sets in when one is content. Being constantly criticized (of course, constructively) helps us perform better. 

"In Project Management, Criticism is Inevitable" is what Stephen says on his blog Project Steps. He says, 

"Keep an open mind when being criticized. Don't let the criticism control you or change what you think about yourself. Ask yourself, can I learn anything from the criticism? Can I change anything? Should I change? 

I don't take criticism well, and I tend to discount those people around me that criticize others too much. I need to take my own advice and learn to be more accepting of criticism, especially when it is constructive"

Skip suggests PINE model for providing constructive criticism.  

In project management constructive criticism is a very important technique to keep the team on edge and hence come out with their best. The key to work with the team member suggesting better ways of doing the same thing to ensure that criticism results in better outcomes.