Project Management That Works

1
Project ManagementThat Works!

• Rick A. Morris, PMP, ITIL, MCITP
• rmorris_at_rsquaredconsulting.com

2
My Defining Moment

• Projects fail because of context, not content.
  (Thomsett, Radical Project Management, 2002, p37)

3
Understanding You

• DiSC Profile
• How to Deliver Proper Messages
• High D Direct
• High I Feeling, Social
• High S Balanced and Friendly
• High C Detail Oriented

4

• Making Emotional Conversations Unemotional

5
What causes emotional conversations?

• Mandated Dates
• Stressed/Overworked Team Members
• Estimates That Are Not Reliable
• The Project Blame Game
• Post-Project Negotiations
• What else?

6
Examples

• That date is impossible!
• We dont have enough resources!
• I thought you said 40 hours!
• Its not my fault, the developers missed their
  target!
• Thats a scope change!

7
Step One

• Establish your mindset.
• Dont say the negative statement
• Learn not to say no, instead say yes with the
  condition.
• Understand the long term effect of the
  conversation

8
Step Two

• Get to the data!
• Data rules all. Data takes an emotional based
  conversation and turns it into an unemotional
  fact based discussion.

9
Step Three

• Once the data is presented, accept the answer
  given.
• This may be difficult, but again our focus is on
  the end game. Not the immediate win.

10
Communications Management

• Communications Management

11
Qualify the Questions

• Hows everything going?
• Dont Lie! It is what it is
• Deal with fear
• Admitting when you are wrong
• Sometimes it cant be fixed.the sooner you deal
  with the issue the better.

12
Unreliable Estimates

• Ask all of the questions, not just how long
• Name That Tune!
• I can write that code in 4 hours
• Define the word done
• Utilize PERT
• (BC (4ML) WC) / 6

13
Triple Constraint
Cost
Schedule
SOW
Quality
Customer Service
14
What is a WBS?

• Graphical representation of the work.
  Deliverable oriented.

15
Rules to Abide By

• It is created with the help of the team
• The first level is completed before the project
  is broken down further
• Each level of the WBS is a smaller piece than the
  level above
• The entire project is included in each of the
  highest levels of the WBS
• Includes only work needed to create deliverables
• Work not in the WBS is not part of the project
• 4/40 or 8/80

16
Benefits of a WBS?

• Helps prevent work from slipping through the
  cracks.
• Provides the project team with an understanding
  of where their pieces fit into the overall PM
  Plan and gives them an indication of the impact
  of their work on the project as a whole.
• Facilitates communication and cooperation between
  and among the project team and other
  stakeholders.
• Help prevent changes
• Focuses the teams experience on what needs to be
  done
• Provides a basis for estimating staff, cost, and
  time
• Provides PROOF of need for staff, cost, and time
• Gets team buy-in and builds the team
• Helps people get their minds around
• the project

17

• WBS Example

18
Activity Definition

• This process takes the work packages from the WBS
  and decomposes them in order to reach the
  activity level.
• The level should be small enough to estimate,
  schedule, monitor, and manage.

19
Activity Sequencing

• This process takes the activities and puts them
  in sequence of how work will be performed.
• The result is a network diagram which in its
  purest form, show dependencies

A
B
C
F
G
E
D
20
Type of Network Diagrams

• Precedence Diagramming Method (PDM) or
  Activity-on-Node (AON) Boxes represent
  activities, arrows show activity dependencies
• This type has 4 types of relationships (read as
  Task 1 must _______ before Task 2 can _________)
• Finish to Start (FS) Most Common
• Start to Start (SS)
• Start to Finish (SF)
• Finish to Finish (FF)

21

• Activity Sequencing

22
Dealing with Mandated Dates

• First, if possible, dont share the mandated date
  with the team. Not until true estimates are
  given.
• Dont speak in dates, speak in time, commitment,
  deliverables, and predecessors.
• Let the date fall out in a project plan.
• Adjust thinking based on the results of the
  project plan.

23
Dealing with Mandated Dates

• Now baseline the plan. (Very Important)
• Present the DATA to the project sponsor.
• Be truthful and honest
• Present options, not problems
• Dont be afraid to ask for what you need
• If you dont get what you need, baseline the
  new plan for future reference.
• Track the plan and report results. Use this as a
  basis for the next mandated date.

24
Stressed / Overworked Team Members

• Protect your team at all costs
• Do we have to work weekends and overtime?
• Know their utilization, be factual
• Dont forget, Drop everything doesnt mean drop
  everything!

25
The Project Blame Game

