Fail-or-no-Fail-Presentation

1. Fail or no Fail. It's a matter of
approach
Marta Komarnytska
Project Manager
CoreValue

2. Why is it that that
so many IT projects
fail? According to
IBM only 40% of IT
projects meet
Asking ourselves, ‘why do projects
fail?’ is an important one because if
we can learn from past project
failures we can avoid making the
same mistakes twice. And it’s always
better to learn from someone else’s
mistakes rather than your own! So
why not learn from my biggest
project failures?

3. Why Do Projects Fail?
#1. Not Communicating When Things Got Difficult
I’ve talked about this being a problem with developers and designers on
remote teams before, but I’ve been guilty of it plenty of times myself.
It’s a basic human instinct to not want to call attention to yourself if
something’s gone wrong and no one’s noticed. It’s counterintuitive to
the very nature of project management, but poor communication is so
often why projects fail.

4. Lesson learned:
• Every time I’m about to pause before delivering difficult news to a
client I think to myself: is it better to set their expectations now, or do
I want to deal with this after it’s too late? The answer is ALWAYS do it
now, and be proactive. You’ll thank yourself later.

5. #2. Going For “Nice To Have” Instead Of
“Need To Have” On A Whim
Lesson learned:
• If your team has a standard and a process, stick with it and don’t
update things on a whim. Should your team really need or benefit
from a change in tools or tech mid-project, it’s worth going through
all of the motions to vet before implementation.

6. #3. Becoming Too Friendly With Your Team
And Clients
Lesson learned:
• Act always professionally in your projects, even with your friends.
• Be friendly but stay professional in order to continue holding people
accountable to their actions on a project. It’s much easier to feel we
get a “pass” with our friends on things, and that can be a dangerous
(and awkward) situation to get into when it’s being mixed with
professional obligations.

7. #4. Panicking Before You Have A Chance To
Process Things
Lesson learned:
Never be afraid to look away from a reactive email or message, pause,
and take a moment to investigate for myself before asking for more
help.

8. #5. Not Using A Process Because Something
Seems Small Enough Not To Matter
Lesson learned:
Always trust in the process and go through the discovery, estimation,
and QA processes accordingly: I’ve learned that there’s never a small
enough change to NOT disrupt something else along the way. Be
protective of your process and become a champion for doing things the
right way—even if it means just a little bit more effort.

9. What Do You
Think?