Workflow & WBS: Develop Requirements-based Deliverables

Build scope definition and solutions - Elicit, Capture, and Collect Requirements, Rules, Deliverables, Resources.
3.0 (3 ratings)
Instead of using a simple lifetime average, Udemy calculates a
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.
12 students enrolled
$19
$75
75% off
Take This Course
  • Lectures 35
  • Length 3 hours
  • Skill Level Intermediate Level
  • Languages English
  • Includes Lifetime access
    30 day money back guarantee!
    Available on iOS and Android
    Certificate of Completion
Wishlisted Wishlist

How taking a course works

Discover

Find online courses made by experts from around the world.

Learn

Take your courses with you and learn anywhere, anytime.

Master

Learn and practice real-world skills and achieve your goals.

About This Course

Published 11/2015 English

Course Description

Based on extensive related hands-on practical experience, this course provides you with skills and knowledge needed for effective and development requirements-base workflows and deliverables needed to support valuable solutions for business and IT organizations.

Please allow me to introduce myself, I'm Chuck Morrison, an MBA and PMP certified Senior Program/Projects Manager and Business Architecture Professional with extensive and diverse experience in Program/Project Management and Business Architecture.

Based on my extensive related hands-on practical experience in Silicon Valley high tech, this course provides you with the skills and knowledge to effectively and efficiently design and develop needed requirements-based business workflows and deliverables solutions needed to support your programs and projects for business and information technology organizations.

Recently, I've authored and published 5 Udemy courses and 5 Amazon Kindle books and am in the process of authoring several more, because as I've discovered teaching and writing are truly my passions.

The “”Develop Requirements-based WBS, Workflows, and Deliverables” course is authored by Chuck Morrison, MBA, PMP with over 25 years Program Management and Business Architecture experience in Silicon Valley California.

Also Authored, Produced, and Published Udemy professional training courses and Amazon Kindle books by Chuck are: Learn to Transform Requirements into UML Use Cases, Learn to Analyze Business Application Issues Root Causes, Learn Agile SCRUM Development for Project Managers, Learn How the Project Management Office (PMO) Operate, Develop Requirements-based WBS, Workflows, and Deliverables.

Critical processes emphasized during this course are collaboration, listening, analysis, and modeling techniques needed for effective and efficient system operations solutions. This course helps you develop the skills and knowledge needed to support effective solutions and decisions regardless of your role.

As stated previously, “Develop Requirements-based WBS, Workflows, and Deliverables” provides you with the needed skills and knowledge to effectively and efficiently design and develop requirements-based business workflows and deliverables needed to support your programs and projects for business and IT organizations. During each lecture you’ll be presented with information and material found useful to others while developing workflows and deliverables for their own organizations. Remember, however, lectures and demonstrations can only help you so far. It’s up to you to learn then take advantage of the methods and tools presented.

If during this course, or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancements and/or adjustments. I look forward to hearing your comments and suggestions.

All affected stakeholders including sponsors, subject matter experts, and other resources must be involved in collaborative development viable solution based on PMO operations and processes for any executive decisions. This requires the leadership, skills, and knowledge or experienced analyst and architects capable of supporting an effective business solution needed to return business systems to proper operation.

Again! Please! You be the judge! If during this course or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancement and/or adjustments. I look forward to hearing your comments and suggestions.

I’m looking forward to sharing with you the skills and knowledge to effectively and efficiently develop and deliver requirements-based business workflows and deliverables solutions needed to support your programs and projects to make you and your organization more successful. And, I now encourage you to take full advantage of the learning opportunities this course offers.

And, please if you find my course useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

Please remember my promise to you, if your have any questions about any part of this training or any related questions about this course or Udemy please don’t hesitate to ask using Udemy’s Instructor Messaging service to contact me.

Are you ready to get started! See you inside J

Thank You and Best Regards,

Chuck Morrison, MBA, PMP

What are the requirements?

  • Some technical experience desired.
  • Ability to collaborate and listen for business wants and needs
  • Capability to capture and define business and technical requirements
  • Interest in the fields of business analysis, quality assurance, and information architecture
  • Ability to collect and organize tasks, activities and resources into diagrams, flow charts, and graphical models

What am I going to get from this course?

  • Elicit, Capture, and Collect requirements needed to describe and support scope of each deliverable
  • Create Business Requirements Document to support Scope and Support for Deliverables
  • Use Structured Analysis to decompose deliverables into required Deliverables, Functions, Rules, Resources, Effort, Costs
  • Communicate with technical team using object-oriented analysis models
  • Communicate with stakeholders using simplified object-oriented analysis models to clarify requirement
  • Identify key relationships and activities for tasks and timing based on risks and issues derived from the project Work-breakdown-structure (WBS)

What is the target audience?

  • Subject Matter Experts (SMEs)
  • Product Owners and Sponsors
  • Business Process Managers
  • Business Process Users
  • Product, Project, Portfolio, and Program Managers
  • Quality Assurance
  • Business Analysts & Architects
  • System & Software Developers

What you get with this course?

Not for you? No problem.
30 day money back guarantee.

Forever yours.
Lifetime access.

Learn on the go.
Desktop, iOS and Android.

Get rewarded.
Certificate of completion.

Curriculum

Section 1: Why Are Workflow Models Needed?
00:41

Welcome to my course “ Develop Requirements-based Workflows and Deliverables”

Hello, I'm Chuck Morrison, an MBA and PMP certified Senior Program/Projects Manager and Business Architecture Professional.

My specialties are: Business Process Engineering, Software Systems Development, Cross-Functional Program and Change Management.

My significant skills and accomplishments include:

  • Over 20 years of expansive and diverse experience as a Program, Project and Portfolio Manager, Consultant and Business Architect/Analyst working for companies such as VMware, HP Enterprise Services, Hawaiian Airlines and DIRECTV.
  • Proven success in leading multiple, complex projects, process improvements and system migrations throughout the entire project lifecycle that generate cost savings of over $50M.
  • Managed a total of 27 concurrent, highly visible CPUC Rule 20 projects according to schedule and timeline across multi-locations and sites with a total budget of $40M for Pacific Gas and Electric Company (PG&E).
  • Extensive technology background with a recognized business acumen to define and deliver small to large-scale, complex business process and systems infrastructure projects.
  • Authored and Published Udemy professional training courses and Amazon Kindle books:
    • UML Use Cases: Transforming Requirements into Context Maps,
    • Logical Troubleshooting & RCA: Learn What You Need to Know,
    • Agile SCRUM: Learn Agile Development for Project Managers,
    • Project Management Office: Learn How the PMO Functions,
    • Safety and Security: Learn CISSP Domains for Project Managers ,
    • Workflow & WBS: Develop Requirements-based Deliverables

… currently authoring a Udemy courses ITIL, Cloud Computing, SDLC; available in early 2016.

My significant accomplishments also include:

  • During my youth, I had the good fortune of calling home the awesome forests near Somersworth, New Hampshire, the exciting salmon runs of Adak, Alaska, and the beautiful mountains and beaches of California – from Eureka to Yosemite to San Francisco, Los Angeles, and San Diego. It was also to my good fortune in my learning experience to see and walk in every state in the United States at least once.
  • Later, it was my good fortune to experience the world on a global scale from the breathtaking beauty and church bells of Frankfurt and Wurzburg Germany. Next, I found myself in experience evening sky of Tokyo, Japan and Mount Fuji for atop Tokyo Tower, followed by the bright red skies of Taipei in Taiwan and Manila Bay in the Philippines, then the busy international harbor of Kowloon near Victoria City, Hong Kong, and the intricate vistas on the Tonkin Gulf near Hai Phong as well as the rugged coastline near Ho Chi Minh City (formerly Saigon) Vietnam, and the exuberant beauty of the Sidney, Australia harbor.

And, please if you find my course useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

02:44

Introduce self to class

Welcome and thank you for joining our course. Please take a moment to introduce yourself to me and the other students in our class using our Udemy Course Discussions to add then post your introduction.

Just include a little information about yourself including your name and location You don't have to be specific about location if you prefer … just include your state or city or country. Also, please let us know where you’re coming from.

Are you working full-time, is this your first time taking or creating and online course, are you working full or part? Is this your first time creating your own online business, or making money online. Do you have a website? If so, please include your website address so we can find out a little more information about you and start following you on your own channel. If you’re on Facebook, Twitter, LinkedIn, or other social media, please let us know your contact information if you want to share.

Please contact me with any questions or suggestions you may have about our course.

If during this or any other of my courses, or after you’ve completed any of my courses, you have any questions or related suggestions for improvement; please don’t hesitate to contact me using Udemy’s Instructor Messaging system.

Simply click the Blue “Add Discussion” button then add you information and comments to the dialog box. When finished click the Green “Post” button. That’s it … it’s that easy for communication with me and other student on Udemy.

Remember, you have my promise to work with you to find an answer for your questions and suggestions, which may include course enhancements and/or adjustments or reviews and ratings. I look forward to hearing your comments and suggestions.

And, please after completing any of my courses or if you find this course or any of my courses useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for any course then click and enter your review and rating.

I'm excited to meet you and just as I did in my “Welcome” video giving information about myself, I really am excited to get to know you better. Please take just 30 seconds to introduce yourself to the course; I will highly appreciate it. See you in the next video lecture.

Thank You and Best Regards, Chuck

03:06

What is Workflow (Process) Mapping and Work-breakdown-Structure (WBS)?

Discussion –

Welcome to our first lecture for this course “What is Workflow (Process) Mapping and Work-breakdown-Structure (WBS)?”

So, let’s get started.

Please note, my lecture notes for this and all lectures for this course are downloadable to enable you to view drawings and note both during and after each lecture.

A workflow model (aka workflow process mapping) defines a repeatable pattern of sequenced operations used to transform input concepts or objects into intended output concepts or objects. Workflows are systematically enabled by defined roles, rules, and resources. Workflow models facilitate the assessment, documentation, configuration, control, and learning of work processes. A workflow model is an abstraction of real work performed by a group of persons intentionally interacting with organizations, information, equipment, and materials.

A workflow model is a repeatable pattern of the flow of work within an organizational area. Workflow models are used to illustrate and document how work processes are performed, and to discover opportunities for process improvement.

A work breakdown structure is used to effectively decompose the project scope, to improve estimating, to better control the project execution and to more accurately verify project required deliverables traceability to product, portfolio, program, and project completion. In addition, using a work breakdown structure approach summarizes project information to improve the opportunity for use of historical information, which, can aid in both speed and accuracy of future projects. The work breakdown structure is a repeatable process that can be used as a template for future projects.

Project Management and Business Analysis use Workflow Models to manage how a process works and use Work-breakdown-Structure (WBS) structure of a process, product, or system to ensure operational completion of tasks required. As well as ensure all deliverable are within project scope thus providing a framework for estimating costs and time needed control project development and schedules from a process sequence.

As show in the overall UML model for this and future lectures in this course, both WBS and workflows show relationships among roles, inputs, transformations, storage, outputs, and dependencies for related organizational project scope and processes can be modeled together in a workflow mapping and WBS collection. Relationships in the model shown will be discussed in lectures to follow. Please download and refer to the model for this and future lectures for this course.

01:18

Lecture 3 – Imagine …

