Rotating leadership successfully
1 project, 2½ years, and 8 different project managers
Most leadership teams feel they need to make a fundamental choice between being a people-oriented organization or a process-oriented organization. Both philosophies bring their own benefits and challenges into play as the organization works to achieve its mission. However, there is another way. My experience is that one can build consistent, straightforward processes that facilitate and encourage people to work collaboratively to solve problems, thereby gaining the best of both worlds.
This paper describes a two and a half year, 48,000+ hour software development endeavor at Menlo Innovations that was led by a series of eight different project managers. As each project manager joined the team, they brought their own strengths, capabilities and working style, but effectively engaged their team and their sponsor by working within a simple, consistent process.
“Orchid” – a project code name created to protect the anonymity of the client – was a project to develop a piece of software to control a medical instrument. The sponsor's goal was to build commercial software that delighted users, and could be extended incrementally as the market opportunities and capital investment allowed.
To align with this goal it was necessary to change the size of the team several times throughout the lifetime of the project. As project effort increased and decreased so did the project management effort, at times resulting in a part-time project manager while other periods required two full-time project managers. Exhibit 1 demonstrates the number of FTE project managers as compared to the number of FTE developers, business analysts, and quality assurance personnel.
Figure 1 Team FTE versus PM FTE
Changing Project Managers
For a variety of unforeseeable reasons – health concerns, a change of career, etc. – several project managers rolled off during the project effort. At times this was transitioned smoothly with one project manager overlapping with another, while at others there was no overlap at all between project managers. See Exhibit 2.
Figure 2 Length of Project Management Tenure on the Project
When the key project sponsor was interviewed for this paper, she was certainly aware that the project had several different project managers. But she was surprised to find out that it had been eight. As she pondered this fact, she concluded that the standardized processes made the transitions between project managers easier. Likewise, these same standardized, but simple processes encouraged the business sponsors to actively participate in the project and, thereby, provide continuity of business purpose. In other words, the processes encourage the participation of different key stakeholders in the project management process, instead of seeking a heroic project manager who can do it all by him/herself.
It's easy to see how a project like this could suffer from changes between project managers’ communications styles, and management strategies. This brings to mind two questions: 1) What processes were enforced by the organization, and 2) How similar were these project managers? First, I'll discuss the processes.
When one thinks of the characteristics of organizational processes, typically many “bad” words come to mind: rigidity, “red tape,” bureaucracy, boring, resistant to change, etc. But that need not necessarily be so. There are also many “good” characteristics of process – standardization, repeatable results, communication facilitation, etc. – that are most vital both to creating processes that work and creating processes that innovate.
It was the “good” characteristics of Menlo's standard processes that enabled project managers to follow the procedures while working with a new team. The key was a variety of people-centric processes that enabled the team to pass on its collective knowledge to the new project managers. This is particularly important because Menlo does not use its project information electronically, rather much of it is in the format of artifacts delivered to the client, story cards (i.e. work packages), and unit tests. The result is that much of the information about the project is contained in the heads of the individual team members.
So what were the processes that worked to keep the Orchid project on track while each new project manager joined the team?
- Open and Collaborative Environment –The concept of collocation and an open work environment where the team works together is an idea advocated by Kent Beck in his book Extreme Programming Explained: Embrace Change(2005). In this work setting the team works closely together in an open space. This is similar to the concept of a “war room,” except Menlo has chosen to have its teams work in this environment full time.
Example: The workspace at Menlo is wide open. (See Exhibit 3.) There are no private offices, no cubicles, and no walls except those that hold up the roof. Teams work together in “pods” – a series of tables arranged so that everyone working on the project, including the project manager, is in close proximity.
Figure 3 The Menlo Software Factory™
- Meetings – There are two types of meetings at Menlo, a daily standup and ad hoc “Hey Ted!” meetings. The daily standup is a major source of information exchange as everyone in the company attends. (See Exhibit 4.) A “Hey Ted!” meeting is an ad hoc meeting called between two people (e.g. “Hey Ted!”) or a person and a team (e.g. “Hey Orchid!”)
Example: A new project manager wanted to call a meeting with the team. He walked over to the team and told them he wanted to meet with them. They looked at him expectantly and waited for him to start talking. He finally asked them when they were available and got the answer, “Now. Later. Whenever you like. Just call ‘Hey Orchid!’”
Figure 4 The Daily Standup Meeting (typically lasts 15 minutes or less)
- Estimation – Every week every new story card is estimated and every unfinished story card gets re-estimated. This session is typically led by the project manager with all team members participating. When the project manager happened to be out of the office when this should occur, another project manager or a member of the team stepped in and ran the session.
Example: The Orchid project ran for a duration of 129 weeks. Of those weeks, 110 were active development cycles. (The project was temporarily suspended several times at the sponsor's request throughout the project to account for the remaining 19 weeks.) For every active cycle, the team gathered to estimate all of the new and unfinished story cards. Each estimation session lasted approximately 1-2 hours.
- Show & Tell – Every week the project sponsor visited to review the work that has been completed during the previous week.
Example: The Orchid project sponsor works offsite in another set of offices. She or a member of her team visited the Menlo office once per week for Show & Tell. During Show & Tell each of the team members showed the work they had finished during the week, such as adding a new feature or designing a new interface. The project manager typically acted as a master of ceremony for the team. This was an opportunity for the project sponsor to verify that the team was progressing down the path she has chosen and to offer feedback about the work completed to date.
- Planning Game – Every week the key project sponsors visit to choose the story cards that will be completed during the next development cycle. Every unfinished story card is evaluated.
Example: Each week the project manager laid out copies of all unfinished story cards. The project sponsor chose the story cards that were in and out of scope and laid them in priority order.
How did standardized processes help? How did these required processes help the organization and project managers successfully transition and/or collaborate? By establishing a series of rituals and ceremonies around the activities of the project, there is a formalized pattern that even an uninitiated project manager can follow. See Exhibit 5.
Figure 5 The Project Management Life Cycle at Menlo
The team helps the project managers be successful because they are all focused on the same end result. In addition to the organizational processes, there are cultural aspects of the Menlo work environment that also contribute to their success:
- Standardized Training – Everyone on the team receives standardized training when they join Menlo for a project. This training is required not only of Menlo staff, but also of their clients. During this class everyone – clients included – learns how their role fits into the overall methodology that Menlo uses to produce software. This standardized training ensures that everyone working at Menlo understands not only their role, but the roles of others on the team as well, and how the roles relate to each other.
- Common Vision – There is an openness in the Menlo environment where any person is free to talk to anyone else, and where the focus is on the results of the team instead of the individual. Because of this the Project Manager is free to ask questions when s/he is unsure of an answer without risking a loss of face.
Example: When a project manager first joined the project, she had trouble asserting herself with the project team. One day the team finally told her, “You need to yell at us when we aren't doing what you told us to do!” This was not a personal attack; the goal was for both the team and the project manager to operate at a higher level. The team felt secure giving her this feedback and she was able to accept it and assert herself more firmly with the team.
- Team Member Adoption – Menlo has an unusual method of interviewing new people to join its team. Rather than hiring being a top-down decision, the team itself participates in the hiring decision. Because they are choosing the people who join their team, there is a greater desire for the project manager to be successful.
Example: Another project manager joined Menlo during a period when Orchid needed a project manager. There was no more experienced choice available to lead the project so she was assigned. The team took her under their wing, helped her learn the project management methods in use at Menlo, encouraged her, and helped her grow. The end result was a stronger team and a stronger leader.
- Regular Reassignments between Projects – Menlo regularly rotates team members between client projects. This rotation forces regular “transfer of knowledge” conversations there by facilitating the ability to easily adapt to new team members joining the team, even project managers. The “experts” who have been rotated to other projects are still in the room and are always within earshot when help is needed.
- Pairing – Pairing (specifically paired programming) is another practice advocated by Kent Beck where two people work together, sharing a single computer, keyboard, and mouse. Menlo has taken this practice and applied it to all levels of team member, including its project managers.
Example: When possible and feasible, so far as budget was concerned, project managers worked in pairs. Reviewing Figure 2 will show you that at times there were as many as three project managers working full or part time on the project.
These cultural practices contribute to the project success by accelerating the typical “forming, storming, norming, and performing” stages of group formation.
The Project Managers
The project managers came from a variety of backgrounds with varying amounts of project management experience. Exhibit 6 contains a quick sketch of each of the project managers.
Exhibit 6 A Comparison of Project Managers
While each individual project manager brought with him/her differences in interpersonal communication styles, managerial techniques, and experiences from their past projects and positions, the fact that everyone follows Menlo's standard processes enabled these project managers to gain a number of benefits.
First, there exists a standard project management methodology. The practices of estimation show & tell, planning, and execution define a heartbeat for the project because they are on an unwavering schedule. Estimation always takes place on Monday, Show & Tell and Planning always take place on Tuesday, etc. Even if a project manager is added to the team that has no previous experience with the Orchid project, they can easily pick up the reins and drive the team instinctively while they bring themselves up to speed on the domain knowledge of the project.
Second, there is candid communication between the team members at all times. Working closely together quickly builds a feeling of camaraderie amongst the team members. Even new team members quickly feel comfortable adding their feedback, asking questions, and challenging long standing assumptions.
Third, there is incremental planning with realistic budgets and schedules. Every week the project sponsor revisits the unfinished story cards and chooses what will be worked on next. This makes three things clear: 1) what is in scope, 2) what is in scope but out of budget, and 3) what is out of scope.
Fourth, there is iterative and incremental documentation of project needs, goals, deliverables, and status. Because of the constant planning and re-planning of the project each week the team can readily adapt to changes in technology, market needs, budget changes, etc. There is little danger of delivering a product that the sponsor does not want because they are choosing the work from week to week.
The success of this project and its team clearly demonstrates that it is not necessary to choose between being a process-oriented organization and having people-oriented project managers. The processes enforced are standardized enough to prevent new project managers from flailing and drowning in the challenges of joining a project midstream. Additionally, each new project manager could focus on building relationships and the all important soft-skills that contribute to project success instead of reinventing a new version of existing administrative procedures. Building consistent, straightforward processes that facilitate and encourage people to work collaboratively enables the organization and the team to reap the best of both worlds.
.Beck, K. & Andres, C. (2005). Extreme Programming Explained: Embrace Change. Upper Saddle River, NJ: Pearson Education, Inc.
Evans, M., Abela, A. & Beltz, T. (2002, April). Seven Characteristics of Dysfunctional Software Projects [Electronic Version]. Retrieved on August 1, 2007 from http://www.stsc.hill.af.mil/crosstalk/2002/04/evans.html.
Jedd, M. (2007, May). Checks & Balances. PMnetwork, 21(5), 58-62.
Perks, M. (2003, June). Guide to Running Software Development Projects [Electronic Version]. Retrieved on July 30, 2007 from http://www.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks.html?ca=drs-.
Shore, J. (2007, January). The Art of Agile Development [Electronic Version]. Retrieved on July 31, 2007 from http://www.jamesshore.com/Agile-Book/whole_team.html.
© 2007, Lisamarie Babik PMP
Originally Published as a part of 2007 PMI Global Congress Proceedings – Cancún Mexico