content 5 and 6.docx

We've just heard that these are the things that we need to do. about all the type of work that has to be done in a Digitalization Project. We've also heard that this work is split into classic phases, such as "Requirements Analysis", "System Design" and "Deployment". This begs the next question:...

We've just heard that these are the things that we need to do. about all the type of work that has to be done in a Digitalization Project. We've also heard that this work is split into classic phases, such as "Requirements Analysis", "System Design" and "Deployment". This begs the next question: The answer to this question -- like to so many others -- is: "It depends." You may be surprised to learn that there are [three very different philosophies] that project managers apply when planning a digitalization -- or any other -- project. They're referred to as "**Waterfall Project Management**", "**Agile Project Management**", and "**Hybrid Project Management**". The "agile" approach to Project Management is most common in IT projects. It was developed in the software industry in the 1990s. Nonetheless, there are aspects of Digitalization Projects that can benefit from other approaches, as well: So we'll look at all three\... Waterfall Project Management is the traditional approach to Project Management. It is called the "waterfall" approach because is follows a [linear approach] through a project that is based on an **Initiation** phase, a **Planning** phase, an **Executing and Controlling** phase and a **Closing** phase. Like a waterfall, the project [flows top-down through these phases]. Each phase is dependent on the completion of the previous one, and - at least in theory - there are no jumps back upwards. One of the hallmark features of the waterfall approach is its emphasis on [comprehensive planning at the beginning] of the project, with a view to [minimizing changes] once development begins. Typical projects that are usually carried out with a waterfall framework are construction projects, manufacturing projects, infrastructure projects, and research and development projects, to name a few.\ In each case, the bulk of the planning must be carried out at the beginning of the project rather than\ incrementally. **Waterfall Project Management works excellently in projects [where the project\'s requirements are well understood from the beginning and unlikely to change significantly].** As stated earlier, traditional waterfall project management works excellently for projects where customer requirements are very clear from the beginning. It is less suited for projects where there are large question marks concerning customer (i.e. "**end user**") requirements at the beginning of a project. - This is because in waterfall project management, each phase is "**siloed**" (i.e. the work of each phase is completed as a "block" that is -- to a large extent - separate from the other phases). - Also, in waterfall project management end users provide significant input (concerning their requirements) at the [beginning] of the project. They also give feedback about how happy they are with the project results at the [end] of the project.\ But in-between (i.e. during the planning, executing, and controlling phases), [there is little room for end users to request new features and/or adjustments], as Project Execution only takes place AFTER Project Planning has been fully completed. At the beginning of most digitalization projects, there are a **[particularly]** high number of question marks\ (i.e. uncertainties) concerning end user requirements. The general direction of what end users need from an\ Information System may be clear, [but their specific needs in terms of e.g. functionality, features, and compatibility often don't evolve until they've had a chance to interact and experiment with a basic version of the new system]. **In Digitalization Projects, End User needs tend to become [clearer and clearer] as\ they have a chance to experiment with early versions of new technologies.** Because of this tendency in digitalization projects, a traditional waterfall project management sometimes bypasses the needs of the end users. This is the reason that the philosophy of **Agile Project Management** was first developed. Rather than combining ALL the planning into one phase and then combining ALL the execution of those plans into follow-up phase, Agile Project Management jumps back-and-forth between "planning" and "executing". It does this in **iterations**. This iterative approach [gives end users far more possibilities to make requests **throughout the** ] **[project]** (i.e. before each new iteration), without forcing project managers to disrupt the logical flow of their work. Let's learn more\... **PRODUCT OWNER:** The **Product Owner** is the [individual (or business)\ that is responsible for defining and prioritizing the features, functionalities, and overall vision] of the product (e.g. a new Information System) that an Agile Project is trying\ to create. A **User Story** is a short [description of the features and functionalities an end user wants] from a product (e.g. \"*As a registered user, I want to be able to reset my password so that I can regain access to my account if I forget my password.*") A **Product Backlog** is a [prioritized list of tasks, features, or user stories that need to be completed] or implemented in a project. It serves as a "To Do" list of work yet to be done in a project. The Backlog is continuously populated and refined throughout the project\'s lifecycle [in order to reflect new or modified user requests]. The **Scrum Master** in an Agile Project shares similarities with a Project Lead\ in a classic Waterfall Project, just as a **Scrum Team** shares similarities with a traditional Project Team. The Scrum Master interacts with both the Product Owner and the Scrum Team. Their main function is to [guide the Team towards successful project completion]. A **Sprint** is the name given to each iteration of an Agile Project. During each Sprint, the Scrum Team [identifies tasks to be completed (i.e. on the basis of the Backlog) and then works through these]. A Sprint is typically planned for a **Timebox** of [one to four weeks]. There's no specific number of sprints that must be completed per project. The final number depends entirely on the individual project's situation and development. A **Release** refers to a specific version of a product (e.g. software, network) that is made available to users. Very often, a Release is not a "final version", but rather the result of a specific Sprint. This Release is then **demoed**\ (i.e. "tried out") by end users. Their feedback serves as input with which to update the Product Backlog. Most project experts would agree that: **(a)** Classic Waterfall Project Management works particularly well with projects that have well-defined and stable requirements from the beginning; while **(b)** Agile Project Management works excellently with projects that that have evolving or unclear requirements (and/or fast-changing environments). But what about projects that have [elements of both]? A Hybrid Project Management approach may be your best option. Hybrid Project Management acknowledges that [not all projects fit neatly into either the structured, sequential nature ] [of waterfall or the dynamic, iterative style of Agile]. Instead, it seeks to find a balance between predictability and flexibility. Now that we've heard about three approaches (i.e. "**methodologies**") that you can choose from when optimizing your Enterprise Information System, let's see what a seasoned digital expert has to say on the digitalization projects\... **Hybrid Project Management** is a flexible project management approach that [combines elements\ of both traditional Waterfall and Agile approaches to suit the specific needs of a project]. Even under the best of circumstances, a Digitalization Project -- let alone a Digital Transformation Project -- is a monumental challenge for most organizations. This is true for an organization with a single location, and it's even more true for an international Group of companies with subsidiaries and branch offices spread over the globe. **[Good planning and preparation are a must]**. Even so, it's a good idea to keep the **[anticipate in advance]** **(1)** [how] and **(2)** **to what extent** the following problems may surface in your own Digitalization Project. After you've redesigned your business processes for the future, you are finally in a position to answer the question that's been on our mind [since Chapter 1]! To put it more specifically: - What data elements will your new EIS need to function optimally? - What will your software need to be able your new EIS need to function optimally? - What will your hardware need to be able to do your new EIS need to function optimally? - What types of job skills your new EIS need to function optimally? - What rules and protocols will your new EIS need to function optimally? Answering these questions is the main goal of a **Requirements Analysis**. Based on your strategy (e.g. mission, values, business model, strategic goals) and on your optimized business processes, you now derive what your new Enterprise Information System needs to "deliver" in order to fulfill your strategy (and optimally support your new business processes). This includes identifying - [functional requirements] (i.e. what the new system must [do]); and - [non-functional requirements] (i.e. [qualities] the new system must possess,\ such as performance speed, security, usability, and scalability). - Once you've identified what your new system needs to be able to do (i.e. Requirements Analysis), the next step is to identify and evaluate the current solutions that the market offers. - **Evaluating Systems Alternatives** involves questions such as: - How and where can we obtain each type of data that our new EIS will need in an ethical and data privacy laws-compliant manner? - What storage solutions (e.g. database solutions, cloud solutions) currently exist that could optimally store the data? - What software currently exists on the market that could fulfill our new EIS' requirements? - To what extent can existing software be customized to our EIS' precise needs? - To what extent can programmers code [new] (or supplementary) software that will fulfill our new EIS' requirements? - What hardware currently exists on the market that could fulfill our new EIS' requirements? - Considering all the above elements ("data", "software", "hardware"): how do each of the potential options integrate with each other? - How could we train existing employees so that they acquire the new job skills our future EIS requires? - How and where can we find new employees that possess the new job skills our future EIS requires? - How and where can we find external suppliers (e.g. companies) that possess the new job skills our future EIS requires? The following section is about business process modelling (BPMN). A **Business Process** a sequence of connected activities that are carried out to achieve a specific outcome. **Two primers about business processes:** - There is **no automatic, 'predetermined' point at which a business process begins or ends**. Every organization decides for itself. There may be "common sense" beginning/end points, but the final decision should be **based on what is useful to your organization**. - *In our tea example, we could just as easily have started [earlier] (e.g. someone realizes they're thirsty, THEN decides it is TEA\ that will quench their thirst!) and ended [later] (e.g. waiting until the tea has cooled down for five more minutes).* - There is also **no "must have" level of detail** in the description of a business process. How detailed a business process description should be depends -- again -- entirely on your purposes. Typically, processes that are **highly standardized and/or automated** (e.g. payment authorization process) are mapped out in **high detail**, while processes that are subject to\ **lots of unstandardized external influences** (or for which an organization wants to give employees\ more **decision discretion**) are mapped out in **less detail** (e.g. social media marketing, recruiting). - *In our tea example, we never specified which type of tea is to be brewed (e.g. black, green).* - In fact, **[the only reason an Enterprise Information System exists is to support your business processes]**. - Plain and simple: If you didn't have business processes, you wouldn't need an EIS. - For this reason, any optimization of your EIS needs to begin with an analytic look at - **(a)** what business processes your organization carries out and - **(b)** what sequence of activities the major processes follow. - Once you've done [that], you may want to **redesign** (i.e. optimize) some of these processes. - When describing business processes, you want to be precise as possible. This means that you and everyone involved have to agree - on certain rules for how to describe a business process. You may decide to use standardized symbols to - visually symbolize certain elements of a business process. Luckily, you don't need to reinvent the wheel. - You have several internationally tried-and-tested **Business Process Modelling Languages** to choose from. - The term we used on the previous slide -- "Business Process Modelling Languages" -- may sound a bit daunting. - It needn't. When we refer to **Business Process Modelling**, we're basically talking about what we did on our first slide with - the tea preparation example. That's a business process model. - When we created our "tea preparation" business model, we simply listed the steps in bullet form. And when two things were to occur simultaneously, we prefaced the parallel activity with the phrase "[At the same time], ". And when there was an either/or situation, we specified that with the phrases "If 'yes'," and "If 'no'," - On a very rudimentary level, this gets the job done. But luckily, there are - far better methods of modelling a process: the internationally well-established - Business Process Modelling Languages thatwe mentioned earlier. - This course will go into more detail on the the most widely used business process - modeling language in the world, **Business Process Model and Notation** (**BPMN**). - But before doing this, let's have a brief look at all the major business process - modelling languages that are out there. **Modelling** is the process of [creating simplified representations of complex systems] to help us understand, analyze, and communicate them effectively. **Business Process Modelling** (**BPM**) creates [visual representations of workflows that take place in organizations]. BPMN 2.0 consists of four basic elements: - Element 1: **ACTORS** (Pools or Lanes); - Element 2: **FLOW OBJECTS** (Events, Activities, and Gateways); - Element 3: **CONNECTING OBJECTS** (Sequence Flow, Message Flow, and Association); - Element 4: **ARTIFACTS** (Data Objects, Groups, and Annotations); Flow objects show the STEPS of a business process. Typical BPMN flow objects include: - Events; - Activities; and - Gateways; **BPMN Element 3: CONNECTING OBJECTS** Connecting objects connect the flow objects we just looked at. Typical BPMN connecting objects include: - Sequence Flow; - Message Flow; and - Association; **BPMN Element 4: ARTIFACTS** Artifacts are used to provide additional information to the Reader about (a part of) a business process. Typical BPMN artifacts include: - Data Objects; - Groups; and - Annotations; An **Event** represents [something that occurs during the execution of a business process]. It can be **(a)** an [occurrence] (e.g. a customer calls the sales department) or\ **(b)** a [significant point in time] (e.g. a deadline has been reached) that affects the further flow of the process. - Events are categorized into three main types: **start events**, **intermediate events**, and **end events**. They are represented by a [circle], and may contain additional symbols to provide more detailed information about the event. - **[Examples:]** Customer Inquiry Event, [ ] Payment Received Event, Inventory Shortage Event, Application Received Event, Customer Registration Event, An **Activity** represents [a unit of work (i.e. a "To Do") that needs to be completed\ (e.g. by an employee, by a team, by a computer) in context of a business process]. - Activities are categorized into three main types: **tasks** (i.e. simplest, most basic activities), **sub-processes** (i.e. activities that include multiple tasks), or **call activities** (i.e. an activities that "calls" for another entire process to be carried out). - Activities are represented as [rounded-corner rectangles]. - **[Examples:]** Procure Raw Materials, Assemble Components, Interview Job Candidate, Validate Data, Generate Report, Create Social Media Post, Conduct A **Gateway** represents [a decision point in a process]. Depending on a criterion\ (e.g. a decision, a value), the path that is followed along the process may differ.\ *In our tea process, we check whether there are tea bags in the kitchen. If not, we must go to the supermarket and buy them. This is an example of a gateway.* - **[Examples:]** "Is the customer a new or existing one?" ,"Is the raw material available in sufficient quantity?" ,"Has the quality inspection passed for the finished product?",\ "Is the item in stock or out of stock?", "Has the customer provided all necessary documentation?", "Will we hire the job candidate or not?" , "Has the customer reached the maximum number of login attempts?" ,"Has the project been Gateways are represented by diamonds. The three main gateways are: **Exclusive Gateway (XOR):** depending on the answer to the gateway question\ (e.g. "Hire the job candidate?" ), [only one] of several follow-up paths can be taken. **Inclusive Gateway (OR):** depending on a decision (e.g. by a manager) regarding a task (e.g. "Send information to prospect" ), [one or more] of several follow-up paths can be taken (e.g. "send by email", "send by snail mail", "send by SMS"). **Parallel Gateway (AND):** this type of gateway also often isn't prompted by a question. Instead, it indicates that [all] follow-up paths must be taken in parallel\ (e.g. "write advertising copy", "photograph product", "book advertising space"). A **Sequence Flow** specifies [the order in which Flow Objects (e.g. Events, Activities, Gateways) occur within a business process]. A Sequence Flow is represented by a [straight line ending in an arrow].\ The arrow indicates the direction of the process flow. **[Example:]** A process consists of the following Flow Objects:\ **(1)** Start Event "I am hungry", **(2)** Activity "Go to refrigerator",\ **(3)** Activity " Take carrot", **(4)** Activity "Eat carrot" and **(5)** End Event "I am full". [These Flow Objects would be connected (in proper order) by four Sequence Flows]. A **Message Flow** indicates that [information is exchanged between different entities] (e.g. employees, departments, organizations, computers) within a business process. Message Flows are typically used in combination with a Message Event\ (i.e. a circle with an envelope). They are also often used in combination with\ the [exchange of physical objects]. A Message Flow is represented by a [dashed line that begins with a small open circle (sender's side) and ends in an open arrow (receiver's side)]. **[Examples:]** **(a)** A customer submits an order online; **(b)** A supplier sends an invoice to a customer; **(c)** An employee submits a leave request; **(d)** A customer service representative receives a complaint from a customer; An **Association** shows [how data, documents, or other artifacts are related to activities and events]. The extent to which you visualize associations should always consider [how useful the information is] to the proper execution of the process. An Association is represented by a [dotted line (without any circle or arrow!)]. **[Examples:]** **(a)** the task "Hold Meeting" is associated with various documents that will play a role in the meeting. (*It could [also] be associated with the room in which the meeting will take place*); **(b)** the task "Review Candidate CVs" is associated with the CV documents the Reviewer must look through; **(c)** the task "Procure\ Raw Materials" is associated with a Bill of Materials; **(d)** the task "Deliver goods" is associated with the customer's address and contact A **Pool** is the "[container]" that specifies all the events and activities that take place within a [single entity (e.g. your organization, your customer, a supplier, etc.)].\ The Reader sees which process elements take place directly in your organization and which take place elsewhere (e.g. by your customer, by your supplier). A pool is represented by [a rectangle that covers the entire width of the model].\ It is labeled with the name of the entity (e.g. "organization", "customer", "supplier"). A BPMN model includes at least one pool, but it may have several. Pools are either **Expanded Pools** (i.e. the Reader can see what is going on within the pool) or **Collapsed Pools** (i.e. the Reader can't see what is going on within the pool). An Expanded Pool is typically split up into several **Swim Lanes**. A Swim Lane represents the [main parties] of a pool that are involved in a process. These are often [departments]. However, they can also consist of smaller groups\ (e.g. a [project team]) or even [individual employee roles] and information systems. Swimlanes are represented visually by dividing a pool with a [horizontal line]. A **Data Object** represents [any form of data that is **(a)** required as an **input** for an activity] (i.e. the activity cannot be carried out correctly without this data or[\ **(b)** generated as **output** by the activity] (i.e. the activity creates this "new data"). Data Objects are represented as [pages with a folded corner]. A Data Object is connected to an Activity through an Association ("Data Association"). Unlike other Associations, Data Associations look very similar to Message Flows (i.e. with an opening circle and an arrow). **[Examples:]** "Customer Information", "Order Form", "Invoice", "Inventory Database", "CV", "Employee Records", "Product Catalog", "Sales Report", "Meeting Notes" A **Group** is used in a business process to show that a sub-set of events, activities, and/or gateways is very closely connected. Groups can extend over several swimlanes and even pools. They are represented by a [rectangle lined with dashes and dots]. This rectangle surrounts all the events, activities, gateways, etc. that are part of the group. **[Example:]** As part of a larger process called "Project Initiation", the following activities take place: **(a)** Project Manager prepares a Project Concept;\ **(b)** Project Sponsor reviews and approves Concept; and **(c)**, Project Manager presents approved Concept to external Project Customer. [To visually indicate that\ these three activities are very closely linked] An **Annotation** is simply a bit of extra information that the business process modeler wants to provide the Reader with about an event, activity, gateway or other element of a process. An Annotation is represented by [a bracket and the information text itself].\ It is connected to e.g. an activity or event by an Association. **[Examples:]** "Supplier is often late", "Notify supervisor for approval",\ "Read Corporate Design Guidelines to see the format required", "Rank candidate's communication skills from 1-10", "Bring at least ten business cards", etc. \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- 6ch: Regardless of whether you run your Digitalization Project on basis of a waterfall, agile, or hybrid methodology, there will be [phases in which your plans are carried out] (i.e. Project Execution). If you've planned prudently, many things will go right during Project Execution.\ But there are also [many things that might go wrong]. For this reason, successful Project Execution requires you to [measure the progress of your project] and [identify potential hazards] early enough to neutralize them. While this is true of any project, Digitalization Projects have a few unique factors that you should be aware of. We'll walk through these on the next slides, beginning with **(a)** developments you should monitor, and continuing with **(b)** KPIs that are often tracked in Digitalization Project. These are developments you should track in a digitalization project: Document updates: All projects produce documentation, but there are few\ project types where documentation requirements are\ as extensive and as critical as in a Digitalization Project. For this reason, make sure to [monitor the maintenance and updating of all technical documentation] to ensure accuracy and relevance. System performance: [Continuously monitor system performance and responsiveness] to identify and address any necessary improvements. Communication and collaboration: In spite of the prevalence of technical work areas\ in a Digitalization Project, don't forget to [measure\ the effectiveness of communication and collaboration among team members, stakeholders,\ and departments]. Data integrity and security: Ensure ongoing data integrity and security by [\ monitoring access controls and vulnerabilities]. Technical debt: In a Digitalization Project, **Technical Debt** refers to the [accumulated software development work that needs to be done in the future because of taking shortcuts or neglecting best practices] during Development. *Imagine you want to build a house, and you have a limited budget and time. To save costs and finish the project quickly, you decide to use lower quality materials and skip some important steps, like proper foundation work or insulation. Initially, you may have a house that meets your basic needs, but over time, you\'ll start experiencing issues like leaks, poor energy efficiency, and structural problems. Fixing these issues will require more time, effort, and money than if you had done it properly from the start. This is similar to technical debt in software development* [Monitor the accumulation of technical debt in your Digitalization Project] and address it proactively to prevent long-term issues. Code quality: Software code is not automatically high quality.\ For this reason, it is important to [track code quality\ metrics] [and code review feedback], in order to catch\ any code-related issues. User feedback: [Gather ongoing feedback from end users and other\ stakeholders] to gauge satisfaction, identify issues,\ and make improvements. Quality assurance: Monitor the [outcomes of testing efforts] to ensure\ that the digital solution meets both **(a)** functionality standards and **(b)** quality standards. Scope change: Take careful note of all [changes to the project scope]\ (i.e. [the total quantity and or/quality of output that\ is demanded from a project]) and and their impact on timelines, resources, and objectives. Task progress and completeion: Ongoingly monitor the [completion status] of tasks,\ user stories, or features, which indicates whether work is progressing as planned. -