• Avoid blame, take it on yourself
• 100/10 rule
• I own 100 of project failure
• I share only 10 of project success

26
Characteristics of Good Requirements

• Take Away Test If you take the objective away,
  does it change the scope? If yes, the
  requirement is valid.
• Extra Eyes Test If two different people read
  it, do they come to the same understanding?
• Clear, Concise, Measurable
• Tie directly back to the scope

27

• Requirements Management

28
Requirements Definition (Functional vs. Technical)

• Functional is What, Technical is How
• Functional should be defined from a user
  perspective, technical should be defined from a
  developer perspective.
• Functional should take into consideration the
  User Interface. The right users should have
  input.
• Technical takes into consideration performance,
  scalability, and availability.

29

• Effective Meetings

30
Meeting Rules

• Is there anything to say?
• Does there have to be a meeting?
• Do we have input?
• Do we have to escalate?

31
Meeting Effectiveness

• No decisions were made
• People were not prepared
• Meetings dont follow agenda
• Meetings dont start and end on time
• Meetings lasted too long
• Meetings were not well run
• There are no notes

32
Setting up a Successful Meeting

• Identify the objective
• Schedule time and stick to it!
• Create an agenda
• Ensure the attendees are prepared

33
Patriots and Scuds

• Understand your own missiles
• Using Patriots
• Using Scuds
• Missiles on Public
• Missiles in Corporate Culture

34

• A Real Risk Assessment

35
Current Process

• so we are told

Create WBS
36
Current Process

• so we are told

Create WBS
Identify Risks
37
Current Process

• so we are told

Create WBS
Identify Risks
Qualify Risks
38
Current Process

• so we are told

Create WBS
Identify Risks
Qualify Risks
Quantify Risks
39
Current Process

• so we are told

Create WBS
Identify Risks
Qualify Risks
Quantify Risks
Pick Strategy
40
Current Process

• so we are told

Create WBS
Identify Risks
Qualify Risks
Quantify Risks
Pick Strategy
Residual Risks
41
What Really Happens
PM Creates Plan
Create WBS
Identify Risks
Qualify Risks
Quantify Risks
Pick Strategy
Residual Risks
42
What Really Happens
PM Creates Plan
PM Identifies Risks
Create WBS
Identify Risks
Qualify Risks
Quantify Risks
Pick Strategy
Residual Risks
43
What Really Happens
PM Creates Plan
PM Identifies Risks
PM Fills Out Spreadsheet
Create WBS
Identify Risks
Qualify Risks
Quantify Risks
Pick Strategy
Residual Risks
44
What Really Happens
PM Creates Plan
PM Identifies Risks
PM Fills Out Spreadsheet
Start Project
Create WBS
Identify Risks
Qualify Risks
Quantify Risks
Pick Strategy
Residual Risks
45
Why Risk Assessments Fail

• End up with an ambiguous answer
• This project has a risk level of medium
• Your risk assessment score is 4.87
• Thanks.but now what?

46
Two Constraining Laws

• Parkinsons Law
• Work will naturally fill the timeframe allotted.
• Murphys Law
• Anything that can go wrong will.

47
Our Dilemmas

• How to capture risk when our team / sponsor /
  management does not believe in risk or will not
  attend risk meetings.
• How do we account for risk without allowing
  Parkinsons Law.
• How can I use a risk assessment to help drive the
  contingency that I need?
• How can I create a risk assessment that means
  something?

48
Simple Approach

• Set up your Microsoft Project Plan using best
  practices (i.e. no manually typed dates,
  everything linked, etc.)
• Save a copy and break your plan.
• Figure out if you can recover the plan. If so,
  what kind of lead time do you need?
• If not, deal with the risk now!

49
More Involved Approach

• Correlate risk score to time and cost guidelines
• Utilize real incidents and lessons learned to
  baseline risk
• Create a repository of items to avoid repeatable
  issues
• Create a system that updates real time as new
  risks are identified or old risks that are
  nullified
• Approach begins with general risks,
• then over time, moves to specific risks

50
Start General
51
Second Step

• How to Capture Real Risk
• Create a real project plan
• No manually entered dates
• Everything has a predecessor
• Baseline, Baseline, Baseline

52
Second Step

• Track variances

53
Third Step

• Gather real variances and categorize them.
• Use actual risks and actual impacts
• Using historical information, correlation can be
  made between risk and cost/time impacts
• Instead of a general feeling when sales or a
  customer inquires about the amount of risk, the
  answer could be, In project A with product B, an
  overrun occurred due to

54
Fourth Step

