Admin at 10:14, 13 January 2017

2017-01-13T10:14:33Z

Admin at 09:36, 13 January 2017

2017-01-13T09:36:19Z

Admin at 09:31, 13 January 2017

2017-01-13T09:31:19Z

Show changes

Admin at 09:14, 13 January 2017

2017-01-13T09:14:43Z

Admin: Created page with "{{DISPLAYTITLE: Enterprise Maturity Guide - Introduction}} == An Introduction to the Enterprise Maturity Guide == In order for organizations to perform well in a global compet..."

2017-01-13T09:13:44Z

Created page with "{{DISPLAYTITLE: Enterprise Maturity Guide - Introduction}} == An Introduction to the Enterprise Maturity Guide == In order for organizations to perform well in a global compet..."

New page

{{DISPLAYTITLE: Enterprise Maturity Guide - Introduction}}
== An Introduction to the Enterprise Maturity Guide ==
In order for organizations to perform well in a global competitive world, it is important to identify the competitive advantages they can benefit from. Models to assess status of one’s capabilities and identify improvement opportunities, and in particular maturity models, that can help organizations assessing their current capabilities in a structured way to implement changes and improvements, has become essential. A maturity model can be described as a structured collection of elements that describe certain aspects of capability maturity in an organization. A maturity model may provide, for example:
*a situational analysis of one’s capabilities
*a place to start
*the benefit of a community’s prior experiences
*a common language and a shared vision
*a framework for prioritizing actions.
*a way to define what improvement means for your organization.
*a benchmark for comparison and an aid to understanding

In this section, we will focus on maturity models, what they are, their historic development, how they can be used and where one can use maturity concepts. This includes a detailed Enterprise maturity self-assessment, a benchmark among the various aspects that are related to the Enterprise maturity context as well as an Enterprise maturity development path.

=== Historic Development of Maturity Models ===
There are maturity models in multiple areas ranging from Software, Organizational Project Management Maturity, People Capability Maturity Model, Portfolio, Programme and Project Management Maturity, to concepts like E-learning Maturity. Maturity Models have existed for close to forty years and are therefore not a new way of evaluating the maturity level of a business. While maturity models for the most are accredited to Carnegie Mellon University Software Engineering Institute is this not really correct.

The first published maturity model was developed by Richard L. Nolan, who, in 1973 published the Stages of growth model for IT organizations. It didn’t take more than 6 years when Philip B. Crosby published 1979 in his book 'Quality is Free' the Quality Management Maturity Grid (QMMG), which is an organizational maturity matrix. The QMMG is used by a business or organization as a benchmark of how mature their initiatives are, and how well they are embedded in their culture, with respect to service or product quality management. The staged structure of the framework is based on total quality management (TQM) principles that have existed for nearly a century.

The work of Frederick Taylor and Frank Gilbreth on “scientific management” and time and- motion studies in the early 1900s eventually led to the new discipline of industrial engineering . In the 1930s, Walter Shewhart, a physicist at AT&T Bell Laboratories, established the principles of statistical quality control. These principles were further developed and successfully demonstrated in the work of such authorities as W. Edwards Deming (1986) and Joseph M. Juran (1988).

In recent years, the TQM concepts have been extended from manufacturing initiatives to service and engineering design initiatives. The software service can be defined as a set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products. As an organization matures, the software service becomes better defined and more consistently implemented throughout the organization. This, in turn, leads to higher-quality software, increased productivity, less rework, and improved software project plans and management. Crosby describes five evolutionary stages in adopting quality practices. As see in Table 1, the quality management maturity grid applies five stages to six measurement categories in subjectively rating an organization’s quality operation.

The five stages of the Quality Management Maturity Grid (QMMG) are:

