Process Learning, Process Maturity and Project Closeout

1
Process Learning, Process Maturity and Project
Closeout

• James R. Burns

2
Learning vs. Maturity

• Learning is very different from maturing
• Learning is similar to the concepts of Lean
• Learning is not measured directly, but its
  effects are measured by profit, cost, quality,
  cycle time, productivity, etc.
• Maturity is measured on a scale of 0 to 5 using a
  maturity model

3
Learning

• Has its origins in systems thinking
• Was popularized by Peter Senge in his book
• THE FIFTH DISCIPLINE

4
The Potential of Wisdom Teams

• Bill Russells Experience of Alignment and
  Synergism
• His play would rise to a new level
• He would be in the white heat of competition, yet
  not feel competitive
• Every fake, cut and pass would be surprising, yet
  nothing could surprise him
• Like we were playing in slow motion

5
Alignment

• A necessary condition for EMPOWERMENT
• Empowering non-aligned individuals worsens the
  chaos and makes managing the team even more
  difficult
• For Jazz musicians, it is called being in the
  groove

6
Alignment and Synergism

• Meetings will last for hours, yet fly by
• No one remembers who said what, but knowing we
  had really come to a shared understanding
• Of never having to vote (because there is so much
  CONSENSUS)

7
Team Learning A definition

• The process of aligning and developing the
  capacity of a team to create the results its
  members truly desire
• It builds on the capacity of shared vision
• It also builds on personal mastery
• Knowing how to play together
• Teams are the key learning unit in organizations

8
The Discipline of Team Learning

• The teams accomplishments can set the tone and
  establish a standard for learning together for
  the larger organization
• Has three critical dimensions

9
Three critical dimensions

• First, there is a need to think insightfully
  about complex issues
• Teams must learn how to tap the potential for
  many minds to be more intelligent than one mind
• Second, there is a need for innovative,
  coordinated action
• Third, there is the role of team members
• on other teams
• A learning team fosters other learning teams
  through inculcating the practices and skills of
  team learning

10
The discipline of team learning

• Is a collective one
• It is meaningless to say that I, as an
  individual, am mastering the discipline of team
  learning
• In the same sense that it is meaningless to say
  I am mastering the practice of being a great
  jazz ensemble.
• Involves mastering the practices of dialogue and
  discussion

11
Dialogue and Discussion

• Are potentially complementary, but most teams
  lack the ability to distinguish between the two
• Teams must learn how to deal creatively with the
  powerful forces opposing productive dialogue and
  discussion
• Argyris defensive routines--ways of interacting
  that protect us from threat or embarrassment, but
  which also prevent us from learning

12
Skills!!
Dialogue
Discussion
Reflection
Inquiry
13
Defensive postures

• Systems thinking is especially prone to evoking
  defensiveness because of its central message,
  that our actions create our reality
• The problems we perceive are caused by our
  actions, not by external, exogenous forces
  outside of us

14
Practice

• The discipline of team learning requires practice
• Teams do not practice enough, generally
• A great play or great orchestra does not happen
  without practice
• Neither does a great sports team
• Such teams learn by continual movement between
  performance and practice

15
The State of Team Learning

• TL is poorly understood
• We cannot describe the phenomenon well--no
  measures
• There are no overarching theories
• We cannot distinguish team learning from
  groupthink
• There are few reliable methods for building team
  learning

16
Need for Team Learning

• Has never been greater
• Complexity of todays problems demands it
• Actions of teams must be innovative and
  coordinated

17
Skills Underlying Team Learning
Team Learning
Personal Mastery
Shared Vision
Systems Thinking
18
Werner Heisenberg

• Science is rooted in conversations
• Cooperation of different people may culminate in
  scientific results of the utmost importance
• Collectively, we can be more insightful, more
  intelligent than we can possibly be individually

19
David Bohm

• A leading quantum theorist
• Developed a theory and method of dialogue when
  a group becomes open to the flow of a larger
  intelligence
• Quantum theory implies that the universe is
  basically an indivisible whole

20
Bohms recent research on dialogue

• A unique synthesis of the two major intellectual
  currents
• systems or holistic view of nature
• interactions between our internal models and our
  perceptions and actions
• Reminiscent of systems thinking which calls
  attention to how behavior is often the
  consequence of our own actions as guided by our
  perceptions

21
Bohm on the PURPOSE OF SCIENCE

