Choosing a Project Leader

In a recent discussion with a potential client, he told me that he was in the process of setting up a team to lead a cost-reduction project in his 1000 employees company. He explained that this project was crucial to the company's short-term survival, but that he did not want to compromise the company's longer-term competitiveness due to short-term cost reduction initiatives. His question to me was how he could decide which person to ask to lead this crucial project.

I explained that I agreed that putting together the right team would be crucial for enabling the success of this very complex project, and that choosing the project leader was the first, and maybe most crucial, step in this process. However, I also told him that the choice of the project leader could not be looked at independently of the choices required for the rest of the team. We discussed how the key goal of putting together a project team is to have the right mix of skills and experience. We agreed that this boiled down to the members of the team having the right mix of problem solving / analytical skills, interpersonal skills, and technical/functional skills. In addition, the team should span the parts of the organization covered by the project in order to ensure that nobody feels "left out".

The team required for a project depends on the phase of the project being carried out. In this case, the cost reduction project was just starting up (see Determining the Appropriate Deliverables for the First Phase of a Project) and the focus was on developing a detailed understanding of the situation and key issues faced by the company, to make an overview of key changes required (by how much do costs need to be reduced in order to be competitive and profitable?), and to suggest the overall direction of possible improvements. In this case, I explained that the overall team needed to be fairly small, and consist of people that:
·Know the company well enough to understand where the issues and fat lie
·Are not too constrained by "we already tried that…………:"
·Are analytically strong and able to dig up data to support their conclusions and recommendations
·Are able to think "out of the box" and develop strong ideas on how the main processes of the company could be changed (with reduced costs and (often) improved results)
·Are good communicators able to get input from across the company
·Are sufficiently respected within the company that people will listen to them

The potential client told me that he had some people in mind for the project-team, but was worried about their age and knowledge of the company. I told him that in my experience, a team to carry out this type of activities can be quite young, as it often will be easier for them to carry out the analytical tasks and do the "out of the box" thinking. However, this entails that the key role of the project leader will include managing and quality controlling the work of the rest of the team, and being the main interface between the team and the rest of the organizations. Based on this, I explained that the project leader would need to be somebody who has a fair bit of working experience in the company (ideally in different roles), is fairly strong analytically, but not necessarily an Excel-whizz, is able to mentor and manage a team of younger staff, and is able to communicate well with people across the company and at all levels of the organization (see How to Ensure That The Project Team Has Sufficient Interaction with Sponsors and How to Get Buy-In for Project Conclusions and Recommendations) .

In going through the potential candidates for the project leader role, I quickly focused on a candidate with an MBA, and who had gotten to the mid--management level of the company fairly quickly after having worked in two or three jobs across the company and gained experience in different functions related to marketing and production. My potential client explained that it would be extremely difficult to free this person from his current tasks for the duration of the cost reduction project. After a discussion where we talked about how crucial this project REALLY was, he finally agreed that he would need to use the best person for the project.

While this blog is based on a specific example, following the general rules and ideas suggested here will help anybody who is in the process of setting up a complex project.

Ensure that Projects Finish on Time by Avoiding Scope Creep

In my discussions with executives, the most common complaint they have about internal project teams is that they hardly ever deliver the agreed end-results on time. While there are a number of reasons why this typically happens, one of the most common reasons is scope creep. Scope creep can be defined as the tendency for project team to carry out more work than originally agreed and/or is required for making the project a success. There are two different types of scope creep (external and internal). The reasons for the two types are different, as are the steps required to ensure that it does not happen, or that the consequences are limited. These two types will therefore be described separately.

External scope creep is caused by sponsors or other stakeholders asking the project team to carry out more work than was originally agreed. The natural tendency of most project managers and project teams is to blindly say "yes" without thinking about the consequences. In fact, sometimes extra work is welcomed by the team, as it gives the team an excuse for not finishing on time. The primary responsibility for guarding against external scope creep lies with the project manager.

The project manager needs to guard against scope creep by ensuring that all requests for additional work are known to him. When he is made aware of a request for additional work he should carefully assess whether the requested work fits within the scope of the project and whether it can be done within the agreed resource and time limitations. If this is not the case, then he and the team should discuss the issue with the sponsor and agree the solution. The solution can be a) not performing the extra activities, b) performing the extra activities but dropping another activity, or c) performing the extra activity and extending the available time or increasing available resources. The project manager should use the project charter as the basis for discussions on this topic. While this will not “magically” ensure that the project is completed on time, it will, at the very least, enable a structured discussion on priorities.

