New project leader seems to have completed the recently appointed project, but the appearance is strange with a very unfriendly-minded face.
the project seems to have ended somehow, but it seems that the cost was exceeded considerably for the initial plan, and the delivery date was delayed, and as a result,
it was judged to be a failure project. today, i'm consulting my seniors about why my project failed.
First project failure
Junior : sem pay! i'd like to talk seriously today, but would you like time? senior: oh, that's fine.
What? what? you're talking seriously with a face that doesn't float? (you mean you're not serious all the time?
Junior: thank you very much.
in fact, my project ended the other day, but it caused significant cost overruns and delivery delays, and it was judged to be a failure project.
i have to write a failure report, but i can't sort out why i failed, and i can't think of any measures to prevent recurrence, so what should i do? i wanted to talk about that area. senior: i'm sorry, yes, you failed the project.
found. then, i'll give you a couple of advice, telling me the situation. Junior : thank you.
seniors: so, can you tell us about the rough details of the project from start to finish?
yes, i want you to tell me the following points as a point.
- agreement overview
- customer requirements (customization)
- was project management implemented (task management, progress reporting, reviews, etc.)
- when and why schedule delays and cost overruns began
- customer impressions (what happened to the customer)
- how did you recover and terminate it?
- Junior's awareness while proceeding with project management
- what projects failed and how to proceed
- Junior : yes, this was the point.
1． agreement overview
we will introduce packages to human resource development companies, but there are some customization development.
requirement definition (quasi-delegation agreement): 1 month (contract separately from the development part).
basic design, detailed design, manufacturing and unit testing, integration test (contract) 2 months.
the initial presentation estimate of the development scale is equivalent to 3.0 people and the amount of the whole process is presented in advance.
after the requirement was defined, a re-quotation has not been presented (the initial quotation has notchanged).
2． overview of customer requirements
THE PRE-EXPLANATION AND EVALUATION OF PACKAGED PRODUCTS WERE ALREADY IN BUSINESS, AND THERE WERE SOME FUNCTIONAL GAP.
IN ORDER TO SUPPLEMENT THE FUNCTION GAP, SEVERAL NEW SCREENS AND RENOVATION OF EXISTING FORMS OCCURRED.
the outline of the requirements (screen image) was obtained, but it was not concrete, so it was planned to be packed with customer representatives by requirement definition.
3． were the main project management implemented (task management, progress reporting, judgment, etc.)
in the requirement definition, in order to materialize the obtained screen image, which information is output to each item, and what item to enter are defined in detail.
the layout of the existing form was changed to the repair of the form, and the image was shared.
NOW THAT THE REQUIREMENTS FOR FUNCTIONS (SCREENS AND FORMS) HAVE BEEN DEFINED, WE MOVED ON TO THE BASIC DESIGN AND STARTED PROJECT MANAGEMENT USING OBPM IN-HOUSE.
we managed the schedule on the gantt chart and conducted weekly progress reports, and reported properly to the superiors.
there were no problems in the middle, so i reported it briefly, "it's going well!" quality checks for each process were not required, but they were carried out independently within the project.
we also carried out a shipping decision and cleared it, so it was sunny and delivered.
4． when and why schedule delays and cost overruns began
the coupling test ended smoothly, the quality was good, and it became strange from the time we presented it to the customer (provisional delivery).
when i had the acceptance test carried out, it became "different from the function i thought!", and while repeating it, such as remake, re-delivery, and pointing out, the delivery time approached, and i approached the superior for consultation.
even though i delivered a proper product, the delivery date was delayed because the customer said , "it is different from what i thought!".
the cost also increased by repeated renovations of what customers had pointed out.
5． customer impressions (what happened to the customer)
we don't know what happened to the customer.
after the basic design, i had hardly talked about it, and when i delivered it, i suddenly said , saying that "operation does not turn in such a thing" or "it is not possible to use it with this function though there is a pattern of such an operation", and it has said with a considerably angry feeling. because it said too much, it corrected as it was said, but no matter how many times it was corrected, it was a settlement that a new point came out one after another.
6． how did you recover and terminate it?
even if the delivery date approached, the customer was not satisfied, so when i consulted with the superior, a veteran "assistant (sket) senior" suddenly helped me.
i visited customers with my assistant seniors and interviewed them carefully on business assumptions.
what kind of operation flow was it supposed to use the developed functions?
how many input patterns there are, whether even normal patterns can be operated, or are they referring to irregular patterns?
rather than talking about functions, i had a lot of business stories, and then organized the points to re-renovate with the current function with the customer.
when i delivered the one that was renovated, i was satisfied.
we delivered it and started operation, but after that we visited about twice to check what the operation situation was and whether there were any new issues, so we received a inspection and completed the project.
7． Junior's awareness while proceeding with project management
even though the development proceeded smoothly and delivered, i feel like the point of failure that we began to make another request at that timing.
when i was really in trouble, i think that the assistant senior helped me by consulting with my superior, and i was able to finish the project safely.
Junior : The way the project proceeds and the end of the solution are roughly like this. I am grateful to my assistant seniors. Senior: I see.
I understand most of the contents. Does Junior think that the direct cause of the project's failure is "good quality, and there is a cause to customers who have complained about the delivered functions after delivery"? Junior : Yes, I think that's also true.
However, I think that there might have been some other fault before becoming it so. In accordance with internal rules, I have been using OBPM to manage schedules, report on progress, and make shipping decisions.
Therefore, I came to consult with my seniors to give advice on where the real cause of failure that I was not aware of was unconvincing. Seniors : As far as I listen to the current story, let's give you about three points that you have noticed.
As I feel, it's not because the customer complained after delivery. It is a result, and the cause lurks until there. Junior : After all.
in order to prevent project failures, you should improve your upstream skills.
Seniors: First, I think we have failed to define requirements in the first place. This is a common story, but if you fail the upstream process, you will always get that wrinkle in the downstream process. I think this is a typical pattern. Junior : Where did you fail?
Seniors : Well, I think one of the factors is that by obtaining a screen image from the customer side, if you only define the item, you have thought that it is the end of it.
Junior : Yes, I thought so.
The customer even made an image, so based on that, we decided on the shortage so that we could develop it. Partly because it went on schedule, we decided that re-estimates were unnecessary. Senior: I don't have a problem defining screen items.
I think there is a problem with the point that I did not consider with the flow of business.
Each function is specifically what kind of business flow, when, who, what purpose to use, the regular pattern is cleared, what kind of operation the irregular pattern is decided, the workaround is decided, the decision is documented, and this area becomes important.
The process of defining requirements is a process that is also affected by the skills of the customer side, and if you are doing only what the customer told you, there is a high possibility that there will be a missing.
Like this time, the work does not flow well, and problems can occur in the downstream process. Just because I had obtained the layout, I think it was necessary to be careful not only in terms of functions but also on the business side.
Certainly, the customer understands the business the most, so it is not bad to consider it according to the screen design plan presented by the customer.
However, this time, I think it was not good to take it for granted and neglect the definition from the viewpoint of cooperation with the background work.
Since we are professional SIers, we need to understand not only the definition of each screen item, but also understand the purpose of the screen, how to obtain information to input each item, how to cover the input patterns, etc., and we need to listen with an awareness of the entire system. Junior : Well, the layout was coming out, so I was thinking that if you make it, there will be no problem with the work.
In addition to functional requirements, we will be more aware of the flow of work in the future. Certainly, when my assistant seniors helped me, the first thing I did was re-interview from the business perspective. Senior: Yes, that's right.
It's not like using a project management tool like OBPM won't work, so you need to hone your skills in the upstream process of your project. There are so many things to learn from mistakes, so let's analyze properly and use this experience to connect to the next time, what is missing! Junior : Yes, I'll do my best!
progress reporting is very important for preventing project failures
Seniors : Secondly, I think there is a problem with the "content" of the progress report. Junior : Eh?
Do you mean that the progress report is incorrect? Seniors : It's not that you're wrong, but progress reporting is very important to who you report, when you report, and what you're doing.
According to Junior, it's terrible that obpm only reports "it's going well." It seems that the rule of writing progress reports for the company every week is followed, but what you are saying is going well, and the contents of the report are important. Especially since Junior is still a project leader, even if you think you are doing well, there are oversights and pitfalls, so you should write a report in as much detail as possible.
In this case, if I had described it in detail, I might have informed someone of the incident sooner. Junior : Well, you were conscious of writing concisely, but you misaligned the meaning of simplicity.
Be consider to write a detailed report concisely. Seniors: And I think it's bad that you've never communicated with customers from the time you've defined the requirements until you deliver them.
In the process of development, there must have been no small questions or unexpected points. However, it is unavoidable to be said that "I decided without permission by the assumption" that I did not confirm it to the customer. You should also report the situation to your customers at the right time.
In this case, if progress reports to customers, progress, consultations, etc. were carried out regularly, it may have noticed discrepancies at an earlier stage.
Progress reports are not just about writing them every week. When, to whom, what to report, and what it is very important. Junior : Yes, yes, I'm sorry.
there are no magic tools to make your project a success
Seniors: The third is that it may not be directly related to this failure, but I want you to think about the role of the tool called OBPM.
Junior says that in accordance with the rules and methods within the company, he has done exactly what needs to be done, such as schedule management using OBPM, progress reports, and shipping judgments. Junior : Yes, I'm going to follow the rules.
Seniors : But the project failed.
Junior : Yes, that's right.
Senior: I'll say something shocking.
No matter how much obpm is used properly according to the rules, as mentioned above, no matter how much detailed progress report is written, "OBPM has no power to make a project successful". Junior : What?
What does that mean? Seniors: If you use OBPM according to internal rules, if projects succeed one after another, no one will have a hard time!
That means. If we understand the characteristics of the tool called OBPM and make effective use of the tool, as a result, "fewer failure projects = more successful projects". It tends to be thought that it is a difference in phrasing, but I want you to understand it properly because it is quite important. Seniors: You can see that using obpm, a shared tool, is a way to share and visualize information.
Because it's "visualized," you'll be the first to discover projects that aren't going as planned, projects that show dangerous signs, and projects that don't follow the rules.
If you can discover it early, it will be faster to treat, so it will lead to "reducing" failure projects.
By using OBPM, by using OBPM instead of succeeding, by detecting and treating projects that are likely to fail early, it will not fail. Equal, more successful projects. Junior : I see!
If you use OBPM according to the rules, it will not be a successful project, but by using OBPM, early detection of projects that are likely to fail and not fail will result in more successful projects! The order of thinking is important. Senior: That's right.
If you think about it this way, I think there is a good possibility that we could have avoided failure if we were able to properly report the latest signs and get advice and provide early allowances for this project.
Junior : Yes, I think that's right.
Even when a lot of points were received for the delivered product, we continued to renovate without proper status reporting, and the cost and delivery date could not be observed, but if we had reported earlier and were able to make allowances early, it might have been another result. Seniors : Oh yes, finally, I'm saying that I continued to make additional renovations at the customer's mercy for the delivered functions, but I'm not impressed with the way I renovate them without going through proper procedures.
Junior : Eh?
But if you don't renovate the point, you won't be convinced, will you? What should I have done? Seniors : This is not an emotional theory, but a place where you should act properly according to your contractual commitments.
If it deviates from the content agreed in the requirement definition, or if additional processing not described in the agreed design document is required, it should be a contract to handle specification changes.
If you become a leader, you should also know the terms and conditions of the contract properly.
In fact, it is often not a story that is so easy to finish, but the indicated content is a design mistake that does not meet the requirements in the first place, a request that is not in the requirement in the first place, because various cases can be considered, not a repair suddenly, but a document (change management) properly, and the impact range and the amount of money are negotiated one by one, We should deal with it in a logical manner. Junior : I see, that's true, it was something that senior Sket did.
Seniors : This is an example of overseas, but there is a story that customers who pointed out that they were not satisfied with what was delivered temporarily like this time, "I think it's good" processing and delivery in a change to the operation that is not according to the design document.
This was refused payment due to non-performance of the contract at the time of the claim.
From the point of view of the contract, "the contract is not fulfilled because the function according to the design is not delivered".
I don't think you can do a successful project, but in the case of a failure project, it can also lead to a trial. It is better to pay attention to the contents of the contract, the promises, and the storage of documents on a regular day. Senior: I wonder if my advice is like this.
Junior : Thank you very much, it was very helpful.
Now I think I can write a good failure report! Senior : Oh, yes, good luck!
(There will be nothing good about the failure report...)
No comments:
Post a Comment