Kyiv Project Management Day 2016 Іванна Заєць: Основи ПМа (PM’s Essentials) Сайт конференції: http://pmday.org/ Спільнота в мережі Linkedin: http://bit.ly/PMDayLin Спільнота в мережі facebook: http://bit.ly/PMDayKyivFB Twitter конференції: https://twitter.com/LvivPMDay

1. Hello!
I am Ivanna Zayets
I work at InternetDevels.
You can contact me at:
ivana.zayets@gmail.com

2. PM’s
Essentials

3. 1. Be honest and tell truth. It is
profitable
2. Understand the expectations
3. Choose the framework
4. Take time for planning
5. Understand the customer’s
fears
6. Learn to improvise and
persuade

4. Do not underestimate the
project to be in time
with the
deadlines.
1.
Be honest
and tell truth. It
is profitable

5. Customers share
positive
experiences with
only 3 people.
While the negative
ones are shared
with 10 to 20 other
people.

6. You could provide your customer with
underrated development time
But sooner or later when you're
not on par with the timescope...
… or don’t make promised things…
… he will leave and believe you no
more.

7. Instead of over optimistic, we can be realistic
This estimation is a draft and if something has
to be added it can be changed.
This functionality is quite difficult so we need
more time to investigate the issue and adjust
the scope properly.
This task includes a lot of communication with
the team and the Dev Lead, deployment on
staging and live site, testing, fixing/re-fixing
and stabilization/re-stabilization. That's why
so many hours have been put into this
estimation.

8. Sometimes, when we don’t want
to lose a customer, we start
panicking
2. Understand the expectations
And make promises we
cannot fulfill.

9. How does it happen?
If you continue
cooperating with us
/approve this
implementation
/etc, you’ll get here
for sure ...

10. ...or even there!

11. What do we have at the end?
Expectations Reality
VS

12. Honesty is
the best
policy!
I have to be honest with you.
In your case, it’s better ***.
However, our devs can ***.
Moreover…. That's what we're
able to provide you with.

13. SDLC (software development
life cycle):
- Spiral
- Waterfall
- V-model
- Agile
- ...
3.
Choose the
methodology

14. The Development Methodology
should match the aim and
characteristic of the project

15. How to choose the
right way?
... emphasize the practical part
on each of the development
methodology.
Time Report
From the beginning
of the month we
used:
XXX hours
If the technical task is
rough/draught and
there are no strict
requirements we can
change some view of
the page or
functionality that will
not influence the
general concept of
the site a lot. In this
case, we analyze the
situation from the
business point of
view.

16. Why is it so important to take
enough time for planning the
sprint/tasks/epics/
site building etc?
4.
Take time for
planning

17. We are currently refining
the backlog for Sprint
One.
We are adding docs into
Confluence and filling
them with the necessary
information. Dev Lead
has already restructured
the sprint due to new
updates in the
document XXX.
Partial reason for this
was that the sprint was
reviewed by Senior
Manager and we
decided to improve the
structure. The planning
is very important for us
as it provides a higher
quality of service and
expected product.
SAMPLE

18. Learn the needs and demands at the
start of the project. Don't start the
project until you've got the answers to
all of your questions.
Bring him back with:
- ”Do I understand you right?”;
- “For my own understanding…”;
- “What you are truly saying ... , is that
correct?”;
- “Help me to understand, please.”;
Focus on the issues. The rest is
unimportant to them.
Doesn't interrupt the process, waits till the deadline arrives and
doesn't answer the questions till then. Starts leaving comments
on the task after it has been closed a long time ago.

19. What do you think about these
suggestions?
Could you please let us know
your thoughts, how should we
move forward? Are there any
additional research you want us
to conduct?
All requests, suggestions,
concerns are welcome.
Could you please let us know of
your thoughts on this post?
Tell me what’s your opinion on
this matter, please.
When we want to get the
feedback:

20. LETTER SAMPLE
I have already asked you about the feedback including the work done, because
we want to be on the same page and provide you with the expected product.
That’s why the moment we start working on the new sprint, means you
approve all the work, which has been done up this point. Are you good with
that? Otherwise, please, check the deployed tasks here *link* and give us your
feedback.
Besides, if you wish, we can appoint the review meeting at the end of the
Sprint #. During this Demo, we will show the work we have accomplished over
the Sprint #. It will include:
- The work we completed
- Key decisions that were made during the sprint
- Demo of the work itself
What do you think about this? Would you like to have the Demo at the end of
the Sprint?

21. Tell the rules. The customer needs
to confirm that he agrees with
them.
While a sprint is running, its tasks
cannot be changed or added.
Interrupts the development process, adds new tasks and
frequently reminds to resolve them. Makes the change requests
on and on.

22. LETTER SAMPLE
If you wish to change something that was implemented during previous
Sprints but we have started working on the new one already, we need to
implement the change request either during the next Sprint or do that instead
of the other tasks approved for the present Sprint.
After sprint is started - it is impossible to update tasks and change its scope
until sprint is finished, because any changes to active sprint would break all
the planning and destabilize all of the project's flow thus dramatically
increasing all the risks and budgets.
If business goals are suddenly changed - you may cancel sprint and set new
priorities, after that team will be able to plan new sprint and perform it.

23. Bad PM:
Doesn’t find out what the
customer wants to
implement in the future
Good PM:
Is informed about
future plans for the
project
- It is very important for us to know the future plans of the
project. Are we going to start the next stage of the project as
soon as the first stage is done? It's just we need to make a
workload plan for developers, QA and Dev Lead. Please, inform
us about your intentions...so all members of the team would be
available should you decide to continue the development.
- My thinking was, that I would start promoting the site and
gathering feedback. Some of the feedback would be actual
bugs, for which I would need relatively quick attention. Other
types of feedback would be improvement requests, which can
wait for a later set of sprints, probably after 2-3 months.
LETTER SAMPLE

24. If everything was done properly, the customer will be glad. But sometimes we need to
tell about business advantages which follow after a successful functionality
implementation. For example, if the customer is afraid to lose some money for
unimportant thing, explain him possible advantages for his business.
5.
Understand the
customer’s fears
(business and
money)

25. Don’t be shy to find that
out!
- Is there anything (in particular) that’s holding
you back?
- Is there anything that disturbs you in our
suggestion?
And then crush that
fear!

26. - *** (money)
- We always try implementing everything in a way the development costs less in
terms of time, money, emotional stress, and effort and brings maximum ROI
(Return of Investments) to business. Once it is ready for shipping, you'll have it
and then we'll start another development cycle...
- I want to reduce the time for QA...
- QA is important in bugs identification, including the unpredicted ones, because a
well-timed fix would help us to decrease the development time and understand the
problem better. This may also reduce the time it would take to make all other fixes
in the future.
DIALOGS SAMPLES

27. 6.
Learn to
improvise and
persuade

28. Let’s watch the Video:
http://videopay.net/video/saGEsG6PEeaStZN
AGpT1tw

29. Thanks!
Any questions?
You can find me at:
ivana.zayets@gmail.com