Internal scope creep is when the project team decides to do more work than agreed and/or is required for meeting the project goals. A clear example of such a situation is a project I am currently helping. In this project the team consists of people from different technical departments within a large network company. The team has been given the responsibility for developing a telecoms vision for the next ten years. The team has been given considerable freedom in defining its specific deliverables and project approach, but has also been given a very tight deadline. The naturally tendency of such a team is for everybody to raise the issues that are critical for their department, and make suggestions for activities that they personally find interesting. Because the team is democratic in its approach, it is very difficult to prioritize or censor, resulting in a very broad list of activities to be carried out.

My help so far to this team has focused on helping them to understand the exact need driving the request from their management team. Using this, we have been able to focus the goals of the project on helping to resolve the core issues that the management is facing. Using this as a starting point, we have then carefully developed a work plan focusing only on understanding the key drivers for the requirements to be placed on the company's telecom services in the next ten years. In parallel, we are defining a work stream that will help us understand how the telecom service provider environment will evolve. Combining these two activities will enable the team to give the management team the vision it required for making key asset-related decisions.

This step has only given a starting point for controlling scope creep, as the real danger will lie in the day-to-day activities being carried out by the team. We have therefore agreed that in the ongoing review of the activities being carried out by the team members and sub-teams we will use a "scope test". Essentially, this "scope test" consists of a diagram showing the inner-most circle of telecoms related assets, services, requirements, etc, and an outer ring which includes all the direct influencers of the internal ring. If there is doubt about an activity being carried out, it will be placed in the diagram. If it is not located in the two inner-most circles, it will be seen as being out-of-scope and discontinued.

In addition to this "yes/no" decision regarding activities, we have also agreed to have an ongoing dialog on the depth of the analysis being carried out. The team mainly consists of engineers, whose normal work requires 100% accuracy. Given the time frames of this project, this will be impossible. In addition, this level of detail and accuracy is not required for developing the high-level vision required by management. We have therefore agreed to have an ongoing dialog with the team members to prioritize their activities and agree when to stop a given activity. Given my experience in putting together presentations for executive boards, this will be one of my key activities going forward.

In conclusion: scope creep is a very common problem for teams carrying out complex projects. However, the effects can be controlled and minimized by using some fairly simple approaches and tools.

Running a Successful Product Development Project

In my discussions with executives, innovation, or product development projects, are often given as examples of internal projects that are not successful. When questioned in more detail, usually the "failure" that is being mentioned can be divided into two separate types. The first type of failure is probably the most damaging and frustrating. These failures are usually products that fail in the market place or result in enormous costs and complexity in the production and supply chain process. The second type of failure is less damaging, but probably more frustrating, as it happens more often. This type of failure involves products which are not launched or launched too late.

In my experience, these two types of failures are caused by two different types of problems. The first type (market failure) is typically caused by the product development project having been structured in the wrong way (hand-overs between departments, wrong type of team, etc). The second type of failure (delay) is typically caused by the team being set up, managed, and run in the wrong way. Given this, how can the success rate for product development projects be improved?

The most crucial response is to ensure that the project is set up and staffed in the right way. Product development projects should avoid hand-overs between departments, and therefore need to include a representative of all key departments involved in the process. This will typically include marketing, production, logistics, account management, etc. The chosen project team then needs to be given the end-to-end responsibility for the successful product launch. This responsibility needs to be collective for the whole team, to ensure that they continue to work together across the whole process. In situations where this methodology leads to teams that are too large, careful thinking should be given to working with core and extended teams, and carefully expanding and changing the team composition across time. An excellent explanation of this is given by Deborah Ancona and Henrik Bresman is their book "x-teams: how to build teams that lead, innovate, and succeed".

Once the right team has been put in place to carry out the end-to-end innovation process, the next challenge is to make sure that the project is successful. A product development / innovation project will typically score highly on both internal and external complexity, and a very high number of the problems that this type of projects face are likely across all three phases of the typical project. However, these problems can be avoided or minimized by ensuring that key pitfalls are avoided.

In the initiation phase of the product development project, great care should be given to ensuring that the team has a clear understanding of the project goals and the deliverables expected from the project. As mentioned earlier, this should be to deliver everything that will be required for the successful launch of the new product. This will entail that the team must come up with the product itself, the production process, the supply chain process, the marketing process, pricing, etc, etc. Naturally, the team will need to get specialist input on a number of these issues, but the total responsibility must be clearly placed with the innovation team.

