Introduction
Every project manager faces the daily problem of dealing with the triple constraints of cost, time, and quality. Our success is usually measured in how well we manage our projects under these constraints. Since you are reading this paper in a Project Management Institute publication, I suspect you are well versed in the quantitative process of planning, measuring, and reacting to the events that impact your ability to deliver your project successfully.
You have formal project management tools and a process or methodology to help you with the process. You know what the expectations are.You know what the schedule is. You know what the budget is. Hopefully, you have the support of your management and your client to get the job done. Now, ask yourself these questions: How about the project team? Is it really a “team”? Do they know what our goals are? Do you have their support? Do they understand the process? Do they know what the expectations are?
As a project manager, you do not do the work. Your role is as a leader, facilitator, negotiator, mentor and manager. Your most important resource is your team. In this paper, we will discuss how a project manager builds a team by being both a manager and a leader.
We will look at building a group of individuals into a team. A team is a group of people working together toward a common, well-understood set of goals and objectives. Sounds like a simple definition, and it is, but it doesn't just happen by getting some people together and calling them a team. Everyone, but in particular, the Project Manager, has an important role in molding this group of individuals into a focused, coordinated, high performance team.
We will talk about what it takes to be successful. We will also talk about what kinds of problems and pitfalls you might encounter, in fact, you might create them for yourself; and what you can do to overcome them.
Remember, you need a team to deliver your project. It's up to you to make this successful. You are the one who will bear the blame, or receive the praise depending on how your project works out. Creating a strong team will help increase your chances for success.
My Own Experience
First, let me give you some background to put these ideas into context. About four years ago, I joined Digital Equipment Corporation (now Compaq Computer Corporation) to help manage the internal Year 2000 Program. In the fall of 1997, the program was in the early stages of operation, and our group was responsible for the assessment, remediation, and redeployment of all applications for the company in North America.
To accomplish this, Compaq had established a Y2K center in Massachusetts with a delivery staff of about 75 technical professionals collocated with Program Management Office. In addition to this Massachusetts-based team, we had a staff of about 100 software professionals and project managers offshore in India. These two groups needed to work together as a single team to ensure the successful delivery of about 700 assessed, and as required, modified and tested applications. These applications covered the full range of technologies from assembly language to COBOL to web-based tools. Though most were legacy COBOL systems.
Besides the core team of about 175 people, each application had a user or owner, known as a Shepherd, and perhaps, a production Information Management (IM) support person associated with it. Since it was impossible for the Y2K core team to know the details of every application we would work on, we would establish a virtual team for each application. This team included the Y2K core team, the user(s) of the application, and the IM support person(s). In some cases, the user side of the Y2K team was larger than the core team side.
Within the onshore Y2K core team, there were about 15 Project Managers (PM). All the PMs were quite senior with significant management experience and a wide variety of technical experience and language background. The rest of the onshore technical resources served in a variety of technical roles including:
• Assessment
• Remediation
• Testing
• Quality Assurance.
Typically, a PM might be managing from one very large to as many as five or more smaller projects at a time. Technical resources would see a similar distribution of work across several projects at a time and in several different roles.
Along with the applications being done onshore, the PMs had coordination responsibility for applications being done in India. The offshore team in India brought some real benefits to our program. Besides adding skilled resources to our team that would not be available to us locally, and their willingness to work many hours, because of the time differences involved, we basically had a 16-hour workday. However, taking advantage of this fact required some team building activity that we will discuss later.
A final note about team structure. The onshore team consisted of resources from a variety of sources:
• Compaq employees—the least number of people
• Contractors from a variety of partners
• India resources who would join us in Massachusetts for three to six months at a time then return to India.
What Are the Challenges?
These are fairly obvious, but let's lay them out:
• A large, geographically, distributed project team with about 175 people in two countries, separated by 10 time zones with some language issues.
• A very demanding project schedule, actually nearly 700 individual schedules, with a completion date that could not slip and high expectation around quarterly milestones.
• Extremely high expectations around quality. This had to work!
• Customers and users who did not always share our sense of urgency.
• An extremely strong job market that made employee retention challenging.
• Much of the work was not exactly cutting-edge technology. See the comment above, and double it.
• A corporate merger occurred during the project. This added confusion to project, along with additional applications, and resulted in even more than the usual uncertainty.
As you read through this list, you might be able to identify challenges that I have not included. Many of you have probably “been there before.” We all have our own war stories to tell, but I would like to use this project, and these challenges to talk with you about the importance of TEAM to the success of this, or any project.
How Can Your Team Help?
There are several things we need to remember as Project Managers. Sometimes, when we're working the numbers, and the schedule, and worrying about the dollars, we lose sight of several important facts:
• The PM does not do the project. The team does that. You get to take credit, or blame, depending on the results. Credit is always better.
• A strong, effective team will be more productive than a group of individual contributors all working on the same projects. And easier for you to manage.
• Success breeds success. As you do a good job building, managing, and leading your team, it becomes easier to do. Try to make it look easy. Never let them see you sweat.
• A strong team makes its own luck. Never underestimate the importance of small victories. Again, success breeds success.
• It is more fun to work on an effective team. We all know it's a job, but wouldn't you rather enjoy yourself?
• Think of your own future. A PM who builds, manages and leads a successful team will be offered the best projects and be able to recruit and retain the best people in the future.
Much of this sounds like basic Project Management 101, but when you are caught up in the day-to-day stress and pressures of the job, it's easy to lose sight of the people side of things. When we think about the constraints, and remember that constraints are just resources with limits attached, we have to deal with: cost, time, and quality, we should add one more—the team. These are the people we bring together, manage and lead. These are the people who do the work. As a PM, your project lives or dies with their successes and failures.
Let's look at some of the things we did to build and support our Y2K team and make our project a success. They may not all apply to you or your situation, but some of them will apply and you can keep the rest of them on file to help you in the future.
How Do We Build a Team?
As the overall PM, it's your responsibility to set the tone for your fledging team. Right from the start, you need to make it clear that you see this as more than just a group of people thrown together by chance. Set the standards and ground rules early and maintain them consistently.
Our situation brought some interesting and unusual issues to the fore and we needed to address them right from the beginning:
• I had 15 very senior, some with more experience than me, PMs working for me. Right from the start I made it clear that they had complete autonomy in their project areas. I was there to help facilitate the process for them. To protect them from the collocated PMO, and to make them successful.
• We had weekly, very focused status meetings. We had a firm agenda and we always started and finished on time.
• All PMs, whether Compaq employees, local contractors, or folks from India, were treated as equals.
• I showed my trust of my PMs by sharing information with them beyond what they needed to do their jobs and encouraged them to do the same with their staffs.
• As a side point, some of the PMs were from India, and tended to be less assertive than their American counterparts. I worked hard to get them to engage during discussions and status meetings and encouraged them to take risks to achieve success.
• We had about 100 team members half a world away in India. They were our resources, but they were there, not here. Simple things help:
• We rotated a number of India team members each quarter from to Massachusetts to help build the relationships in a one-on-one manner.
• We maintained several India team members here to act as a liaison to the folks back in India.
• We communicated regularly and often with our colleagues in India. Regular conference calls between on shore and off shore PMs were the norm. However, to build a more equal relationship, conference calls were usually scheduled by the on shore PMs to be at times convenient to the India team. After all, midnight here is 10:00 AM there. It's only fair!
• Of the 75 team members in Massachusetts as many as 20 to 30 were from India, mostly Hindu. We had a number of other ethnic groups represented as well, and saw this as an opportunity to share and build some community.
• At the urging of the some of our Indian team members, we became regular celebrants of Dwali and other holidays.
• No American holiday or Christian or Jewish, or Chinese celebration was off limits.
• Having trouble with American slang? Not to worry!
• Confused by the Registry of Motor Vehicles…well, so are we!
• I know it sounds overused, but by valuing the differences our team members brought to the table, we helped the team, and enriched our own experiences. It was good for us, and very good for the project.
• We had a very demanding, quarterly driven project schedule. Over 700 individual applications to deal with.
• As the overall PM for the project, I allowed my PM team the freedom to set their schedules within some very basic and broad constraints. Allow your team, as much as possible, control over their work. Let them sign up to the commitments and then help them be successful. A team works as a group toward the common goal by helping each other achieve individual goals
• Share success with team members. Pizza, or a day out at the Topsfield Fair is not that expensive. The Kosher Cook Out on the front lawn was a great event. Tee shirts that foster the common bond add value. Remembering that a lot of folks on the team were vegetarians was important.
• Celebrate the small successes and the large ones with the team, but don't forget the individuals. Find out what your people value and reward them with it. Money is not usually the first thing. A personal memo, a note,…always remember to say “Thank you.”
• How do you address expectations of high quality?
• Quality should be everyone's job. That includes you as the PM. Make it clear by making your Quality Manager, you have one on the team, don't you, a peer to your PMs.
• Make sure the team understands how important quality is. It can't be seen as an adversarial situation.
• A good team takes pride in its work. Quality is part of that pride.
• The relationship with your customers and users, and the way the PM deals with it, will help set the tone for the team.
• Sometimes, and this was the case with Y2K, your customer, the person you are trying to help, would rather be somewhere else doing something else.
• Be an advocate for your team. Smooth the way and ease the pain for the users.
• Try to make the users part of the team. At our regular end of quarter celebration, we always invited our application owners to participate, and many did. They were often as instrumental in our success as our core team, and they deserve to be recognized. By the way, the “word of mouth” factor in our very collaborative approach to these projects really helped us gain the support and participation of the user community. They're an important part of your team too.
• Some friction and issues will always arise. Some times, your team members will make a bad decision or an error in judgment. Be open to discussion, encourage open communications, identify the issues, admit mistakes and fix the problem, mentor and support the team member and move on. This is one of the things you're there for.
• Employee turnover on a multiyear project is always an issue. A strong job market, and not very exciting technology just exacerbates to the problem.
• You know, most of the time, people don't start looking for a new job because you're not pay them enough! More money is just a byproduct of changing jobs.
• If you've done a good job of team building, people will be less likely to want to leave.
• You like your job?
• They're paying you enough?
• They know you're doing great things?
• There's mutual respect on the team?
• Why would you want to leave?
• For us, the legacy technology issue was a problem for the Compaq employees on the project.What would they have to look forward to after this project was over? What skills would they have?
• We made and kept a commitment to each Compaq employee on the team. Training: Microsoft, Oracle, Novell, CRM, Seibel, PMI certification. If you want it and are willing to do the work, we'll give you the time and pay for the training. This was a very powerful tool in retention. If you get the training, we'll guarantee you a job in the Professional Services Organization when the Y2K project is over. Our turnover rate was very low.
• When you compare the cost of the training commitment to the cost of recruiting and training new team members, it's a good deal.
• Like much of the dot-com world, or the business world in general, change is a constant. During our Y2K project, Digital Equipment Corporation and Compaq Computer Corporation merged. Aside from that fact that this resulted in a large increase in work for the Y2K team, the initial effect was a great deal of uncertainty.
• The way to deal with uncertainty is communications. From the Y2K PMO, the project team management, to the team and to our clients. Communicate the changes, and address the fears and uncertainties. Hearing the news, good or bad, is better than not knowing.
• After all, you're team, and everyone deserves to know what's going on. As a PM you don't like surprises, neither does the team.
Wrap It Up
As a Project Manager, in addition to managing the quantitative aspects of your project, you also need to look at your most important resource, your people, and figure out how to make them a team. Here are some bullet points to summarize what we've discussed:
• You don't do it alone. Each person has a responsibility to make the teamwork, but the leadership comes from you.
• Respect and value the knowledge and experience of your teammates. They have good ideas, and if you let them, they'd love to help you. Remember, with everything else you have to do, you can use all the help you can get. You hired these people because you thought they were good, trust them and trust your own judgment.
• Respect and value the differences on your team. It will enrich your life, and make your team even more outstanding.
• Try to understand the personality of your team by understanding what motivates the individual members. Not everyone is the same. The rewards should be something they care about.
• Remember that your clients and users are team members too. “Stakeholders” is the word that comes to mind here, but in the team context we mean something a bit different. Get them involved; recognize their contributions to your joint success.
• Take pride in your work. This is what you do. When you take pride in the product, quality will follow. As the PM, you set the tone. Make sure you care everyday and share that enthusiasm with the team.
• When you make a commitment to the team keep it. You promised them training, keep your promise. If you can't keep the promise, and sometimes things do happen, then tell the people effected, and see what you can do about it.
• Communications, clear, regular, honest communications, is the solution to so many issues, that we shouldn't even have to think about it. As a PM, you never want to be surprised. Don't surprise your team.
• Try to enjoy yourself. I know it's a job, but if we can, we should be happy in our work.
If you look at these points, you'll see it's a lot like life. How do you maintain a good relationship with someone? Be open, honest, and respectful, earn and give trust, communicate. It works in life and it will work for your team. Most of us have the natural instincts to do these things. Trust your instincts. After all, you're a Project Manager. This is what you do. Enjoy it.