{| class="wikitable" style="text-align: left; width: 100%;"
|-
| style="background: #0b98d6; color: #ffffff;" |
| style="background: #0b98d6; color: #ffffff;" | '''Stage 1: Uncertainty'''
| style="background: #0b98d6; color: #ffffff;" | '''Stage 2: Awakening'''
| style="background: #0b98d6; color: #ffffff;" | '''Stage 3: Enlightenment'''
| style="background: #0b98d6; color: #ffffff;" | '''Stage 4: Wisdom'''
| style="background: #0b98d6; color: #ffffff;" | '''Stage 5: Certainty'''
|-
| style="background: #f0f0f0;" | Management understanding and attitude
| No comprehension of quality as a management tool. Tend to blame quality department for "quality problems".
| Recognizing that quality management may be of value but not willing to provide money or time to make it all happen.
| While going through quality improvement programme learn more about quality management; becoming supportive and helpful.
| Participating. Understand absolutes of quality management. Recognize their personal role in continuing emphasis.
| Consider quality management as an essential part of company system.
|-
| style="background: #f0f0f0;" | Agile Driver & Forces (external/internal)
| Pressures that arise from outside or inside a system triggering agile approaches.
|-
| style="background: #f0f0f0;" | Backlog
| A prioritised list of requirements that are waiting to be worked on.
|-
| style="background: #f0f0f0;" | Bug
| An error, flaw, mistake, failure, or fault in the process models, process rules or process design that produces an incorrect or unexpected result, or causes it to behave in unintended ways.
|-
| style="background: #f0f0f0;" | Burndown chart
| A visual representation that shows work remaining over time.
|-
| style="background: #f0f0f0;" | Burnup chart
| A visual representation that shows work completed over time.
|-
| style="background: #f0f0f0;" | Business capability
| An abstraction that represents the abilities and the quality of being capable, intellectually (logical) and or physically. Agile enterprise developments must be able to specify the aptitude that may be developed for the enterprise and how it will perform a particular function, process or service.
|-
| style="background: #f0f0f0;" | Business change
| Changes in the way an organisation functions brought about through a project or other initiative.
|-
| style="background: #f0f0f0;" | Business resource/actor
| A specific person, system or organization internal or external that is part or effected by the agile development to the enterprise. This can include that the agile development will influence or impact the resources/actors defined functions and activities.
|-
| style="background: #f0f0f0;" | Business Service
| Agile concepts applied to business concepts will impact the change and development of business services. In terms of the externally visible ("logical") deed, or effort performed to satisfy a need or to fulfil a demand, meaningful to the environment.
|-
| style="background: #f0f0f0;" | Business Workflow
| A business workflow involved in the agile development, impacting and or changing the stream, sequence, course, succession, series, progression as well as order for the movement of information or material from one business function, business service, business activity (worksite) to another.
|-
| style="background: #f0f0f0;" | Continuous integration
| Where individual process models are combined in, for example, an entire end to end process flow and tested as soon as they are produced.
|-
| style="background: #f0f0f0;" | Cross-functional team
| A group of people with different skills and expertise working towards a common goal.
|-
| style="background: #f0f0f0;" | Defect trend
| A report that shows a rolling average of the number of problems (bugs) the team has opened, resolved and closed.
|-
| style="background: #f0f0f0;" | Definition of ‘done’
| An increment of a product that is ready for continual use by the end user. Can also be referred to as ‘done, done’.
|-
| style="background: #f0f0f0;" | Deployment
| All of the activities that make the process models ready for use and implementation.
|-
| style="background: #f0f0f0;" | Elaborate
| Where the delivery team adds detail to high-level business requirements.
|-
| style="background: #f0f0f0;" | Function
| These are sometimes called Epic Stories or Epics. Functions represent large sets of functionality, for example – Accounts receivable, Accounts payable , month-end close, etc.
|-
| style="background: #f0f0f0;" | Functionality
| The behaviours that are specified to achieve.
|-
| style="background: #f0f0f0;" | Information radiator
| A large, highly visible display which gives a picture of progress and key issues relating to an area of work.
|-
| style="background: #f0f0f0;" | Iteration
| A short time period in which a team is focused on delivering an increment of a product that is useable.
|-
| style="background: #f0f0f0;" | Kanban Board
| A visual board where columns represent a state that a user story can be in, for example – planned, blueprinting, realization, testing, done. Stories are arranged on the Kanban board and moved from one column to another as progress is being made. Many teams build physical Kanban boards by using tape and post-it notes. Digital Kanban boards are another alternative.
|-
| style="background: #f0f0f0;" | Lean
| Techniques to streamline processes and eliminate any activities that do not add value to the user.
|-
| style="background: #f0f0f0;" | Non-functional requirements
| Describe how the process models or enterprise concept projects should operate as opposed to functional requirements which describe how it should behave. Typical examples would be: wished behaviour, process security, accessibility, usability, availability, response times, etc.
|-
| style="background: #f0f0f0;" | Owner
| The person who is ultimately responsible for prioritization and acceptance of delivered features on a given process or project.
|-
| style="background: #f0f0f0;" | Performance Expectations
| While for the most tagged and classified as non-functional requirements, the performance expectations are more as they specify the desire for the manner in which, or the efficiency with which, something reacts or fulfils its intended purpose as anticipated by a specific stakeholder. It will give an input to non-functional requirements, however the performance expectations will also be used in the early validation and thereby be the baseline against performance testing.
|-
| style="background: #f0f0f0;" | Release
| Each release is associated with some type of go-live where a number of processes or enterprise concept projects are moved to roll out/production. For example, a “big bang” enterprise concept program could have just a single large release. A more phased approach could lead to many releases within a single program.
|-
| style="background: #f0f0f0;" | Release plans
| A plan that sets out the order in which user requirements will be released into live service.
|-
| style="background: #f0f0f0;" | Retrospective
| A retrospective is a focused session where your team looks back at how the current agile approach is working and which areas can be improved. Many agile teams conduct retrospectives at set intervals of time (every 8 weeks or at the end of every sprint).
|-
| style="background: #f0f0f0;" | Rework
| Components of a project that will need to be revisited to correct bugs or altered to meet new requirements.
|-
| style="background: #f0f0f0;" | Show and tell
| Where the delivery team demonstrates how the product or service works at the end of each iteration to elicit feedback.
|-
| style="background: #f0f0f0;" | Sprint
| A sprint is typically a pre-determined period of time (2 weeks, 4 weeks, 6 weeks, etc.) within which a set of identified user stories needs to be complete. Alternatives to sprints are to use a Kanban variation of agile project management methodology.
|-
| style="background: #f0f0f0;" | Stand-up
| A short meeting conducted standing up to report progress, share impediments and make commitments.
|-
| style="background: #f0f0f0;" | Task
| We generally try to avoid tracking detailed tasks, but sometimes we need to breakdown a single user story into multiple tasks and assign those to different people. For example this can by handy for tracking specific process design and development tasks. Each task belongs to one and only one user story. Generally speaking, it is the lowest level entity that we track.
|-
| style="background: #f0f0f0;" | Technical debt
| Poor process design in overall process architecture. The consequence of this is that more time is needed later on in the project to resolve process issues.
|-
| style="background: #f0f0f0;" | Testing
| A set of actions undertaken to assess whether a process or process model behaves as expected.
|-
| style="background: #f0f0f0;" | Test coverage
| The proportion of a process model that has been assessed.
|-
| style="background: #f0f0f0;" | Time box
| A fixed time frame, usually to undertake an intense increment of work.
|-
| style="background: #f0f0f0;" | User Story
| Each user story describes a particular business requirement and is assigned to a single function. In many ways a user story is the next level down in terms of detail after a function. The standard question approach is followed: “WHO is needed, WHAT we do, WHY we do it”. User stories are business-centric, not technology-centric. They do not capture HOW something will be accomplished (that comes later).
|-
| style="background: #f0f0f0;" | Value Expectation
| Tagging and classifying value expectations as non-functional requirements is a part of specifying the anticipated benefits that are of worth, importance, and significance to a specific stakeholder. It will give an input to non-functional requirements, however the value expectations will also be used in the customer orientation feedback loop, relating back to the specific stakeholders value expectations.
|-
| style="background: #f0f0f0;" | Value Proposition?
| A key principle of agile is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Agile enterprise concepts concepts need to adopt an empirical approach, accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to respond to changing value and or performance expectations and thereby emerging requirements and create specific value proposition to the new need/want.
|-
| style="background: #f0f0f0;" | Velocity
| The rate at which a team completes work.
|}