• Create new risk assessment utilizing actual risks
  and actual impacts. Utilize actual variances to
  determine impacts.

55
The New Report
56
The Process
57
Remember the 2 Laws?

• How do you plan for risk, put it in your project
  plan, but not give it away to your team?

58

• Turning Around Failing Projects

59
Why Projects Fail

• Nobody ever got around to agreeing on the
  projects goals and objectives in the first
  place.
• Major problems go unresolved.
• There isnt enough staff, or the staff is
  inappropriate for the job.
• Inadequate oversight has kept problems from being
  anticipated.

60
Why Projects Fail

• Inexperienced project manager.
• The wheel gets reinvented.
• Unforeseen circumstances.
• Changes in organizational requirements

61
Dealing With Difficult Sponsors

• The Setup
• Large Pharmaceutical Company
• My organization had over 150 contractors employed
• Responsible for many different areas
• Personally My daughter was born 2 weeks prior.

62
Dealing with Difficult Sponsors

• The Issue
• The top 2 of the company uses Palm Pilots
• Calls to the support desk jumped over 5000 (3-4
  per day versus 150-200 a day)
• Team was so far behind, they grew frustrated and
  could not catch up

63
Dealing with Difficult Sponsors

• My First Impression
• CIO Introduction was one of the worst I have ever
  been a part of.
• The Local Management Team (my company) was
  confused, disheartened, and at wits end.
• The team has been so battered, they really could
  care less what would happen.

64
Dealing with Difficult Sponsors

• The Process
• Interviewed team
• Validated their information
• Researched contracts
• Put action plan in place to fix

65
Dealing with Difficult Sponsors

• Action Plan
• Preemptively ward off customer calls by issuing
  regular information to anyone who had a Palm
  Pilot (Stop the calls)
• Let one person focus on one type of call (Define)
• Group the calls by cause (Measure, Analyze)
• Create fix and implement (Improve)
• Monitor performance to ensure item was fixed
  (Measure)
• Implement fixes globally via a software push
  (Control)

66
Dealing with Difficult Sponsors

• Results
• Found issue and cause (New version of messaging
  software)
• Communicated fixes and calmed tempers
• Personally followed up with each user to ensure
  customer satisfaction
• The final CIO meeting (Save face Columbo Close)

67
Lack of Management Support

• The Setup
• Failing project that had 3 previous project
  managers
• One of the Big 4 firms
• Client was in Florida, Servers were in Texas,
  Development Team was located in Indiana
• The product was a first to market strategy

68
Lack of Management Support

• The Issue
• Project Management was changed rapidly, however,
  nobody else on the team or upper management was
  changed.
• The development lead and upper manager were very
  close.
• I was an outsider picked by senior management
  (the upper managers boss)

69
Lack of Management Support

• My First Impression
• The development team was absolutely demoralized.
  One announced he would not work one minute of
  overtime. Another announced he wanted as much
  overtime as possible.
• The development lead was a great individual with
  a huge heart and truly wanted what was best for
  the customer
• The upper manager was an egomaniac, controlling,
  blow hard (in my opinion)

70
Lack of Management Support

• The Process
• Interviewed team to find out what was happening
  (Define)
• Identified remaining work and barriers to
  completing the work (Analyze)
• Made suggestions to fix the issues (Improve)
• SCREECHING TIRES!!!!!!!

71
Lack of Management Support

• The Upper Manager Takes Over!
• Shot down all improvements
• Announced to the client that we were changing
  development methodologies (which neither the
  client, development team, or project manager
  agreed with!)
• Would not return phone calls
• Would launch a Scud.
• ..so I fired a Patriot.

72
Lack of Management Support

• Results
• I was forced to ask for another upper manager as
  the internal sponsor or be removed from the
  project (referent power)
• The senior manager became the new internal
  sponsor
• The development team got their requested deals
• The project moved forward (more on this to come
  later)

73
Wrong Product, Wrong Time

• The Setup
• A large non-profit organization that relies on
  donors and investors to maintain operations
• The project is midway through a 3 year
  commitment.
• 15 developers are assigned

74
Wrong Product, Wrong Time

• The Issue
• Due to relationships, the project was awarded
  without technology validation
• My company (at the time) had a sales person sell
  Lotus Notes as a transactional system.
• When I arrived, the client had expended 275,000
  in development fees already.
• The first process chosen to automate and
  implement was the donor receipts records.

75
Wrong Product, Wrong Time

• My First Impression
• I am going to die.
• This is a no win situation
• Who did I upset to draw this assignment?

