• TODO V Merge in: SwDevFitpPgBusinessCaseCreation
• TODO N at some point, coordinate with WritingTheCharter

%X% It's about giving people what they need, not what they ask for(Rob04,c4,p1).

All projects, no matter what Problem Category they relate to, progress through the same series of tools in the Define phase. The purpose of Define is to ensure that(Wed06, sec2)

• The project scope is clear.
• The customer/market value is understood.
• The business value is understood.
• The measures of process performance are agreed upon and baselined.
• Clear breakthrough goals are set for the measures.
• There is business support to do the project in the form of a Project Leader and Team
  • (and all resources are freed up appropriately to do the project).
• There are agreed Champions and Process Owners for the project to ensure barriers are removed.
• This is the right project to be working on.
• See also: OrganizationalDashboard.

The general steps to follow: Objective: Understand the problem category(Wed06, ch01)

• Establishing the background
• Dashboard
• Ideation
• Develop the business case
• Compute the benefits of the Six Sigma project.
• assessing the risks and benefits of the project;
• forming the team;
• Activate the PD team.
• developing the project plan;
• writing the project objective.
• Pass the Define Phase tollgate review.
  • If a Six Sigma project does not pass the Define Phase tollgate review, then it is revised and resubmitted for a future tollgate review, or it is abandoned as an unfruitful area of inquiry.

Why do this project, what is the expected end result.

Often it is required to explore the problem domain, to be able to understand enough about the project to describe the projects to others.

To identify the business fit the background needs to be established, this can be done by addressing the following questions:

• Purpose of the project
• What is the problem (Is this in alignment with NLP? what will, answering this question, enable me to do?)
  • If this is in the initial phase, then the problem needs to be defined first.
  • define the problem
  • identify the problem
• What will doing the project at all enable us to do?
  • Describe why the project should be done, what drives the project.
  • Why should we take this project on
• What is expected to get out of it?
• What will doing the project now enable us to do?
  • What is the motivation for doing this project now
• What are the consequences of not doing the project?
• Is the project aligned with other business initiatives.
• What will be the impact on other business units and employees.
• ??? Link To Grand Parent Charter Business Objective:
• What SixSigmaObjectives are supported by the project?
  • What area objective(s) are driving this project.
  • TODO V So how do you do this part if you don't have access to the Business Prioritization Matrix?
  • Can you do anything but create the Charter and then simply go for it?
• Identify its location on the organizational dashboard
• Show its priority on the organizational project priority matrix

Often we first think of all the things that the product should be able to do. Or the features the product should provide.

So that is where we begin.

This is where the flood gates of ideas are opened.

Brainstorming, mindmaping

You could just list all the things that you want the product to do.

Write down the ideas in such a way that others will be able to understand the ideas, and that you can understand it yourself four weeks later.

• Capture in story cards?

When you are working on a subject that you do not understand, then it is very important to define the boundaries of what you are doing. e.g. Packet filtering. You need to define the requiremetns for it, but you need to flag what you know and what you do not know, so that the reviewers do not make false assumptions about the requirements. The reviewer(s) might extrapolate or expect more out of a requirement than what you actually have intended. They might know something is needed due to the requirement that you write, and expect that 'something' is part of your requriement, when in reality you don't have a clue that the 'something' is needed.

TODO C So how do you avoid this?

Only go through this if it hasn't been done yet.

What is the ache.

• MarketSegmenting#Audience_type_identification

In this section the description is listed in the order that it is expected to be filled into the SixSigmaCharterTable.

Name or identifier of the project. If you can make it catchy great, it could help. A boring name is probably better than a corny name.

%INCLUDE{SixSigmaProjectType}%

Describe in five sentences what this project is about, and why it should be done. See StandardParagraph.

• The reason for starting the project.
• This is what should inspire the participants

Mission statement TODO V this seems to be missing, I must have it somewhere else, get it described here.

aka: Productvision,

The productvision aligns all stakeholders in a common direction. The vision describes what the product is about and what it eventually could become(Wei03,48).

• For - target customer
• Who - statement of the need or opportunity
• The - product name
• Is - a product category
• That - key benefit, compelling reason to buy or use
• Unlike - [primary competitive alternative, current system, or current business process],(Wei03,53)
• Our product - [statement of primary differentiation and advantages of new product].(Wei03,53)

What are we selling. /What is the context. Is it the blue print or the Building we are selling?. %X% somewhere there was a reference to doing a SIPOC and explain which part we are changing.

The opportunity statement defines the problem and the effect it has on the business. The opportunity statement should address these questions:

%T% Note that the opportunity statement does not mention causes or solutions.

%X% TODO C Move the economical calculations to the end, ROI, NPV, IRR etc.

• What is wrong or not working?
• Where and when does the problem occur?
• What is the extent of the problem?
• What is the impact on customers?
• What is the impact on employees?
• What is the impact on the business overall?
• Does addressing the problems make strategic sense?

The opportunity statement describes the current and desired states of the problem, clear, concise, and measurable terms. It answers the question: "What is the pain?" (Git06, c4.4)

• Current state: What is the current state, relevant to the current project.

  • This is to introduce the reader to project. Put things in perspective.
    • Know where we are coming from in order to understand where we are going

• What has changed: objective being affected; The (main) objective(s), see 'Objective'

  • Measurable effect on objective: Data driven description.
  • What is wrong or not working? (WritingTheCharter)