Table 1: The Quality Management Maturity Grid (QMMG).

[[Category: Maturity Assessment]]

← Older revision		Revision as of 10:14, 13 January 2017
Line 90:		Line 90:


−	[[File:The Enterprise Maturity Model Guide - Figure 1.png\|thumb\|400px\|left\|alt=~~Figure 1:~~ Figure 1: Overview of various Maturity Model concepts.\|~~Figure 1:~~ Figure 1: Overview of various Maturity Model concepts.]]	+	[[File:The Enterprise Maturity Model Guide - Figure 1.png\|thumb\|400px\|left\|alt=Figure 1: Overview of various Maturity Model concepts.\|Figure 1: Overview of various Maturity Model concepts.]]

@@ Line 61: / Line 61: @@
 | Reported: 6.5%<br>Actual: 8%
 | Reported: 2.5%<br>Actual: 2.5%
 |-
 | style="background: #f0f0f0;" | Quality improvement actions

@@ Line 27: / Line 27: @@
 {| class="wikitable" style="text-align: left; width: 100%;"
 |-
-| style="background: #0b98d6; color: #ffffff;" |
+| style="width: 16%; background: #0b98d6; color: #ffffff;" |
-| style="background: #0b98d6; color: #ffffff;" | '''Stage 1: Uncertainty'''
+| style="width: 16%; background: #0b98d6; color: #ffffff;" | '''Stage 1: Uncertainty'''
-| style="background: #0b98d6; color: #ffffff;" | '''Stage 2: Awakening'''
+| style="width: 16%; background: #0b98d6; color: #ffffff;" | '''Stage 2: Awakening'''
-| style="background: #0b98d6; color: #ffffff;" | '''Stage 3: Enlightenment'''
+| style="width: 16%; background: #0b98d6; color: #ffffff;" | '''Stage 3: Enlightenment'''
-| style="background: #0b98d6; color: #ffffff;" | '''Stage 4: Wisdom'''
+| style="width: 16%; background: #0b98d6; color: #ffffff;" | '''Stage 4: Wisdom'''
-| style="background: #0b98d6; color: #ffffff;" | '''Stage 5: Certainty'''
+| style="width: 16%; background: #0b98d6; color: #ffffff;" | '''Stage 5: Certainty'''
 |-
 | style="background: #f0f0f0;" | Management understanding and attitude

LEAD Reference Content:Enterprise Maturity Guide - Introduction - Revision history

Admin at 10:14, 13 January 2017

Admin at 09:36, 13 January 2017

Admin at 09:31, 13 January 2017

Admin at 09:14, 13 January 2017

Admin: Created page with "{{DISPLAYTITLE: Enterprise Maturity Guide - Introduction}} == An Introduction to the Enterprise Maturity Guide == In order for organizations to perform well in a global compet..."