Discussion –

  • You and your team are responsible for planning and controlling major, business system deliveries programs and projects and were just assigned that one of your deliveries crashed and everyone is waiting for your next application delivery.
  • You're part of a team that must support the company's product delivery operations for several critical customers with symptoms you and your team have never seen nor heard of before.
  • More precisely, customers are beating down your companies doors for must-have immediate delivery of products and services without a page written about processes or procedures and people you've never met who do not know what to do next and you haven't even a clue about what happened, when, or what's the impact on time or resources or security and safety related issues.
  • What do you do, where do you begin …
  • By completing this course, you will posses the set of tools and guidelines needed create your action plan and move forward to resolving business and technical problems and issues using Safety and Security related methodologies and processes to support project needed to ensure value of safe and secure product and service delivery to customer with minimal time, costs and risks. So, are you ready to get started?

    00:56

    Lecture 4 – Please Allow Me to Share a Few Related Quotes …

    Discussion –

    •Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. – Albert Einstein

    •Continuous improvement is not about the things you do well — that’s work. Continuous improvement is about removing the things that get in the way of your work. The headaches, the things that slow you down, that’s what continuous improvement is all about. ~Bruce Hamilton

    •Perfection is not attainable, but if we chase perfection we can catch excellence. -Vince Lombardi

    •The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. ~Bill Gates

    •What gets measured, gets managed. ~Peter Drucker

    10:03

    Lecture 5 – Why are Workflow (Process) Mappings and Work-breakdown-Structures (WBS) Needed? …

    Discussion –

    Why a Workflow (process) Mapping is Important

    Workflow process mapping is an important step needed for managing workflows. Whether specifically defined or not, all organizations need workflows to perform work – that is make and deliver products and services. Undefined workflows often evolve quickly based on need and accident, with little no consideration about effectiveness or productivity. Inefficient workflows often become entrenched within a system or process.

    Workflow maps visually illustrate actions, steps, and tasks performed to achieve required outputs or deliverables. Registering students for a courses, delivering a product or service, and answering telephones are processes occurring routinely. Required process steps can be mapped creating standard workflows while removing wasted effort.

    Workflow maps provide organizations easy and quick methods to visualize an entire process from start to finish including all the needed steps in between. A graphical image such as an activity diagram or flowchart work currently performed in your organization can readily be shared.

    Workflow maps also show tasks performed by each role for each activity or task of the process allowing all stakeholders to understand other roles and dependencies related to the process. This further enables coordination among all participants working in, monitoring, and managing the process. Often stakeholders involved with a process are not aware of what colleagues actually do within the organization. Because processes can involve many people from multiple disciplines to complete activities and tasks, a workflow map ensures process details are accurately captured and shared within a multidisciplinary team as needed for discussion.

    Five key considerations for workflow mapping:

    •Maintain an open and collaborative environment.

    •Focus on the system or process, not the people.

    •Consider if this event is a one-time occurrence or routine, before deciding on a process change.

    •Map the “As-Is” process to share with and enable your team to pinpoint process gaps to be improved collaboratively and by consensus.

    •Workflow mapping is a continuous improvement tool.

    With workflow mapping, processes steps and interactions are diagrammed enabling understanding, evaluation, and improvement of performance. Workflow mapping creates a “roadmap” enabling visibility of the most efficient route from start to completion for delivery of products and/or services.

    Workflow Process Mapping as a Learning Tool

    Workflow mapping results in a process baseline view. A workflow must map a process “As-Is”. How you wish it to be comes later. Meanwhile, when your workflow maps your current processes, relationships, and dependencies, your opportunities for improvement are visualized.

    Workflow process maps are designed to document processes providing a collection of reference points from a bird’s eye view showing how activities and roles work together. Next, you analyze each process step or operation determining if any can be automated, removed, or reworked. Many steps may be candidates for successful combination to further streamline and enhance your process.

    Workflow Mapping Can Lead to Optimizing Efficiency

    Workflow mapping is often performed within re-engineering project. Using clearly illustrated steps within processes and showing how processes flow together as workflows, provides the best opportunity for inefficiencies recognition enabling these to be eliminated. Workflow mapping enables baseline workflows, modification, implementation, and measurement using Key Performance Indicators (KPIs) resulting in improved efficiency, lower costs, and improved revenues.

    Why a Work Breakdown Structure (WBS) is Important

    A work breakdown structure (WBS) enables project managers to plan scope and deliverables effectively and efficiently. Project are characterized by time-limited activities and tasks with fixed time frames and costs assigned. When it is finished, a project must fulfill the stakeholder needs it designed to address. The project management plans and schedules, using fixed costs and functional completeness of each project deliverable then assigns responsibilities for completion. The WBS enables consistent planning within scope and provides for effective and measurable project execution.

    The WBS represents the entire scope of a project used by the project manager in collaboration with stakeholders to assign scope, deliverables, work packages, costs, schedule, schedule, functionality, responsibility

    Scope

    A critical function of project management is to clarify and define project scope. The challenge is ensuring all deliverables within project scope is completed work and effort. The WBS defines scope by listing each deliverable with supporting work package and task for the project. The project team completes all the listed deliverables and tasks with no additional work unless specified by approved change order.

    Deliverables

    A Deliverable is a project management term describing objects produced and delivered by the project for a customer, client, or stakeholder. A deliverable can be a report, document, server upgrade or any component, task, or service resulting from project work packages, tasks, or activities; deliverable can be composed of multiple smaller deliverables. A deliverable is either an outcome or an output provided within a project. Deliverables are the end result of a process not a milestone. Milestones represent completion of product design whereas deliverables can be a technical diagram of a physical product.

    Work Package: Tasks, Activities

    The main purpose of a WBS is to reduce complicated activities to a collection of deliverable work packages and tasks. The project manager finds the WBS important for enabling overseeing tasks more effectively within more complex activities or operations. Tasks are measurable and independent with clearly defined measurability. All the project work must be included in a task and tasks cannot include out-of-scope work.

    A work package is a key WBS building block allowing project management to define steps required to complete required work. A work package is a sub-project task collection combined with other work packages forming a completed project.

    Costs

    WBS tasks are measurable enabling project management to assign specific costs to each task. The WBS enables project managers to distribute budget for defined packages linked to each task and validates total costs do no exceed total project cost.

    Schedule

    WBS is important for tracking project schedule progress. Because WBS tasks have clearly defined and measureable limits, project management finds how advanced the project is by checking for completed tasks and milestones. Project management can check for percent completion because each task is measurable.

    Functionality (Functions and Features)

    A major criterion for project success is fulfillment of required purpose within scope. WBS tasks each implement part of the overall scope and deliverables. When all tasks are completed, all required functionality equals a fully functional project completing all required deliverables within scope.

    Responsibility (Role)

    An important project management responsibility is assignment of work for completion of work packages, tasks, and deliverables. Using a WBS, project management assigns responsibility for each project task. The project manager is responsible for completion of full project scope on time, within budget and with all deliverables completed.

    05:33

    Lecture 6 – What’s This Course About?

    Discussion –

    Summary - Based on extensive related hands-on practical experience, this course provides you with skills and knowledge needed for effective and development requirements-base workflows and deliverables needed to support valuable solutions for business and IT organizations.

    Please allow me to introduce myself, I'm Chuck Morrison, an MBA and PMP certified Senior Program/Projects Manager and Business Architecture Professional with extensive and diverse experience in Program/Project Management and Business Architecture.

    Based on my extensive related hands-on practical experience in Silicon Valley high tech, this course provides you with the skills and knowledge to effectively and efficiently design and develop needed requirements-based business workflows and deliverables solutions needed to support your programs and projects for business and information technology organizations.

    Recently, I've authored and published 5 Udemy courses and 5 Amazon Kindle books and am in the process of authoring several more, because as I've discovered teaching and writing are truly my passions.

    The “”Develop Requirements-based WBS, Workflows, and Deliverables” course is authored by Chuck Morrison, MBA, PMP with over 25 years Program Management and Business Architecture experience in Silicon Valley California.

    Also Authored, Produced, and Published Udemy professional training courses and Amazon Kindle books by Chuck are: Learn to Transform Requirements into UML Use Cases, Learn to Analyze Business Application Issues Root Causes, Learn Agile SCRUM Development for Project Managers, Learn How the Project Management Office (PMO) Operate, Develop Requirements-based WBS, Workflows, and Deliverables.

    Critical processes emphasized during this course are collaboration, listening, analysis, and modeling techniques needed for effective and efficient system operations solutions. This course helps you develop the skills and knowledge needed to support effective solutions and decisions regardless of your role.

    As stated previously, “Develop Requirements-based WBS, Workflows, and Deliverables” provides you with the needed skills and knowledge to effectively and efficiently design and develop requirements-based business workflows and deliverables needed to support your programs and projects for business and IT organizations. During each lecture you’ll be presented with information and material found useful to others while developing workflows and deliverables for their own organizations. Remember, however, lectures and demonstrations can only help you so far. It’s up to you to learn then take advantage of the methods and tools presented.

    If during this course, or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancements and/or adjustments. I look forward to hearing your comments and suggestions.

    All affected stakeholders including sponsors, subject matter experts, and other resources must be involved in collaborative development viable solution based on PMO operations and processes for any executive decisions. This requires the leadership, skills, and knowledge or experienced analyst and architects capable of supporting an effective business solution needed to return business systems to proper operation.

    Again! Please! You be the judge! If during this course or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancement and/or adjustments. I look forward to hearing your comments and suggestions.

    I’m looking forward to sharing with you the skills and knowledge to effectively and efficiently develop and deliver requirements-based business workflows and deliverables solutions needed to support your programs and projects to make you and your organization more successful. And, I now encourage you to take full advantage of the learning opportunities this course offers.

    Thank You and Best Regards,
    Chuck Morrison, MBA, PMP

    02:20

    Lecture 7 – What Do You Get from This Course?

    Discussion –

    •Create the Business Requirements Document to support Scope and Support for Deliverables

    •Use Structured Analysis to decompose deliverables into required Deliverables, Functions, Rules, Resources, Effort, Costs

    •Elicit, Capture, and Collect requirements needed to describe and support scope of each deliverable

    •Communicate with technical team using object-oriented analysis models

    •Communicate with stakeholders using simplified object-oriented analysis models to clarify requirements

    •Identify key relationships and activities for tasks and timing based on risks and issues derived from the project Work-breakdown-structure (WBS)

    Enables identifying, assigning, tracking, controlling, and managing activities based on WBS and Workflow Modeling methods.

    Aids capture & development of WBS and Workflow for effective portfolio/program/project delivery meeting scope, effort, risk, budgeting and scheduling requirements for your organization.

    To achieve our course goals, the course is delivered using sections, lectures, quizzes, out-of-class exercises, and downloads. Also included with your course is a glossary and further reading references. As each section is presented, the section’s goals will be discussed and related lectures introduced.

    During lectures, key concepts will be first presented then demonstrated as appropriate. Students are encouraged to use skills and knowledge discussed and demonstrated outside of class in their own work as much as possible to enhance learning success. During course lectures or outside lectures, students are further encouraged to ask questions or make comments and suggestions using Udemy’s Instructor Messaging service to contact me so I may do related research then get back to the student promptly with results.

    00:36

    Lecture 8 – What are the course requirements? Intermediate technical level

    Discussion –

    During this course you’ll gain skills and knowledge to develop and deliver requirements-based business workflows and deliverables solutions as you develop and enhance these core competencies based on our course goals…

    •Some technical experience desired.

    •Ability to collaborate and listen for business wants and needs

    •Capability to capture and define business and technical requirements

    •Interest in the fields of business analysis and information architecture

    •Ability to collect and organize tasks, activities and resources into diagrams and graphical models

    00:24

    Lecture 9 – Who’s the Target Audience?

    Discussion –

    “Develop Requirements-based WBS, Workflows, and Deliverables" provides you with the skills and knowledge to effectively and efficiently develop requirements-based business workflows and deliverables solutions needed to support your programs and projects.

    •Subject Matter Experts (SMEs)

    •Product Owners

    •Business Process Managers

    •Business Process Users

    •Product, Portfolio, Project, and Program Managers

    •Business Analysts & Architects

    •Quality Assurance

    •System & Software Developers

    Note: " Develop Requirements-based WBS, Workflows, and Deliverables" is an intermediate level course, anyone with little or no business and/or technical interest or experience is not a good candidate for this course

    1 question

    Which of the following is true?

    Section 2: Overview of Requirements-based WBS, Workflows, and Deliverables
    08:39

    Lecture 10 – Product, Portfolio, Program, Project, Scope, Deliverables, Workflow and WBS

    Discussion –

    Product, Portfolio, Program, Project Scope and Deliverables

    As shown in the overall UML model (refer to ”Workflow (Process) Mapping”) for this and future lectures in this course, both WBS and workflows show relationships among roles, inputs, transformations, storage, outputs, and dependencies for related organizational project scope and processes modeled together in a workflow mapping and WBS collection. Relationships in the model shown are discussed in lectures to follow. Please download and refer to the model for this and future lectures for this course.

    Product Scope

    Product scope is defined as features, functions, or characteristics of a product. Whether considering design, function and features, or component parts, product scope refers to an actual physical product as a deliverable. In project management, products are project deliverables making up or contributing to delivery of requirements objectives of the project as defined by product and project scope .

    Portfolio Scope
    Portfolio Scope is a dynamic continuous process with these basic operation or steps –

    • Monitoring portfolio performance incorporating current market conditions
    • Identifying investor objectives, constraints, and preference
    • Evaluating portfolio income with target and achievement comparisons
    • Revising the portfolio
    • Implementing strategies in conformance with investment objectives.


    Program and Project Scope

    Project scope is a project initiation planning process group outcome for determining and documenting specific project goals, deliverables, tasks, resources, costs, budgets, and milestones. Project management is application of information and knowledge, skills, tools, and techniques to project activities enabling completion of project requirements. Program Scope defines and delivers functional work packages. Program scope defines collections of projects scoped to deliver dependent, specified functionality and features. When each project is successfully delivered, all components and work packages collectively complete a comprehensive deliverable. Programs include single or multiple products or deliverables traceable to business requirements and objectives delivering business value benefitting stakeholders and management.

    Workflow Mappings and Work Breakdown Structures

    Workflow Mappings and Work Breakdown Structures are used to document repeatable patterns of work and scope. Both are based on knowledge and information about process transformations from material and information inputs to product and services outputs and deliverables defining the scope of organizational portfolios, programs, and projects.

    Workflow Models or Workflow Process Mappings define repeatable patterns of sequenced operations used to transform input concepts or objects into intended output concepts or objects. Workflows are systematically enabled by defined roles, rules, and resources. Workflow models facilitate the assessment, documentation, configuration, control, and learning of work processes. A workflow model is an abstraction of real work performed by a group of persons intentionally interacting with organizations, information, equipment, and materials. Workflow models are used to illustrate and document how work processes are performed, and to discover opportunities for process improvement.

    Closely related to the practice of workflow modeling is Business Process Engineering (BPE), Business Process Management (BPM), and Business Process Reengineering (BPR) key fields in operations research studies of the nature of work both quantitatively and qualitatively supported by such disciplines as Artificial Intelligence (AI) and Object Oriented Analysis and Design (OOAD). The following concepts are also closely related to workflow modeling.

    Processes Process is a more specific concept than workflow applying to physical or biological processes for example. A process as contrasted with a workflow has more well-defined inputs, outputs and transformations. Workflows are generally related to a systematic pattern of activity (such as all processes occurring in semiconductor fabrication and assembly).

    Planning and scheduling A plan describes a logical, ordered set of activities required to achieve required goals or deliverables within scope given certain starting conditions and materials. A plan, supported by a schedule and resource allocation, defines an instantiation of a specific event-driven, goal-directed systematic process. A workflow is the realization of heuristics and algorithms needed to repeatedly execute the related process.

    Work Breakdown Structure (WBS) is used to effectively decompose product, portfolio, program, and project scope, to improve estimating, better control of project execution, and more accurately verify project required deliverables traceability to product, portfolio, program, and project completion requirements. In addition, using a WBS approach summarizes project information improving opportunity for use of historical knowledge and information, which, can aid in both speed and accuracy of future projects. The work breakdown structure (WBS) is a repeatable process that can be used as a template for future projects.

    Project Management and Business Analysis use Workflow Models to manage how processes work and use Work-breakdown-Structure (WBS) structure of a process, product, or system to ensure operational completion of tasks and material transformations required. This ensures all deliverable are within project scope thus providing a framework for estimating costs and time needed to control project development and schedules of a process sequence and deliverables.

    08:28

    Lecture 11 – Systems, Processes, Organizations, and Workflows – Work, Knowledge and Information

    Discussion –

    Work (Activity-Based), Knowledge and Information Mapping

    Organizations are systems. Knowledge and Information Mapping enables knowledge and information inputs and outputs linking systematically to all organizational activities and processes – from office mail to strategic reviews. Knowledge and Information Mapping of workflows and work structures enables tasks and activities modeling as an overall organizational process – understand why and how and document order of activities – requirements and dependencies for each activity – who performs each activity, as well as what inputs are required and how knowledge and information flows support related roles and tasks.

    Workflow, process, or business process mapping was discovered by multiple organizations as being a powerful analytical tool for managing and improving processes. Software vendors, including Oracle and IBM, market systems designed enabling workflow process mapping and work breakdown structure (WBS) modeling of operations as various Unified Modeling Language (UML) and Business Landscape maps and diagrams. Available systems are effective at capturing formal and explicit knowledge inherent in any workflow. A long-term problem with these approaches is a full 'knowledge base’ contains many underlying 'tacit knowledge' elements.

    This results in a series of diagrams visually displaying knowledge and information within the context of a business process and systems. Workflow maps illustrate how knowledge is currently used within a given process with related knowledge and information sources and points to how improvements can be performed. When undertaken and applied correctly, activity-based knowledge and information mapping and workflow approaches serve to identify key activity-based priorities for improving knowledge and information flows within an organization, group, or department. Key activity factors to consider for prioritization are: number of people involved in activities within the organization, effectiveness of an activity; 'tacit' knowledge needed to perform an activity.

    Complications presented by tacit knowledge in software-driven approaches workflow and WBS mapping are formidable. Until formal and tacit knowledge are both understood, software-driven approaches cannot achieve full capability. Consequently the mapping process, by necessity, becomes methods for managing knowledge as well as methods for mapping materials and information flows. As a basis for process improvement, the mapping process supports development of software-driven process mapping and creation of dynamic programs based on accurate understanding of existing workflows and WBS.

    Systems

    Systems are collections of interacting or interdependent components forming complex Input, Output, and Transformation processes within an environment with a specific system boundary.

    Systems are delineated by spatial and temporal boundaries, contained and influenced from external environment, and described by structure and behaviors as expressed by functions, features, and events.

    Fields of general properties studies of systems include systems science, systems theory, systems modeling, systems engineering, cybernetics, dynamical systems, thermodynamics, complex systems, system analysis and design, artificial intelligence and systems architecture. Each field investigates abstract properties of material and organization of a system, seeking concepts and principles independent of related domain, substance, type, or time scale.

    Common characteristics systems share include –

    • Systems have structure and contain materials or components directly or indirectly related
    • Systems exhibit behavior – processes fulfill functions, interactions, or purpose
    • Systems have dependency – components and processes are connected structurally and/or have behavioral relationships
    • System’ structure and behavior is decomposed via subsystems and sub-processes to elementary objects, components and process steps
    • Systems exhibit behavior categorized as loosely or tightly coupled among components and the environment
    • Systems are defined by collections of rules governing structure and/or behavior. Alternatively, in the context of complex social systems, institutions describe the collection of rules governing structure (attributed, features) and/or behavior (events, methods, procedures).

    Processes

    Processes contain sequences of interdependent and linked procedures consuming one or more resources (employee time, energy, machines, money) converting inputs (data, material, parts, …) into outputs (products, deliverables). Outputs then serve as inputs subsequent (dependent) next step in a collection of processes until a expected objective or deliverable is achieved and complete.

    Organizations

    Social groupings of people structured and managed to achieve collective objectives. Organizations have a management structure determining relationships among various activities and organization members assigning roles, responsibilities, and authority needed to perform required tasks. Organizations are open or closed systems affecting and affected by activities within a shared environment.

    Workflows

    A workflow is a pattern of steps tasks, events, and interactions comprising a workflow or process, involving multiple roles and materials needed to create or add value to organizational activities. Within a sequential workflow, each step is dependent on occurrence of a previous step; in a parallel workflow, two or more steps occur concurrently.

    Work Breakdown Structure (WBS)

    Work breakdown structure (WBS) is a key project deliverable for organizing a team's work into manageable components. The Project Management Body of Knowledge (PMBOK) defines work breakdown structure (WBS) as a "deliverable oriented hierarchical decomposition of work to be executed by the project team.” A WBS visually defines product and project scope into manageable work packages to enable project team understanding, execution, and delivery. Each WBS decomposition level and component provides further definition and detail of work packages.

    Work (Activity-Based), Knowledge and Information Mapping

    Organizations are systems. Knowledge and Information Mapping enables knowledge and information inputs and outputs linking systematically to all organizational activities and processes – from office mail to strategic reviews. Knowledge and Information Mapping of workflows and work structures enables tasks and activities modeling as an overall organizational process – understand why and how and document order of activities – requirements and dependencies for each activity – who performs each activity, as well as what inputs are required and how knowledge and information flows support related roles and tasks.

    Workflow, process, or business process mapping was discovered by multiple organizations as being a powerful analytical tool for managing and improving processes. Software vendors, including Oracle and IBM, market systems designed enabling workflow process mapping and work breakdown structure (WBS) modeling of operations as various Unified Modeling Language (UML) and Business Landscape maps and diagrams. Available systems are effective at capturing formal and explicit knowledge inherent in any workflow. A long-term problem with these approaches is a full 'knowledge base’ contains many underlying 'tacit knowledge' elements.

    This results in a series of diagrams visually displaying knowledge and information within the context of a business process and systems. Workflow maps illustrate how knowledge is currently used within a given process with related knowledge and information sources and points to how improvements can be performed. When undertaken and applied correctly, activity-based knowledge and information mapping and workflow approaches serve to identify key activity-based priorities for improving knowledge and information flows within an organization, group, or department. Key activity factors to consider for prioritization are: number of people involved in activities within the organization, effectiveness of an activity; 'tacit' knowledge needed to perform an activity.

    Complications presented by tacit knowledge in software-driven approaches workflow and WBS mapping are formidable. Until formal and tacit knowledge are both understood, software-driven approaches cannot achieve full capability. Consequently the mapping process, by necessity, becomes methods for managing knowledge as well as methods for mapping materials and information flows. As a basis for process improvement, the mapping process supports development of software-driven process mapping and creation of dynamic programs based on accurate understanding of existing workflows and WBS.

    Systems

    Systems are collections of interacting or interdependent components forming complex Input, Output, and Transformation processes within an environment with a specific system boundary.

    Systems are delineated by spatial and temporal boundaries, contained and influenced from external environment, and described by structure and behaviors as expressed by functions, features, and events.

    Fields of general properties studies of systems include systems science, systems theory, systems modeling, systems engineering, cybernetics, dynamical systems, thermodynamics, complex systems, system analysis and design, artificial intelligence and systems architecture. Each field investigates abstract properties of material and organization of a system, seeking concepts and principles independent of related domain, substance, type, or time scale.

    Common characteristics systems share include –

    • Systems have structure and contain materials or components directly or indirectly related
    • Systems exhibit behavior – processes fulfill functions, interactions, or purpose
    • Systems have dependency – components and processes are connected structurally and/or have behavioral relationships
    • System’ structure and behavior is decomposed via subsystems and sub-processes to elementary objects, components and process steps
    • Systems exhibit behavior categorized as loosely or tightly coupled among components and the environment•Systems are defined by collections of rules governing structure and/or behavior. Alternatively, in the context of complex social systems, institutions describe the collection of rules governing structure (attributed, features) and/or behavior (events, methods, procedures).


    Processes

    Processes contain sequences of interdependent and linked procedures consuming one or more resources (employee time, energy, machines, money) converting inputs (data, material, parts, …) into outputs (products, deliverables). Outputs then serve as inputs subsequent (dependent) next step in a collection of processes until a expected objective or deliverable is achieved and complete.

    Organizations

    Social groupings of people structured and managed to achieve collective objectives. Organizations have a management structure determining relationships among various activities and organization members assigning roles, responsibilities, and authority needed to perform required tasks. Organizations are open or closed systems affecting and affected by activities within a shared environment.

    Workflows

    A workflow is a pattern of steps tasks, events, and interactions comprising a workflow or process, involving multiple roles and materials needed to create or add value to organizational activities. Within a sequential workflow, each step is dependent on occurrence of a previous step; in a parallel workflow, two or more steps occur concurrently.

    Work Breakdown Structure (WBS)

    Work breakdown structure (WBS) is a key project deliverable for organizing a team's work into manageable components. The Project Management Body of Knowledge (PMBOK) defines work breakdown structure (WBS) as a "deliverable oriented hierarchical decomposition of work to be executed by the project team.” A WBS visually defines product and project scope into manageable work packages to enable project team understanding, execution, and delivery. Each WBS decomposition level and component provides further definition and detail of work packages.

    14:12

    Lecture 12 – Business Solutions Lifecycle

    Discussion –

    Business Solutions Lifecycle (BSL)

    Refer to the “Business Solutions Lifecycle” diagram as basis for this discussion. The Business Solutions Lifecycle helps enterprise organizations manage and improve business processes, enterprise systems architecture, and infrastructure delivery throughout the business, product, and system requirements lifecycles, as well as Strategic Planning, Operations & Maintenance, and solution Deactivation. Whether utilizing agile, iterative & incremental, or waterfall (SDLC) approaches, the Business Solutions Lifecycle aligns software delivery best practices, customer and market successes, and innovative technology needed to address today’s complex enterprise vision, strategies, requirements, quality, and innovation. The focus of Business Solutions Lifecycle management processes:

    • Software Delivery Management
    • Requirements Definition & Management
    • Lifecycle Quality Management
    • Continuous Process Improvement
    • Change Management
    • Accounting and Financial Estimation & Budgeting

    As shown in the diagram, the Business Solutions Lifecycle BSL) is decomposed into 3 major component collections – Deliverables, Knowledge Areas, Skills & Techniques (Underlying or Core Competencies). Deliverables follows a organization environment related breakdown in key component areas of Study Period (Strategic Planning & Enterprise Analysis), Implementation Period (Requirements, Design, Construction, Test, and Delivery), Operations Period (Operations & Maintenance, Deactivation). PMBOK is categorized under Knowledge Areas as Initiating, Planning, Execution, Closing with Monitoring and Control inclusive of all PMBOK Knowledge and Process groups. Also shown is Rational Unified Process (RUP – Object Oriented approach) incorporating PMBOK groups – Inception, Elaboration, Construction, Transition.

    The Systems Requirements Lifecycle (SRL) incorporates RUP and PMBOK in support of the Business Solutions Lifecycle. Although not specifically shown in the model, Agile Development lifecycle is supported by RUP, PMBOK, and the Business Solutions Lifecycle (BSL) – all are used by product, portfolio, program and project management for scope and deliverables planning, design & analysis, acquisition, execution, monitoring & control, closure and support.

    Focusing on these critical processes significantly improves visibility, traceability, and manageability. Key performance indicator (KPI) and Critical Success Factors (CSF) based metrics monitoring and control leads directly to increased quality, reliability, and predictability with minimized cost, time, and risk over the entire enterprise solutions delivery process.


    Business Process and Systems Delivery Management
 Addressing complex management needs of enterprise portfolio and organization alignment and compliance, business process and information technology solutions delivery, the following management framework of organizations can:

    • Drive clarity and alignment between business process and enterprise Information Technology (IT) solutions delivery teams and business stakeholders
    • Deliver key business process and enterprise solution initiatives on-time and within budget and scope with high predictably and quality
    • Minimize risk through a combination of rich analytics and automated, real-time monitoring and control
    • Support iterative, waterfall, and agile product and project management
    • Effectively manage, measure, and improve organizational performance.

    Requirements Definition & Management
 Deliver software right the first time, every time by ensuring business and enterprise IT alignment throughout the BSL. Using Business Process and Systems Delivery Management BPSDM, business analysts and stakeholders collaborate to collect, document, validate, and manage business process and enterprise IT requirements consensus. Effective BPSDM solutions facilitate enterprise organizations savings up to 40% of total project schedule and budget with the specified portfolio, program, and projects scope.

    Lifecycle Quality Management
 Revolutionize your approach to business process and systems quality by improving it across all phases of the business and enterprise system solutions delivery lifecycle. The BSL approach to Lifecycle Quality Management (LQM) supports incremental, continuous, or systemic improvements to the enterprise QA process, thus ensuring quality is addressed by and addresses requirements, measured and improved during development, deployment, and release & delivery. User acceptance is maximized with UML use case-based test cases coupled with appropriate test automation and managed within an open, scalable framework.

    Change Management 