• What could the consequences be: What is the consequence as a result of the change?

  • Where and when does the problem occur?(WritingTheCharter)
  • What is the extent of the problem?(WritingTheCharter)

• Consequence(if not changed): What is the result if no changes:

  • What is the impact on customers?(WritingTheCharter)
  • What is the impact on employees?(WritingTheCharter)
  • What is the impact on the business overall?(WritingTheCharter)

• Desired state(what):

• When:

• gain at desired state: Result(why?):

  • Does addressing the problems make strategic sense?(WritingTheCharter) %X% Isn't this part of the Business fit?
  • What are the reasons for change? VOC/VOB Gaps? Are the reasons 'significant' enough to warrant major change? (OT)
  • It provides a high-level description of the issue and reasons why the project is a business priority.
    • Has the value of the benefits been quantified?
  • TODO V There is probably room for a SmartGoal formulation here... (Desired state +when)

• Example:

  • (Current state) The competition has developed a product similar to our flagship product. Although it has a few minor new features, its quality is well-received by customers and its price is 15% lower than our price.
  • (Effect) This could lead to erosion of market share, making it difficult to achieve our business objective of 'Increasing Market Share by 2%.'"
  • (Desired state) "Marketing and sales estimate that a new version of our flagship product, with some significant new customer-desired features, could reverse the projected market share erosion. If it could be released by the end of the fiscal year and priced competitively, (Gain) we could gain 2,3% market share beyond current levels."

• For a commercial product, describe the market opportunity that exists and the market in which the product will be competing.(Wei03,51)

• For a corporate information system, describe the business problem that is being solved or the business process being improved, as well as the environment in which the system will be used.(Wei03,51)

• Include a comparative evaluation of existing products and potential solutions, indicating why the proposed product is attractive and the advantages it provides. (Wei03,51)

• Describe the problems that cannot currently be solved without the product.(Wei03,51)

• Show how it aligns with market trends, technology evolution, or corporate strategic directions.(Wei03,51)

• Include a brief description of any other technologies, processes, or resources required to provide a complete customer solution.(Wei03,51)

• What should the feature provide:

  • Specific:
  • Measurable:
  • Atianable:
  • Relevant:
  • Time bound:

See also:

Transfer the 'Initial market segments' from the InitialCharter, so we have an idea of whom the customers are, and what their needs are.

See: MarketSegmenting

And: #MarketSegmentInBusinessCase

Getting all the ideas down on paper.

