In every project team members gain knowledge that can be used to improve future projects (Birk, Dingsøyr, & Stålhane, 2002). I was involved small eLearning project for a large international company. The goal was to create short eLearning modules on various topics in adult learning. The project was relatively straightforward and fun. I created several modules and things were going very well. I created some job aids for adult learning that were very popular and helpful. I still hand them out in my classes today.
On my last module I was paired with a SME who just didn’t get back to me. He did approve the storyboard I’d created and then he disappeared. I knew the SME and we’d had a good working relationship. I’d send him emails and leave voice messages and he just didn’t respond. The SME provided graphics and a rough idea of what he wanted. I tried to create the eLearning module based on what he’d given me but there were holes in the content and I needed more information. I was supposed to leave the country for 6 weeks for an international project and I wanted to have this last module completed before I left. The SME would not get back to me or schedule a time to meet with me. I had to submit the module to the project manager with the holes. The meeting was scheduled after I left the country. The project manager handled the meeting with the SME and he complained about everything when I wasn’t there to defend myself. He complained about the content when he approved the storyboard. He hated the graphics – the graphics he gave me. He complained about the holes in the content – when he wouldn’t respond to my questions. The project manager was furious and blamed me. I have to admit, it was my fault. If the SME didn’t respond I should have escalated the issue. Of course, who wants to run tattling to a manager? Because I was out of the country for such a long period someone else had to finish my module. I never even saw the completed project. It was a very bad end to what had been a fun and engaging project.
My lessons learned include:
- Make sure the storyboard is approved. (Mine was approved and I will never continue without approval.)
- Document communication – track emails and phone calls.
- Track the number of requests for specific answers or additional information.
- Escalate the issue when the SME doesn’t respond within a reasonable timeframe.
- Attend the meeting when your module is reviewed so you can defend your design.
- Make sure you finish the project you started.
I make sure I follow my list of lessons learned. I don’t want to go through an experience like that again. Lessons learned are vital to improved performance in future projects. “Lessons learned the hard way on past projects are, if nothing else, risks for future projects” (Collier, DeMarco, & Fearey, 1996).
I found out that the SME quit two weeks after my project was reviewed. He went to another company. We found out that there were many projects that he just left hanging. He knew he was leaving so he just didn’t care.
Birk, A., Dingsøyr, T., & Stålhane, T. (2002). Postmortem: Never leave a project without it. IEEE software, (3), 43-45.
Collier, B., DeMarco, T., & Fearey, P. (1996). A defined process for project post mortem review. Software, IEEE, 13(4), 65-72.