Mistakes are inevitable. If you aren’t making mistakes in your current position you are either not taking chances to improve your process, you are not empowered by your boss to make decisions that matter, or you are lying to yourself. Digital project management is a lifecycle of trial and error. As you start in a position you learn by doing, you try A, you readjust. You try B, you readjust until you find the most optimal way of doings things within your organization. When you’re part of a failed project, it seems stressful and downright painful, but you have the opportunity to learn a lot of lessons that will help lead you to project successes. Below are my top three lessons from a failed project.
1. Meetings for Meetings sake
One of the topics that every project manager has to go through is Meetings. On-boarding meetings, technical meetings, database/catalog meetings, scope planning meetings, creative meetings, and sprint planning meetings to name a few. Meetings will take over your calendar and furthermore you entire day if you let them. I have made the mist
Imagine you have a team of 10 people. A few designers, 5 developers, an assistant, a salesman, and you (the project manager). Now take all the meetings I mentioned before, which are 6 meetings. If you are lucky and only have 1 of each meeting that will give you 6. Multiple that 6 times 10 = 60; If your employees are making $25 an hour that factors out to $1500 to have 6 meetings. Wait, now think about this again. $1500 Dollars! To sit in a room and discuss hypotheticals. If that doesn’t put it in perspective I don’t know what will.
The first lesson that I’ve learned is to strategically plan meetings and strategically select the team members that should join each meeting. Write all of your team members out in a spreadsheet and next to their name, list out their 3 best skills. Use these skills when planning the meetings within the project. If someone doesn’t have the applicable skills for the agenda they should not be invited to the upcoming meeting. Your meetings should be structured well to be most effective, but I will create another post on that soon.
Additionally, to combat the “meetings for meetings sake” mentality go ahead and nominate owners for each major part of the project. Have a go to person for each segment/topic of the project. If your client asks a development question, you have a clear path to get that questions answered, if your client asks a billing question you can act quickly and get them the answer. Cut out as much ambiguity in the communication channel as possible.
Key Takeaway: Schedule meetings to involved the necessary team members. For non-essential member use a centralized communication platform to keep them information with meeting summaries but allow them to focus on their daily duties instead of taking them out of their element and into the meeting room.
2. Project schedule
Another large reason that projects fail is the lack of a detailed project schedule and missing important dates. While the gantt charts and line graphs are really
pretty they don’t mean jack if you don’t communicate those and stick to them. I’ve worked in marketing, IT, and operations and at times I’ve seen projects that have “started” with no integrated project schedule. Tasks started getting done, but without the perspective of where that task fit in the greater project we were actually not making any progress at all, simply just spinning our wheels. Over time we realized that people were doing the same tasks, we were getting behind and pushing the launch date further and further back, and we were starting to get frustrated because everything was tasks based and didn’t seem to add value to the overall goal of the project. I’ve heard the quote “The project schedule is only correct one time a project, and that is after launch.” and that is typically true, but that doesn’t mean you should have it to refer to.
Key takeaway: Build and manage around a project schedule.
3. Asking for help
Heroes only work in superhero movies. Whether you are a developer and you are trying to speed-code your feature into production or the designer that rushes through a final PSD you are actually hurting the entire team. One of the things that teams that I have been on struggled with is asking for help or acknowledging that they can’t meet deadlines.
As example story I remember a developer that had a lot of pull within the company because he had been around for longer than anyone. The COO and upper management had full faith in him, and heck I had faith in him to come through. I heard the response, “Yes, things are fine” and “I will be able to deliver on time” about 15 times, and each time I believed him. The time came to deliver the code and the project and, bam!, nothing. The code was unfinished, I had to grovel with the client begging for more time and we blew through our budget. We had a very strong culture at my place of work and if that developer would have simply told it like it was and said “Hey team, I need help to deliver” everyone would have jumped to help him instantly.
The team is smarter and more capable of delivering than one individual person and that will always ring true. It is acceptable to say “No”, and that “I can’t deliver within that time frame”, in fact I try to empower my team members to be honest and forthright with those statements.
Key takeaway: Don’t be a hero and build an effective team.
Projects have successes and failures at different points in the project lifecycle. The key to future successful projects is to learn from past project failures and take the actionables/reflections and empower yourself and your team to make better decisions.
If you have had any failed project experiences I would love to hear about them, feel free to comment on this post below.