Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Project Management for the resource-challenged
1. Project Management
for the resource-challenged
Ari Davidow
adavidow@jwa.org
Workshop for Museum Computer Network Conference 2010
2. Agenda
• What is Project Management?
• The PMI project management lifecycle
• Components of a project
• Understanding the bones of your project
– Work Breakdown Structure
– Critical Path
– Gantt Charts
• Risk Management
• Agile Development and Project Management
• Tools for Managing Projects
• Where to go to learn more
3. If we don’t manage projects…
• How do we know when they are done?
• How do we know if we succeeded?
• How will we do better next time?
• And in the middle, how will we know
where we are and what it means?
7. Common reasons
projects fail
• Too many projects competing for the same
resources
• Insufficient or inadequate resources
• Insufficient or inadequate business involvement
• Project team isolated from the business
• Team roles & responsibilities are unclear
• Poor communications
• Roadblocks are not resolved in a timely manner
• Scope changes are not managed properly
[slide adapted from Lydia Milne, “Foundations of Project Management,” from Brandeis
University Graduate Professional Studies.]
8. Project Management is …
PMBOK:
• A temporary endeavor undertaken to create a unique product, service or
result.
– Temporary -- not on-going
• Does not imply short in duration
• Does not apply to the product or service
– Has a beginning and an end
– Unique product or service -- not a commodity or ongoing operation
– Can be a subset of a larger program or a stand-alone effort
– Requires coordination of tasks and resources
Wysocki, Beck, & Crane:
• A project is a sequence of unique, complex, and connected activities having
one goal or purpose and that must be completed by a specific time, within budget,
and according to specifications.
[slide adapted from Lydia Milne, “Foundations of Project Management,” from Brandeis University Graduate Professional Studies.]
9.
10. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
11. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
12. Project Management Knowledge Areas
Integration
Management
Scope Management
Objectives, needs,
specifications
Time Management
Schedules, activities,
control
Cost Management
Budget, control
Quality Management
Planning, assurance
control
Risk Management
Probability, impacts, actions
Procurement Management
Solicitation, sub-contractors
Communications
Management
Information System
Human Resource
Management
Productivity and efficiency
[from Lydia Milne, “Foundations of Project Management,” from Brandeis University Graduate Professional Studies.]
13. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
14. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
15. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
16. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
17. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
18. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
19. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
20. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
21. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge
(PMBOK Guide)--Fourth Edition
22. Initiation (in 5 bullet points)
• This is where you take the idea
• Flesh it out
• Create a Project Charter (larger projects)
• Create RFP (in some cases)
• Identify and Engage Stateholders
23. Copyright 2008, Project Management Institute. From A Guide to the Project Management Body of Knowledge (PMBOK
Guide)--Fourth Edition
24. Work Breakdown Structure (WBS)
In Agile development, we would talk about a “Feature Breakdown
Structure (FBS), rather than a WBS
25. Gantt Charts
• Used to Model
dependencies,
milestones
• Helps visualize
critical path
• Overall activity
snapshot of
project
27. Project Summary Dashboard
'Example Program'
Multi-Project Summary Dashboard
Division: ACME Software Works Revision 1.9 Manager: Peter White
Project Name Manager Customer Week Schedule Incidents Requirements Staffing
1) Eager Beaver Byron Murray FPQR 1-Mar-98 (1 of 20) 100.0% G 100.0% G 100.0% G 100.0% G
2) The Big Dig Ron Holliday FMNO 15-Mar-98 (15 of 30) 81.0% Y ò 97.6% G ñ 99.0% G ñ 101.4% G ò
3) We Need Programmers Jim Hassey FJKL 15-Mar-98 (5 of 20) 77.3% Y ñ 100.0% G – 98.0% G – 50.0% R ñ
4) Too Good to be True Joel Lehrer FGHI 15-Mar-98 (9 of 12) 100.0% G – 100.0% G – 100.0% G – 97.6% G ñ
5) Churn and Burn Tom Carter FDEF 15-Mar-98 (6 of 20) 83.3% Y ò 93.3% G ò 89.0% R ò 96.1% G ñ
6) Too Many Bugs Bob Albanese FABC 15-Mar-98 (15 of 20) 92.3% G ò 82.9% Y ò 99.0% G – 101.4% G ò
Notes:
- Percentages represent indices for 'Schedule Performance', 'Incident Closure', 'Requirements Stability', and 'Staffing'
- Color-coded status is determined by ranges that are defined for each project.
- Arrows indicate whether the status is improving (up) or worsening (down).
- For more information about any of these statistics or status codes, see the relevant project dashboard workbook.
[from Lydia Milne, “Foundations of Project Management,” from Brandeis University Graduate Professional Studies.]
28. Individual Project Dashboard
[from Lydia Milne, “Foundations of Project Management,” from Brandeis University Graduate Professional Studies.]
'The Big Dig'
Project #: 998877005 Project Dashboard Manager: Ron Holliday
Division: ACME Software Revision 1.8 Customer: Pay More Inc
Staffing
0
2
4
6
8
10
12
12/7/1997
12/21/1997
1/4/1998
1/18/1998
2/1/1998
2/15/1998
3/1/1998
3/15/1998
3/29/1998
4/12/1998
4/26/1998
5/10/1998
5/24/1998
6/7/1998
6/21/1998
StaffWeeks
0
50
100
150
200
Planned Actual CumPlanned Cum Actual
Requirements
0
1
2
3
4
5
6
12/7/1997
12/21/1997
1/4/1998
1/18/1998
2/1/1998
2/15/1998
3/1/1998
3/15/1998
3/29/1998
4/12/1998
4/26/1998
5/10/1998
5/24/1998
6/7/1998
6/21/1998
ChangestoRequirements
0
2
4
6
8
10
12
14
16
18
Added M odified Deleted CumChanges
Incidents
0
2
4
6
8
10
12
14
12/7/1997
12/21/1997
1/4/1998
1/18/1998
2/1/1998
2/15/1998
3/1/1998
3/15/1998
3/29/1998
4/12/1998
4/26/1998
5/10/1998
5/24/1998
6/7/1998
6/21/1998
NumberofIncidents
0
20
40
60
80
Opened Closed Cum Opened Cum Closed
Schedule
0
10
20
30
40
50
60
70
80
90
100
12/7/1997
12/21/1997
1/4/1998
1/18/1998
2/1/1998
2/15/1998
3/1/1998
3/15/1998
3/29/1998
4/12/1998
4/26/1998
5/10/1998
5/24/1998
6/7/1998
6/21/1998
RemainingActivities
Planned Actual Projected
Main Menu
Update Chart Update Chart
Update Chart Update Chart
Update All Charts
30. Risks?
• So many things can go wrong
• What are the risks you worry about on
your projects?
– Schedule?
– Wrong requirements?
– Stakeholder problems?
– Budget overruns?
– ….
31. Levels of Risk Management
from “Rapid Development” by Steve McConnell, Microsoft Press c. 1996, pg. 84
• Crisis management
– Fire fighting; address risks only after they become problems
• Fix on failure (important to fix but not crisis)
– Detect and react to risks quickly, but only after they have
occurred
• Risk mitigation
– Plan ahead of time to provide resources to cover risks if they
occur, but do nothing to eliminate them in the first place
• Prevention
– Implement and execute a plan as part of the project to
identify risks and prevent them from becoming problems
• Elimination of root causes
– Identify and eliminate factors that make it possible for risks to
exist at all.
32. Cost of Correcting a Technical Problem
$1 ---
$10 ---
$100 ---
Normalized Projected Lifecycle
25
1000
$1000 ---
Why we accurate requirements matter
[from Lydia Milne, “Foundations of Project Management,” from Brandeis University Graduate Professional Studies.]
33. K-J Technique
1. Question: What are the next priorities for the MCN website?
2. Divide into two groups – 5 each
3. Now everyone write sticky notes: One note per priority
4. Stick notes to the wall so that you can see each other’s priority notes
5. Group similar items. Help each other. Talk about what belongs where. Don’t
discuss the priorities, themselves, just how to group them.
6. Name the groups using the other sticky notes (2nd
color). Each group , even with one
item, should have a label. If you don’t like a label, change it, add your own,
rearrange. Try, then discuss, until everyone is happy.
7. Now we’re going to figure out priorities:
1. Write down individually the three most important items.
2. When you have your list, and only when you have your list, rank them.
3. Note your rankings on the group labels on the wall: Your top ranking gets three XXXs; 2nd
gets two XXs; last gets one X.
8. Count the votes. If you realize that two groups are the same, combine them now,
and add their votes together.
9. When you have consensus on what you have voted, you are done.
Source: http://www.uie.com/articles/kj_technique/
34. Agile Development
• A range of development methodologies based on the idea that
projects are divided into short sequences – “sprints”
• Commonly, index cards or similar medium used to note feature
requests, requirements
• Next sprint is derived from which features matter most, that can be
delivered in the sprint (usually defined as 1-3 months)
• Goal is to put working tools into people’s hands quickly for feedback
and learning, rather than get to the end of a two year project and
discover that it no longer makes sense
35. Agile Core Values
• Delivering value over meeting constraints
• Leading Team over Managing Constraints
• Adapting to Change over Conforming to Plans
36. Closing Processes
At JWA, for web development projects, we require the
following deliverables before we will accept a project as
“done”:
• Code must be checked into a source control repository (CVS,
Subversion, etc.) and/or be available as an AWS AMI
• Documentation must be available, usually via wiki
• We are able to successfully check out the code, and by following
the documentation, install it on our site.
37. Final tests run
Contracts closed
Project completed
Then … Lessons Learned
And everything archived
Lessons Learned
38. Some good tools
• The “traditional” project management
information system:
– MS Word
– MS Excel
– MS Outlook
– MS Project – note that MS Project, in and of itself, is
not a PMIS
– MS Visio
• An online hosted service with similar capabilities:
Zoho: http://www.zoho.com
43. Additional Resources
• Project Management Institute (PMI)
www.pmi.org
Look for local chapters!
• Brandeis University Graduate Professional
Studies (includes distance learning using
Moodle)
www.brandeis.edu/gps/
One good example of a Project Management
Cert/Master program*
*Disclaimer: I have a degree from the program. I currently co-teach an
online course in “Content Management” and am developing a new one in
“Cloud Computing”
44. Books
• Wysocki, Robert K. Effective Project
Management. Wiley, 5e, 2009.
• Highsmith, Jim. Agile Project
Management. Addison-Wesley, 2e, 2009.
• Don’t read the PMBOK unless you need it
to get certified.
45. Feedback
On any convenient piece of paper, please write the
name of this workshop and answer the following:
1.Why did you take today's workshop?
2.Were your expectations met?
3.If not, why not?
4.Would you recommend this workshop to a
colleague?
Thank you, all!
Survey adapted from Avinash Kaushick’s
http://www.kaushik.net/avinash/2007/04/the-three-greatest-survey-questions-ever.html
Notes de l'éditeur
This is my favorite. These pieces came embedded in a 13-page proposal for something we called an OAI-ORE-compatible presentation tool.
Note that there is no mention of OAI-ORE.
Note that there =is= mention of a PDF creator
Break into groups
Use the sticky pads and make lists of reasons projects fail
After five minutes, stop and we’ll compare findings
Not going to go into network diagrams, etc.
Go back to risks we just identified – what are appropriate levels for each of the risks we covered? What are good examples of those in action?
In the end, we have a “Risk Register” – things that we have identified, what we intend to do if they show up. Update this regularly.