76
Wrong Product, Wrong Time

• The Process
• I tried to define the problem, however, it was
  apparent that the application architecture was
  completely wrong.
• In analyzing, I did not see a way to repair. I
  also found out that the client had not been
  notified that in the implementation of the first
  process, we have lost 2 years worth of donor
  records in which we could not recover.

77
Wrong Product, Wrong Time

• Results
• We stopped the project
• We ate the expended funds
• We signed a non-disclosure agreement where the 2
  sides would never disclose what had occurred.

78
Data Rules All

• 2 of a project will go wrong no matter how good
  of a project manager you are.
• Your job is to represent the other 98

79
Numbers Win, Every Time

• The Setup
• Large Hospitality organization
• My company had the add, move, change, break/fix,
  rebuild, LAN operations, Help Desk, and Desktop
  Configuration teams.
• Unhappy with the results, the client wanted to
  transition the entire management team to a new
  team.
• I was to come in, run the account, select the 3
  replacement managers, train them, and then
  transition out.

80
Numbers Win, Every Time

• The Issue
• A large perception that there were consistent
  quality issues.
• Pricing was based on per seat, so projects were
  discouraged as they were additional charges.
• Service Level Agreements were being breached.

81
Numbers Win, Every Time

• The Process
• Since there were so many angles, I started with
  the Add and Help Desk processes. I defined what
  was in and out of conformance based on the
  contract (Define)
• The first month, we gathered metrics by
  categorizing help desk calls, adds, and filling
  out non-conformance reports. (Define)
• We also left customer satisfaction surveys at the
  desk of every person and after every call on the
  help desk to provide the opportunity to rate the
  service. (Define)

82
Numbers Win, Every time

• The Process (Cont.)
• We analyzed the metrics for trends and began
  reporting (analyze)
• The discovery was that we were well within SLAs
  and the customer satisfaction rating was 99.8.
  Utilizing non-conformance reporting, anything
  that missed SLA had a justified cause outside of
  our control.
• The improvements came in streamlining the
  reporting of metrics.
• Measure and control was performed in collecting
  and adjusting metrics as needed.

83
Numbers Win, Every time

• The Results
• All the client sponsors were hearing was the
  negative 2. Once the other 98 was represented,
  we were allowed to perform business as usual.
• The non-conformance reporting allowed for a
  weekly call to improve quality between us and the
  client and allowed us to focus on the issue
  versus who caused the issue.
• The client resigned a 3 year deal with us.

84
And Some That Got Away

• Remember the Big 4 project?
• (I still have nightmares)
• After the removal of the upper management
  barrier, the client no longer had their Yes man
  to approve or include any changes.
• I made the suggestion to stop the project, it was
  decided that we are so close to finishing that it
  should be continued.

85
And Some That Got Away

• The Process
• Sat with the client to define the areas of
  confusion. It was quickly apparent that they
  were not interested in definition
• Analyzed issues and developed solutions.
• Presented change requests with options. Their
  response was We want all of them, at no charge
• I stopped the process.

86
And Some That Got Away

• Action Plan
• I appealed to the senior management of the client
  to try to control costs and end scope creep.
• I tried to limit scope and refused to do any code
  outside of the SOW without a signed change
  request.
• Rollout the system.

87
And Some That Got Away

• The Results
• We finally finished and moved to user acceptance
  testing.
• THE USERS HATED IT! There was no involvement in
  the requirements definition and the product
  actually added work.
• The client tried to blame the poor product on our
  development versus the requirements. There were
  8 different he-said, she-said meetings with
  executive management
• After not being able to beat us with false
  claims, the client became desperate and lied.

88
And Some That Got Away

• Another One
• We had the most prepared client ever. This was a
  detriment to the project.
• We missed a key requirement that made us run over
  180,000 and 3 months.
• The project was a failure on all accounts of the
  iron triangle (cost, schedule, quality)
• HOWEVER.

89
And Some That Got Away

• The Results
• My company still does business with this company.
  This is because of the following
• When trouble occurred, we were honest and
  forthcoming
• We avoided the he-said, she-said conversations
• We never left the clients side
• We admitted where we were wrong and made it
  right.
• When I didnt know, I said so.

90
Lessons Learned

• Be honest, at all costs! It is what it is!
• Get to the data, it truly does rule all!
• Use the Six Sigma process of DMAIC (Define,
  Measure, Analyze, Improve, Control)
• You do not have to be right!
• Listen to your people. In my experience, when
  projects fail, someone knows why and is not being
  heard.

91
(No Transcript)
92

• Questions?