Lessons Learned Report Template - University Services
PROJECT LESSONS LEARNED REPORTProject Name:Business Intelligence (BI)Prepared by:Diane KleinmanDate:June 15, 2009Project Close-Out DiscussionA Lessons Learned meeting was held on 6/12/09. The summarized lessons learned survey results are attached tothis document.Attendees:Vel AngamthuWendy BerkowitzWayne BowkerAaron DemengeMichael GarzaJim GreenGeorge HardgroveJanet HellerBill KanfieldJanet HellerBill KanfieldAnn LundholmRon MapstonPeggy McCarthyTammy NelsonBill PaulusJennifer PiersonShari ZeiseList this project’s biggest successes.DescriptionFactors that Promoted this SuccessWe have a more organized reportingstructure.The capabilities of BI allow for a more organized reportingstructureWe were able to remove a lot ofreports that weren’t being used andwe have reports that actually work.A benefit of this project was time was taken to examineexisting reports and to remove those reports that no longerwere needed or did not work.The tool will allow users to write theirown reports and these can bemodified on an ongoing basisBI allows more than just a few people to have the capabilityto create reports. There is no bottleneck like there wasbefore when only one person knew and was able to writereports that are needed. Now users can write their ownreports and reports can be modified on an ongoing basis.List areas of potential improvement along with high-impact improvement strategies:CategoryProject ManagementProject ShortcomingThere are still questions aroundwhether or not to still treat this as aproject and let the team makedecisions on how to move forwardwith operational monthly reports.Project CommunicationThe right people were not alwaysincluded on project teams andsometimes the teams needed tochange mid-stream as the projectrequirements changed.LESSONS LEARNED REPORT BI ProjectLesson LearnedFM Leadership needs todetermine if this project shouldcontinue with a project structurein place. There needs to be afocus on completing operationalmonthly reports.Continually monitor the makeupof project teams to make surethat the right people areincluded when requirementschange.Page 1
Project Close-Out DiscussionProject Roles &ResponsibilitiesRequirementsTestingWeekly project status reports didnot always accurately reflect thereal-time status of the project.These reports became morevaluable towards the end of theproject because they moreaccurately reflected what washappening. Part of the reason forthis is that there were sometimesconflicting reports from projectteams and there were day-to-daychanges in the status of issues.There were other projects besidesBI that also had priority andresources were pulled in multipledirections (e.g., 8iR2, PeopleSoft,Pillar projects). Team member didnot lack interest or commitment;there were just competing prioritiesthat made it difficult to dedicate thetime needed to meet all scheduleddeadlines. As an organization, weneed to figure out what our projectcapacity is.Key decision makers were notinvolved early enough.Requirements from top levelmanagement came in too late.“The end that we had in mind wasdifferent from the boss’s end”.Need to formalize the reportrequest process. Some “vetting” isrequired to do any monthly and adhoc reports. Sending an email witha report request is not enough.A design document that clearlydefines business rules needs to bedone for any new universe data(e.g., parts universe).As new reports/needs weredefined, then the design changedand that impacted previouslycreated reports. “I felt like I wasworking on the beach and every sooften the tide would come in andwash my work away.”LESSONS LEARNED REPORT BI ProjectStatus reports should be moredirect and reflect what the realproject issues are. This can bechallenging when things aremoving quickly on a project andthe status report is just a“snapshot” of what is happeningat the time.FM Leadership needs todetermine project prioritiesacross the organization and thisshould be clearly communicatedto management so resourcesare not pulled in multipledirections.Project direction needs to be atop-down approach with inputfrom top level managementearlier in the project rather thanlater after requirements havealready been defined.Consider formalizing the requestprocess for monthly and ad hocreports.A design document needs to bedone before bringing insomeone to do the design work.This will help eliminate anyconfusion and will save time inthe end.A test environment needs to beset up early in the project.Page 2
Project Close-Out DiscussionTrainingFM needs to determine howreports will be used by FM users.Training plan should bedeveloped for different userroles which includes:- How to navigate in BI- How to read andunderstand data inreports- What actions should betaken with reportsEnter other comments:Project Lessons-Learned Document / SignaturesProject Manager:Vel AngamthuI have reviewed the information contained in this Project Lessons-Learned Document and agree:NameProject TitleSignatureDateBill PaulusBusiness SponsorEmail approval6/16/09Wayne BowkerTechnical SponsorEmail approval6/16/09Vel AngamthuProject ManagerThe signatures above indicate an understanding of the purpose and content of this document by thosesigning it. By signing this document, they agree to this as the formal Project Lessons-Learned Document.LESSONS LEARNED REPORT BI ProjectPage 3
Business Intelligence (BI) - Lessons Learned Survey Summary1.Are you satisfied with the finished deliverable?Answer OptionsVerySomewhatNot VeryNot at AllIf not satisfied, what could have been done 5%38.5%7.7%25517answered questionskipped question130Comments: This is difficult to answer since I don't think the deliverable is finished. I started out as a co-lead of a team but the other co-lead began heading in a different directionworking directly with the AVP. Complete lack of up front planning. There no attempt to apply what was learned from the mistakes ofCrystal 10. It is not finished. Specs and code were changed up until the last minute. There were no deliverable orspec freezes so it seemed nothing got done. Also some key players were brought in at the final hourwith a different vision which caused tons of work to be discarded. The project is nearing completion, but there is a lot of work ahead of us to operationalize this solution. Because of the nature of the project, potential issues continued to surface up to the end of theproject. I am not sure what could have been done differently An initial design (or requirements documents) should have been created before development started.2.How efficient and effective were project team meetingsAnswer OptionsVerySomewhatNot VeryNot at AllWhat would you 3%0.0%36406answered questionskipped question121Comments: I really wasn't a part of these so I can't answer this one. Most times not everyone was at meetings. Several times, no one showed. Not clear agendas ordeliverables The project dropped from the sky. There was zero research of what they had and what they needed.LESSONS LEARNED REPORT BI ProjectPage 4
Each meeting seemed to be a recap of the last meeting. The org structure chart was handed out somany times even when there were no new players in the room. Project team meetings were not necessarily held regularly with one core team. I think theeffectiveness of the meetings varied by group. Too many meetings at the beginning of the project and too few at the end. I felt I lost touch with theproject somewhat near the end.3. Was the entire team committed to the project schedule?Answer OptionsVerySomewhatNot VeryNot at allIf not, what could have been done 2%23.1%7.7%36317answered questionskipped question130Comments: As much as we could be. This was a high priority but management did nothing to help us with the restof our workload. See #2 above. What project schedule? I feel many competing projects caused people to not be as committed as they could have been. I don't think that team members lacked interest or commitment, but there were competing prioritiesthat made it difficult to dedicate the time needed to meet all schedule deadlines. I think the team was committed to the project schedule, but did not understand all the implicationsand resulting time requirements until too close to the end of the project. I thought we accomplished a lot near the end. More resource time for internal staff was availablethan at the beginning.LESSONS LEARNED REPORT BI ProjectPage 5
4. How involved did you feel in project decisions?ResponseFrequencyAnswer Options30.8%Very38.5%Somewhat23.1%Not Very7.7%Not at allIf you did not feel involved, what decisions did you feel left out of?ResponseCount45314answered questionskipped question130Comments: Decisions affecting data were made and not communicated to the entire group. Some of us knewthings and others didn't -- made it very difficult to test, make recommendations, etc. It seemed like they wanted to put everything in BI, but didn't stop for a second to consider what wasalready working and what was not. The initial design. Report Design. Ability to present options to Operations.5.How efficient and effective was communication between the projectsponsor, project manager and team members?Answer OptionsVerySomewhatNot VeryNot at allWhat could have been done 8%15.4%15.4%27227answered questionskipped question130Comments: I did not hear much from the sponsors and when I did it was too late to do anything about it. Vel did his best to keep everyone moving toward the same goal, but it feels like we haven't reached alogical conclusion. Goals and planning would have been a good start. The project sponsor that represented my area did not communicate results from those meetings toour organization. Weekly status meetings and formal communications were very helpful. Sometimes communication was done at a personal level, rather than a team level and this made itdifficult to ensure all team members were equally informed. I didn't do very well at first but I put more emphasis on this towards the end. Needed to have moreinput towards items that were assigned to me at the end of the project. Time for completion wassometimes unreasonable and didn't felt I got enough advanced notice.LESSONS LEARNED REPORT BI ProjectPage 6
6.How clearly defined were the objectives for this project?ResponseFrequencyAnswer Options16.7%Very41.7%Somewhat33.3%Not Very8.3%Not at AllIf not well defined, what could have been done differently?ResponseCount25415answered questionskipped question121Comments: I'm still not sure what is in and out of scope. Never saw a single document. At a high level, the business objectives and benefits for this project were clear and well documented. This project was different than many technical projects because the objectives became more definedas the project progressed. Requirements were defined incrementally which made the project moredifficult to manage There did not seem to be a very clear scope for this project.7. How clear were you on your role in the project?ResponseFrequencyAnswer Options41.7%Very25.0%Somewhat16.7%Not Very16.7%Not at allIf your role was not clear, what could have been done differently?ResponseCount53223answered questionskipped question121Comments: Part of this is due to my manager not communicating this information. They could have planned resource needs in advance. I felt my role (or my perception of my role) changed throughout the project.LESSONS LEARNED REPORT BI ProjectPage 7
8.How effective was the requirements identification process?Answer OptionsVerySomewhatNot VeryNot at allI was not involved in this stepIf not effective, what could have been done %41.7%0.0%16.7%055025answered questionskipped question121Comments: The fact that we have very different customers who need different things from a report was nevervalidated. We haven't completed this yet! The desired infrastructure was clear, but specific reporting needs were developed throughout theproject by business owners. Requirements sometimes seemed to be a moving target and some key decision makers were notinvolved early enough in the project to ensure all requirements were clear. Once again, sometimesrequirements were identified incrementally, which is different from a more traditional project and thatmakes it more difficult to assess the identification process. Not enough of this was done up front. Requirements were fairly well known for this phase of the project. Still due to the nature of theproject, new potential uses continued to come up which sometimes diverted attention.LESSONS LEARNED REPORT BI ProjectPage 8
9. How effective was the design (or implementation specifications)?Answer OptionsVerySomewhatNot VeryNot at allI was not involved in this stepIf not effective, what could have been done 0%16.7%8.3%25.0%332133answered questionskipped question121Comments: We were told BI is a design and build as you go along. But as new reports/needs were defined, thenthe design changed and that impacted previously created reports. I felt like I was working on thebeach and every so often the tide would come in and wash my work away. More University employee input may have been beneficial earlier in the project. Globus employeeswere sometimes left to use their judgment instead of getting clear direction. Not enough of this was done up front.10. How effective were project team specification or design reviews?ResponseFrequencyAnswer Options16.7%Very16.7%Somewhat25.0%Not Very8.3%Not at all33.3%I was not involved in this stepIf not effective, what could have been done differently?answered questionskipped questionResponseCount223143121Comments: I did not see design reviews. I saw finished product and was asked to review it. Changes were made without notifying the correct people. So people were using the universe or tryingto test data and were not getting the result expected (because they did not know a change wasmade). Liked the folder structure meeting(s).LESSONS LEARNED REPORT BI ProjectPage 9
11. How effective was the functional specifications?Answer OptionsVerySomewhatNot VeryNot at allI was not involved in this stepIf not effective, what could have been done %16.7%8.3%41.7%042153answered questionskipped question121Comments: Everything seemingly went into the Universe. I don't think many people will be able to navigate it. Andthat will be worse as people move around. Where are the written specs? Since this project did not follow a traditional waterfall approach, the iterative nature of the specdesign-test- implement makes it more difficult to assess the steps individually. Not sure we really had any for the most part.12. How effective was the test plan?ResponseFrequencyAnswer Options0.0%Very63.6%Somewhat9.1%Not Very0.0%Not at all27.3%I was not involved in this stepIf not effective, what could have been done differently?answered questionskipped questionResponseCount071035112Comments: Data validation continues to be a challenge. Test plans were not clearly defined and were different depending on the type of data being analyzed. Depends on the area. Not all areas had the same level of detail in their test plans. Plan was ok but I only knew my part. Didn't have time to fully complete. Will continue to find issuesas the system is used.LESSONS LEARNED REPORT BI ProjectPage 10
13. How effective was the training plan?Answer OptionsVerySomewhatNot VeryNot at allI was not involved in this stepIf not effective, what could have been done 7%16.7%8.3%25.0%422136answered questionskipped question121Comments: Is there a training plan? There was much discussion about a need for one, but to date, I haven't seenone. A number of people went to two days of training. But what about the many people that will beaccessing the reports going forward? Key members are trained, but there is a remaining activity to train and deploy for a wider FM audienceto be effective users. The training plan was very clear, but the implementation steps were not completed exactly as defineddue to time constraints and staff turnover Didn't really have a training plan. I believe this is still being worked out?14. How effective was the testing process?Answer OptionsVerySomewhatNot VeryNot at allI was not involved in this stepIf not effective, what could have been done %8.3%8.3%25.0%161134answered questionskipped question121Comments: It was effective, but too short and too much crammed into the last two weeks. It was frustrating because you could test a report and be happy, then something would change somewhere unrelated and your report change and you would have to re-validate it. Detailed and defined testing should have started early in the project to provide adequate time forchanges and retesting Depends on the area being tested. Not all areas were tested the same.LESSONS LEARNED REPORT BI ProjectPage 11
15. How effective was the interaction/cooperation between technical subteams?Answer OptionsVerySomewhatNot VeryNot at allI was not involved in this stepIf not effective, what could have been done 7%0.0%8.3%25.0%350134answered questionskipped question121Comments: Again, Vel tried but attendance was scarce. Seemed everyone had their own universe and there was little cooperation between them. And at timesa change in one universe could negatively impact reports in another group. Changes to the universesneeded to be better communicated and agreed to before the change. There is always a balance between the time invested by team members, and the benefit of increasedcoordination. At the beginning this was not very good. At the end of the project this was much better.16. How effective was the deployment process?Answer OptionsVerySomewhatNot VeryNot at allI was not involved in this stepIf not efffective, what could have been done %27.3%0.0%18.2%153025answered questionskipped question112Comments: It hasn't been deployed yet. I think efforts to date have been effective but there is more to do. There was not a traditional deployment process in this project It hasn't really been officially deployed. It is currently in this half deployed half dev status. System was deployed as it was developed.LESSONS LEARNED REPORT BI ProjectPage 12
17. For the next project, how or what could we improve onin the way the project was conducted?ResponseCountAnswer Options8answered questionskipped question85Comments: Management needs to do a better job of communicating to their staff and adjusting workloads toaccommodate the project. Define the scope and budget before you start. A code and spec freeze well before the final week of the project would be a good start. But there weremany decisions that were delayed early on that caused delays along the way.a software license,defining what Tree to use, are two such examples. More formal requirements gathering, project plan, and agreed upon deliverables at the onset would ofhelped. As well as commitment by the entire team. I thought Vel and his team did the best they couldwith what they we given. Even though there could of been things done better, we still accomplished alot and have a foundation for future growth, if we use it correctly. For a future project of this type, I would like to see USIT take ownership of the application supportsooner in the project. If it is possible, to more completely define the scope of this type of project early in the project thatshould be done. In addition, input for executive decision makers should be received throughout theproject Have a defined scope, functional specific
LESSONS_LEARNED_REPORT BI Project Page 1 PROJECT LESSONS LEARNED REPORT Project Name: Business Intelligence (BI) Prepared by: Diane Kleinman Date: June 15, 2009 Project Close-Out Discussion A Lessons Learned meeting was held on 6/12/09. The summarized lessons learned survey results are attached to this document. Attendees: Janet Heller Vel Angamthu
Apr 19, 1995 · Lessons Learned Major Lessons Learned Lessons Learned through Response/Recovery Operations Lessons Learned from Other Agencies Statistics Introduction, Summary of Fatalities and Injuries Exhibits Exhibit A - Murrah Building Floor Plan Image of Floors 1 and 2 (73Kb) Imag
As the centralized lessons learned capability for the Army, CALL synthesizes input from across the ALLP community and disseminates pertinent lessons learned information to units to help plan, prepare, and execute mission requirements. This collaboration allows TRADOC, as the lead for Army lessons learned, to provide
The purpose of a lessons learned activity following a cyber incident is to reflect, learn and improve. Lessons learned from the incident should be used to improve security measures and the incident handling process itself. This paper is an overarching lesson learned report for SEPA. To produce this paper, information has been
5S Template 279 5 Whys Template 281 A3 Template 282 Change Management Plan Template 284 Check Sheet 286 . Hoshin Kanri 291 Lessons Learned Survey Content 293 Meeting Minutes Template 296 Metrics Chain 297 Policy Template 298 Procedure Template 299 Process Map 300 Process Monitoring P
TOPIC 12 Understand Fractions as Numbers 8 LESSONS 13 DAYS TOPIC 13 Fraction Equivalence and Comparison 8 LESSONS 12 DAYS TOPIC 14 Solve Time, Capacity, and Mass Problems 9 LESSONS 11 DAYS TOPIC 15 Attributes of Two-Dimensional Shapes* 5 LESSONS 9 DAYS TOPIC 16 Solve Perimeter Problems 6 LESSONS 8 DAYS Step Up Lessons 10 LESSONS 10 DAYS TOTAL .
Learned.” The USFA acknowledges the effort of the individuals responsible for producing those legacy works. The updated content from those two publications is coupled in this report with a stronger focus on learning from lessons learned. The lessons learned by first responders and emergency managers in the April 2011 tornado outbreak in
The Warrior King (Lessons 41—44) 64 Two Splendid Kingdoms (Lessons 45—50) 69 The Man of the Fish (Lessons 51—54) 76 A Miraculous Birth (Lessons 55—61) 81 The Man with the Two Horns (Lessons 62—64) 90 The Hidden Cave (Lessons 65—70) 95 . Le
Your sheet-pile program FADSPABW (B-9) is a special case of this method. It was separately written, although several subroutines are the same, because there are special features involved in sheet-pile design. These additional considerations would in-troduce unnecessary complexity into a program for lateral piles so that it would be a little more difficult to use. Many consider it difficult in .
