1.6 Identify which part of the problem / opportunity the project will address

Identify and agree on which part of the problem/opportunity the project will address

Introduction

This section is about identifying and agreeing on which part of the problem or the opportunity the project will address.

Big problems

One of the most common reasons projects fail is that the project scope is too big. Too big for a single project. Large project scopes take a long time and are difficult to plan and execute.

You can argue that the problem or the opportunity the organization is facing is huge and so the project to solve it needs to be huge as well. However, to big problems applies the same principle as for elephants. There is only one way to eat an elephant and that is a bite at a time.

Organizational goals are elephants and their achievement normally exceeds the possibilities of a single project.

Achieving organizational goals is at the level of a portfolio of projects and programs that collectively attain the goal.

The key to avoid projects that seem to go for ever is at the level of programs: a group of related projects and operations. Projects in the program, delivering the items to be used to change and operations in the same program using those items and so effectively producing the desired change. If the program was well defined than the change should bring the envisaged benefits explained in business cases and during the selection phase in portfolio management. As this will not always be the case, we will need changes in the composition of the portfolio; new or modified projects and programs will be needed to adjust for variances between expected and realized benefits.

Using the example of the new equipment costing 100.000 € that reduces operating costs at 45.000 € per year, instead of defining a 5 years project that has to wait until end of year 5 to declare success or failure, we could define a program consisting of a one year project to put the new equipment in place, spending 100.000 € and 4 years operating the new equipment that should demonstrate that it has effectively saved 45.000 € per year during 4 years. The program as a whole would deliver the benefit envisaged in the business case, while the individual project to install the equipment would need to define other success criteria for instance delivery in time, in scope and in budget (the classical ones), and perhaps a couple of other metrics such as satisfaction with the project team, easiness of operation of the new equipment, etc.

 Big problems. Multiple problems.

Let us use another, more complex example to better illustrate the importance of defining which part of the problem “one project” will solve.

Let us say that one organization’s goal is to double the overall customer retention rate within 3 years.

The background might be – as an example – a profitability problem, which is a huge issue to solve. We cannot solve that in a one-shot approach. We must look at smaller components of the problem. If we have a profit problem, we have two components: either our revenues are down, or our costs are up, or some combination of the two.

Let us fade-out the entire cost part of the equation, focus on the revenues and break this down.

Revenue issues are caused by either sales volumes or realized prices. Let us fade-out the pricing aspect and focus on volumes sold, which is still a big issue. As for volume sold, we may have an issue with getting enough new customers and /or with existing customers not buying enough. Let us focus on existing customers

Imagine that our problem-solving techniques have revealed an issue with “customer retention”. Once we acquire a new customer, which is an awfully expensive operation, these customers only buy once or twice and then leave.

Our problem-solving techniques have further disclosed that our failure in retaining existing customers goes back primarily to unsatisfaction with our customer handling, not to the quality or price of our existing products.

Accordingly, corporate has included in the strategic goals for the next three years to increase customer retention from now 35% to 50% in one year and to 85% in three years.

Our analysis shows that customers are unsatisfied with the long time it takes to receive the goods ordered and with the lack of transparency of the steps happening after placing an order. They feel that they never know when they will receive the goods ordered. Another point is the customer handling at our customer desk: phones are always busy, and when the customer finally gets someone on the line, the operator asks many unnecessary questions trying identify the customer and to track the status of the corresponding order. Additionally, from a customer perspective, answers received after complains about issues are usually defensive and sometimes a bit unfriendly. Finally, there are also notable inconsistencies in the handling of accounts receivables.

In fact, the low customer retention rate of currently 35% is the effect of several problems in different areas. How to solve them?

Decomposing the cumulative effect of the problem into the individual sources, the causes of the problem, we become able to handle each smaller problem by one single project or perhaps sub-programs. If we did a good job in detecting the sources of the problem we can assume, that solving those smaller problems will produce the desired effect – an increased customer retention rate, which would be the outcome. And this outcome should produce over time the desired higher turnover with existing customers and therefore a contribution to the benefit: an improved profitability. Probably, to improve the profit situation of the organization, additional projects and programs will need to happen at other levels of the organization – on the cost side, on the pricing and on new customers acquisition – that we have faded-out in this exercise.

A final though about defining individual projects of a “manageable size”. Remember that managing things takes time and that also a project manager has only 2000 hours working time in a year (50 weeks x 40 hours per week), if working full time as a project manager. How much work can you manage if you have 2000 hours available? The formula has been approximately the same since the times of the Roman Empire, or probably before: approximately 1 to 6. All kinds of organizations implement something like 1 manager or coordinating person every 6 FTE, full time equivalents to be coordinated. Six full time equivalents to be coordinated, each working at 2.000 hours per year, produce collectively a total effort of some 12.000 hours.

This means, if your project has an estimated effort larger than 12.000 work in a year, the project manager will need some support to manage the initiative. Perhaps this support in managing the specialists creating the solution comes in form of suppliers that bring in not only their teams but also their team-leaders. This is also applicable if the suppliers are internal, assuming the project manager delegates the execution of work packages to a team leader.

The idea is that there is a limitation of the capacity of the project manager to manage 12.000 hours work. However, if the project manager is managing 6 team leaders and each of those 6 team leaders is managing a sub-team of 6 people, then the project manager would have capacity to manage 6 x 12.000 hours work = 72.000 hours work, which is the equivalent of 45 persons working full time. The point to retain is that the project manager – as everybody else – has a limitation in the amount of work she can manage.

This limitation is a parameter to consider when addressing the question: which part of the problem is your project going to address. The other parameters are:

• Break down big problems into smaller ones.
• Establish manageable individual projects to tackle smaller problems.
• Combine those projects into programs for a coordinated management and benefit delivery.