Looking back on the project

Do you have any review of the project?

"project retrospective" literally means looking back on the start to end of a project when the project is completed, and evaluating and reflecting on it.

what is a look back on the project?

If the project you are looking back on fails, analyze what caused the failure, whether there is any countermeasure to avoid repeating the failure in the future, and so on.

Even if a project is successful, there are few projects that do not have any points to reflect on. (At least it's not in the project I've been working on...)

Another way to look back is to analyze not only the points to reflect on but also the good points of the success of the project.

This time, based on my actual experience (hereinafter referred to as "Author A)," I would like to consider the points when "looking back on the project" and the important things I noticed in the execution of the project that I noticed from the retrospective.

case1: looking back on the project, "swiftly" implementation!
It is one frame in a certain project. There are three characters:
Department Head
/ Boss (Project Leader)
・ Author A(Project Member)

About large-scale system development project s of about one and a half years from design to release, shortly after delivering deliverables and customer acceptance test, i was told this by my boss.


Boss "The long project was finally over, when I was doing the combined test, I thought the quality was tattered and what would happen temporarily, but I was glad I was able to make it on time. We have to hold a retrospective party, but now we are busy with other tasks, so let's launch with project members for the time being! Author A-kun, I'm asking you to make a reservation for a nice shop!"

Aside from my boss's vague shop search instructions, at this moment, my boss and I thought that we had to carry out a look back on Project S, but I unconsciously deferd the retrospective from the relief that the project ended.

The launch was grand, and then time flowed

One day, two months after the end of Project S, my boss, the leader of Project S, was told this by the head of the department.

Section Chief "Speaking of which, project S was completed a little while ago, but it seems that the quality at the time of the combined test was not quite good, if you look closely, the cost of the project is much exceeded from the original plan, and can you look back on the whole project and analyze what went wrong?"

Neither my boss nor I had forgotten, but there were other tasks that took precedence, and looking back so far after two months.

The boss immediately convened the project stakeholders and held a review meeting for Project S.
But here the problem arises. Although we looked back, time had passed since the project was carried out, so there is only fragmentary memory, and we can not dig deeper and analyze the problem.

Boss "The test on the screen here is unnaturally overworked, but what

was the cause of this?" author A"There is certainly a performance problem there, let's ask the partner who was actually in charge of the work!" Boss"Oops, that partner ended his contract last month..."


it is such a state. there are some problems in this case, but the most fatal point is that it takes too long from the end of the project to the implementation of the retrospective.

human memory varies from person to person, but unlike computers, it fades over time. therefore, we believe that the important thing in looking back more effectively is tolook back as soon as the project is finished.

If there are situations or circumstances that cannot be implemented promptly, one of the countermeasures is to supplement the memory by recording. Our project management tool "SI Object Browser PM (HEREAFTER OBPM)" can record the detailed cause of failures and issues, and the history of the project in the middle.

specifically, the history in the middle of the project can be saved by the [progress report registration] function.

[progress report registration] function can record qualitative report contents at that moment in addition to automatically calculated figures such as progress delay rate, remaining number of obstacles, cost excess rate at the time of registration, etc., so when looking back later, what happened at that time and progress delay occurred? ・ it can be said that it is also suitable for looking back on the history of what happened at that time and the quality was declining.

in addition, the progress rate of each work task at the time of completion of the project is usually 100%, but if you register the progress report, the gantt chart (progress of each task) and profitability information at the time of registration are also saved, so you can look back in more detail (the part surrounded by a red frame in the imagebelow).

1

in this way, it is possible to supplement human memory to some extent by recording the history of the past using tools. however, even if you are recording, the level of description varies depending on the person in charge, and it is immeasurable how far you can complement a person's memory. it is also important to record, but in terms of effective retrospectives, there is no better way to carry out retrospectives quickly.

case2: 

"Awareness" gained from looking back on the project
 

It is one frame in a certain project different from case1.
There are two characters:
・ Boss (Project
Manager) ・ Author A(Project Leader)

It's been over a year since i started working on projects as a leader, and shortly after the completion of one of them, a package renovation project z worth 5 million yen, my supervisor and leader, as project managers, are holding a review meeting on the project.


Boss "No ~ This project failed splendidly ..."

Author A"Well...

Boss "I have to analyze the cause in detail..."

There is a somewhat of a vague atmosphere. that should be the case, although even the final deadline was met, the actual cost was greatly exceeded compared to the cost originally planned, and eventually the profit of the project became a deficit project of minus 970,000 yen. when my supervisor and i analyzed the cause, there was a significant cost overrun in the manufacturing process and the acceptance test process after delivering the deliverables, which led to the final project deficit. a more detailed analysis follows.


Superior "First of all, it is the cause of the cost overrun of the manufacturing process, but looking back on the history, the progress transition is also good in terms of the requirements definition and design process before the manufacturing process, and there is no cost excess. Why would it be?" Author A "Well, actually, the package renovation of this Project Z was almost the same as the package repair project Y that I did to another customer before, so I created an estimate based on the estimate at that time, project Y left very good results,

It was such a project that I received an award in the company, so I was not supposed to fail with this estimate..." "Certainly, the function to be refurbished and the estimated amount for each function are almost the same, both projects are designed and designed by author A," but wait. The previous project Y was manufactured by one veteran SE and two young PG's, but three young PG's are in charge of the production of project Z. Is this the cause?"
 

As my boss guessed, if you compare the previously successful project y with project z that failed this time, the target repair function (= thing) and the cost of renovation (= money) are almost the same, but the concept of who will perform the renovation (= human) was not reflected in the estimate at all. the three young pg's who were involved in project z that failed this time were also excellent members, working overtime every night and working hard, somehow maintaining the progress as planned. however, the result was that manufacturing could not be done at the same level of productivity as the team that contained the veteran se, and the cost increased.



the retrospective party continues still more...

Boss "Next, it is the cause of the cost over of the acceptance test process, but

why did I receive such a complaint and be chased by correspondence every day?" author A "The cost of the manufacturing process has exceeded, but there was no problem in terms of quality, and the results of the internal integration test before delivery were good, but as you said, as soon as we entered the acceptance test, there were several complaints from the customer, and most of the causes were [specification recognition discrepancy] of both parties. This didn't happen in previous Project
Y..."

"Taking advantage of the previous lesson...

This time I noticed the cause myself. Previously, successful Project Y customers were IT companies, but project Z customers who failed this time were non-IT companies. I followed the successful Project Y approach to defining requirements, and I intended that the format and level of the requirement definition document were still at that time.

However, the specifications that are not written in the requirement definition manual and the expression that I took for granted did not pass, which resulted in [specification recognition discrepancy] with the customer at the time of acceptance test, and it became the cause of cost over. When I talked with customers and made documents for customers, it was a moment when I became keenly aware of how I was aware of the common sense and assumptions that the other party has.

the "awareness" gained from the review of this failure project, it is the importance of the "human" element in the project. i think that' not it. no matter how much project creates the same "thing", a project carried out on the same scale, that is, "money", "people" will always be intervened there. in this case, i was not conscious of this "human". it is no exaggeration to say that the failure of this project was guaranteed at the stage of estimates, or plans.

Also accumulates information on projects completed in the past as data, and it is possible to search instantly. for example, when an additional project occurs for a customer who has a past transaction track record, and when making a plan, it is possible to list past results for the customer as reference information by specifying "customer" when searching the [project list].

1.5

during the list display phase above, you can see the execution budget (internal cost) for the specified customer's past issues and the profit margin of the project. for example, if you have only projects with low return margins across the board, you can think of a difficult customer and you need to pay close attention when estimating new deals. (of course, it may not be such a decision, but as a trend), if you want to check the details of each project, you can move from the above list to the project menu and check the details of the estimate (execution budget) and final profit result at that time. at this point, you can also analyze in detail who is responsible for developing which features, what plans and achievements they were. why don't you make a plan that is conscious of "humanity" while referring to these past results?

use project retrospectives in your planning

So far, we have introduced the two cases with a look back.

In OBPM, there is a column on the "Completion Information" tab of the [PJ Registration] screen to record the results of the project retrospective (the part surrounded by a red frame in the imagebelow).

2

We actually manage projects using OBPM, but our OBPM operation rules also have a rule that "When the project is completed, in principle, project evaluation is registered within one month". In addition, although the point of "prompt retrospective implementation" was mentioned in case 1, for projects that have not been completed for a certain period of time, attempts have been made to send an alert email to the project leader using the OBPM function.

The word "Don't look back on the past" is sometimes a cool word, but human beings are not only failing creatures, but also living things that learn from reflection and grow up.

By recording the results of the project retrospective and accumulating it as know-how, we will utilize it in the planning of future projects. As a result, it will lead to increased project success.

I myself am still an active company SE, and when I wrote this article, I realized again the importance of looking back on the project.
 

By continuing to look back, we will lead to a project plan with as little risk as possible! I decided so.