The document provides an overview of project management concepts including understanding success, defining project goals and requirements, different project types, and the project lifecycle. Key points include:
- Project success requires delivering organizational benefit and meeting objectives, not just technical functionality.
- Goals and requirements must be clearly defined, and each requirement tied to a project goal.
- Iterative projects allow for greater visibility, risk reduction, and incorporation of feedback compared to waterfall projects.
- The project lifecycle involves initiation, planning, executing, controlling, and closing phases, with the planning phase including developing the project plan and work breakdown structure.
2. 2
'Mr. Winston Churchill, sir, to what do you attribute
your success in life?' and he said without hesitating:
'Economy of effort. Never stand up when you can sit
down, and never sit down when you can lie down.'
And he then got into his limo."
3. Value?Value?
• Warren Buffett reads six hours a day, around 500
pages during that time.
• He only makes a couple of decisions during the rest
of his time.
• Is this a productive uses of someone’s time?
3
4. YES!YES!
• Yesterday 7/10/2013 Berkshire Hathaway Inc. (BRK-
A) stock was $172,605.00 a share.
• Forbes magazine 2013 – Warren Buffett’s net worth is
53.5 billion dollars.
• Planning can create a lot of value.
4
6. What Is A Project?What Is A Project?
• “It’s a temporary group activity designed to
produce a unique product, service or result” –
(PMBOK).
• A project is temporary in that it has a defined
beginning and end in time, and therefore defined
scope and resources.
• And a project is unique in that it is not a routine
operation, but a specific set of operations designed
to accomplish a singular goal. So a project team
often includes people who don’t usually work
together – sometimes from different organizations
and across multiple geographies.
6
7. Understanding SuccessUnderstanding Success
• In order to measure success, we must first define
what success is.
• Too often, teams focus on technical aspects of the
project only to find themselves divorced from the
“sometimes not too obvious” real business benefit
desired by the users.
• Project success requires a combination of product
success and project management success.
7
8. What Does A SuccessfulWhat Does A Successful
Project Do?Project Do?
•A successful project facilitates organizational change.
•This organizational change should be in the form of a
clear benefit to the organization
•The benefit to the organization must be measurable and
verifiable so it can be presented to the project sponsors.
•Measure and verify the difference, caused by a positive
change, between the baseline environment, before the
project started, and the new environment, after the
project has finished.
•Baseline environment + positive change = new
environment (measurable verified success).
8
9. What Is Required ForWhat Is Required For
Project Success?Project Success?
• Clearly defined goals and objectives.
• Specifically defined roles.
• Open clear communication.
• Verifiably defined deliverables.
• Detailed success factors which equate into a
definition of “WHAT DOES DONE MEAN?”
9
10. Mindset Of Project SuccessMindset Of Project Success
• Providing “specific technical functionality” is not as
important as delivering organizational benefit.
• The term organizational benefit can be defined as an
outcome of an action or decision that ...
o Contributes towards meeting organizational objectives.
o Has positive value for the organization.
o It answers the “What’s In It For Me” for the organization.
10
11. Quality = SuccessfulQuality = Successful
ProjectProject
• The ability to satisfy the needs of the customer and
users determines the quality of a product.
• Successful projects produce high quality products.
• As quality increases project success increases.
• Quality is defined by requirements and project
success factors.
11
12. Defining Project GoalsDefining Project Goals
• Describe, in a few sentences, what project success
or the positive organizational change looks like?
• Describe, in a few sentences, how you know you
have completed the project?
• Describe, in a few sentences, how you know you
have done a great job on the project?
• Describe, in a few sentences, how you will clearly
verifiably measure project success or the benefit to
the organization?
12
14. Client Centered InsteadClient Centered Instead
Of User Centered ProjectOf User Centered Project
A client centered project has the following:
•Arbitrary judgments
•No market or user based research (SME
Requirements)
•No metrics tracking who clicks on what
•No user feedback (UAT)
A successful project is the opposite of a Client
Centered Project. A successful project is a User
Centered Project
14
15. Define Success FactorsDefine Success Factors
• Is it ok to be one day late, one week, or one
month?
• What is the priority of requirements?
• Are we measuring against the original schedule or
the current baseline?
• Do individual activities have to be on-time for the
project to be on-time (Critical Path)?
• Make success factors easy to understand so people
will accept them.
15
16. Can or Can’t InfluenceCan or Can’t Influence
As an IS department, you must determine what you
can and cannot influence when deciding on success
factors:
Can Influence Can’t Influence
Unit Cost Organizational Based Decision
Compliance Organizational Based Savings
Training
16
17. Clearly Defined RolesClearly Defined Roles
• Each resource on the project needs to have a
clearly defined published project related job
description.
• Each resource on the project needs to know their
job description.
17
19. Types Of ProjectsTypes Of Projects
• Large Project: An internal team size of thirteen or greater, and a level
of effort of more than an ideal year. (Many Iterations)
• Medium Project: An internal team size of six to twelve, and a level of
effort of an ideal six months to a year. (Few Iterations)
• Small Project: An internal team size less than six, including team
members who switch between this project and others on a daily
basis, and a level of effort of less than an ideal six months. (Couple
Iterations)
• Change Request Project: Any task that is executed by one or two
internal team members only, with a level of effort measured in ideal
weeks. (Change Request)
19
20. Process AdaptationProcess Adaptation
Achieved through:
•rightsizing the process to match project needs.
•Adapting the degree of process ceremony to
lifecycle phase.
•Continuously improving the process.
•Balancing project plans and associated estimates.
20
21. Change Request ProjectChange Request Project
• Receive a request for change
• Ask for the request in writing or confirm your
understanding of the request (Project Proposal).
• Assess the change’s potential effects on all aspects
of your project and other impacted projects.
• Write down the necessary steps to implement the
change.
• Create brief project’s plan to reflect any schedules,
outcomes, or resource budgets.
• Put team together and include appropriate
stakeholders.
21
22. Methodology PhilosophyMethodology Philosophy
No matter the methodology the most important feature of a
methodology, when not managing a Change Request Project, is
its iterative and incremental nature.
• Regardless whether use-cases, scrum-meetings, feature-driven
development, design by test approach or others, an iterative
approach will greatly assist in producing predictable results.
• Iterative development is characterized by small mini-projects
(iterations) designed with a clear set of objectives producing a
measurable executable (product) objectively assessed that
incrementally advances a product of increasing business value.
• The objective of this approach is simply to maximize chances for
project success.
22
23. Good Things About IterativeGood Things About Iterative
ProjectsProjects
• Iterative approach provides greater ability to see
what’s happening during development.
• Force issues to be dealt with immediately and not
put off to the end of the project.
• Feedback is folded into the planning of the next
iteration.
• Have time to take action to resolve issues and risks.
• Iterative projects produce prototypes almost
immediately.
• Changes are addressed and captured during
each iteration.
23
24. Iterative Projects AndIterative Projects And
ChangeChange
• In iterative development, the project may be adapted
to changing requirements as changing understanding
of what constitutes success as the project progresses.
• An iterative approach helps us avoid the possibility of a
project viewed as a failure by some yet a success by
others.
• We need to measure project success by focusing on
desired organizational success and not necessarily on
pure functionality.
24
25. Key Characteristics Of AKey Characteristics Of A
Successful Iterative ProjectSuccessful Iterative Project
• Demonstrable, objectively measured progress
(wireframe, demos, prototype)
• Incrementally increasing functionality (features built on
completed features)
• Continually improving quality (continual refinement of
requirements)
• Continual risk reduction (testing early in the project)
• Increasingly accurate estimates (Incorporating lessons
learned from previous iterations)
• Reducing levels of change (avoiding water fall)
• Convergence on a accurate business solution
(continual reviews and phase audits during each
iteration)
25
26. Creativity & ControlCreativity & Control
• To much open creativity stifles control in the latter
phases of a project (Not Enough Measured
Progress).
• To much control stifles creativity in the beginning
phases of a project (To Much Measured Progress).
• Encourage creativity in earlier phases of lifecycle.
• Enhance predictability by having more control in
later phases.
26
27. Measured ProgressMeasured Progress
• Examples:
• Number of products / documents produced
• Number of Lines Of Code produced
• Number of activities completed
• Amount of budget consumed
• Amount of schedule consumed
• Number of requirements verified to have been
implemented correctly.
• Most Important: number of requirements verified to
have been implemented correctly
• We must test before releasing and we must record the
amount of verified requirements!
• Requirements verified vs. project schedule
• It’s about the planning not the plan.
27
28. When Management Of ProjectsWhen Management Of Projects
Goes WrongGoes Wrong
• Not enough visibility because task being performed
are not detailed enough.
• Not enough time to attend meetings involving the
tracking of tasks and milestones.
• Limited resources.
• Conflicting priorities among different projects.
• Project start dates and end date not clear or
accurate.
• Not enough communication regarding status of
project tasks.
28
29. Good ProjectGood Project
Management Is?Management Is?
• You cannot micromanage every single task as a
program manager. Review milestone and sub-
milestones, phase audits, demos, testing, and do it
often.
• Create project checklists.
• Prioritization of projects
• Check progress of every project on a daily basis
through stand-up meetings.
• Breakdown milestones and task so they can be
sequenced accurately.
• Create a project dashboards.
29
30. Buckner Project LifecycleBuckner Project Lifecycle
For more in-depth information about the Buckner
Project Lifecycle, please refer to the Buckner
International Project Lifecycle found in the SharePoint
BI Site Collection under the Buckner IT PMO Document
Center.
http://portal/sites/projects/BucknerITPMODocumentCent
30
31. Five Process GroupsFive Process Groups
The five PMBOK process
groups are:
•Initiating
•Planning
•Executing
•Monitoring & Controlling
•Closing
31
33. Initiation PhaseInitiation Phase
• To understand the desired outcomes you MUST
have an Initiation Phase to start the project.
• The Initiation Phase must consist of some type of
proposal which includes high-level goals and
objectives. Some type of feasibility study (if
needed) to see if the project is right for the
organization at this time, and a project charter to
give authority and budgeting to the project
manager, so they can move forward with the
project.
• Each of these deliverable must be signed off on by
the sponsors of the project.
33
34. Missing Initiation PhaseMissing Initiation Phase
If the Initiation Phase of a project is missed, it is a
MAJOR risk to the project, because the Initiation
Phase is where the project’s scope is defined, the
budget of the project is established, and authority is
given to manage the project.
Don’t build your project on shifting sand…
34
35. Project Management Check ListProject Management Check List
Check off the Initiating Phase deliverables on the
Project Management Check List when completed.
35
36. Example Of Project ManagementExample Of Project Management
Check ListCheck List
<Project Name> Project Management Check List
(If any of the deliverables below will not be needed during
the project, an explanation of why the deliverable is not
going to be needed should be written below the check
item.)
INITIATING PHASE
□ The Project Proposal has been completed and signed
by the project’s sponsor(s) and the Buckner Steering
Committee Board Members?
□ The Project Feasibility Study has been completed and
signed by the project’s sponsor(s) and Buckner Steering
Committee Board Members (If needed)?
□ The Project Charter has been completed and signed by
the project’s sponsor(s) and Buckner Steering
Committee Board Members?
PLANNING PHASE
□ The Project Management Plan has been completed.
□ The Critical Success Factors have been completed.
□ The Work Break Down Structure has been completed.
□ The Project Schedule has been completed.
EXECUTING PHASE
□ Actual Efforts are being collected.
□ Project deliverables are being completed.
CONTROLLING
□ Project performance status reports are being created
and presented.
□ Corrective actions are being taken to make sure scope
creep is not taking place.
□ Measurement metrics are being used to measure
success factors.
□ Change requests are being submitted, reviewed, voted
on, and implemented.
□ Risk management and issue management is taking
place.
CLOSING PHASE
□ Deliverables are being accepted.
□ Lessons Learned are being captured.
36
40. Executing PhaseExecuting Phase
• The Executing Phase is the engine that
drives the project.
• The engine can be changed into an
Agile, Scrum, or Iterative methodology.
40
42. Nine Knowledge AreasNine Knowledge Areas
The Project Plan covers the Nine Knowledge Areas
of PMBOK:
•Project Integration Management
•Project Scope Management
•Project Time Management
•Project Cost Management
•Project Quality Management
•Project Human Resources Management
•Project Communication Management
•Project Risk Management
•Project Procurement Management
42
43. Project PlanProject Plan
INTRODUCTION
FUNDING AND SOURCES
CONSTRAINTS
DEPENDENCIES
ASSUMPTIONS
PROJECT MANAGEMENT APPROCH
PROJECT MANAGEMENT LIFECYCLE
DELIVERALBE APPROVEL ATHORITY
DESIGNATION
DELIVERABLE ACCEPTANCE PROCEDURE
PROJECT SCOPE
PROJECT SCOPE MANAGEMENT STRATEGY
COMMUNICATION MANAGEMENT STRATEGY
CONFIGURATION MANAGEMENT STRATEGY
VERSION CONTROL
PROJECT REPOSITORY (PROJECT LIBRARY)
PROJECT GOVERNANCE STRUCTURE
STAKEHOLDER MANAGEMENT STRATAGY
ORGANIZATION/DEPT
PROCUREMENT MANAGEMENT STRATEGY
MILESTONE LIST
SCHEDULE BASELINE AND WORK BRAKEDOWN
STRUCTURE
STAFF AND RESOURCE STRATEGY
EXECUTIVE REPORTING STRATEGY
SCHEDULE MANAGEMENT STRATEGY
CHANGE MANAGEMENT STRATEGY
COST MANAGEMENT STRATEGY
QUALITY MANAGEMENT STRATEGY
DELIVERABLE QUALITY
AGENCY/CUSTOMER SATISFACTION
RISK MANAGEMENT STRATEGY
RISK REGISTERY
ISSUE STRATEGY
STAFF RESOURCE MANAGEMENT STRATEGY
COST BASELINE
PROJECT CLOSE
ADMINISTRATIVE CLOSE
CONTRACT CLOSE
43
44. Completing The ProjectCompleting The Project
PlanPlan
• Every section of the Project Plan should be
completed.
• If a section of the Project Plan is not needed, tell
why it is not needed in writing.
• If a vendor supplies the Project Plan, make sure it
meets Buckner’s requirements by comparing it to
the Buckner Project Plan Template!
44
45. Key Project Plan ContentsKey Project Plan Contents
• Critical Success Factors?
o Now you know what done is.
• Work Breakdown Structure?
o Now you know how, or what steps to take in order to reach a done state
in the project.
• Project Schedule?
o Now you know what the milestones of the project are, and what to
communicate and present to project sponsors.
45
46. 5 Basics Of Project5 Basics Of Project
PlanningPlanning
• Final Outcome – What is the end required result?
• Methodology – How will you get to the final
outcome?
• Resources – What type of team do you need for the
methodology to work?
• Evaluate – How and who will evaluate the final
outcome?
• Monitor – How will you monitor and control the
methodology?
46
47. Risk ReductionRisk Reduction
• We know that healthy projects address risk up front
by testing early, as this reduces the likelihood of
project failure.
• We divide projects into iterations to gain greater
control over the project and mitigate risk.
47
48. Increasingly AccurateIncreasingly Accurate
EstimatesEstimates
• Accurate estimates for both short-term and long-
term activities must be predictable.
• All estimates have an element of probability in
them.
• Iterative projects do better due to revised estimates
based on real progress measures / verified each
iteration.
• We constantly revised our estimates and hence
converge more quickly to actual costs
• As time progresses, the closer we get to actual
results
• Margin of error decreases as time moves on in the
iterative approach.
48
49. Estimating FactsEstimating Facts
• Estimating is so very poorly done because
often estimates are dramatically influenced
by management; perhaps negotiated.
• Be careful, the reductions in schedule
without corresponding reductions in scope
have the effect of setting the project up for
failure from the start.
49
50. Lessons Learned FromLessons Learned From
EstimatingEstimating
• We tend to be overly optimistic
• There’s very little historical information to base
estimates upon
• Teams do NOT continuously revise estimates
• But by continuously estimating via learning more,
developing additional business value, assessing,
and verification, and, equivalently, developing our
own history, our estimates can become much more
authoritative and result in more predictable
outcomes.
50
51. Convergence on an AccurateConvergence on an Accurate
Business SolutionBusiness Solution
The following perspectives converge iteration by iteration:
o What the customers think they need
o What the customers expect to get
o What IT thinks the customers need
o What IT expects to deliver
o What the users actually need
o What IT is actually going to deliver
o What the customers actually going to get
51
52. More on Convergence…More on Convergence…
• Reality is that users and business analysts often don’t
know what they really want until they see it.
o Too close to the action in many cases…
o Too busy; resistance to change
o Often users ‘need’ the world… until they see the
cost and impacts on schedule.
• Nice thing is that early iterations address risk and
force early problems to be resolved via
demonstrations, proofs of concept, prototyping,
etc….before long term project commitments need
to be forthcoming.
52
56. ControllingControlling
• Create and present status reports.
o By executing what you documented in the Communication Strategy
section in the project plan.
• Manage scope.
o Manage scope and feature creep by executing the change control
process documented in the Change Control Strategy section in the project
plan.
• Measure success factors.
o Success factors are being measured and documented, as described in
the project plan.
• Implement change control.
o All changes are being captured on SharePoint, reviewed, voted on, and
implemented as documented in the project plan.
• Manage risks and issues.
o All risks and issues are being documented on SharePoint as described in
the project plan.
56
58. Controlling ChangeControlling Change
• Again, there will be change and rework. But it is
a matter of controlling and managing these
activities.
• Implement a change control process.
• Change and rework generally come at a much
higher expense later on in the project because
the architecture is stabilized and so much
functionality has been verified and integrated
into the project.
• Bringing Change and Rework under control
dramatically impacts overall project
completion.
58
59. Controlling ChangeControlling Change
• Early in lifecycle, we expect change – typically
between 35% and 100% - as we become more
stable and learn more about the project.
• Rework will then typically decrease and should drop
to something below 25%.
59
61. Closing PhaseClosing Phase
• Deliverables are accepted?
o Sponsors need to sign-off on all deliverables.
o All deliverables need to be uploaded to the
SharePoint project site.
• Lessons learned are captured?
o All positive and negative project lessons are
captured and uploaded to the lessons learned
site.
• Ask not “Was the project a success?” ask :How
successful was your project?”
61
63. SharePoint & Project SitesSharePoint & Project Sites
• Each project has its own project site on SharePoint
2010.
• All project sites include risk, issue, & change control.
• All project deliverables are stored in the project
sites.
• Deliverable version control is implemented through
the project site functionality.
• Project announcements and project status is
communicated through the project site.
• Project deliverables can be tracked through the
use of tasks lists on the project site.
63
64. Deliverable TemplatesDeliverable Templates
Deliverable templates have been created and can
be found in the SharePoint 2010 BI Site Collection
under the Buckner IT PMO Document Center.
http://portal/sites/projects/BucknerITPMODocumentCen
64
The Development box is shown with a dashed outline to indicate that this may be a separate team
Initial requirements statements and understanding is typically flawed:
People don’t know what they want until they see it
People feel if they don’t ask they won’t get
If people understand the cost and implications of what they are asking for they may not want it
Negotiation and shared understanding are integral parts of the requirements process. The iterative development of the solution allows the key requirements themselves to be challenged by the demonstration of early versions of the system providing a firm foundation for increased understanding and a realistic basis for negotiation.