This document discusses evolving views of project management. It begins by outlining that the discussion will focus on structured and agile project management methods based on the author's experience. It then notes that effective project management alone does not provide value, but rather influences the effectiveness of existing systems. The key is establishing project management in a cost-effective way that represents a good return on investment. The document goes on to discuss choosing appropriate project management tools based on a team's maturity level, with more structured methods like Scrum suited for newer teams and a mix of methods or no formal method potentially suitable for very experienced teams. It also touches on estimation as an optional tool that depends on availability of knowledge and managing user expectations.

1. An Evolving View of
Project Management
Anthony Jones

2. Thanks for inviting me

3. Thanks for inviting me

4. Scope
• Discussion at level of “process models”
– Structured and agile methods of project
management (PM)
• Based on my own experience and research

5. EFFECTIVE PROJECT MANAGEMENT

6. User
Developer

7. User
Developer
Client
Business

8. User
Developer
Client
Business

9. User
Developer
Client
Business
$
(solution price – costs) * effectiveness = PROFIT

10. User
Developer
Project
Management
Client
Business
$
(solution price – costs) * effectiveness = PROFIT

11. Effective project management
• Project management does not
provide value by itself
• Project management influences
the effectiveness of an existing
system to amplify success
• Establishing and maintaining
project management costs both
Project
Management
time and money
• Effective project management * effectiveness
represents a good return on
investment (ROI)

12. KEY POINTS

13. Manifesto for Agile software development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.

14. Manifesto for Agile software development
Individuals and interactions
over processes and tools

15. Project management methods...
Comprehensive packages?
Or flexible tools?

16. Key points
• Project management is people management
• Software development methods as tools
• Favour explicit pragmatic application based on
people, culture, context and goals

17. BUILDING YOUR PROJECT
MANAGEMENT TOOLBOX

18. Which project management method?
Select project management tools based on
TEAM MATURITY

19. Team maturity
• Roy Osherove
– Teams have varying levels
of maturity
• Chaotic Stage
– (most teams)
• Mid-Life stage
• Mature stage
• I’m expanding Roy’s idea...

20. Instructed team  SCRUM
• Newly formed, less experienced teams
• Needs support and control to be effective
• Hierarchical roles in “service model”
– Product Owner, Scrum Master, Developers
• Limited and supported decision making
• Regular reviews

21. Mature team  MIXED METHODS
• More experienced team, strong relationships
• Needs steering and coaching to be effective
• Peer roles based on suitability
– Including leadership roles
• Decisions primarily based on discussion,
convincing others and reaching a consensus
• Regular discussions

22. Mature team  MIXED METHODS

24. Free team  NOTHING!
• Very experienced, highly trusted teams
• Needs culture and community to be effective
• No distinctive roles
– Developers adopt roles according to suitability
• Actions based on everyone doing what they
feel is the right thing for the business

25. The Valve handbook
for new employees

26. Free team  NOTHING!
• Fred George
– Programmer Anarchy

27. Programmer Anarchy
Agile best practices not used:
•
•
•
•
•
Stand ups
Unit tests
Story narratives
Acceptance tests
Retrospectives
•
•
•
•
•
•
Refactoring
Estimates
Patterns
Iterations
Continuous integration
Mandatory pairing
Copyright © 2011 by Forward Internet Group, Ltd 10

28. Programmer Anarchy
Agile roles used:
•
•
•
•
•
•
Customer ✓
Project manager X
Business analyst X
Developer ✓
Quality assurance / tester X
Manager of programmers X
Copyright © 2011 by Forward Internet Group, Ltd 10

29. Key points
• Project management is people management
• Software development methods as tools
• Favour explicit pragmatic application based on
people, culture, context and goals

30. If there is time...
ESTIMATION AS AN
OPTIONAL TOOL

31. Estimation in project management
• Certain project management methods require
the developers to estimate the complexity of a
task or the time required to complete it
• Estimates may be used to prioritise work, to
establish deadlines and release dates
• Is this an effective tool?

32. We don’t do this...
DEADLINES BASED ON ESTIMATES

33. Estimate or guess?
• Depends on availability of relevant knowledge
• Task = known work + unknown work
3 days
+ ? days
Erm...
Developer
Project
Management

34. Estimate or guess?
• Unknown work
– Learning
– Problem solving
– Emergent complexity
• Can you really estimate these?
• For familiar tasks these may be constrained
unknowns that may be given a rough estimate

35. Estimate or guess?
• Depends on availability of relevant knowledge
• Task = known work + unknown work
+ around
3 days
2 days
Around
5 days
Developer
Project
Management

36. Estimate or guess?
• Unknown work
– Learning
– Problem solving
– Emergent complexity
• Can you really estimate these?

37. Estimate or guess?
• Unknown work
– Learning
– Problem solving
– Emergent complexity
• Can you really estimate these?

38. Rubik’s Cube

39. Four stages of competence
• You don’t know what you don’t know!

40. Estimate or guess?
• Padding is a common tactic
• Task = known work + unknown work
3 days
+ ? days
Erm...
Developer
Project
Management

41. Estimate or guess?
• Padding is a common tactic
• Task = known work + unknown work
(3 days
+ around 2 days) * 3
Around
15 days?
Developer
Project
Management

42. Estimate or guess?
Around
15 days?
Developer
Project
Management
User

43. Estimate or guess?
$!?*&
Developer
Project
Management
Be careful when setting user expectations
User

44. More honest communication?
...
Ok.
Project
Management
User
Can we agree on releases based on dates or features,
but acknowledge that doing both is much harder?

45. We do estimate sometimes...
ESTIMATION AS A USEFUL TOOL

46. Not having an estimate
I don’t
know
Ok.
Developer
Project
Management
Not having an estimate is a useful sign of uncertainty,
risk or training opportunities

47. Having different estimates
Around
8 days?
3 days
Developer
Developer
Having different estimates is another useful sign of
uncertainty, risk or training opportunities

48. Estimates and even guesses
can be useful for prioritisation
Task A is
smaller than
Task B
Let’s do
Task A
first
Developer
Project
Management

49. Key points
• Project management is people management
• Software development methods as tools
• Favour explicit pragmatic application based on
people, culture, context and goals

50. THANKS FOR LISTENING