The team will typically consist of people who have never worked together and who probably do not know each other. This means that the team should be given help in forming themselves into a team. They need to understand what is required to become a successful team, how it is to work as a team, how they can best make use of each other's skills and capabilities, etc. Finally, the team should be helped / forced to develop a realistic plan for how they are going to achieve their goals and deliverables. They should be made to understand that they will be held accountable for this plan (especially the overall timing and milestones).

In the work phase key focus areas should include avoiding scope creep, sticking to the agreed milestones, carrying out the required analytics, and communicating with the sponsors and stakeholder. Scope creep is a common problem is this type of projects, as the team is asked to look into related issues, or dives into too much detail on specific issues. To avoid this, a clear process (involving the sponsor) should be put in place to control this. One of the main challenges the team will need to solve (on a continuous basis) is the optimal split between the activities carried out within the team and the use of external experts. When using external experts timing and milestones can become a major problem, as the external experts will not have the same dedication and focus on meeting deadlines. The team should therefore always have a "plan b" for use if the external expert does not deliver (on time).

In the finalization phase the team will need to develop its overall conclusions and the final deliverables. This will typically include the total plan for launching the new product covering all the issues mentioned earlier. In addition, the team will need to develop and carry out a communication process. In my experience, this is something that innovation teams often overlook. Their implicit assumption is that the rest of the organization will automatically accept their conclusions and recommendations. Unfortunately, this is often not the case. Therefore the team must carefully consider who the stakeholders are, what their "hot buttons" are, and how they can be convinced to accept the team's conclusions.

It is in the nature of the process that not all innovation projects are successful. However, it is my experience that companies that make use of a structured process as described in this article, have a much higher success rate than other organizations.

Follow the links if you are interested in more information on project planning or project management training.

Has Your Project-Team Considered All the Key Dimensions of the Problem?

Many readers have mentioned to me that they feel that a lot of the projects they sponsor (even the successful ones) are often on "automatic pilot". This typically happens once the project teams feel that they understand the problem and have decided on what they believe to be the most appropriate direction for solving the key issues facing the project. The consequences from this can be severe. The most dangerous consequence is often that key aspects of the problem are overlooked. More common is that the team has not analyzed all the relevant dimensions to the problem, and therefore has not developed complete and optimal solutions.

An example of a similar situation from my own work was a project-team in the insurance sector that was developing a new structure for a company in response to key legislative changes. A key component of the project team's work was to look at the key business drivers for succeeding in the new environment. In a meeting the team presented their key hypotheses, which seemed to make sense. However, a clarifying question was asked about one of the success-drivers suggested by the team, and this lead to a broad discussion in which several new success drivers were identified which the team had not considered. Luckily, this did not happen in the final presentation to a SteerCo, but in a pre-meeting.

This type of situation can easily be avoided by borrowing a methodology used by consultants called a Blue Team (sometimes it has a different name). The methodology helps ensure that project teams are shaken out of the "automatic pilot mode" and have considered all relevant aspects before the end of the project. This methodology can easily be adapted to internal project teams as well, and is guaranteed to improve the overall quality of the work delivered.

A Blue Team is a structured meeting typically held once, maybe twice, during a project. In this meeting, the project team gives a short presentation on what it believes to be the key issues (if the meeting is early in the project) or key hypotheses (if the meeting is later in the project). The presentation is given to an invited group of people who are not directly involved in the project. The guest list for the Blue Team should include people with relevant knowledge and experience to the issues being dealt with by the project. Typically the people invited have market knowledge, technical expertise, and/or process experience.

The invited group needs to be able to quickly understand the issues being discussed, and is meant to be critical in the questions they ask, the comments they give, and the suggestions they make. However, the participants also need to understand that their comments and questions are meant to be helpful to the team. The Blue Team therefore needs to find a balance between criticism and support. One way of achieving this is to clearly state upfront that the process is meant to help the project team, and therefore only the project team can decide how to use the criticisms, ideas, and suggestions coming out of the meeting.

Even in the best of cases, the Blue Team is tough on the project team, as they (by definition) will get criticism on the work that they have carried out. Given the psychological barriers related to receiving criticism, even a project team with good previous experiences may have to be forced to carry out the Blue Team. My recommendation is therefore to make Blue Teams a standard part of all complex projects that you sponsor, thereby avoiding any choice or discussion on the process.