• not the accumulation of knowledge, since all
  scientific theories are eventually proved false
• Rather, the creation of mental maps that guide
  and shape our perception and action, bringing
  about a constant mutual participation between
  nature and consciousness

22
Bohms most distinctive contribution

• Thought is largely a collective phenomenon
• Analogy between the collective properties of
  electrons vs. way our thoughts work
• Leads to an understanding of the general counter
  productiveness of thought

23
Bohms contribution, continued

• our thought is incoherent and the resulting
  counter-productiveness lies at the root of the
  worlds problems

Prepared by James R. Burns
24
More Bohm

• As electrons, we must look on thought as a
  systemic phenomena arising from how we interact
  and discourse with one another

25
Dialogue and Discussion

• Suspending assumptions
• Seeing each other as colleagues
• A Facilitator Who Holds the Context of Dialogue
• Balancing Dialogue and Discussion
• Reflection, Inquiry and Dialogue

26
Dialogue and Discussion

• Their power lies in their synergy
• No synergy without an understanding of their
  distinctions
• DISCUSSION--like a ping/pong game where the topic
  gets hit around
• subject is analyzed and diagnosed from many
  points of view
• Emphasis is on winning--having ones view
  accepted by the group

27
More Dialogue and Discussion

• A sustained emphasis on winning is not compatible
  with giving first priority to coherence and truth
• To bring about a change of priorities from
  winning to pursuit of the truth, a dialogue
  is necessary

28
Dialogue

• From the Greek, it means through the meaning
  meaning passing or moving through
• Through dialogue, a group accesses a larger pool
  of common meaning which cannot be accessed
  individually.
• The whole organizes the parts

29
More Dialogue

• Purpose is not to win, but to go beyond any one
  individuals understanding
• In dialogue, individuals gain insights that
  simply could not be gained individually
• In dialogue, individuals explore difficult,
  complex issues from many points of view
• Dialogue reveals the incoherence in our thought

30
The Purpose of Dialogue

• To reveal the incoherence in our thought--three
  types of incoherence
• Thought denies that it is participative
• Thought stops tracking reality and just goes,
  like a program
• We misperceive the thoughts as our own, because
  we fail to see the stream of collective thinking
  from which they arise
• Thought establishes its own standard of reference
  for fixing problems

31
Incoherent thought

• Thought stands in front of us and pretends that
  it does not represent
• We become trapped in the theater of our thoughts
• Dialogue is a way of helping people to see the
  representative and participative nature of
  thought
• In dialogue, people become observers of their own
  thinking

32
Suspending Assumptions

• HOLDING THEM IN FRONT OF YOU
• Difficult because thought deludes us into a view
  that this is the way it is

33
Seeing each other as Colleagues

• Necessary because thought is participative
• Necessary to establish a positive tone and offset
  the vulnerability that dialogue brings
• Does not mean that you need to agree or share the
  same views

34
Dialogue, Colleagues, and Hierarchy

• Choosing to view adversaries as colleagues
  with different views has the greatest benefits
• Hierarchy is antithetical to dialogue, yet is
  difficult to escape in organizations

35
Dialogue, Colleagues, and Hierarchy

• People who are used to holding the prevailing
  view because of their senior position, must
  surrender that privilege in dialogue, AND
  CONVERSELY
• Dialogue must be playful--playing with the ideas,
  evaluating and testing them

Prepared by James R. Burns
36
A Facilitator Who Holds the Context of Dialogue

• In the absence of a skilled facilitator, our
  habits pull us toward discussion and away from
  dialogue
• Carries out many of the basic duties of a good
  process facilitator

37
A Facilitator, Continued

• But the facilitator is allowed to influence the
  flow of development simply through participating
• As teams develop skill in dialogue, the role of
  the facilitator becomes less crucial

Prepared by James R. Burns
38
Balancing Dialogue and Discussion

• Discussion is the necessary counterpart of
  dialogue
• In discussion different views are presented and
  defended, which may provide a useful analysis of
  the whole situation
• In dialogue, different views are presented as a
  means toward discovering a new view
• Thesis Antithesis, leading to Synthesis

39
Dialog Vs. Discussion

• Dialogue established the view that leads to
  courses of action
• Discussion leads to new courses of action without
  establishing that new view
• Teams that dialogue regularly develop a deep
  trust that cannot help but carry over to
  discussion

40
Dealing with Current Reality Conflict, and
Defensive Routines

