The document provides pragmatic advice for project management. It discusses challenges project managers may face including stakeholders, timelines, and fear, uncertainty, and doubt. It recommends communicating frequently with stakeholders, organizing work with tools like planning software and ticketing systems, addressing problems promptly through prototypes, and taking ownership of assignments to help ensure project success.
3. pragmatism : an approach that assesses the truth of meaning of
theories or beliefs in terms of the success of their practical application
– google definition
6. How to pick up project management
basics
READ (see some ideas at end of preso)
Organize a small open source project
Volunteer to help with project communication.
Learn to manage yourself effectively.
Put yourself in others shoes and ask what you would need to know if you
had to report to the investor.
what if you’re in the fire already?
7. COMMUNICATE
Most instances of PM status meeting thrashing can be solved through
consistent communication.
If you haven’t planned out what you’re working on, take the time to do it,
even if the project has already “started”
The sooner you can flag potential problems the better.
Make sure you answer people’s questions, try to understand their
concerns, and always offer a solution.
8. How to relay things clearly..
Know what you want to say.
Know your audience.
What do you want then to learn
What is their interest in what you've got to
say
How sophisticated are they
How much detail do they value
Whom do you want to own the information
How can you motivate them to listen to you.
Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master
9. Don’t forget the little things
Choose your moment.
Choose a style.
Make it look good.
Involve your audience.
Be a listener.
Get back to people
Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master
11. Why are these conversations different?
A : PM is not given enough information to do their job.
B : PM was given information they can relay to their stakeholders
stakeholder could choose to course correct but is assured that progress
is being made.
offer of demo gives credibility to status update
12. Phrases to avoid
“I’ll try.
I should be able to do
that.
Let’s hope for the best.
I’ll just do….
We’ll have to make do.
I’ll multitask.
“We can’t do this impossible
thing, but we’ll try it anyway.
We’ll suck up the risk and
postpone a painful discussion
until later.”
Johanna Rothman, Esther Derby. “Behind Closed Doors”
13. Instead try…
“I don’t know how to do that.
I won’t promise something I know I cannot deliver. Here’s what I believe we
can deliver.
I will work with my team to see what we can achieve.”
“We’ll work on the most important features first and show you each month
what we’ve completed.”
Johanna Rothman, Esther Derby. “Behind Closed Doors”
15. Organize your work
Do not start on a project without a basic plan. Make one and share it with your
teammates and with anyone responsible for your success.
Schedule demos of functionality to get better interim gauge of progress.
Communicate proactively on a schedule that people can anticipate.
Take control by providing information frequently on a schedule that works for you.
If you are already providing an answer, and people can easily find it, they will
not have to come ask you.
16. Learn to effectively analyze stories /
bugs
Break bug / story into chewable pieces.
try for a day or two of effort
this is essential so that features can be triaged when requirements
change
if a bug is going to take more than two weeks to fix, it needs to be
flagged and escalated to the overall project plan.
Sanity check your analysis with a peer before you embark on the solution.
17. Take control of your assignments
Treat each assignment as its own mini project
Take the time to outline the requirements for yourself
This will help you identify holes in them
ASK IMMEDIATELY for any missing information, but to not refuse to begin if
you can do so without every detail.
18. Be your own boss
YOU are ultimately responsible for your success.
Each person taking ownership will ensure the larger project succeeds.
Do not compromise on minimum planning, but do not spend more time
doing it than you would spend on a simple prototype.
19. Use tools to your advantage
Agile Ceremonies
Planning software
Ticketing systems
Workflow process
Tools can be helpful if they
are used judiciously and
applied to solve specific
problems encountered in
your project.
Every project needs some version of these tools
20. If you do not understand a tool, learn
about it before you suggest it *
*this especially goes for specific development ceremonies
22. Planning software
Let’s look at OmniPlan
How can this thing help?
List your chewable features
hook up dependencies
Classify into reasonable buckets
go and adjust your calendar impacts (vacation, efficiency, etc)
get some high level milestones to put on the quarterly plan
adjust it weekly as things change
23. Ticketing systems
not everything, sadly is a new project
warranty and maintenance can be killer for status and communication
ticketing systems give everyone the same view on progress and status
half an hour a day working your tickets can save hours of wasted status
meetings later
any project without a ticketing system needs one, stat. Never agree to use email
or spreadsheets (static documents) in place of some form of live ticketing system
24. Workflow processes
Establish a culture for code deployment and release management by documenting how
this will work and sticking to it on a daily basis
Ensure there are automated ways to perform tasks that need to be completed
consistently by multiple parties
project compilation / build
test execution
code deployment
environment health checks
25. Workflow cont’d
consider a peer code review process
if you are not working alone (it is always better if you can find at least one partner) ask a peer to
both spot check your code commits, and sanity check your solutions *before* that code gets into
a release.
nobody is beyond the need for peer review
foster a culture of constructive criticism. focus on the code, not on the person.
ask your reviewer to execute your solution and spot check whether it is meeting the requirements.
plan for time your schedule to allow code review to be completed by all parties participating in the
development process
26. Fear, Uncertainty, Doubt
some common sources of FUD
analysis paralysis
incompetent team members
ignorant management
lack of momentum
29. “Accepting the first truth means you are not afraid to begin your journey
without knowing everything up front. You understand that requirements are
meant to be discovered and that not proceeding until all are gathered would
mean never starting.”
“Accepting the second means you no longer fear or avoid change. You
know it is coming. You accept it for what it is. You adapt your plan when
necessary and move on.”
“By accepting the third, you no longer get stressed when your to-do list
exceeds your time and resources to deliver. This is the normal state for any
interesting project. You do the only thing you can—you set some priorities,
get the most important stuff done first, and save the least important for last.”
Excerpt From: Jonathan Rasmusson. “The Agile Samurai”
30. “Some things are better done than described.”
–The Pragmatic Programmer
31. Prototypes are your friend
Lots of hypothetical concerns can be deflated with a working prototype
Instead of a 3 hour fight, that same 3 hours into a prototype can answer
questions for days or weeks, and can remind you a month later how the
problem was approached initially
Most “concerns” about whether something will work or solve the problem
can be proven or disproven.
32. Lack of Momentum….
Stop, re-evaluate your initial plan
If you are way off, re-analyze the problem based on the information you have
gathered and determine what assumptions were inaccurate.
adjust and reproduce your plan, share it with the team, and validate the parts
with the parties producing them. if possible, do not communicate estimates that
has not been vetted by the developer(s) who will be doing the work.
share a new plan, but do not promise large items. start by promising attainable,
small goals, and build trust before taking a shot at a big deliverable again.
