By Following the conclusion of projects, I like to conduct a post mortem assessment. A more pleasant term is retrospective or debrief…but I kind of like the ominous sound of post mortem. It’s an opportunity to identify what worked and what didn’t work so that pitfalls can possibly be avoided in the next project. It’s all about improvement. The clients’ names and certain details have been removed and/or changed to protect the innocent (or maybe the guilty…).
Project 1 – The one-time ‘easy’ incident conversion from one system to another. A data dump in excel was provided. Sounds like this would be straightforward…but of course there were several gotcha’s. Three months into the project as I’m reviewing the data and finding homes within the database, thinking I’m done, we hit a speed bump. The project expanded a bit because with the conversion came new users, new intake screens, new security access, new reports…which had not been contemplated when I provided my initial hours quote. They were also deprecating the prior incident system, so there was more angst around go live.
Project 2 – Expansion of an existing certificate request module. In this project, the client already tracked US requests. They wanted to expand to add a few other countries. This also seemed pretty straightforward. The client provided a power point presentation showing the changes desired on screen, as well as email text changes that were country specific.
Combined lessons learned list:
- There is no such thing as a stupid question when it comes to requirements gathering. Questions should be a mix of closed and open questions. I’ve taught courses at Marsh and Origami Risk on how to ask questions (and actively listen), so I was disappointed in myself for missing a few things because I didn’t ask the question.
- Requirements gathering is critical. The second project I felt went a little more smoothly because they had thoughtfully prepared their requirements in the presentation. This allowed me to ask more strategic questions.
- Be prepared for the time tied to project management. For the first project I believe I included 5 – 10 hours for project management…but that was before the project increased quite a bit. An increase in scope and length of time for a project means additional meetings. In my next proposals, I’ll bullet point out that project management time increases if the project lengthens so that it is clearer to everyone that it is a variable amount.
- Be realistic regarding UAT activity. In both projects we ended up with multiple separate UAT sessions. In the second project, the client had a major acquisition, so was unable to conduct UAT immediately. Their UAT was slower and more sporadic. All of the UAT sessions yielded changes. I need to be clearer that the client should expect we’ll find some things missed and that there will be iterations.
- Engaged clients are awesome! Both clients were enthusiastic partners. Implementations ALWAYS go better when you have a client that is excited to work with you.
- Slow and steady wins the race. Often times, I’m so excited to build something that I jump to that phase without being more methodical with the questions and documentations. It is a balancing act for sure. I don’t want to have analysis paralysis either.
- Ideally there’s a separate sandbox or staging environment to build in first. Unfortunately, that wasn’t an option for either client, so I had to carefully make changes in a live environment being mindful to not upset the existing workflows and processes.
- Humor helps.
Both clients are live with their projects and still are engaging me as a consultant, so I must have done something right. On to the next project!
My sister sent this gif to me, so tack these rules on just for fun!