• An overbearing, charismatic, and intimidating
  posture
• Craig Bean his experiences at TI and why TI
  does not today own any share in the huge personal
  computer business
• Is there a conflict between alignment and being
  open to dialogue???

41
Great Teams vs. Mediocre Teams

• A team that is continually learning is the
  visible conflict of ideas
• In great teams, conflict becomes productive,
  inducing the need for ongoing dialogue
• Argyris the difference between great teams and
  mediocre teams lies in how they face conflict and
  deal with the defensiveness that invariably
  surrounds conflict

42
Defensive Routines

• Entrenched habits we use to protect ourselves
  from the embarrassment and threat that come with
  exposing our thinking.
• Form a protective shell around our deepest
  assumptions
• Forceful, articulate, intimidating CEOs
• Cannot be seen

43
Defensive Routines

• In some organizations, to have incomplete or
  faulty understanding is a sign of weakness or
  incompetence
• IT IS SIMPLY UNACCEPTABLE FOR MANAGERS TO ACT AS
  THOUGH THEY DO NOT KNOW WHAT IS CAUSING A PROBLEM
• To protect their belief, managers must close
  themselves to alternative views and make
  themselves uninfluenceable

44
Defensive Routines

• Defensive becomes an accepted part of
  organizational culture
• We are the carriers of defensive routines and
  organizations are the hosts
• Defensive routines block the flow of energy in a
  team that might otherwise contribute toward a
  common vision

45
A Shifting the Burden Archetype
Defensive Routines
Perceived need for new understanding and behavior
THREAT
Learning Gap
Need for Inquiry and change
Current Understanding and behavior
Delay
46
Maturity Models

• Software Quality Function Deployment
• Capability Maturity Model
• Project Maturity Model

47
Quality Function Deployment

• Translates the voice of the customer into
  technical design requirements
• Customer is King
• Displays requirements in matrix diagrams
• First matrix called house of quality
• Series of connected houses

48
Quality House
49
(No Transcript)
50
(No Transcript)
51
(No Transcript)
52
(No Transcript)
53
Capability Maturity Model

• Developed in preliminary form by Watts Humphries
  (published in a book he wrote that appeared in
  1989)
• Refined by the SEI (Software Engineering
  Institute) , a spin-off of Carnegie Mellon
  University in Pittsburgh
• Known as the CMM
• Discussed in Larson Gray, Ch. 16, page 575

54
Immature Software Organizations

• Processes are ad hoc, and occasionally chaotic.
• Processes are improvised by practitioners ON THE
  FLY.
• Testing, reviews and walkthroughs usually
  curtailed under stress.
• Quality is unpredictable.

55
Immature Software Organizations, Contd

• Costs and schedules are usually exceeded.
• Reactionary management is usually firefighting.
• Success rides on individual talent and heroic
  effort.
• Technology benefits are lost in the noise.

56
Mature Software Organizations

• Processes are defined and documented.
• Roles and responsibilities are clear.
• Product and process are measured.
• Processes and projects finish on time and within
  budget
• Management has time to plan, monitor, and
  communicate.

57
Mature Software Organizations, Contd

• Quality, costs, and schedules are predictable
• Management committed to continuous improvement.
• Technology is used effectively within defined
  processes.

58
Software Process Definition

• Project Planning
• Project Management
• Software Engineering Procedures
• Software standards
• Software Quality Evaluation
• Software Configuration management

59
The Five Levels of Software Process Maturity

• INITIAL
• REPEATABLE
• DEFINED
• MANAGED
• OPTIMIZING

60
Five Levels
61
Organization Project Management in the Long Run

• Capability Maturity Model (CMM)
• Focuses on guiding and assessing organizations in
  implementing concrete best practices of managing
  software development projects.
• Organizational Project Maturity Model (OPM3)
• Is divided into a continuum of growth levels
  initial, repeatable, defined, managed, and
  optimized.

62
Project Management Maturity Model
FIGURE 16.2
63
Initial

• Software processes are ad hoc, even chaotic
• The software processes are not defined
• Success depends on individual effort
• The environment is not stable

64
Initial, Continued

• The benefits of software engineering practices
  are undermined
• Planning is nonexistent or ineffective
• Process capability is unpredictable because the
  software process is constantly changed or
  modified as the work progresses

65
Repeatable

• Basic project management policies and procedures
  are established
• Cost, schedule and functionality (scope) are
  tracked by module and task