Change Management helps business process and enterprise IT solution teams maintain fluidity and responsiveness to constantly changing business needs. Embracing and dealing with change promptly increases your organization’s business agility; a significant advantage in today’s fast-changing business world. With BSL, geographically distributed and centralized business and enterprise IT teams are empowered to orchestrate and control change throughout the Business Process Lifecycle further significantly enabling communication and organization alignment by leveraging best practices when managing project scope, milestones, tasks, and associated assets and artifacts.

    Continuous Process Improvement (CPI)
 Continuous Improvement Process (CPI) is a management process in which process enhancement or correction delivery efficiency, effectiveness and flexibility is continuously evaluated and improved. CPI is considered a management systems meta process (e.g., Business Process Management (BPM), Quality Management, Project Management). CPI is a strategic approach for developing a culture of continuous improvement in the areas of reliability, process cycle times, reduced resource consumption and cost, quality, productivity, and performance. Deployed effectively, CPI increases quality, productivity, and performance, while reducing waste, cycle time, and throughput.

    Workflow Modeling Lifecycle
 The illustration below shows the funding decision-points or milestones for each phase of a workflow development project. Within each milestone or project phase, due diligence is provided for the dynamic events and processes, business logic, data access and retention, usability, and technical infrastructure interface requirements. The principal focus throughout is optimal execution of the enterprise vision in an iterative, incremental, component approach thus ensuring due consideration for resources, time, cost, and risk of each phase. Anticipation provides scanning for accommodation of potential scalability and technical robustness for future expansion of business operations to meet customer demand. Partnering is also considered to ensure competitive advantage derived from enterprise core competencies. Simplification is considered to ensure scalability, reliability, and maintainability of business systems including legacy.


    Work-in-Process System Development Lifecycle (WIPSDLC) Model (Incremental/Iterative Process)

    Refer to the “WIPSDLC” diagram for this discussion. The WIPSDLC Model employs an incremental and iterative process approach to Workflow (Process) Modeling based on extended BSL PMBOK (SDLC) Process Groups. PMBOK Knowledge Areas are also incorporated during Workflow (Process) Modeling – Scope, Integration, Time, Cost, Quality, Human Resources, Communications, Risk, and Procurement (Materials, Equipment, Tools, Services).

    The key to Business Solution Lifecycle (BSL) modeling is determination of scope based on Business Case, Feasibility Study, Project Charter, Statement-of-Work (SOW), Contracts, and Stakeholder Management Strategy and captured in the Problem Definition and Solution Response.

    As seen in the diagram, the WIPSDLC Phases Model includes as extended from PMBOK Scope, Project Plan, Discovery (Requirements), Analysis (Functionality Knowledge and Information), Design (Components and Infrastructure), Implementation and Test (Rules Logic), and Delivery (Components/Services/Training).

    The Problem Definition includes (Project Manager, Domain SME, Architect) collaborative documentation as Material Requirements Definition (MRD), Business Requirements Definition (BRD), Product Requirements Definition (PRD), and Technical Design Specification (TDS). The Solution Response includes (Project Manager, Domain and Technical SME, Architect, Quality Assurance) collaborative documentation as High Level Definition (HLD), Detailed Design Specification (DDS), User Acceptance Testing (UAT), Development Specification (DEV), Training Documentation, and other related documents as required.

    WIPSDLC Model Phase Tracks include –

    Process Track – Concept/Object Models, Use Cases, Scenarios (Stories), Test Cases, Workflow and Exceptions, Component Model, Algorithms, Heuristics, Release, Maintenance, Prototype, Patterns, and other related documented knowledge and information.

    Rule Track – Events, Decisions, Business Rules Model, Migration, Configuration, Version Control, Security, Prototypes, Patterns, and other related documented knowledge and information.

    Data Track – Logical Model, Business Types, << Create, Read, Update and Delete (CRUD) Charts >>, State/Transition Models, Version Control, Prototypes, Patterns, and other related documented knowledge and information.

    Usability Track – Access, Wireframes, Layout, Navigation, Search, Sessions, Prototype, Patterns, and other related documented knowledge and information.

    Technology Track – Distribution, Tiers, Layers, Network, Security, Repository, Change Management, Content Management, Availability, Disaster Recovery, Prototype, Patterns, and other related documented knowledge and information.


    Methodology Phases/Deliverables (SDLC)

    Program and project consulting establishes strategies and funding decision points for working within a phased, iterative life cycle from inception to completion. Life cycle management is used to administer your program and projects portfolio within your architecture framework. Adherence to Software Development Lifecycle (SDLC) results in a high quality system that meets or exceeds customer expectations, within time, cost and risk estimates, works effectively and efficiently in the current and planned information technology infrastructure, and is cheap to maintain and cost-effective to enhance. SDLC is a systematic approach to problem solving composed of several phases (refer to “Software Development Lifecycle” diagram): Scoping, Planning, Discovery, Analysis, Design, Implementation, Testing, Delivery (Deployment), Maintenance. Vision, Rhythm, Anticipation, Partnering, and Simplification (VRAPS) is used for conceptual development work-in-process (WIP) elements of the SDLC model. The VRAPS model sharpens ability to recognize, diagnose, and heal harmful conditions. VRAPS works best when internalized and integrated with your own experiences and observations.

    11:12

    Lecture 13 – What Is Workflow (Process) Mapping and Work-breakdown-Structure (WBS)

    Discussion –

    What Is Workflow (Process) Mapping?

    The “Workflow Model” diagram shown illustrates the baseline modeling considerations or a typical workflow. The process shown integrates multiple resources, communication (knowledge & intelligence), requirements, and security across an architectural framework focused on transforming inputs using multiple steps into product/project scope deliverables according to one or a mix of methodologies listed.

    Work-flow (process) mapping is a method for reducing errors, increasing productivity, and affecting customer service effectively and efficiently. Work-flow (process) mapping follows these steps:

    Choose a process

    First decide what improve. Examples include making corporate travel center reservations, handling a car dealership customer repair order, or registering students into a college. The process is time-consuming, error-prone, and critical to organizational success. Begin where there is solid improvement potential to build morale and support future launch of subsequent mapping projects.

    Assemble a team

    The team includes all stakeholders from sponsors, to SMEs, to architects and users involved in process related operations. The team roles must be empowered with responsibility and sufficient authority to make significant changes in work flows as required.

    Map the process “As-Is”

    Diagram each process step, showing decision branches, activity effort, distances traveled, resource contacts, and other important specified requirements of related roles and work. First diagram each task, event, and interaction, then refine details.

    Identify problems

    These are areas where people feel there are currently major issues to be resolved, such as poor customer satisfaction, "dropping the ball," large expenses, or significant delays. Where there are many areas to choose from, try to follow the 80/20 Pareto principal: work on the 20% of the areas that cause 80% of the problems.

    • Brainstorm solutions. Identify all possible action steps for each problem area, without evaluating them.
    • Evaluate action steps.
    • Set up a set of "final" action steps by group consensus.

    Assign responsibilities

    Ask stakeholders to volunteer and assume responsibility and accountable for each action step required by the team, and to establish completion milestones to each work package, task, and deliverable.

    Create master plan (Scope, Deliverables)

    Summarize responsibilities for each required action, deliverable, and milestone (project gate). Communicate the plan with stakeholders ensuring consensus so everyone agrees with and accurately reflects decisions made during sessions.

    Follow through

    Meetings are useless without appropriate follow-through. Review using retrospective meetings set at bi-weekly intervals for collaboration on what went well and what can be improved. When time is appropriate, additional brainstorming sessions can be scheduled. Having a detailed, clear, and well communicated master plan based on Work-flow (process) mappings is invaluable. Workflow mapping related collaboration meetings can be facilitated by an experienced process consultant.

    What Is Work-breakdown-Structure (WBS)

    Work breakdown structure (WBS) is the foundation project managers (PM) to manage scope, work, and deliverables. For example, the company website creation project shown depicts both project and product WBS deliverables for their website project in “Product/Project WBS Model.

    PMs use WBS for project control and management of related teams within and organization. A WBS provides checkpoints used by the PM and organization to measure product, program, portfolio, and project progress and performance.

    There are two ways to use a WBS. The first is develop the WBS as a “To Do” list. Similar to a grocery shopping or errand list. The problem with to do lists is assignment to others for completion. For example, If a to do list for a workday includes a “Fix XYZ’s program schedule” entry, this is a good personal reminder about personal considerations of stakeholder consideration including political ramifications of changing program scope. But do executive stakeholders have different positions about program scope impact from schedule changes? The short to do reminder “fix XYZ’s program schedule” is fine from my perspective, because I’ve considered the change for days, talked to stakeholders and considered the change even further.

    However, If my to do were assigned to another stakeholder or consultant, would they have any idea what my to do statement meant? Those assigned could spend days getting acquainted with organization and any new strategic programs. The assignment would have no performance expectation nor provide any work or deliverables completion evaluation. Certainly, PMs should limit use of to do lists to personal reminders. Because project results may affect your own professional career and organizational success, a better tool is required.

    Work Breakdown Structure (WBA) Modeling Considerations

    A WBS must minimally meet these critical success factors (CSF) for inclusion in a project –

    • Informs the person assigned work what successful completion is (objectives) and how it is evaluated before starting the work, thus providing clear performance expectations.
    • Work deliverables completion must be unambiguously measurable. Stakeholders need hard-edged project progress measures not open to interpretation, semantics, or prevarication.

    Those two criteria sound simple, but difficult to implement. However, this is one of the most difficult tasks within the art of project management. The specific, required assignment end result must be decided then converted into a metric or key performance indicator (KPI) for measurement of results for objectives. The assignment of the XYZ program schedule we discussed earlier can now be used to illustrate.

    Identify specific results expected from the assignment to “fix the XYZ schedule.” In reviewing conversations with stakeholders, a number of characteristics required from the schedule are identified and defined. Stakeholders expect the project to be finished within 250 days while avoiding use of outside contractors for a spend of less than $325,000.

    These metrics are used to inform the assigned consultant the schedule must be complete within 250 days or less, cannot use outside contractors, and is budgeted for less than $325,000. These are the assignment KPIs for successful delivery defined for and by assigned team members. Obviously, stakeholders must know exact KPI metrics for consensus of expectations. A weak assignment would be advising team members of a revised shorter and cheaper schedule without use of outside consultants. How likely are these metrics to gain a consensus decision? Probably poor; stakeholders can surmise for themselves what faster, cheaper, and with no outside consultants means. To determine what result is actually achievable, requires meeting with assigned staff members, reviewing the current schedule together, and allowing team members to consider whether expected results are achievable. Staff members then need time to consider achievement effort for the expected result requires for successful completion. The staff member’s approach and budget for work completion leads to a solid WBS entry. In short, create the WBS in collaboration with team members.

    Unfortunately, too many project managers (PMs) don’t recognize WBS and related collaboration importance. Many PMs believe all that is needed is a list of project tasks for start of work. This approach leads to projects taking longer than needed thus wasting time, resources, and budget without all deliverables successful completed. Further, this lack of structure produces late projects because scoping of all required deliverables, resources, and costs in the initial planning are not defined in the WBS. Developing a strong WBS, requires defining the scope and all major deliverables for the project followed by decomposition into required tasks and roles needed to support required deliverables when creating a WBS.

    Measured Product/Project management and control requires:

    • Identifying problems early and fix them quickly and inexpensively
    • Each project team member knows their assignment responsibility and accountable is for delivery.

    Acceptance criteria informs team members of their responsibility and accountability for successful deliverable completion.

    02:40

    Lecture 14 – Role of Workflow Mapping in Scope Baseline, Deliverables and Scope Change Control?

    Discussion –

    What Is Project Scope Management?

    Scope management is use to define product and project scope. Project scope includes business requirements, project requirements and delivery requirements. Product scope includes technological requirements, security requirements and performance requirements.

    Scope refers to a project or product boundaries: Scope determines work to be completed during the project or product development lifecycle including identification or work, functions and features as well current product/service development not included within scope. During initiation and planning processes, requirements collection methods are used to capture and define work and deliverables to be completed. Controlling and monitoring process groups are concerned with managing scope creep , documenting, tracking, and approving/disapproving project changes. During the closing process group, project deliverables are audited to assess actual outcomes against requirements, scope for products as well as WBS for projects.

    .

    Refer to ”Project Scope Management” diagram. Project Scope Managements follows the PMBOK process groups – Initiating, Planning, Monitoring , Controlling; these groups are the domain responsibility and accountability of the Project Manager (PM). The Executing process group is followed for automation and product development deliverables within the scope of a project.

    During Initiating and Planning, the PM ensures the following task are performed and completed –

    • Capture Requirement – Define and document stakeholder’s needs to meet project objectives.
    • Define Scope – Develop detailed description of both product and project.
    • Create WBS – Decompose project deliverables and work into manageable components and work packages

    During Monitoring & Control and Closing, the PM ensures the following task are performed and completed –

    • Verify Scope – Formalize traceability & acceptance of completed deliverables.
    • Control Scope – Monitor Status of product and project scope, and manage scope baseline changes.
    08:48

    Lecture 15 – Role of WBS in Scope Baseline, Deliverables and Scope Change Control?

    Discussion –

    Role of WBS in Scope Baseline, Deliverables and Scope Change Control?

    Refer to “Product Project Scope Measures” for this discussion.

    Product scope – Is features and functions characterizing a product, service, or result. Project scope is used not only to create the website, but execution of project management of work related including acquisitions, quality, risks, human resources, costs, time, and communications. Project scope is concerned with website infrastructure, documentation, training materials, and related business processes. Though not shown in the diagram, website marketing and promotion, website content and launch, and other project deliverables must defined and planned.

    Project scope – work required to deliver a product, service, or result with specified features and functions. Project scope goes beyond the product scope. For example, the company website creation project shown depicts both project and product WBS for this project.

    Project scope is used not only to create the website, but execution of work related project management including acquisitions, quality, risks, human resources, costs, time, and communications. Project scope is concerned with website infrastructure, documentation, training materials, and related business processes. Though not shown in the diagram, website marketing and promotion, website content and launch, and other project deliverables must defined and planned.

    Product scope focuses on website features, functions, and functionality. Product scope concerns include customer newsletters, order tracking, corporate events photo gallery, surveys, and other related deliverables. In product projects, project scope is managed by a project manager and product scope is managed by product managers, system and business analysts and/or technical leaders, depending on organizational resources and structure and project scope. Project and product scope must be properly integrated resulting in the project manager and person with product scope responsible must work and collaborate closely.

    In speaking with a project manager managing complex banking industry customer projects, the PM asked WBS related questions to clarify and improve understanding of scope management. “It's almost all about scope and how to better manage it. Scope is the basis of planning. Most customer disagreements end up being scope changes, scope expectations, requirements and such". Issues often found in product and project scope management generate a degree of stress created by complex projects or industries. WBS helps project managers deal with the stress.

    Care is important when selling projects without a clear and measurable scope definition then expecting the PM and project team to meet poorly defined and unrealistic deadlines and to successfully complete unreasonable workloads. There must be a fair and realistic match between the sales and planning processes. Otherwise, failure is almost certain. A project without a solid and measurable scope definition may occur once or twice to gain a client, but you'll burn yourself or your project team out if you work without a well-defined project and product scope and Statement of Work (SOW). Unfortunately these expectations are not a rare instance. This also explains why many projects fail despite excellent knowledge, tools, and skilled project managers. It's simply too easy to make the project manager a target for decisions outside the project manager's authority, or for decisions made before assignment of the project manager; it's not right to easy make the project manager the scapegoat for product or project failures. It seems a shared belief exists within most organizations whatever happens, if the project fails, this is always the project managers fault. And yet, based on survey after survey most reasons for project failure are organizationally related and are outside the direct control or authority of project managers.

    What’s Product Scope, Project Scope, and Product WBS?


    Project Context Scope refers to –

    • Product scope – features and functions that characterize a product, service, or result
    • Project scope – work required to deliver a product, service, or result with specified features and functions. Project scope goes beyond the product scope. For example, the company website creation project shown depicts both project and product WBS for this project.

    One of the key reasons why the WBS and WBS dictionary are important to every product and project is because each of these, together with the Scope Statement, are an integral component of the scope baseline shown in the “WBS/Project Scope Baseline” diagram.

    The scope statement defines product scope, project deliverables, and defines product user acceptance criteria. Consider a project to build a house and customer requests adding an attached garage to the house. Referring to the scope baseline to see if the garage was inside scope or not, you find the garage is not listed within scope nor is it listed in either the scope statement or WBS. You advise the customer the garage in the project plans. The customer must submit the requested change to the formal change control process for approval. Once approved the scope baseline is updated to include the customer request as seen in the “Scope Baseline Creation Process“ diagram.

    What’s the Change Request Process?

    In ”Workflow & WBS Change Process” diagram, the PMBOK change control processes are graphically represented. Processes in the “Executing Process Group” and “Monitoring and controlling process group” produce change requests as output. During project execution or monitoring and control of the project, change request may be issued. Resulting from any of processes shown, such as controlling scope or conducting procurements, change requests may be needed. Change requests present different impacts on the project.

    As an example, some changes impact costs while others impact quality or combination of both. A change request may impact project scope resulting in impact on the WBS. Any of fifteen processes shown may require WBS and/or WBS dictionary updates. The diagram represents impact of change requests on various project management areas. During project execution, monitoring or controlling, WBS may require update resulting from change requests. Changes require using the formal change control process to ensure the scope baseline is updated.

    Procurement (Acquisition) is the act of acquiring, buying goods, services or works from an external source. It is favorable that goods, services or works are appropriate and procured at the best possible cost to meet the needs of the acquirer in terms of quality and quantity, time, and location. Corporations and public bodies often define processes intended to promote fair and open competition for their business while minimizing exposure to fraud and collusion.

    20:40

    Lecture 16 – Fundamentals – Functional Decomposition and Object Oriented (OO) Analysis for Workflows and WBS Mapping

    Discussion –

    What Is Functional Decomposition?

    Functional Decomposition is a set of actions or steps taken to break down a complex process into smaller, simpler, more comprehensible tasks or components used in creation of functional requirements documents, work breakdown structures (WBS), and workflow process mapping. Functional decomposition is a method used to sub-divide a complex problem into simpler components, data, or tasks required to be performed or delivered.

    Functional decomposition is a process used to resolve functional relationships into constituent objects and components so original functionality can be recomposed from decomposed objects and components into an alternate more robust composition. Decomposition is performed to gain insight into identity, structure, and behavior of constituent objects and components, or to obtain a compressed representation of a global function or task only feasible at modular level of independence or non-interaction. Interactions among components are critical to function of a collection. Not all interactions are observable, but can be deduced with repetitive observation, synthesis, validation, and verification of recomposed behavior.

    Functional decomposition involves perceiving functional relationships regarding how original complex business functionality was developed. The principal focus is how "As-Is" functionality was developed together with interactions among collective components. Complex functionalities are better understood when operations and relationships are separated using functional decomposition.

    When and How is Is Functional Decomposition Used?

    Requirements based functional decomposition is used during product and project initiation, planning and analysis process groups for functional decomposition diagrams production needed for the functional requirements document. Functional Decomposition results during collaboration with business analysts and subject matter experts. Decomposition begins with first level components and functions then continues to lower levels until sufficient or atomic level of detail discovered, captured and documented. An end-to-end walk-through of business operations and validation of each function is performed to confirm functions and interactions are traceable to meet requirements being delivered.

    Object Oriented Methods

    Object Oriented methods are based on three concepts – objects represent real-world entities. An object has a state, i.e. one of the possible conditions in which the object may exist represented by the values of its properties (attributes). State changes are reflected by behavior, i.e. how an object acts and reacts determined by the set of operations the object can perform on itself, and also knowing its interface, functions and methods. A set of similar objects is called class. For example, the attributes for the class animal are having four legs and a tail. Its behaviors is sleeping and eating. Then possible instances or objects of the class animal are cat, elephant, and horse.

    Finally, messages are requests (events) for the receiver objects to invoke the indicated method or behavior and return the result of that action to the sender objects. States changes through behavior when the object receives a message. There are many different techniques based on Object-Oriented (OO). Unified Modeling Language (UML) is considered the standard OO modeling language. COAD and Yourdon’s method preceded UML from the 3 Amigos (see “For Further Reading” lecture).

    UML Diagrams

    UML is a modeling language primarily used for specification, visualization, and development and documenting of software systems. Business professionals adapted UML as a powerful business process modeling technique.

    With 14 diagram types, UML offers a flexible and powerful methodology for visualizing most business process. UML diagrams are used for modeling detailed logic of business processes. UML diagrams are the OO equivalent of flow charts with extensive facilitative system knowledge and information through model of business and technical domains.

    UML is far more flexible for defining system knowledge and information requirements than flowcharting. However, with 14 different diagram types understand the diagrams may be difficult for many stakeholders not familiar with OO because the same process is modeled from many viewpoints using different UML diagrams.

    OO Workflow Model Notation

    Workflow is a continuous movement through tasks between computer applications or people in an organization. Two or more members of a workgroup to reach a common goal can define workflow as any task performed in series or in parallel. Workflow is more than a technique to model a process. It is a method to analyze and improve a process, including its modeling.

    The workflow development process uses workflow models to capture relevant information about processes and related courses of action. The process uses of four stages: Information Gathering, Business Process Modeling, Work flow Modeling, Implementation and Execution, and Verification.

    How to Diagram a Workflow –

    Refer to “OO Work Flow Model Notation” diagram.

    Identify a Process – A process captures a repeatable collections of operation, steps, or activities. This differs from a project. Projects capture a collections of work or tasks to be completed as a work package then delivered by assigned resources at specific time (based on effort) to deliver specific results within specified scope. Work or activities occur repetitively within an organization.

    Name the Process – A process name must be clear and specific. A process name using a verb e.g., “Collect Past Due Payments” is clearer and more specific than “Past Due Payment Process.” The tendency is to use broad names in capturing related activities. This leads to multiple problems as discussed in the next step.

    Identify a Clear Process Start/End Conditions and Exceptions– A common mistake found in reviewing deliverables from Business Process Analysts and SMEs is lack of a clear process start or end points. This often leads to models with decision boxes on the side not integrated into the workflow diagram. Identify the first activity with preconditions in the workflow that must be true before the process can begin. Identify the last activity with post-conditions requiring completion signaling the process has ended. Identify any exceptions to process start or completion.

    Identify Workflow Diagram Purpose – Many decisions regarding detail granularity and workflow scope are driven by purpose and scope based on context for diagramming a workflow. Identification of know errors root cause, automation project preparation, or initiation of a business process improvement project.

    List or Diagram All Steps Identified from Start to End of Process – Use pen, paper and whiteboard for initial draft. Avoid using complex tools as this slows the thought process and distracts from capture of process-related information. Ensure all steps are identified then integrated into the list or diagram. Use decision boxes to capture exceptional flows. Process or Workflow Analysis requires frequent review of initial drafts scanned from paper drawings or photo images of whiteboard drawings. Errors in thought are easily identified and corrected prior to participant commitment of the diagram to an electronic tool.

    Identify Exceptions and Rules for Each Process Step – If receiving requests by phone is the main process flow, is email an option? Are email requests managed differently from phone request? How? Include this information in the visual model. Often a decision box, is adequate to capture workflow exceptions.

    Leverage Relevant UML Model Symbols and/or Workflow Modeling Symbol Set (to be discussed) to Visually Diagram the Process Model – Use only the symbols needed for diagramming. Most Business Analysts do not use all optional symbols or diagramming types available for notation because it is confusing to stakeholders. SMEs probably don’t care if Workflow Mapping and Analysis (WFMA), Business Process Model and Notation (BPMN), or Unified Modeling Language (UML) Use Case, Sequence, Class, Activity, or Landscape (flowchart) are used for the Process Diagram. Stakeholders want a clear and easily understood diagram.

    Follow the steps above to create workflow diagrams improving project communication, resolving business problems, and moving the project forward getting real, useful work accomplished.

    UML Model Symbols

    Refer to “UML Model Notation” diagram.

    Use Case – A UML use case (also story or scenario) encapsulates a series of related interactions between an actor (also persona or user) and a system enabling the actor to achieve a goal. To rephrase, a use case describes a system's behavior as it responds to a series of related requests (events) initiated by an actor.

    Relationship types used for use case diagrams are –

    • Association between actor and use case
    • Association between two use cases
    • Generalization between two actors
    • Generalization between two use cases

    System Boundary Box – A rectangle bordering a use case is called a system boundary box. As the name suggests it defines the scope and context of a system - the use cases inside the rectangle represent functionality (requirements) to be implemented within the system. Indicate Release Scope using a System Boundary Box. Boundary boxes are labeled indicating the release assignment for related use cases.

    Actor – An actor is a person, place, time, organization, or external system playing a role in interactions with a system (actors are typically drawn as stick figures on UML Use Case diagrams).

    Class – UML class encapsulates required objects and relationships among them. A class compartmentalizes detailed information about properties (attributes, data) and method interfaces (associations to other classes, functions, operations) defined by classes.

    Interface – An interface is a collection of operation signatures (methods) and/or attribute definitions defining a unified set of behaviors. Interfaces are realized by classes and components - to realize an interface, a class or component implements operations and attributes defined by the associated class interface (method, operation). A class or component can realize zero or multiple interfaces. One or multiple classes or components can realize the same interface.

    State (Machine) – A UML state machine is a behavior diagram encapsulating discrete behavior of an object or component of a system using finite state transitions. State machine diagrams are used to express usage protocol for an object or component of a system. Behavior of an object or component is a direct consequence of input, and depends on preceding state as well. An objects prior event responses are modeled by a finite state diagram. A State Machine diagram presents various object or component states as well as various event responses changing from one state to another.

    Component – A UML component encapsulates system content and events. Manifestation of the component is replaceable within the component's environment. A component defines behavior to events through use of required interfaces.

    Node – A UML node is a computational resource within which UML artifacts are deployed for execution as either device nodes or execution platform environment such as an operating system or a database management system.

    Activity – A UML activity is a major task requiring execute to complete an operation contract. Activities are represented in activity diagrams. Activities represent –

    • Operation invocation
    • A business process step
    • An entire business process.

    Activities are decomposed into sub-activities, until atomic actions are reached.

    Decision – UML decision and merge nodes are represented by a diamond shape optionally named. Decision node output control have guard conditions allowing control flow when guard conditions are met.

    Note – UML Note symbols are especially common used on class diagrams. A UML note symbol is displayed as a dog-eared rectangle with a dashed line to the annotated element. A note symbol represents several information such as –

    Package – A UML package is used to group elements, and provide a namespace for grouped elements. Packages may contain other packages, providing for hierarchical packages organization.

    Pattern – A pattern (or design pattern) is documents description of a general solution for a design problem recurring repeatedly in multiple projects. Designers adapt pattern solutions to specific projects. Patterns employ a formal approach for describing design problems, proposed solution, and related factors affecting a problem or solution. A successful pattern is established as leading to good solutions in three or more previous projects or situations.

    Synchronization – UML standardizes behavioral notations such as state machines (charts) and sequence diagrams, but does not define synchronization rules. A key feature of Executable UML is it does not constrain implementation with unnecessary sequencing. In traditional programming languages the processing stream is sequential by default, unless intentionally diverted using platform specific concurrency mechanisms. In Executable UML, the opposite is true. All events occur concurrently in a platform independent timeframe unless explicitly synchronized. This facilitates creation of application models deployable within arbitrarily distributed platforms. As platform technology evolves from embedded to parallel to distributed to cloud and back, this capability is increasingly relevant for the duration of a project.

    Association – UML association is a relationship between classifiers used to show instances of classifiers are linked or combined logically or physically into some aggregation.

    UML categorizes association as semantic or structural relationship. Association is used on various UML diagrams

    • class diagram associations
    • use case diagram associations
    • deployment diagram artifact associations
    • deployment diagram communication path

    Several concepts related to association are

    • association end ownership
    • navigability
    • association-arity (multiple items)
    • aggregation type.

    Refinement – UML Refinement encompasses various approaches for producing accurate computer applications and simplification of existing programs enabling formal validation and verification.

    Transition – A UML transition exits each state or activity, connecting to another state or activity. A transition transfers operations from one state to another and representing response to an event. States connect with transitions creating internal transitions within states.

    Dependency – UML Dependency is a relationship exhibiting an element, or collection of objects or components, requiring other model objects or components for their specification or implementation. A component is dependent upon an independent component called supplier.

    Workflow Modeling Symbol Set

    Refer to “Workflow Modeling Symbol Set” diagram.

    Rectangle – Rectangles denote– Process and activities, Location, Hold or Delay, One Exit Path (Arrow) Only

    Diamonds – Diamonds denote – Decision Branch, Two Mutually Exclusive Paths (Arrows) Only (Yes/No or True/False) and are always labeled

    Circles – Circle denote – Use in Matched Pairs or Groups to Connect Parts (components) Flow or Continue across Pages (“B3” Connects to “B3” …), Use alone for “Start” or “FInish” Terminals, Material and Information – Clarify Flows

    Arrows – Arrows denote – Material or Information Flow in Direction of Arrowhead, One Arrowhead Only, Always Labeled with Diamond; May be labeled with Other Symbols

    Documents – Documents denote – Use or Consultation of Required Input Document, Production of Required Output Document, General Compliance with Documentation Requirements, Applies to Hard or Soft Copy Documents.

    03:44

    Lecture 17 – Project Requirements Impact on Workflow and WBS

    Discussion –

    Requirements Impact on Workflow and WBS

    Well-defined project requirements, are essential to success with project planning and execution. Project scope cannot be complete with poorly defined requirements.

    “Requirements include quantified (measurable) and documented needs and expectations of the sponsor, customer, and other stakeholders.

    Similar to project scope and product scope, project requirements and product requirements are essential to success.

    Project requirements must include business, delivery, and project management

    Product requirements relate to technical characteristics such as functions and features, security, safety, compliance, performance, quality requirements.

    Revised PMBOK scope management offers a new process named Collect Requirements. This relates the importance of scope management to the global project management community. PMBOK includes requirement documentation in creation of workflows and WBS. Because requirements are the foundation of workflows and WBS, this is a significant enhancement.

    Although scope management is a process other stakeholders are involved in, collaborative interaction between the project manager and analyst is essential. Project success is gauged by level of effort given to requirements management. Key stakeholder must be integrally involved in Workflow and WBS requirements mapping and document creation based on knowledge, expertise, and contributions to work definition thus scope.

    Related to requirements, the Requirements Traceability Matrix links project requirements with the originator facilitating tracking of requirement to deliverables. Refer to “Requirements Traceability Matrix”. The Requirements Traceability Matrix (RTM) tracks requirements throughout the project for monitoring and controlling changes to product scope. RTM ensures each requirement adds value to the business and only approved requirements are delivered. The RTM column titled Requirement ID defines a unique identification number for each requirement listed in the matrix.

    Each requirement includes a name (description), owner (requestor of the requirement), priority, and comments. The WBS ID column links each requirement with a WBS deliverable. The WBS ID ensures each requirement in the matrix has a corresponding approved deliverable in the WBS. A deliverable can be listed with multiple requirements; the same WBS ID in several rows can correspond to multiple requirements. Requirements are identified by a unique numbers in the Requirements ID field, but the WBS ID is not identified by unique numbers in the matrix. Using the matrix, requirements are traceable to corresponding WBS deliverables.

    04:11

    Lecture 18 – Project Requirements Impact on Deliverables

    Discussion –

    Key Tasks Used for Scope Planning

    The “Scope Planning” diagram show the key tasks and flow of work used in scope planning –

    • Capture Requirements
    • Determine Deliverables
    • Define Scope
    • Create WBS

    Monitoring Project Activity and Deliverables

    Effective project management requires though before action, identifying and managing potential problems before these occur, and constant monitoring to determine achievement of project scope and objects. Internalization of project management best practices is the goal. To make project management best practices second nature, a way of considering decisions made in managing a project, while not to controlling but effectively and efficiently delegating project related activity and information.

    Developing scope for a project entails identification of three key components – boundaries, deliverables, and requirements regardless of project size or type. Project managers are ultimately responsibility for scope statement creation by defining product and project key components. Project Managers must ensure major project documents including the scope statement are defined in compliance with project goals based on initial requirements and expectations of key stakeholders.

    Boundaries Definition

    Project boundaries require measurable and auditable characteristics defining what is in project context and what in not. Project boundaries are integrally linked to project objectives creating a holistic vision of project work and content definition of expected product and project results. A clear boundary statement directs work and content applicable to project scope.

    Requirements Definition

    Project requirements are the foundation of Workflows and WBS. A quality Workflow and WBS is constructed for use in meeting all project requirements and deliverables within scope. Project requirements are qualitative and quantitative interpretations of interests and expectations of product or project stakeholders. Project requirements support project objectives, budget, communications, assumptions, and schedules. Requirements essential to achieving project success. Incorrect, inaccurate, or excessive project definition of requirements result in delays, productivity loss, wasted resources, or/and customer dissatisfaction. Product requirements may specify characteristics of deliverables and define customer interaction with a product and how a product interacts with other products.

    Deliverables Definition

    A Project deliverable is a tangible, measurable, and auditable result or output expected to be gained or produced upon successful completion of a project work package, object or task. Defining project deliverables is the baseline for overall product or project scope. Deliverables may include well-trained employees, Improved skills, and/or Increased performance as required and expected project success.

    11:59

    Lecture 19 – Knowledge Framework for Requirements-based Workflows, WBS, and Deliverables Modeling Development

    Discussion –

    Knowledge Is Information

    Information is knowledge base on human intellect. A practical definition of information is human intellect structured rather than random facilitating communication and dialog. Refer to the ”Knowledge Universe” and “Information Vector” diagrams for this discussion.

    The 1st diagram shows knowledge apportioned to four cells indicating the state of the universe of knowledge versus the state of our information. The 1st quadrant represents Known knows (KK) or information considered facts. In the 2nd quadrant knowledge (facts) has little or no uncertainty. Known unknowns (KU) are questions known to be unanswered. Unknown known (UK) is available information requiring unambiguous interpretation similar to a problem faced by an analyst confronted by a myriad of facts not easily evaluated for collective accuracy or meaning. Unknown unknowns (UU) are an effectively undefined information the existence of which is surmised but does not forcibly yield to analysis. The 3rd diagram provides characterization of overall state of information from both known and unknown perspectives. The information characteristics of content is not the same for various observers. However, information is a product of and dependent on a specific observers intellect. Information characteristics are described as a collection of vectors. Base on human experience, at least seven properties characterize information. Where dotted lines intersect, each scale defines a vector value specific to information seen by an observer. The vectors represent a bundle of qualities not necessarily reconcilable with one another, let alone serve a basis for conclusion, decision, or immediate action. Time is required to determine what is considered KK.

    Refer to “Formal Tacit Knowledge Organizational Functioning” diagram for the following discussion.

    Formal and Tacit Knowledge and Organizational Functioning

    Knowledge if information and information is never complete and therefore is only rendered useable through processing. A major organizational function is processing information and knowledge to enable coordinated progress toward common goals despite limits of information. Organizations are systems exposed to both inner and outside shocks requiring them to be adaptable.

    A key function of workflow and WBS mapping is to enable an organization to know what it knows. Tacit knowledge is key organizational adaptation to the limits of internal and external knowledge. Successful organizational coordination depends on related knowledge to resolution of procedural, workflow, or WBS problems. Both formal and tacit knowledge are equally important organizational capabilities. Technical success is dependent on what people learn and can be thought of as apprenticeships. What is important about tacit knowledge is shown in the lower quadrant of the “Formal Tacit Knowledge Organizational Functioning” diagram. This literally represents everything else the organization needs to know how to do. This is where individual and group learning and knowledge provide the organization with response capabilities not anticipated nor designed. In a universe without perfect knowledge or information, the ability to compensate and adjust to UUs are essential for organizational survival. This is the beginning where our understanding framework expands into the basis for simple, robust, and widely acceptable method for graphically describing workflow processes and WBS in a form readily mastered and applied by an organization. The capability to accurately capture formal and tacit workflow and WBS knowledge has large dividends to organization performance through product, portfolio, program, and project management.

    Refer to “Locus Mode Action Interactions” diagram for the following discussion.

    Action Resulting from Interactions and Locus Mode

    Expanding the concept of the product of actions and information basic process building blocks of a system can be assembled. Action are concerned with two basic system dimensions. Where actions occur (Locus) and how actions happen (Mode). Actions are active or passive when inherent system properties causing action to occur. Animals eating is active whereas radioactive decay is passive. Locus of action is also internal within the system or action spanning boundaries where environment is involved with the internal system. Interaction between locus and mode actions enables a multitude of specific actions aggregated into complex actions within complex systems.

    Locus Mode of Information

    Information is elemental to all we do and can be conceptualized similar to actions. A mode (function) of information is inherent to action. In addition, regulatory action is found in more complex action as when people automatically perspire to cool down as body temperature rises. The framework of systems rely on regulatory action to maintain stability – is seen in the balance of motion and gravity within the solar system. Information can also be thought of as stock and flow found in economics theory where a stock is an accumulation of information and a flow is movement from one state to another as shown in the interactions found in the ”Locus of Information” diagram.

    Systems Organization

    The previous concepts can now be combined as shown in the “Work Information Flow” diagram. Systems interact with their environments including organizations – receiving inputs, transforming inputs into outputs and returning output to the environment. Within this context, organization processes are considered transformation of inputs to output or a combination of acquisition, transformation, and delivery of outputs.

    Organization processes are of two types. The first is exchange of boundary spanning inputs and outputs with an environment crossing a permeable system boundary to interact with an environment. These processes add value to acquired inputs as these are used to create outputs exchanged across an environment. Transformation is central to human and organizational existence and a primary concern and focus when examining and designing organizational workflow processes and work breakdown structures.

    Most organizations influence and alter what environments do through public relations, promotion and marketing, influence of laws and government regulation. Bank hold depositor money and limit access while using depositor money as the basis of loans and creation of other assets. Transactions and thus organizational processes over time are dynamic due to material, new technology, and other delays. Time is a universal, irreplaceable cost and resource. Temporal action and component relationships pose important consequences to overall organizational and system functionality.

    Organizational processes are information dependent and of major importance to an organization while striving to meet goals. Information dependency is inherent to process and used specifically for a specific process. Information must be transformed as required for customer and stakeholder satisfaction, product and project design, promotional campaigns, Information Technology support, and related processes and functions. Regulatory information is used to provide information about consumption, evaluation, performance to expectations, and work provided by the system. Feed-forward information guide future action and decisions based on criteria established for targets (objectives) performance and expectations as shown in interactions.

    Flow Synchronization Effects

    A dimension of workflow relationships is synchronicity. Material and information flow may be synchronous that is simultaneously linked with a serial sequence with minimal information access delay and material support. Material and information use the paths through steps and processed in parallel at a common location. Asynchronous flows are non-parallel with different paths through boundaries and/or sequence with timing less likely linked between flows where connection is less desirable.

    Synchronous flows are typically preferred for workflow designs keeping materials for processing and information kept in close proximity. This facilitates rapid decisions and exception handling with relevant expertise available where and as needed. Asynchronous material and information flows considered undesirable; non-synchronization creates delay and requires more information processing.

    As shown in the “Flow Synchronization Effects” diagram, consequences of Synchronous and Asynchronous workflow design can be functional or dysfunctional for organizational goal achievement. Functional relationships are valuable for support of organizational objectives from material and information as designed. Dysfunctional flows cause unneeded delays, costs, and errors from which no value is achieved. Thus convergent flow coupling may be the best choice for process improvement. Functional or dysfunctional results can occur in all four cells of the diagram. Notice, convergent and synchronous in the top left cell renders both high efficiency and risk – the opposite result is show in the lower right cell. Tradeoff is operative in deciding the path to follow.

    09:07

    Lecture 20 – What Are the Workflow and WBS Levels, ID, and Numbering


    Discussion –

    Workflow and WBS Levels, ID, and Numbering

    Workflow and WBS mapping support stakeholder understanding while highlighting problems, miscommunications, gaps, redundancies, workarounds, rework loops and waste. Maps convey what and why while workflow maps convey why, how, where, when, and what with.

    A workflow and WBS are key project deliverables for organizing project team work into manageable components and functions. The WBS visually defines the scope into manageable components and interactions a project team can understand. Each level of a workflow and WBS provides further detail definition for a product, process and/or service deliverable. When creating a Workflow or WBS, identify and organize required work at various structural levels. The diagram depicts a sample WBS with three defined levels.

    Level 1 is the 1st level of workflow or WBS. There is only one component in level 1. A workflow map or WBS is an outlines scope of specific project deliverables. A workflow or WBS starts with the project as the level 1 deliverable then is decomposed into sub-deliverables using the outline hierarchy similar to that shown. The WBS shows the component breakdown for a product or service deliverable from a project.

    Work packages and associated costs are grouped and assigned to specific departments for production of work. Departments (cost accounts) are defined in an organizational breakdown structure and are budgeted to specific deliverables production. Integrating cost accounts from the organizational breakdown structure and the project WBS enables an organization to track financial progress in addition to project performance.

    Workflows map organizational collaboration needed to accomplish a goal. Essentially everything done in an organization involves or contributes system, process, or workflow.

    Typical business workflow characteristics are –

    • Exists to meet a specific business need
    • Collaboration among multiple people or groups
    • Operates over time
    • Often has multiple iterations
    • Is repeatable.

    The project team creates the project workflows and WBS by identifying functional deliverables and decomposing these deliverables into smaller systems and sub-deliverables or work packages. Sub-deliverables are decomposed to a level for single person to be assigned. At this level, specific work packages required to produce the sub-deliverable are identified and grouped. Work packages represent a list of tasks or activities required to produce specific work units. Work packages and tasks are organized into project schedules for completion a specific time using a specific level of effort. As shown in the diagram, the bicycle assembly consists for three major assemble components (WBS 1-3) which are further decomposed into three three component and work packages to be discussed in subsequent lectures 21-23.

    Work Breakdown Structure (WBS) Guidelines

    These guidelines are considered when creating a WBS –

    • Work packages define work, duration, and costs for tasks required for sub-deliverable production
    • Work packages should not exceed 10 days duration
    • Work packages are independent of other WBS work packages
    • Work packages are unique.

    Workflow (Process) Mapping

    Process mapping is collection of tools and methods used to capture, define, document, and support understanding an organization and its processes. Process mapping tools allow organizations to document, analyze, improve, streamline and redesign business processes to realize organizational effectiveness and efficiency. A workflow process map provides visual aid for showing work processes and how inputs and tasks are linked highlighting steps, materials and behaviors required for consistent production of required deliverables. A workflow process map enables critical thought and collaboration of how work is done, where it is done, who performs it, what problems (constraints and exceptions) frequently occur and how these can be solved effectively. Workflow maps show where we are (“As-Is”) then help plot our best possible routes to where we want “To Be”.

    Process Model levels

    • Level 1 – Outlines organization operational levels are rarely actually drawn. For example customer and administrative processes.
    • Level 2 – Shows end-to-end processes across operational areas. For example a process for purchasing capital equipment crosses multiple operations: requesting department, purchasing, accounts payable, asset management, receiving and maintenance. Also referred to as top down or high-level process maps. Quick and easy to draw providing detail required to understand or realize improvement.
    • Level 3 – Shows the roles, inputs, outputs and steps required to complete a specific process within an operational area. For example, a purchasing process (request, sourcing, purchase order) can be depicted as a process map. Also referred to as cross-functional or deployment diagrams. Contains information for improvement efforts, but often insufficient and functional detail for training or operational documentation.
    • Level 4 – Provides documentation of systems, instructions and procedures required to complete steps in level three processes showing inputs, outputs, associated transformation steps, material requirements, and decision points. For example, specific steps necessary to create a Purchase Order in an enterprise application requires a level four process map.

    Procedures and system instructions are represented as text, algorithms or as a detailed process map. Level of detail requires resource-intensive creation, but offers greatest improvement potential. Illustrate of decisions and subsequent actions provides excellent training and reference materials detail. However, time and effort can turn stakeholders off before experience of benefits from the work is given a chance.

    Workflow maps have a many important properties. 1st maps are graphic diagramming a combined flow to activity and information. 2nd the method is singular meaning a specific symbol set is used for all workflows or processes and used according to a specific rule set. 3rd rules constitute discipline. 4th maps are scalable encompassing the entire process at any level of detail. 5th maps are robust an can be applied to any organization. And, 6th maps are verifiable describing an existing auditable process of actual flow, material, information, and behavior for determination of accuracy thus promoting process improvement.

    Two Levels of Workflow and WBS Component –

    Level of Effort – Support activity not producing product definitive end products – seller or customer liaison, project cost accounting, project management.

    Discrete Workflow or WBS Component – The end product, service, or result directly planned and measured – book, application, house, bicycle.

    Workflow and WBS Fields an Attributes –

    A field is a container for a data such as name, price or number. Field are usually stored as text but can be held in other forms.

    03:22

    Lecture 21 – What Is a Workflow and WBS Component and Type

    Discussion –

    Workflow and WBS Component and Type

    Both a workflow and WBS area deliverable-oriented project decompositions into smaller components. Workflow maps and WBS are key project deliverable organizing project team work into manageable activities, tasks, and work packages. Both workflow and WBS contain Components defining –

    • Inputs
    • Outputs
    • Transformations (Rules, Steps)

    Components may be connected when output description of one component matches the input description of another.

    Workflows define components for:

    • Who performs tasks
    • How the tasks are ordered
    • How relevant information flows to tasks
    • How the tasks are tracked

    Generally object-oriented methodology as shown in the diagram is the preferred foundation for designing and constructing components. UML component diagrams are used as an architecture-level artifact, for modeling business software architecture, technical software architecture, or both together. Physical architecture issues generally are better addressed using UML deployment diagrams or network diagrams. Component diagrams are particularly useful with larger teams. Initial architectural modeling efforts focus on identifying initial architectural landscape of your system. UML component diagrams enable modeling high-level software components, and more importantly interfaces to those components. Once component interfaces are defined, and in consensus with stakeholders, organizing development effort among teams is more manageable. Need to evolve interfaces to reflect approved requirements changes to design as the project progresses must be negotiated among stakeholders and teams then appropriately implemented.

    Design Business Components to Support Workflow and WBS

    Implementing workflows involves ensuring all workflow exception conditions are handled. When designing business workflows consider method invocations requiring no reply, or long response times. If a component executes a specified collection of steps sequentially and synchronously, consider using a pipeline pattern. Alternatively, process steps are executed asynchronously in any order using the event pattern.

    A pipeline consists of a chain of processing processes, threads, and functions arranged so output of one component is input to the next; the name is analogous to a physical pipeline.

    An event is a significant change in state. What is produced, published, propagated, detected or consumed is an asynchronous message or event notification. While the event, is a state change triggered by an event message.

    03:24

    Lecture 22 – What Is a Workflow and WBS Work Package

    Discussion –

    Work Package Definition

    Work package is the effort required to produce a deliverable within a project. Effort is either a single task or several related tasks. A work package is often considered a “mini project” within a larger project. Work defined at the lowest level of WBS used for cost and effort estimation and management according to PMBOK. A work package typically is assigned to one person or entity such as a supervisor, a team lead, or designated team member. Work packages are at the lowest of WBS.

    Structure of organization units provides an important internal view of a business system. In UML, organization units are depicted as packages containing employees, business objects, and other organization units. Organization units are responsible for execution of business-process activities. Organization units abstract individual jobs within a project or organization. In UML an organization unit spans workers, business objects, other organization units, and their relationships. As a basic principle, organization units are located within business systems. Organization units that are located outside business systems are actors. Organization units are depicted as packages.

    Workflow and WBS components located at the lowest level of a hierarchy are referred to a work packages. At this level planning is performed to include work, assignment of resources, development of estimates and measurements, monitoring and control of work. The diagram above provides decomposed web portal from a UML technical view of work packages. Work packages provide sufficient detail to enable activities or tasks identification as well as milestones for creation of a project schedule once scope is defined and consensus achieved with stakeholders.

    Decomposition is used to create both workflows and the WBS. The structure of the work and materials divided into component deliverables at the work package level. Work is divided into deliverables of functional components from the top level of a product or project into low enough detail to monitor and manage work completion including estimates for effort (time) and cost for a work to complete a work package. A key question for functional decomposition is are task well defined and small enough to be effectively and efficiently estimated and managed or doe the work require further decomposition to define scope. This is an iterative and incremental process. Products and projects must be sufficiently decomposed as graphical representation for use in planning, execution, monitoring and controlling, and closure.

    02:45

    Lecture 23 – Workflow and WBS Schedule Integration

    Discussion –

    For this discussion, several related concepts must be defined – Refer to workflow and WBS Schedule integration diagram.

    Schedule – Is an organized list of activities and milestones. Each activity or milestone provides information such as duration, responsibility, start date, and end date. Schedules are presented as a spreadsheet showing how and when a task is to be completed by an assigned resource.

    Task – Activity requiring completion within a specified timeframe. A workflow or WBS show in the diagram lists what tasks are to be performed (workflow) and what components are needed as product or project deliverables.

    Gantt Chart – Graphical display of schedule-related information. A show in the diagram, a Gantt chart shows dates along the top axis bars and beside the bar to completion durations and dates of tasks descriptions listed along the left axis of the Gantt chart to provide a schedule.

    What versus How –

    While the workflow map and WBS represent project scope and deliverables or “What” required to achieve product or project goals, a schedule shows “how” and “when” the work is performed to achieve project goals. The WBS provides no sequencing or dependencies of deliverables, tasks or events, nor does it define “how” or “when” deliverables are completed, whereas workflows and schedules do. The WBS is limited too defining and detailing of project outcome or scope.

    Nouns versus Verbs –

    The WBS is written using nouns and adjectives describing components. Schedules use verbs to name activities or tasks.

    Deliverable versus Task Oriented –

    WBS is oriented toward deliverables. Schedules and workflows are oriented to task and activities. There are no tasks in a WBS; only in a schedule. While a WBS cannot have tasks, schedules and workflow use WBS components for work execution. Work packages provide a framework to define schedule activities such as purchases and layout. Activities creating deliverables inherit the deliverable WBS ID.

    01:53

    Lecture 24 – Linking Workflow and WBS with Costs

    Discussion –

    Refer to “Workflow & WBS Costs” diagram for this lecture.

    How Can Costs Be Linked to Workflow and WBS?

    Workflow and WBS are related to project cost estimation, budgeting, and management. As shown in the diagram, Scope baseline is an input process cost estimating and budgeting. The workflow and WBS dictionaries are components of the scope baseline. Both dictionaries provide input to estimation of project cost and budget creation. Initial cost estimates are rolled up into work packages and during project planning, the WBS is used as an input with estimates refined as new information is available. The budget is then created.

    One use of the WBS is production of cost estimates for the project by assigning individual cost estimates to each work package. Thus, the WBS presents total work scope so this becomes the cost estimates for the entire project. Cost overruns decrease because the cost estimates for entire project scope is the total cost of all deliverables.

    Use of WBS to Create the Project Budget

    One technique for determining the budget is Cost Aggregation consisting of aggregating cost estimates for work packages based on WBS. Work package cost estimates are rolled up to higher levels of WBS by consolidating costs into the budget allowing export to spreadsheets for monitoring and control of project and work package spending.

    05:04

    Lecture 25 – Linking Workflow and WBS with Resources

    Discussion –

    Comparison of WBS and Resource Breakdown Structure (RBS)

    A project RBS is considered similar to a WBS, but and RBS focuses on resources needed for project delivery. A WBS identifies project deliverables structure within groups then is decomposed to a detail level needed to define project scope and controlling project workflows. Once a Workflow or WBS is defined, resources needed to deliver all the work packages must be establish. All resources have associated costs. Thus, identification of resources and quantities required for delivery of project scope establishes a baseline cost for the whole project.

    Project Resources

    A resource is any physical or virtual entity of limited availability consumed to obtain a benefit.

    Three main types of resources must be consider when developing an RBS –

    • People
    • Materials
    • Equipment

    Projects are delivered by people using equipment to perform work by assembling materials into in a tangible (measurable) form as deliverables defined by project scope. Not all resource types above are needed for all projects. IT projects, for example deliver software solutions. Delivery of an IT project primarily involves people developing software by using computers (equipment) with material resources required (such as cloud or virtual).

    People – This type of resource is a person or team of people with defined skills and available time needed to complete delivery of project work within budgeted costs.

    Materials – are physical items consumed to produce and/or assembled or incorporated as tangible deliverables required by the project. Component items consumed may be – steel, concrete, lights, wood, cables, paint, or other required physical entities.

    Equipment (Tools) – Is used to support incorporation of materials constituting tangible deliverables of the project.

    RBS is a means of organizing and structuring resources required for a project in a hierarchical manner represented in tree-diagram structure similar to a WBS. Each resource type (node) has a unique identifier code for assigning quantities and cost rates for each resource type.

    RBS Level of Detail

    Only decompose an RBS to a detail level required to efficiently and effectively control project scope responsibility allowing estimates of resource quantities within the level of accuracy required.

    Link to Project Budget Cost

    Having developed an RBS reflecting the project level being managed, the next step is to assign cost rates for the lowest level resources of each RBS branch; how much will each resource unit resource cost the project? Cost values are obtained from a variety of sources having differing levels of accuracy depending on data source.

    Data Sources may include –

    • Previous similar projects
    • Published industry norms
    • Previous quotations for similar items
    • Budget quotations sought for this project.

    If needed, consult other experience analyst.

    WBS (deliverables) + RBS (resources) = total project direct cost.

    Conclusion

    An RBS, at the project definition stage, is a great tool for structuring project planning around development using human resourcing strategy as well as for outsourcing and procurement strategy.

    Developing an RBS requires considering skills needed to deliver work packages identified by a WBS then drives outsourcing and procurement strategy for the project. This is key to an overall project management execution plan. Assignment of resource requirements to relevant activities within the project schedule enables efficient use of resources to project deliverables cost effectively. Using associated resource costs enables understanding of the cost profile of work packages and the overall project driving commitment and cash flow requirements for the project.

    3 questions

    What are key typed of business scope, work, and deliverables mappings?

    Section 3: Integrating Workflow & WBS Communications, Risks, Acquisitions, HR, & Quality
    01:28

    Section 3 – Integrating Workflow and WBS with Communications, Risks, Acquisitions, Human Resources, and Quality

    Goals:

    • Elicit, Capture, and Collect requirements needed to describe and support scope of each deliverable
    • Create the Business Requirements Document to support Scope and Support for Deliverables
    • Use Structured Analysis to decompose deliverables into required Deliverables, Functions, Rules, Resources, Effort, Costs
    • Communicate with technical team using object-oriented analysis models
    • Communicate with stakeholders using simplified object-oriented analysis models to clarify requirement
    • Identify key relationships and activities for tasks and timing based on risks and issues derived from the project Work-breakdown-structure (WBS)
    03:40

    Lecture 26 – Using Workflow and WBS in Communications

    Discussion –

    Refer to “RACI Matrix” in the diagram for this discussion.

    RACI Matrix – Responsible, Accountable, Consulted, Informed

    The RACI matrix is used to identify roles and responsibilities avoiding confusion about roles and responsibilities during a project. A project manager key role is set expectations of people involved in the project from the outset. Delegation is an essential project manager's role., thus identifying roles and responsibilities early in a project is important. Applying the RACI model supports the project manager role. Without clearly defined roles and responsibilities projects can easily run into trouble. When people know exactly what is expected, completion of work on time, within scope and budget and at the right level of quality is easier. A RACI matrix is used to supports discussion, agreement and communication of project roles and responsibilities.

    Responsible - Person doing work to achieve a task has responsibility for getting work done or decision made. As a rule this is one person who may be business analyst, application developer, technical architect, or other project stakeholder.

    Accountable – Person accountable for correct and thorough completion of a task. This is often a project executive or sponsor. This role is responsible and accountable for approval resources and work.

    Consulted – People providing project related information and with whom there is two-way communication. May be usually several people who are often subject matter experts.

    Informed – People kept informed about project and/or work package progress and with whom there is only one-way communication. People affected by task outcomes and must be kept up-to-date on progress and events related to the project.

    Using WBS for Communications

    WBS is used to communicate project scope or work and changes. WBS is also a reporting tool supporting communication of project progress and status through …

    •Color of Levels, Releases, Progress, Acquistions – use colors to display related information

    •Progress and Status Communication – Identify status of deliverables to manage stakeholders expectations

    •Communications Plan (refer to RACI) – Stakeholder information approach as to format, content, level of detail, reason for distribution, dates and frequency, person(s) responsible for reporting and receiving information, methods or technology used, and other project related information. Also required is identification of stakeholders requiring communication reqarding WBS, WBS Dictionary, Workflow Dictionary, and/or scope baseline, budget, accomplishments, and risks.

    03:00

    Lecture 27 – Using Workflow and WBS in Risk Management …

    Discussion –

    Workflow and WBS Risk Management

    Risk management is identification, assessment, and prioritization of risks Used to coordinate and economically apply resources needed to minimize, monitor, and control probability and/or impact of unexpected events or maximize realization of opportunities.

    Risks derive from various sources – Financial and legal uncertainty, credit and liabilities; project failure threats from design, development, production, or support; accidents or natural disasters; deliberate adversarial attack; or events from uncertain or unpredictable root-causes. Events are classified as one of two types – negative or risks and positive or opportunities. Strategies for managing threats include - avoidance, reduction of negative impact or occurrence probability, transference to another party, and retention of potential or actual consequences with opposite strategies for opportunities (uncertain beneficial future states).

    Workflow and WBS Risk Management Support

    Workflow and WBS are two main sources for identifying product and project risk. By analyzing the scope of work enables discovery of possible threats of failure or prevention of each deliverable thereby discovering potential risks. Two key questions are –

    • What are deployment risks associated with each workflow or WBS deliverable?
    • Are there in-house developed deliverables not part of our core business that can be outsourced?

    Risk identification at the package level provide early warning using a workflow map or WBS for managing risks resulting in better risk response planning. When identifying risks, use the workflow map and WBS as a review checklist to ensure most potential risks and impact are considered. The workflow map and WBS support implementing risk responses such as mitigation, avoidance, acceptance, and transference. A Risk Breakdown Structure (RBS) and Risk Registry based on the workflow map and WBS supports display and highlight of components with potential risks and resource responsibility assignment. The Risk Registry lists important risk related features – Risk, Category, Probability of Occurrence, Impact, Response Strategy, Responsibility (from RACI), Due Date, Status.

    04:26

    Lecture 28 – Using Workflow & WBS in Quality Management …

    Discussion –

    Quality Management overseeing activities and tasks needed to maintain desired level of excellence including creating and implementing quality planning, assurance, quality control, and quality improvement referred to as total quality management (TQM). Quality reporting based on workflow map and WBS provide quality planning, monitoring and control, and closure information to ensure project deliverables to scope meet project requirements for quality. Project Quality Reporting includes – WBS ID, Schedule Task ID, Deliverable Name, Internal Errors, External Errors, Responsibility (based on RACI), Status.

    “Plan-Do-Check-Act (PDCA)” and “Define Measure Analyze Improve Control (DMAIC)” methods shown in the diagrams are presented below –

    Plan-Do-Check-Act (PDCA Cycle) – iterative four-step management method for business control and continuous improvement of workflows and products (also Deming Wheel and Shewhart cycle …

    • Plan (Purpose) – Quality Criteria … Establishes objectives and processes required for delivery of expected target, goals, or results. Establishment of deliverables expectations, ensuring completeness and accuracy of specification supports targeted improvement. Start using small scale to test possible effects.
    • Do (Implementation) – Supporting Implementation … Implement plan, execute process, build the product. Collect data for charting and analysis for "Check" and "Act" steps.
    • Check (Awareness & Evaluation) – Evaluation … Study results measured and collected in "Do" comparing against expected results (targets or goals from "Plan") to determine differences. Search for implementation deviation from plan and observe appropriateness and completeness of plan enabling execution. Charting data makes trends easier to discover over several cycles for conversion of collected data into information. This Information is needed for "Act" step.
    • Act (Feedback Procedure for Change) – Feedback … If "Check" indicates "Plan" implemented in "Do" is an improvement to standard baseline, then this becomes new standard (baseline) for how organization is to "Act" from point forward as new standard baseline. If "Check" shows "Plan" implemented in "Do" is not improvement, then existing standard baseline remains in place. If "Check" shows results other than expected, more learning is needed suggesting another iteration.

    Define, Measure, Analyze, Improve, Control (DMAIC, 6δ)

    The Six Sigma DMAIC basic methodology as shown in the diagram below consists of these steps:

    • Define the process improvement goals that are consistent with customer demands and enterprise strategy
    • Measure the current process and collect relevant data for future comparison.
    • Analyze to verify relationship and causality of factors. Determine what the relationship is, and attempt to ensure that all factors have been considered.
    • Improve or optimize the process based upon the analysis using techniques like Design of Experiments.
    • Control to ensure that any variances are corrected before they result in defects. Set up pilot runs to establish process capability, transition to production and thereafter continuously measure the process and institute control mechanisms.
    04:14

    Lecture 29 – Role of Agile, Waterfall, PMO, and PMBOK …

    Discussion –

    Refer to “PMBOK” and “Agile Development” diagrams for this discussion.

    Project Management (PMO) Supporting Methodologies –

    Waterfall (System Development Life Cycle (SDLC)) – Stages/Phase Gates …

    The waterfall model consists of these 6 phases

    • Requirements Analysis
    • System Design
    • Implementation
    • Testing
    • Deployment
    • Maintenance

    Waterfall (SDLC) is most appropriate for clear, fixed, well documented requirements. Waterfall methodology is a sequential software design and development process in which progress flows steadily downwards as in a waterfall through sequential phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.

    Project Management Templates for Waterfall methodology

    • Project Charter
    • Business Requirements
    • Technical Design
    • Quality Plan
    • Test Plan
    • Project Schedule
    • Risks and Issues Log
    • Progress / Status Report
    • Lessons Learned

    Agile SCRUM

    Agile is a project management method used software development characterized by decomposition of deliverables as iterative incremental short work sprints with frequent reassessment for adaptation of plans. Agile development is a collection of software development methods enabling project requirements and solutions to evolve using collaboration and consensus among self-organizing, cross-functional teams. Age promotes adaptive planning, evolutionary development, early delivery, continuous improvement encouraging rapid and flexible response to change.

    Agile Scrum focuses on

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    Agile Manifesto based on twelve principles

    • Customer satisfaction by rapid delivery of useful software
    • Welcome changing requirements, even late in development
    • Working software is delivered frequently (weeks rather than months)
    • Working software is the principal measure of progress
    • Sustainable development, able to maintain a constant pace
    • Close, daily cooperation between business people and developers
    • Face-to-face conversation is the best form of communication (co-location)
    • Projects are built around motivated individuals, who should be trusted
    • Continuous attention to technical excellence and good design
    • Simplicity—the art of maximizing the amount of work not done — is essential Self-organizing teams
    • Regular adaptation to changing circumstances

    Project Management Body of Knowledge (PMBOK)

    PMBOK identifies the project management body of knowledge generally recognized as a good or best practice. Knowledge and practices described in PMOBK are applicable to most projects most of the time with consensus about value and usefulness. 'Good practice' means general agreement that application of knowledge, skills, tools, and techniques enhances chances for success over many projects.

    1 page

    Exercise 1 (Lecture 30) – Prepare one Workflow Map and one WBS

    Discussion –

    Exercises – Choose an exercise from any or all below or make up your own ...

    • Prepare Workflow and WBS diagrams to make a pot of coffee
    • Prepare Workflow and WBS diagrams to mow the lawn
    • Prepare Workflow and WBS diagrams to make a shopping list then go shopping
    • Prepare to periodically review customer credit accounts
    • Prepare a product bill-of-materials and assembly workflow process
    1 question

    Workflow and WBS are used to manage business

    Section 4: Develop Requirements-based WBS, Workflows, and Deliverables – Conclusion
    01:51

    Lecture 31 – Develop Requirements-based WBS, Workflows, and Deliverables – Conclusion …

    Congratulations!! You’ve made it! …. you’ve completed all Course Goals …

    Course Goals

    • Elicit, Capture, and Collect requirements needed to describe and support scope of each deliverable
    • Create the Business Requirements Document to support Scope and Support for Deliverables
    • Use Structured Analysis to decompose deliverables into required Deliverables, Functions, Rules, Resources, Effort, Costs
    • Communicate with technical team using object-oriented analysis models
    • Communicate with stakeholders using simplified object-oriented analysis models to clarify requirement
    • Identify key relationships and activities for tasks and timing based on risks and issues derived from the project Work-breakdown-structure (WBS)

    Thank you and congratulations for taking this opportunity for yourself to expand your skills and knowledge. Thank you for your decision to complete this course successfully.

    And, please if you find my course useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

    Please remember my promise to you, if your have any questions about any part of this training or any related questions about this course or Udemy please don’t hesitate to ask using Udemy’s Instructor Messaging service to contact me.

    Thank You and Best Regards, Chuck Morrison, MBA, PMP

    http://www.linkedin.com/in/chuckmorrison

    http://www.chuckmorrison.com

    11 pages

    Lecture 32 – Glossary …

    For definitions of terms used in this course, please see downloadable Glossary

    2 pages

    Lecture 33 – For Further Reading …

    OO UML developed by “The 3 Amigos” Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software during 1994–95 with further development led by them through 1996. … Rational Software transferred to IBM … OO UML accepted by OMG & ISO

    References:

    A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition, Project Management Institute, 2008

    A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), 2ed, International Institute of Business Analysis, 2009

    A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition, Project Management Institute, 2008

    Advanced Use Case Modeling: Software Systems (v. 1), Frank Amour, Addison Wesley, 2001

    Getting It Right: Business Requirement Analysis Tools and Techniques, Kathleen B. Hass, Management Concepts, 2007

    Mastering the Requirements Process (2nd Edition), Suzanne Robertson, et al, Addison-Wesley, 2006

    Object-Oriented Analysis and Design with Applications (3rd Edition), Grady Booch, Addison-Wesley, 2007

    Patterns for Effective Use Cases (The Agile Software Development Series), Alistair Cockburn, et al, Addison-Wesley, 2002

    Practice Standard for Work Breakdown Structures, 2ed, Project Management Institute, 2006

    Professionalizing Business Analysis: Breaking the Cycle of Challenged Projects, Kathleen B. Hass, Management Concepts, 2007

    Seven Steps to Mastering Business Analysis, Barbara A. Carkenord, J. Ross Publishing, 2008

    The Art and Power of Facilitation: Running Powerful Meetings, Kathleen Hass, Management Concepts, 2007

    The Business Analyst as Strategist: Translating Business Strategies into Valuable Solutions, Kathleen Hass, Management Concepts, 2007

    The Elements of UML(TM) 2.0 Style, Scott Ambler, Cambridge University Press, 2005

    The Unified Software Development Process, Ivar Jacobson, et al, Addison-Wesley, 1999

    The Unified Modeling Language Reference Manual (2nd Edition) (The Addison-Wesley Object Technology Series), James Rumbaugh, et al, Addison-Wesley, 2004

    Unified Modeling Language User Guide, The (2nd Edition), Grady Booch, et al, Addison-Wesley, 2005

    UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition), Martin Fowler, Addison-Wesley, 2003

    UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd Edition), Jim Arlow, et al, Addison-Wesley, 2005

    Unearthing Business Requirements: Elicitation Tools and Techniques, Kathleen Hass, Management Concepts, 2007

    What Not How: The Business Rules Approach to Application Development, C. J. Date, Addison-Wesley Professional, 2000

    Writing Effective Use Cases, Alistair Cockburn, Addison-Wesley, 2000

    Students Who Viewed This Course Also Viewed

    • Loading
    • Loading
    • Loading

    Instructor Biography

    Chuck Morrison, Program/Project Manager & Business/IT Architect (MBA, PMP)

    “A working model using mission-driven measures in a team approach enables focus on profitable customer-driven solutions."

    With extensive Program Management and Business Architecture experience in Silicon Valley California it's been my good fortune and opportunity to experience working with many Fortune 500 companies. Workflow modeling is my expertise, joy and passion. As a seasoned professional my enjoyment is using and sharing the skills and knowledge with others through teaching and writing. Chuck has also authored and published other Udemy courses, Amazon eBooks, Linked SlideShare, and YouTube videos.

    PMI PMP certified: Principal Strategist, Architect, and Leader with MBA and extensive experience in business and technology consulting, planning, designing, mentoring, negotiating, and delivering project, product, program, and process solutions. Successful track record planning, managing, and leading small to multi-site, concurrent, complex cross-functional projects and portfolios requiring business process engineering, Internet and information technology, quality management, instrumentation, and training.

    Specialties: -Programs/Projects Management (PMI PMP): Program, Product, Project, and Process (SDLC, Agile, PMBOK, DMAIC, RUP, ITIL, InfoSec, NetSec, CISSP)-Business/Technical Process/Systems Modeling, Analysis, and Design (UML, OOA/D, BRD, MRD, FRD, HLD, ERD)-Web Portal Planning, Design, Documentation, and QA (Web 2.0, HTML, TCP/IP, HTTP, B2B, B2C)-Client/Team-Focused Consultant, Mentor, and Communicator-Inventory/Supply Chain Modeling/Management (APICS CPIM)

    Thank You and Best Regards,
    Chuck Morrison, MBA, PMP, CPIM, WWISA

    Ready to start learning?
    Take This Course