• Pour your ideas out.
• List all the stuff you want from this project.
• methods
  • Reasons
  • UseCase
  • CreateStoryCard (StoryCardForm)
  • SipocProcess (Maybe this should go down to the Scope part of this phase.
• No bars held.
• this does or/should not be, the full list of what the project must provide, just enough information to indicate a direction.
  • Steps further on in the project will capture the actual requirements.
• LateralThinkingHabbits
• SixSigmaKanoSurvey - This is probable for the SixSigmaDmadvMeasure phase.
• MindMap
  • Apps: [[http://freemind.sourceforge.net][Freemind]] runs on OSX, Linux and windows. [[http://www.ithoughts.co.uk/Start/Welcome.html][iThoughts]] runs on iPAD and iPhone, iPOD Touch.

1 Market segmentation 1 Project description 1 Initial project objective 1 Project scope 1 Business fit

MarketSegmentInBusinessCase

Follow: MarketSegmenting and fill out e.g. a MindMap.

• Describe the needs of typical customers or of the target market segment, including needs that current products or information systems do not meet.(Wei03,53)
• Present the problems that customers currently encounter that the new product will address and provide examples of how customers would use the product.(Wei03,53)
• Define at a high level any known critical interface or performance requirements, but do not include design or implementation details.(Wei03,53)

Fill in the 'Market segments' part of the SixSigmaCharterTable

For each market segment, identified, fill out the entries:

• Use:
  • Behavioral:
    • Brand loyalty: Low/Mid/High.
    • Rate of use: How often is the tool used. Tools being used seldom must be more intuitive to be easy to get back to.
    • Benefits sought from usage: Primary purposes of usage. Get info from 'Audience type identification'
  • Where is it used: Get info from: 'Audience type identification'.
• Type of organization: 'Market type -> Consumer -> Type of Organization'
• Customer size: 'Market type -> Consumer -> Customer size'
• Key purchasing criteria: 'Market type -> Consumer -> Key purchasing criteria'
  • personal characteristics of purchasing agent:
  • purchasing strategy variables:
  • competitive bidding on price assuming equal quality versus competitive bidding on quality and price:
• Importance of purchase: 'Market type -> Consumer -> Adventure designer'

This is your summary of the whole project. It's you selling spiel. And the key points of the project.

Write a short description of project, then list the key features. I wonder if the 'description' part is covered by the Mission statement? If not what would the difference be?

find the general concept/direction of the project.

The first step is to get a bearing, to loosely frame the project.

Do an affinity diagram (AffinityDiagramCreation) to the the brainstorm input organized and find the key features.

Are the cardinal points: What, Why, How ?; It is probably: What problems are we solving...

%T% Where the 'mission statement' faces the customer, the 'Goal statement' of the Project Description phases the team members.

The goal statement defines the project in measurable terms. It provides the specific success criteria. The goal statement should address these questions:

• What will the improvement team accomplish?

• How will the team's success be measured?

• What parameters specifically will be measured?

• What are the deliverables of the project?

• What is the timetable for delivery of results? The goal statement should be very specific in terms of outcomes.

• Identifies a specific process that you are going to improve and level of performance.

• Goal Statement should be measurable and reference a process.

• Project Scope - Bound the process and focus on something that can be achieved in 3-6 months.

• What is the specific, measurable goal you are attempting to achieve?

  • M13: Critical Success Factors
  • (M15: Describe the idea)

• Goal Statement: Write a 'single' goal statement for your project

  1. Measurable
  2. Time bound
  3. Specific to a single process

See also 'Business Objectives and Success Criteeria' in (Wei03,52)

TODO V This was also missing here, I have a nagging feeling that I have another description of how to do Charters, somewhere else.

See 'Major Features' in Wei03,p54 Giving each feature a unique label (as opposed to a bullet) permits tracing it to individual user requirements, functional requirements, and other system elements(Wei03,54).

%X% TODO V find out how M tag this.

A project objective describes a team's design objective. It uses the template: To Action CardinalObjective of Project in MarketSegment Direction of Measure to Target by Deadline.

• Action: See also SixSigmaDmadvAnalyze for the 'effort level needed to create design concepts'
  • Improve: Improve a process,product etc. Level A.
  • Create: Create a Process,product etc. Level B.
  • Innovate: Level C.
  • Invent: Level C+
• Cardinal Objective: See the Cardinal SixSigma Objective list below.
• Project: product, service, or process. %X% Find a better word that sums up Product,Server and Process.
• Market segment(s): (This looks like part of the Business plan thing). Who are the final customers that are affected by this Charter?. Who are the customers of the product, service or project.
  • Would stakeholders be acceptable to use here? What is the definition of stakeholders?
  • It seems to me that it would actually make quite a lot of sense to use stakeholders in this, then one could group a number of these stakeholders into market segments. That way there would be a better data path or more direct data path from the objective to the market segment. A more clear path.
• Direction: Increase, Decrease.
• Measure: The measure of success; market share, sales, ROI, etc.
• Target: What is the goal of the measure.
• Deadline: When is the project expected to be done. When you are developing a Charter, you might not have a fixed deadline date, in that case write the calendar time the project is expected to take.
• Example: "To create a high-end living facility that encourages learning and community (service) aimed at executives in residence, MBAs, and junior and senior undergraduate business students (market segments). It should increase (direction) the number of on-campus residents (measure) by 200 students (target) no later than July 15, 2003 (deadline)."

%INCLUDE{SixSigmaObjectives}%

TODO V Describe how to calculate it, See SixSigma

TODO V Describe how to calculate it.

TODO V Describe how to calculate it.

%T% Not used in Phase0

The project scope sets the project boundaries.

You need to state both what the system is and what it is not(Wei03,54).

• The Scope defines what the project will do and what it will not do. *The scope description establishes the boundary and connections between the system we are developing and everything else in the universe.(Git06, 4.6)

• Is scope the same as goal?: The scope is what the project entails, including the goals, but it also defines what is part of the project and what isn't part of the project.

• What should the product do

  • Brainstorm elements of the project.
  • MindMap of what the product must do/contain

• Do SIPOC, to help define the process(Wed06,ch2)

• Do ContextDiagram

• Do the BusinessUseCase's of the ContextDiagram

• Do In-/Out- scope

  • Write each element on a self-stick note.
  • Draw a frame on a flipchart to indicate project boundaries.
  • Place the notes either inside or outside the frame's boundaries to show whether the element is within the team's scope or not.
    • Out-of-bounds project elements are identified by answering the question: "What, if anything, is out-of-bounds?"

• Fill out Scope table.

| In-Scope | Out-of-Scope | | | |

Everyone should agree on the scope of the project. If the scope is deemed too large, it should be split into smaller projects.

The projectscope identifies what portion of the ultimate long-term product vision the current project will address(Wei03,48).

• What are the boundaries?

• What are the first and last steps of a process?

• What are the first and last steps of the initiative?

• what parts of the business are included?

• What part of the business is not included?

• What is outside of the team's boundaries?

• Identify the process you are changing. Where does it start and stop.

• Identify departments that touch the process

• Meaningful: Meaningful projects have impact on customers, expenses, productivity, and profits. Since you will be spending up to six months working on the project, you want to be sure there is a benefit to be gained from the time and effort invested. Solving the problem of how many chocolate chips are in the cafeteria cookies may make some employees happy, but it won’t improve the bottom line.

• Manageable: Manageable projects can realistically be accomplished with practical effort within a reasonable span of time. Some projects require too many people, too much time, and too much money. These are not manageable projects. Always make sure your project is within your scope of control.

%INCLUDE{SipocProcess}%

• Do SIPOC, to help define the process(Wed06,ch2)

The central "Process" column of the SIPOC can be extracted and rotated 90� to become a High-Level Value Stream Map(Wed06, ch2).

See: ValueStreamMap

%X% TODO C I think the problem domain part belongs in SwDevFitpPgStage2ProductDefinition or later, it seems too detailed for this level.

(Rob06,c3,p10)

• Possibly do this MindMap style.

• Entity: In this case, the computer systems, or the parts that you are not changing, are adjacent systems(Rob06,c4,p9).

  • If this is the top level Problem Frame/Context diagram, then each entity is probably a problem domain, in its own right.

• Machine: Configure Machine M to produce effects R in domain D (Kov99,25).

The problem is split into domains to(Kov99,61):

• Limit scope of concern(Kov99,61).
  • %X% How do we avoid turning this into a packing problem? How do I keep it in the Mapping sphere?
• Be able to talk about causation, and other relations between domains.

Shared phenomena:

• states

• events

• objects

• Listing all the parts of the domain that you can think of

  • Is this kind of the OOD thing?

• Identify the work(what the customer needs to do, and how the product can support that)

The purpose of this ContextModel it to give a graphical presentation of what is in scope, and what is out scope.

The purpose of tools such as the context diagram is to foster clear and accurate communication among the project stakeholders(Wei03,56).

The context diagram graphically illustrates this boundary. It identifies terminators outside the system that interface to it in some way, as well as data, control, and material flows between the terminators and the system. The context diagram is the top level of abstraction in a data flow diagram developed according to the principles of structured analysis (Robertson and Robertson 1994), but it's a useful model for projects that follow any development methodology(Wei03,56).

From the SipocProcess description/table

• Adjacent systems: In this case, the computer systems, or the parts that you are not changing, are adjacent systems(Rob06,c4,p9).

  • If this is the top level Problem Frame/Context diagram, then each entity is probably a problem domain, in its own right.

• Connector: According to Soren, in the [[http://en.wikipedia.org/wiki/Structured_analysis][Hatley-Pirbha Structured Analysis]]. All input/output must be shown on the top level(not necesarrily in detail) no new I/O is allowed at lower levels.

• The Work: Configure Machine M to produce effects R in domain D (Kov99,25).

• Do First-Cut Work Context(Rob06,c3,p11)

%X% TODO V What detail level is right?/Needed? It seems to be rather important since we base rough estimates on it.

Create a table wir a description of the Entities of the ContextDiagram

| Entity | Type | Description | Reference | | | | | | | | | | | | | | | |

• Description: Short description of the Entity.
• Entity: Name of the entity.
• Reference: Link to a more detailed description of the the Entity.
• Type: Adjacent, Connector, TheWork

%X% It seems like the Context model are based on building a Problem Domain Frame, See (Kov99,53)

Describe the Problem domain

• Entities: (Kov99,41)
  • Attributes: (Kov99,41)
  • Events: Events the Entities are capable of
• Cardinalities of relations between entities: (Kov99,41)
• Causal rules: (Kov99,42)
• Interfaces: (Kov99,42)
• Data formats: (Kov99,42)

So it goes:

• Understand what is required, what is the boundary of the problem domain. The Premises.
  • You should have a set of upstream requirements, or a problem statement.
• Identify each entity in the problem domain.
• Identify what information that is exchanged between the machine domain and each Entity.
  • Problem Domain(Rob06,c3,p12).
  • Shared phenomena(Kov99,61)
• Identify the Problem domains(Kov99,)/(Rob06,c3,p9-11)

%X% How do you identify that all systems and contexts have been identified? Is there a common list of areas that should normally be covered.

• Security
• Update
• UI

Is this possibly the Quality areas?

Do AffinityDiagramCreation.

Next we want to find the cardinal operations/solutions.

One way to do that is, for each entry in the idea list do: %INCLUDE{FiveWhys}%

See also LateralThinkingHabbits

Then categorize the ideas by the Root Cause.

The purpose is to identify the smallest list that covers the identified areas. In the next step the condensed list is then translated into a list of problems that the product is to solve.

• Come up with a loose definition on what the focus is for the product.
• Split into In-Scope and out-Scope ideas, based on the focus.

When you have consolidate the ideas/feature, then extract the essence of what problems the product must solve.

Go through the Cardinal SixSigmaObjectives, for each entry that fits the product, describe how the product fits the particula SixSigmaObjectives.

See also

• SixSigmaObjectives
• CodeDev.SixSigmaDmadvDefine

%X% TODO C I think this needs to go to the SwDevFitpPgStage2ProductDefinition/ItpPhase4.

Possibly this could also use some of the QFD stuff.

• Murphy's Analysis:
• Customer Interviewing: Interview representatives for each Stakeholder? To get richness of data possibly needs 12-20 interviews(Wed06,ch2), expect 1-2 weeks
• Customer Surveys: Web site, e-mail, hand out, Hang on wall. Expect 1 week to get back. Surveys are notoriously error prone, so do not rely on this as your main source of Customer input - use the interviews instead(Wed06, ch2).
• Affinity Diagramming:
• Customer Requirements Trees:
• 5 Whys:
• Key Process Output Variables (KPOVs): Determining the Ys is done by taking the output of the Customer Requirements Tree and firming up Operational Definitions of the key metrics. For each metric, a baseline measure is made.

aka Business Case aka Business Results See: SwDevFitpPgBusinessCaseCreation#Business_case

The business case describes the purpose of a project.

It provides a high-level description of the issue and reasons why the project is a business priority.

The business case shows how the project relates to the big Y, the major output of the process that determines organizational success.

The business case establishes links to the customer, business goals, and business initiatives.

• What benefits will be derived?
• Has the value of the benefits been quantified?
• What are the reasons for change? VOC/VOB Gaps? Are the reasons 'significant' enough to warrant major change?
• What's your burning platform?
• What's broken? What are we losing?
• What's the linkage to big Y? Big Score Card Goals
• What's the linkage to small Y? lower level Score Card Goals
• Vital X: What do we actually wish to do, within this charter.
• Summarize the rationale and context for the new product(Wei03,51).
• %T% Take the 'Strategy Alignment' from M15 preparation.

Record any assumptions that the stakeholders made when conceiving the project(Wei03,54). This avoids possible confusion and aggravation in the future(Wei03,54).

. Also record major dependencies the project has on external factors outside its control(Wei03,54).

%T% Not used in Phase0

Before you can identify the Project objectives, it is a good idea to ensure an overall understanding of the project.

Your understanding of the project needs to be at a level where you can transfer the general understanding to others.

Once you have the holistic view/understanding then you are ready to identify the Project Objectives.

%X% How can I be sure that everything has been covered???

TODO V The list here should probably be moved further down the define list, I don't think it makes sense here.

• List all Cardinal SixSigmaObjectives that are relevant to this project.
  • It would seem that it might be worth trying to go through each of the key features and link those features to all relevant Cardinal SixSigmaObjectives
• For each of these objectives list how much it affects the project, in %. %X% is this a kano like thing, or pugh matrix.
  • We want to focus on the most important objectives, the biggest bang for the buck (ROI)
• For each objective list which market segment is affected by it, and how and how much it affects the market.
• Fill in the Project Objective

It consists of

• Product
• relevant market segment
• Measure of success
• Direction
• Target
• Deadline

The objective starts with: Invent, Innovate or Create(Git06,4-6).

A project objective describes a team's design objective. It uses the template: To Action CardinalObjective of Project in MarketSegment through Direction of Measure to Target by Deadline.

• Action: See also SixSigmaDmadvAnalyze for the 'effort level needed to create design concepts'
  • Improve: Improve a process,product etc. Level A.
  • Create: Create a Process,product etc. Level B.
  • Innovate: Level C.
  • Invent: Level C+
• Cardinal Objective: See the Cardinal SixSigma Objective list above.
• Project: product, service, or process. %X% Find a better word that sums up Product,Server and Process.
• Market segment(s): (This looks like part of the Business plan thing). Who are the final customers that are affected by this Charter?. Who are the customers of the product, service or project.
  • Would stakeholders be acceptable to use here? What is the definition of stakeholders?
  • It seems to me that it would actually make quite a lot of sense to use stakeholders in this, then one could group a number of these stakeholders into market segments. That way there would be a better data path or more direct data path from the objective to the market segment. A more clear path.
  • TODO V For each section, describe what and why.
  • See also MarketSegmenting
• Direction: Increase, Decrease.
• Measure: The measure of success; market share, sales, ROI, etc.
• Target: What is the goal of the measure.
• Deadline: When is the project expected to be done. When you are developing a Charter, you might not have a fixed deadline date, in that case write the calendar time the project is expected to take.
• Example: "To create a high-end living facility that encourages learning and community (service) aimed at executives in residence, MBAs, and junior and senior undergraduate business students (market segments). It should increase (direction) the number of on-campus residents (measure) by 200 students (target) no later than July 15, 2003 (deadline)."

The vision is a summary of what the product accomplishes.

This description will be your sales pitch, the guiding light for whomever is working on the initial part of the project write up.

• What are you selling
  • In order to provide an precise summary you need to understand what your product is.
  • Blue prints
  • or the finished building.
• Why is it worth investing in
• This is you 90 seconds sales pitch find out how long it actually takes to pitch this. Test it on various people.
• The Vision for the project.
  • Perhaps think of this as a kind of clean-room thing, somebody should be able to take these key points, and from them formulate the project. (Perhaps you can test this yourself) If this is successfull, then you have successfully been able to convey the essence of your project.
• List the problems that the product will solve are the reasons for the project.
• Don't list the solution to the problem, list the general concept that is going to be solved.

At first just write down what is on your mind, then edit it later/afterwards (Ran Look this up).

For the process part:

• identify which part of the process are you concerned with.
• It should be clear what process you are trying to improve (Charter Element 1).
• The process provides the focus and context for the work. A clear process definition helps the Black Belt see where the work will focus and what needs to be accomplished.
  • Identifying the process is often difficult for those persons and organizations that are not skilled in thinking about their work as a series of interconnected processes[[DevelopingTheCharter][See here]].

The vision is written as a StandardParagraph.

%INCLUDE{StandardParagraph}%

The project plan presents how the goals will be approached and achieved. It should document the major milestones and the timing. The project plan:

• Documents the major milestones of the project
• Defines the project activities
• Defines when activities begin
• Defines when activities will be completed

In Six Sigma process improvement projects, the major milestones are often the five steps in the DMAIC process. In new product, process, or service-development projects (Design for Six Sigma), the major milestones are often the five steps of the DMADV process; and in Digitization for Efficiency, and the major milestones are often the six steps of the DMADDD process.

It is important that a project reach its goals in the time allotted.

1 Identify Obstacles to the completion of the project 1 Identify resource constraints

• Budgetary issues; Planning, design, construction and maintenance costs.
• Time commitments expected from team members and the acceptable impact on their normal jobs. 1 Appoint Project manager with fiscal responsibility.

See Scope Planning in (Ste08, c5, p 149)

(Git06, c4.7)

• When estimating time for at task, it could be helpful to provide factor dependt on the persons knowledge. So e.g.
  • an expert would have a factor of 0.7 and a cost of 1.3
  • Intermittent would have a factor of 1 cost 1
  • Noob would have a factor of 2.0 and a cost of 0.6
  • All of this data could then go into the discussion on how to plan a project, and how to populate it.

If you envision a staged evolution of the product, indicate which features will be deferred and the desired timing of later releases(Wei03,55).

(Git06)

Use MGPP to:

• avoid scope creep.

• hold the vision for the future

• by having a future vision, avoid make decision that will make future changes harder

• provide a structure for adding ideas generated throughout the project.

• Write Multi-Generation Product Plan (MGPP).

• Identify the tasks of the project by answering the following questions:

  • What are the steps in the flowchart for completing this project?
  • Does this activity produce any outputs that are required in another activity?
  • What inputs does this activity require and where do they come from?
  • Can Activity A be completed independently of Activity B, etc.?
  • What activities must be completed so that this activity can be completed?
  • Where or how are the outputs of this activity used?

• Identify the milestones for each task.

• Identify individuals responsible for each task.

• Identify the start and stop dates for each task (duration of task).

• Identify the resources needed for each task and check against the budget.

| Task | Resp. | Month |||||||||||| |^|^| jan | feb | mar | apr| may| jun| jul |aug | sep |oct| nov |dec | | Define | | | | | | | | | | | | | | | Measure | | | | | | | | | | | | | | | Analyze | | | | | | | | | | | | | | | Design | | | | | | | | | | | | | | | Validate | | | | | | | | | | | | | |

ue the table to characterise your project, as a generation 1,2 or 3. |Generation|Generation 1|Generation 2|Generation 3| | Vision |Stop bleeding in existing market(s). |Take offensive action by filling unmet needs of existing market(s). |Take leadership position in new market(s).| | Product/Service Generations |Improved or lessexpensive existing features. |New major features. |New products, services, or processes.| | Product/Service Technologies and Platforms |Current technology. |Current technology with relevant technological enhancements, if any. |Current technology plus new technology, if possible.|

|Generation|Generation 1|Generation 2|Generation 3| | Vision | | | | | Product/Service Generations | | | | | Product/Service Technologies and Platforms | | | |

Milestones should:

• Flow naturally
• Represent important decisions
• Be controllable
• Be limited in number (10 - 15)
• Occur at useful intervals
• Require similar activities to complete
• Be complete sentences
• Be a statement ("When the proposal is completed and accepted by the division manager," not "When the proposal is completed")

When you develop your project milestones:

• Avoid focusing on activities
• Involve team members who will be responsible for milestone implementation
• Address technical, cultural, time, cost, and quality elements
• Choose carefully according to scope (do not underestimate tasks)
• Use previous project experience as an estimate only
• Group milestones into logical sequences or result paths

This worksheet can help you develop your milestones.

| Milestones Worksheet || | Milestone | Estimated Completion Date | | | | | | | | | |

Activities are smaller tasks that help you reach milestones. To successfully plan activities:

• Plan well before the work should start in order to prepare people and resources (rolling wave approach)
• Involve those who will be committed to the work in a detailed planning process to instill ownership and commitment
• Plan controllable activities (work segments of fewer than 80 hours) to produce measurable results

| Activities Worksheet ||| | Activity/Milestone | Estimated Completion Date | Function | | | | | | | | | | | | |

|#| Success Predictors | Rating | | 1| Project is a strategic priority, aligned with a Big Y| | | 2| Key stakeholders are willing to try new solutions | | | 3| There are sufficient reasons for change | | | 4| There is a clear and measurable goal | | | 5| A significant ROI expectation has been established | | | 6| Right vertical & horizontal team members are available | | | 7| Several team members are top talent and innovative thinkers | | | 8| Management is willing to commit serious resources to solutions | | | 9| Project is capable of completion within 3-6 months | | | 10| Full time, capable DSS advisor assigned | | | | Total Success Probability Rating | |

Rating/Priority: Yes=2, Partial=1, No=0

Risk categories include

• marketplace competition(Wei03,53),
• timing issues(Wei03,53)
• user acceptance(Wei03,53)
• implementation issues(Wei03,53)
• possible negative impacts on the business(Wei03,53) Estimate the
• potential loss from each risk(Wei03,53)
• likelihood of it occurring(Wei03,53)
• your ability to control it(Wei03,53)
• Identify any potential mitigation actions(Wei03,53)

• High=18-20
• Medium= 15-17
• Low = 1-14

| Key DSS Project Organization Members|Weak|Med|Strong| | Sponsor Executive w/ resource & authority to make it happen | | | | | Functional process experts representatives who touch different areas of the process (vertical & horizontal) TOP TALENT! | | | | | Assumption Busters, Creative Thinkers, Devil's Advocate (30%)| | | | | Key Customers & Suppliers (ad hoc)| | | | | DSS Resource (MBB/BB/DSS Leader)| | | | | Key Executives/Managers impacted by solutions (ad hoc)| | | | | IT Resource (ad hoc)| | | |

Stakeholders are the individuals, groups, or organizations who are actively involved in a project, are affected by its outcome, or are able to influence its outcome (Project Management Institute 2000; Smith 2000)(Wei03,55).

Each stakeholder profile should include the following information(Wei03,55):

• The major value or benefit that the stakeholder will receive from the product and how the product will generate high customer satisfaction. Stakeholder value might include
  • Improved productivity(Wei03,55).
  • Reduced rework.(Wei03,55)
  • Cost savings.(Wei03,55)
  • Streamlined business processes.(Wei03,55)
  • Automation of previously manual tasks.(Wei03,55)
  • Ability to perform entirely new tasks.(Wei03,55)
  • Compliance with pertinent standards or regulations.(Wei03,55)
  • Improved usability compared to current products.(Wei03,55)
• Their likely attitudes toward the product.(Wei03,55)
• Major features and characteristics of interest.(Wei03,55)
• Any known constraints that must be accommodated.(Wei03,55)

Commitment Level:

• 0 = current commitment level
• X = needed commitment level

do FMEA. %X% Though it seems like there are some present and danger to the project execution, and then the risks in the project itself.

The financial impact of a project is a best estimate that will be refined through iterative learning over the life of the project.

• Cost Reduction: Cost reduction includes costs that fall to the bottom of the profit and loss statement. A cost reduction can be used by management to offset price, increase profit, or reinvest elsewhere.

• Cost avoidance: includes those costs that can be reduced, if management chooses to do so; but until action is taken, no real costs are saved. Examples include reducing labor hours needed to produce some fixed volume of work. Unless the headcount that produced this fixed volume is reduced (e.g., through attrition) or unless there is an increase in volume of work completed with the same headcount, then there are no real savings realized. The impact of cost avoidance is not visible on the profit and loss statement and is difficult to define, but is still important in meeting organizational goals.

• Tangible Costs: the costs of rejects, warranty, inspection, scrap, and rework. (Git06, ch 4.9)

• Intangible Costs: the costs of long cycle times, many setups, low productivity, engineering change orders, low employee morale, turnover, low customer loyalty, lengthy installations, excess inventory, late delivery, overtime, lost sales, and customer dissatisfaction.

• Cost Reductions ________________________________________

• PLUS Cost Avoidance ____________________________________

• PLUS Additional Revenue __________________________________

• LESS Implementation Costs __________________________________

• EQUALS Financial Benefits __________________________________

(Git06, )

Is this the same as 'Hazard Escalation matrix for those unforeseen circumstances' in (Wed06,ch2)

1 Identify the process, product, or service under study, as well as all related processes that might cause or experience collateral damage from the design project. 1 Identify risk elements for each process. 1 Assign risk element scores for each process step using the following two scales. * Probability of Occurrence Scale 1- 5 * Impact of Problem Scale 1 - 5 1 multiply both scales for each risk element to compute a risk element score 1 prioritize the risk elements for all relevant processes, products, or services * Column 1: states the name of the process, product, or service. * Column 2: lists the risk element(s) (for example, failure modes) for the process, product, or service. * Column 3: lists the potential source(s) of harm (hazards) for each risk element. * Column 4: lists the source(s) of actual injury or damage (harm). * Column 5: shows the likelihood score. * Column 6: shows the severity score. * Column 7: shows the risk element score. 1 construct risk abatement plans for risk elements with high- and medium-risk elements; that is, a risk element score of 16 to 25 1 identify changes to the process under study to reduce the risk for each high- and medium-risk element in the related processes identified 1 estimate the risk element score after the risk abatement plan is set into motion 1 identify the risk element owner and set a completion date for the risk abatement plan to become operational 1 document the risk abatement plans 1 carry out the risk abatement plan. 1 1

In this phase of the DMADV model, you use FMEA (see Table 4.16) to reduce the high- and mediumpriority risk elements (risk element score > 15).

| | Impact of Problem on Project |||| | | | Low (1) | Medium (3) | High (5) | | Probability of Occurrence of Problem | High (5) | Fix before production (5) |Reassess project (15) |Do not proceed (25)| |^| Medium (3) | Proceed with caution (3) |Proceed with great caution (9)| Reassess project (15)| |^| Low (1) | Proceed (1) | Proceed with caution (3) |Fix before production (5)|

| Format for a Risk Abatement Plan ||||||| | 1 |2 |3 ||4 |5 |6| |Potential Risk Elements for Process| Potential Harm for the Risk Elements from Process |Risk Element Score || Countermeasure (Risk Abatement Plan)| Risk Owner| Completion Date for Countermeasure| |^|^| Before| After| ^| ^ | ^| | | | | | | | |

%INCLUDE{ProblemCategory}%

To enable effective decision making, the stakeholders must agree on the project�s priorities(Wei03,56). One way to approach this is to consider the five dimensions of a software project(Wiegers 1996a):

• features (or scope),(Wei03,56)
• quality(Wei03,56)
• schedule(Wei03,56)
• cost(Wei03,56)
• staff.(Wei03,56) Each dimension fits in one of the following three categories on any given project(Wei03,56):
• A constraint - A limiting factor within which the project manager must operate
• Driver - A significant success objective with limited flexibility for adjustment
• Degree of freedom - A factor that the project manager has some latitude to adjust and balance against the other dimensions

List the top five: QualityAttributes.

(Wei03,56) Describe the environment in which the system will be used and define the vital availability, reliability, performance, and integrity requirements.

Used for SixSigma projects.

• Sponsor: Selects the Little y's and Vital x's; Has influence and often authority over the process and connecting organizations. Is most often a key executive that commissions the project. Is responsible for removing organization roadblocks and insuring all the right team members are assigned.
  • Remains ultimately accountable for a project's impact
  • Provides project resources
  • Reviews monthly and quarterly achievements, obstacles, and key actions
  • Supports the project Champion by removing barriers as necessary
• Champion: Owns the process being changed. Responsible and accountable for final results. Should be seen as co-lead on the project, with the MBB or BB. Is present at working meetings. 'Sometimes' the champion and sponsor are the same person.
  • Reviews weekly achievements, obstacles, and key actions
  • Meets with the team weekly to discuss progress
  • Reacts to changes in critical performance measures as needed
  • Supports the Team Leader, removing barriers as necessary
  • Helps ensure project alignment
• Team Leader: Black belt on complex issue, Green belt on less complex issues.
  • Leads improvement projects through an assigned, disciplined methodology
  • Works with the Champion to develop the Team Charter, review project progress, obtain necessary resources, and remove obstacles
  • Identifies and develops key milestones, timelines, and metrics for improvement projects
  • Establishes weekly, monthly, and quarterly review plans to monitor team progress
  • Supports the work of team members as necessary
• Team members :
  • Assist the Team Leader
  • Follow a disciplined methodology
  • Ensure the Team Charter and timeline are being met
  • Accept and execute assignments
  • Add their views, opinions, and ideas
• DSS Leader: Develops DSS organization, manages sector change strategy, reviews overall progress, develops MBB's, keeps sector staff aligned with DSS priorities.
• MBB: Manages and oversees multiple DSS projects, guides project selection, selects and develops BB's, manages cross-functional interfaces as necessary, implementation review.
• BB: Project lead on team, advises and support data collection and analysis, facilitates team meetings.
• Functional Team Experts: Process experts who provide input, do data analysis, develop solutions, communicate with functional area, and support implementation. Green Belt trained when possible.
• Assumption Busters: Creative thinkers to enable alternative views
• IT Representative: Support digitization effort
• Finance Representative: Helps with validation of financial opportunity, accuracy of accounting, and cost/benefit justification. May help with new accounting requirements.
  • Define -- Determine the financial opportunity in the improvement project, and make sure that financial assumptions are accurate
  • Measure -- Translate process steps into unit cost and calculate the Cost of Poor Quality (COPQ)
  • Improve -- Develop CostBenefitAnalysis (CBA) and ReturnOnInvestment (ROI) using key financial metrics to help convince management to accept recommendations
  • Control -- Confirm benefits and pass financial responsibility to process owners
• Process Experts
• Customer/Supplier
• Outsiders

The team selection identifies team members and assigns responsibilities. Consider the following questions when selecting team members:

• What types of members are needed?
• At what point will members be needed?
• Who is accountable to whom, and accountable for what?
• Who is the project sponsor? What is his or her responsibility to the team?
• How will project teams coordinate efforts?
• Who is the Team Leader?
• What are the Team Leader's responsibilities?
• Who is on the team?
• How does the team report?
• How often does the team report?

Black Belts, Champions, and Team Leaders select the team members. Green Belts also have input into the team selection of a project.

It is very important to select the best-qualified members of the team, not just people who want to be involved with the project.

Do all the economy calculations; NVP, IRR, ROI?

See: FinancialMetrics

• What's the $ value of this project?

  • If you can't identify a bottom line impact, why would management invest resources in it?

• What's the potential financial gain? What's the Investment requirement?

  • M15: Identify opportunities
  • M15: Opportunity Boundaries
  • M14: Customer Economic Model
  • M13: estimation (Sum)

• % ROI = { (benefits – costs) / costs} * 100

• Cost of project consists of:

  • Staff resources.
  • Training: Does the staff need special training to enable them to complete the project.
  • Tools: Additional software and hardware.

• TODO C %X% Vision statement, may be the one-line version of the mission statement. So it should be here as well.

Describe what you are peddling - Vision

NPV IRR

• SixSigmaCharterTable

A master black belt establishes a schedule with deadlines for management and tollgate reviews of Six Sigma projects. There are four types of management reviews:

• Daily: reviews are conducted by the team leader to assess and resolve problems with Six Sigma projects.
• Weekly: meetings are held between the team members and their champion to resolve budget, resource, and scheduling issues; to evaluate project requests; and to remove barriers to the project.
• Monthly: reviews are done by the top management of selected project teams to evaluate the status of projects, approve the scope of new projects, approve communications plans for lessons learned from projects, assess the risk for each project, and evaluate the quality management plan for each project.
• Tollgate: reviews are conducted by the champion and process owner (of each project) after completion of each phase of the Six Sigma project.

• Project team [leader (BB or GB), members, champion, process owner, IT representative, finance representative].
• Project business case.
• Project objective.
• Project plan (Gantt chart).
• Document control system.
• Risk reduction plan.

This analytic tool set uses a five-step process to help an organization's processes reach levels of performance never before seen.

Use for improving quality & service problems; reducing variation

The DMADDD is an analytic tool set used to drive the cost out of a process by incorporating digital improvements.

These modifications can drive dramatic improvements in efficiency by identifying non-value tasks and using simple web-enabled tools to automate certain tasks. In doing so, employees can be freed up to work on more important duties.

Use for developing new products or processes; or radical change in process

DMADV is an analytic tool set used when an organization needs a new product, process, or service.

Using this tool set, Black Belts optimize performance before production begins, making this tool proactive, as opposed to reactive like other tool sets like DMAIC.

From Wei03,51