• A process discipline is put in place to repeat
  earlier successes
• Managing new projects is based on experience with
  similar projects

66
Repeatable, Continued

• Basic software management controls are installed
• Estimations of cost and time to complete are
  based on history for similar projects
• Problems are identified and documented
• Software requirements are baselined (made tough
  to change)

67
Repeatable, Continued

• Project standards are defined
• Project teams work with their customers and
  subcontractors to establish stable, managed
  working environments
• Process is under the control of a project
  management system that is driven by performance
  on previous projects
• A project performance database is defined and
  populated

68
Defined

• Software processes are documented
• Software processes are standardized and
  integrated organization-wide
• All projects use documented and approved versions
  of the organizations processes of developing and
  maintaining software
• A Software Engineering Process Group (SEPG) is
  created to facilitate process definition and
  improvement efforts

69
Defined, Continued

• Organization-wide training programs are
  implemented
• Organization-wide standard software processes can
  be refined to encompass the unique
  characteristics of the project
• A peer review process is used to enhance product
  quality
• Process capability is stable and based on a
  common understanding of processes, roles, and
  responsibilities in a defined process

70
Managed

• Quantitative quality goals are defined
• Product quality and productivity are measured and
  collected
• Both processes and products are quantitatively
  understood
• Both processes and products are controlled using
  detailed measures
• A productivity and quality database is defined

71
Managed, Continued

• Projects achieve control by narrowing the
  variation in performance to within acceptable
  boundaries
• Process variation is controlled by use of a
  strategic business plan that details which
  product lines to pursue
• Risks associated with moving up the learning
  curve of a new application domain are known and
  carefully managed
• Process capability is measured and operating
  within measurable limits

72
Optimizing

• Continuous process improvement is enabled by
  quantitative feedback
• Continuous process improvement is assessed from
  testing innovative ideas and technologies
• Weak process elements are identified and
  strengthened
• Defect prevention is explicit

73
Optimizing, Contd

• Statistical evidence is available on process
  effectiveness
• Innovations that exploit the best software
  engineering practices are identified
• Improvement occurs from
• INCREMENTAL ADVANCEMENTS IN EXISTING PROCESSES
• INNOVATIONS USING NEW TECHNOLOGIES AND METHODS

74
How are firms doing??

• Many U.S. firms have reached the highest level,
  OPTIMIZING
• Indian firms may be doing better

75
Organizational Project Management Maturity Model
(OPM3)

• 1. Ad-Hoc The project management process is
  described as disorganized, and occasionally even
  chaotic. The organization has not defined systems
  and processes, and project success depends on
  individual effort. There are chronic cost and
  schedule problems.
• 2. Abbreviated There are some project management
  processes and systems in place to track cost,
  schedule, and scope. Project success is largely
  unpredictable and cost and schedule problems are
  common.
• 3. Organized There are standardized, documented
  project management processes and systems that are
  integrated into the rest of the organization.
  Project success is more predictable, and cost and
  schedule performance is improved.
• 4. Managed Management collects and uses detailed
  measures of the effectiveness of project
  management. Project success is more uniform, and
  cost and schedule performance conforms to plan.
• 5. Adaptive Feedback from the project management
  process and from piloting innovative ideas and
  technologies enables continuous improvement.
  Project success is the norm, and cost and
  schedule performance is continuously improving.

76
Enter CMMI Capability Maturity Model Integration

• In 2007, the SEI asserted that it would no longer
  support the old SW-CMM.
• On Dec 31, 2007 all SW-CMM appraisal results were
  expired
• The purpose of the CMMI was to focus process
  maturity more towards project performance
• Organizations must now upgrade to the CMMI
• The CMMI is vastly improved over the CMM
• Emphasis is on business needs, integration and
  institutionalization

77
CMMI Staged Representation - 5 Maturity Levels
Process performance continually improved through
incremental and innovative technological
improvements.
Level 5
Optimizing
Level 4
Quantitatively Managed
Processes are controlled using statistical and
other quantitative techniques.
Process Maturity
Level 3
Processes are well characterized and understood.
Processes, standards, procedures, tools, etc. are
defined at the organizational (Organization X )
level. Proactive.
Defined
Level 2
Managed
Processes are planned, documented, performed,
monitored, and controlled at the project level.
Often reactive.
Level 1
Initial
Processes are unpredictable, poorly controlled,
reactive.
78
CMMI Origins

