Tuesday, 25 January 2022

Project Case Study - Goal setup & results analysis

 




In the 2018 PMI study, there are interesting statistics on problems arising in projects. The question was posed to respondents as follows:

"In the projects launched in your organization over the past 12 months, which were stopped without obtaining results and recognized as failures, what were the main reasons for these failures? (You could choose up to 3 reasons)."

The results of a survey of 4455 practicing project managers are presented in the diagram below:



As you can see, the second and fourth places in the list of reasons for the failure of projects were taken by reasons related to the goals of the projects, and the third place was taken by errors in the collection of requirements.

In this article, I want to talk about an algorithm that allows you to formulate the project goal correctly, and then move from the goal to the project task list.

Below is a diagram that shows the essence of the approach:



First, let's deal with the definition of the term "goal". Wikipedia gives the following definition of purpose:

A goal is the end result to which the process is intentionally directed.

I like this definition better: the goal is a description of the result that needs to be achieved at the end of the project, taking into account the constraints on the budget and deadlines.

If we rely on this definition, then the goal should be described through the result of some process. A process is usually defined as some activity aimed at converting an object from the initial state to the target state. Thus, it turns out that in the formulation of the goal there must necessarily be a description of the expected result and the way to achieve it.


The SMART technique is often used to formulate goals in business. The essence of this technique is to check the formulation of the goal according to the following criteria:


Specific — concrete. At this point, I propose to describe the result that the business wants to get from the project.
Measurable is measurable. The goal should contain a description of the metric with which you can measure the degree to which the planned result has been achieved.
Achievable — achievable. My understanding of the criterion of "achievability" is to describe the way to achieve the goal and the budget available to the customer of the project to obtain the result.
Relevant — corresponding to other higher goals. At this point, I propose to explain what higher purpose this purpose serves. One may ask the question: why do we need the result that we described above?
Timed/Time-bounded — limited in time.



Let's look at the use of SMART with an example.




Let's say some wholesaler decided to implement a CRM system. The project manager, familiar with the reasons for the failure of the projects, invites the project customer to formulate a SMART goal of the project.



The customer of the project formulates the goal as follows:

"Reduce the cost of attracting a new customer by 10% due to the automation of sales processes on the Bitrix24 product until 30.12.2021, spending no more than $ 10,000."

Let's check if all the criteria from SMART are covered in this wording?

S - Reduce the cost of attracting a new customer
M - by 10%
A - thanks to the automation of sales processes on the bitrix24 product, spending no more than 10,000 US dollars
R – why does the company need it? The answer to this question is not disclosed in the wording.
T – until 30.12.2021




Let's finalize the wording and answer the question: "Why does the Customer of the project need to reduce the cost of attracting a new client by 10%?"

Suppose the company's management set a goal: To increase the average profitability of projects. At the same time, the costs of not attracting a new client under the company's management accounting policy are attributed to the first project with the client.

In this case, it becomes clear that reducing the cost of attracting a new client is necessary to increase the average profitability of projects.

The full formulation of the goal will be as follows: "Reduce the cost of attracting a new client by 10% by automating sales processes on the Bitrix24 product to increase the average profitability of projects, until 30.12.2021, spending no more than $ 10,000."

Is it difficult to set SMART goals? My experience is that for most people this is difficult.

But, if we don't set a measurable goal, how can we judge the extent to which the goal has been achieved at the end of the project?


And now let's move on to the description of the results of the project. The final result for which the project is started is the Cost of attracting a new client, reduced in relation to the current level of cost and measured 1 month after the implementation of Bitrix24. In order to get this result of the project, you need to implement a number of intermediate results of the project, for example, the following:


  • A document that describes the requirements for automating sales processes.
  • Regulations describing the work of employees with customers
  • Working support service for users of the software product



Obtaining intermediate results of the project should with a high degree of probability guarantee the receipt of the final result of the project.

So, we looked at how to formulate a project goal using SMART criteria and how to decompose a goal for results.

But, the project consists of tasks and the performers work on the tasks of the project. How do I move from results to tasks?

The most correct technique for moving to tasks, in my opinion, is to describe the requirements for each intermediate result of the project, and on the basis of the existing requirements to formulate a list of tasks.

On how to extract requirements for the results of the project on the example of a CRM implementation project and what these requirements can be, I already wrote in

It remains for us to analyze the last transformation in the pyramid: from requirements to tasks.

We have a list of requirements for such a result as "trained employees":



Employees must be trained to work with the software product

  • For the training of employees, a training program should be developed (there may be requirements for the content of the program)
  • Training should take place on real examples of the company. Examples for training must be approved by the project customer
  • Based on the results of the training, the knowledge of employees is tested. The average score on the results of testing for knowledge of the software product is not




The requirements for the methodology of testing the knowledge of employees are as follows: each employee must create 10 real leads in the program, enter the results of negotiations into the lead card, transfer the lead to the next stage of the process, generate a report on the conversion of leads.


Let's go to the list of tasks for this project result:

  • Prepare a training program for employees to work in CRM
  • Agree on a training program for employees to work in CRM
  • Prepare real-world examples for training
  • Approve examples for training from the Project Customer
  • Prepare computer equipment and base in CRM for training
  • Conduct testing of employees' knowledge based on the results of training
  • Calculate the average score at the end of the training


As you can see, the transition from the list of requirements to the list of tasks is no longer particularly difficult. But, when creating a task list based on the requirements for results, the project manager greatly reduces the likelihood that some tasks will be forgotten.


The approach I have described in this article is based on 16 years of wholesale project management and certainly needs to be polished and improved.

If you have ideas on how to improve it, I'm open to communication.

No comments:

Post a Comment