• The CMMI was derived from the
• SW-CMMcapability maturity model for software
• EIA/IS electronic Industries Alliance Interim
  Standard
• IPD-CMMCapability Maturity Model for Integrated
  Product Development
• CMMI architecture is open and designed to
  accommodate additional disciplines, like
• CMMI-DEV processes for development
• CMMI-ACQprocesses required for supplier sourcing
• CMMI-SVCprocesses required for services

79
CMMI cap mat model integration

• Level 0 Incomplete
• No goal.
• Level 1 Performed
• The process supports and enables achievement of
  the specific goals of the process area by
  transforming identifiable input work products to
  produce identifiable output work products.
• Level 2 Managed
• The process is institutionalized as a managed
  process.
• Level 3 Defined
• The process is institutionalized as a defined
  process.
• Level 4 Quantitatively Managed
• The process is institutionalized as a
  quantitatively managed process.
• Level 5 Optimizing
• The process is institutionalized as an optimizing
  process.

80
Use of this tool has shown

• The Engineering and Construction Industries have
  a higher level of maturity than do the
  information systems and software development
  disciplines

81
Completing and Terminating a Project

• James Burns

82
Completing

• Integration Testing
• Regression methods
• Final Testing
• Acceptance Testing
• Installation/Conversion
• Training

83
Purpose of Acceptance Testing

• to get paid every dime that you are owed!!
• When is the best time to write the Acceptance
  Test Plan
• Why???
• Who dictates what those tests will consist of?
• Do you think there should be at least one test
  for each and every defined requirement?

84
Final, Thorough Test

• Do beta testing??
• Run some old integration tests
• Devise true-to-life tests
• Try to overload the system
• Try to break it by entering wrong inputs, out of
  range values, etc.
• Test user documentation as well.

85
Installation

• going live

86
Training

• Usually, not enough budget is set aside for
  training
• At the mid-market level and lower, training
  budgets are slim
• On-line, context-sensitive help is one answer

87
Conversion

• Crash
• Parallel
• Pilot

88
Customer Survey

• Degree to which objectives were achieved?
• Degree to which users accepted and endorsed the
  product
• Overall satisfaction level
• Best if done by an outside survey agency or firm

89
Lessons LearnedHERE ARE SOME POSSIBILITIES

• Allow enough time?
• Make it fun?
• Beginnings are important!
• Top management support is critical!
• Managing change is 50 percent of project
  management!
• Make management reviews interactive!
• Set realistic milestone dates, but stick to the
  schedule!
• Plan at a workable level!

90
Closing Bash

• Party?
• Rap song?
• Actor?

91
Practices

• A walkthrough after every design phase is a good
  practice
• Architectural design
• Then a walkthrough
• Medium-level design
• A walkthrough
• Database design
• A walkthrough
• Detailed design
• A walkthrough

92
Software Tools--use them

• Librarians--keep track of who changed what when
• also called Code Management Systems
• Module Management Systems
• automate the building of an entire software
  system
• Visual Studio is one example
• Eclipse is another
• Performance Coverage analyzer
• determines where all the computing time is being
  spent
• traces sections of the system that were executed,
  their frequency and duration

93
More Tools

• Source code analyzers
• Tells you where youre doing strange or
  inefficient things in the source code
• Lets you find all usages of a particular variable
  or string
• Test Manager
• makes regression testing very simple
• Debugger
• Program stop, trace, and step through

94
Closing

• The closing process
• Provide a warranty
• Be willing to address any problems that crop up
  within a six-month period of installation

95
Termination

• Get paid
• History Database
• Lessons Learned
• Post project review (also called a POSTMORTEM)
• Write down what went well, what could have been
  improved, make suggestions for follow on
  projects, gather more statistics on actual vs.
  planned performance
• Produce a formal report
• Write follow-on proposal for next project
• Sell the next project

96
Maintenance

• Should be considered as a separate project,
  separately funded, so you can get paid for all of
  the development work

97
Checklist for Closeout Termination Stage

• New system is up and running smoothly
• Conversion and cutover from any older systems is
  complete
• End users are trained and comfortable with new
  system
• Warranty is provided
• The next project is sold
• A post project review (POSTMORTEM) is held
• Responsibility and method of ongoing maintenance
  is defined

98
User documentation

• Run/installation manual
• Users Guide
• Maintenance Guide
• Training documentation

99
Thats it, Folks