Osnova sekce

    • eu_en

      Project Increasing the quality of education at Charles University and its relevance to the needs of the labor market, CZ.02.2.69/0.0/16_015/0002362  

      Content is subject to Creative Commons BY-SA 4.0 International.

      cc


    • Logo kurzu

      Zdroj: "Project Management Plan" by perhapstoopink is licensed under CC BY 2.0
  • The aim of this module is to make you familiar with some basic terminology that you are going to need throughout the whole course. You will find out what are the definitions and meanings in the framework of project management methodologies. This will help you understand better the recommended literature and other materials, that will be used within the course.

    • Project

      Eventhough project have been completed by humans for hundereds and even thousands of years, the exact word is quite a recent piece of terminology that relates mainly to the birth of modern project management in 60s of the last century. You will learn more about the recent history of project management in the section xxx. However, these days we may see projects all around us. Very often this word is used in a inappropriate way - being confused with processes, operations, innovations or planning in general. All these terms are however in close relationship to "projects" and in a way they also overlap. Lets have a look at it more closely:

      Project definition

      Project is a unique and temporary endeavour, that has a specific goal, allocated resources and definied timeframe. Temporary means that project has a definite beginning and an end. Unique  means that the final product or services is different from other products and services in a particular organisation that are created on a regular basis (see Processes below).

      Specification, resources and time are the three factors that are often visualized together as a "project triangle". 

      Project triangle - an isosceles triangle with "Specification", "Time" and "Resources"

      Please note, that "Resources" may be not only human resources, but also financial, material or any other resources that are needed for a successful completion of a project.

      Projects that are more complex may be divided to subprojects that all together contribute to a successful completion of the overall project goal. Similarly, projects may be grouped together to create large programmes with extensive and diverse programme goals. In any case, the structure in which project is organised has to enable a succesful completion of the definied goals within a logical and comprehensible framework.

    • Processes

      Projects are not to be confused with organisation processes. By processes we understand ongoing and repetitive operations of an organisation that lead to products and services that are commonly provided by the organisation as means of fulfillement of its vision. 

    • What is project management?

      According to APM, "project management is the application of processes, methods, skills, knowledge and experience to achieve specific project objectives according to the project acceptance criteria within agreed parameters. Project management has final deliverables that are constrained to a finite timescale and budget.

      A key factor that distinguishes project management from just 'management' is that it has this final deliverable and a finite timespan, unlike management which is an ongoing process. Because of this a project professional needs a wide range of skills; often technical skills, and certainly people management skills and good business awareness." (Source: https://www.apm.org.uk/resources/what-is-project-management/

      Project management evolution

      Modern project management methodologies may be traced back to the 60s of the 20th century, when two major lines of innovations evoked a need for complex project management approach. The two major innovative streams were:

      1. the first complex projects in information technology

      2. the space conquest (reaching the orbit, sending a man to the space, moon landing) etc. in the midst of a cold-war between the two political bloks of that time period

      These two types of projects were by far too complex to just rely on the major (and indisputadly up to today the crutial) tool of any project manager - common sense. More tools and methods were urgently need to achieve those  challenging goals.  Still today, we may see many of the approaches that were orginally developed by NASA, Department of Defence or pioneer IT companies to be frequently and commonly used by project managers across different industries and specialisations.

      Project management approaches

      There are two major distinct approaches to project management:

      1. waterfall approach

      2. agile approach

      Waterfall project management approach

      In waterfall approach, there is a pre-defined sequence of steps and stages followed in the process of project completion. With some small overlap, each stage starts after the prior one is completed.

      The typical stages of waterfall project management are: 

      • Requirements: This is the stage in which the manager analyzes and gathers all the requirements and documentation for the project.
      • System design: During this phase, the manager designs the workflow model for the project.
      • Implementation: The system is put into practice in this phase; this is the stage where things get built.
      • Testing: During this phase, each element is tested to ensure they work as expected and fulfill the necessary requirements.
      • Deployment (in the case of a service) or delivery (in the case of a product): The service or product is officially launched in this phase.
      • Maintenance: In this final, ongoing stage, the team performs upkeep and maintenance on the resulting product or service. (Source: https://www.wrike.com/project-management-guide/faq/what-is-waterfall-project-management/)

      Agile approach to project management

      APM defines agile approach as "Agile project management is an iterative approach to delivering a project throughout its life cycle.

      Iterative or agile life cycles are composed of several iterations or incremental steps towards the completion of a project. Iterative approaches are frequently used in software development projects to promote velocity and adaptability since the benefit of iteration is that you can adjust as you go along rather than following a linear path. One of the aims of an agile or iterative approach is to release benefits throughout the process rather than only at the end. At the core, agile projects should exhibit central values and behaviours of trust, flexibility, empowerment and collaboration." (Source: https://www.apm.org.uk/resources/find-a-resource/agile-project-management/

      Whereas agile project management are gaining a lot of attention recently, the waterfall project management approach keeps being a valid and powerful tool to be used in certain types of projects, environments and circumstances. Certainly, a good knowledge of the classical waterfall approach is helpful to understand concept of project life-cycle and grasp the overall project complexity. In the following modules, we will concentrate primarily on the waterfall approach. However, one specific module will be devoted to SCRUM as a typical example of agile project management approach.

    • Organisational structures

      Projects are integral part of the process of inovation and improvement in organisations with various management structures (process, agile, matrix etc.). 

      Implementing project management methodologies may lead to a change from a classical functional organisational structure (with stricktly defined line management hierarchy and related division of power, reponsibility and communication flow) to a matrix structure. In matrix structure, project management teams are created on a horizontal axis - crossing boarders of line management divisions on the vertical axis. In this way, more empowerment is given to project team members as representatives of the vertical lines and thus more flexibility in communication, negotiating, problem solving and decision making is achieved.

    • TEST: Try to define in your words the interelatedness between projects and processes.

    • TEST: Try to define when and under which circumstances may be a project declared as succesful.

    • Project life-cycle

      Project life-cycle defines a phase sequence of a project. For each phase, the project life-cycle should define: 

      - what technical work should be completed

      - who should be involved in each phase

      - what inputs are needed

      - how outputs should look like etc.

      Deliverables from the preceeding phase should be usually approved before the next phase is started, however, in real life situations the phases have a tendency to overlap.  

      Project life-cycle should be always distinguished from product life-cycle!

    • Project life-cycle (PMBoK, 2000)

      Project life-cycle (PMBoK, 2000)

  • The aim of this module is to make you familiar with major project management methodologies that are recognized as global standards in the field of project management. In the end of the module, you will be familiar with PMBoK, PRINCE2, IPMA and their specific approaches to project management in general as well as certification of professional project managers in detail. 

    • What are project management methodologies?

      Project life cycle descriptions may very in the level of detail - some with highly detailed descriptions, added charts, forms and checklists, others may just provide elementary structures and consistency. HIghly detailed approaches are often called "project management methodologies" (PMBoK, 2000).

      Major, worldwide project management methodologies are:

      - Project Management Body of Knowledge (PMBoK) by PMI (Project Management Institute: https://www.pmi.org/)

      - Prince2 by PeopleCert (https://www.peoplecert.org/)

      - IPMA by International Project Management Organisation (https://www.ipma.world/individuals/certification/)

      All of these methodologies are global, provide complex certification and accreditation services for both waterfall and agile approach to managing projects. They are all recognised as de facto standards in the field of project management.

    • * This courses is based primarily on the approach of PMBoK. However, other methodologies and methods are introduced each time, the lecturer finds it useful and necessary.

    • TEST: Find out under which conditions may project managers get certified in each of the methodologies listed above. 

    • TEST: What kind of arguments would you take into consideration when choosing the right project management methodology for your organisation?

    • The PMBoK approach

      In order to express the interactive nature of project management, the PMBoK describes project management as processes and their interactions. "Processes are series of actions bringing about a result and may generally fall into one of major categories:

      1. Project management processes - describe, organize and complete the work on the project. These processes are applicable across disciplines in a variety of projects.

      2. Product oriented processes - specify and create project´s product. These processes vary by application area.

      Project oriented processes are in PMBoK organized into 5 process groups:

      • initiating processes - authorisation of project/phase
      • planning processes - definition of project´s goals, objectives and deliverables
      • executing processes - coordinating people and other necessary resources
      • controlling processes - monitoring and mesuring of project´s process, identification of variances, taking corrective measures
      • closing processes - finalisation and acceptance

    • Process groups - PMBoK

    • Across the project phases, the following management project knowledge areas are applied:

      1. project integration management
      2. project scope management
      3. project time management
      4. project cost management
      5. project quality management
      6. project human resources management
      7. project communication management
      8. project risk management
      9. project procurement management

    • PMBoK: Project management processes and knowledge areas

    • In this module you will find out:

      • What are the outcomes of the initiation phase
      • Impulses for project creation - where do they get generated?
      • Who proposes, who decides?
      • Basic documentation: Business Case and RFI (followed by RFP)
      • The importance of the initiation phase

      The aim of the initiation phase

      The aim of the initiation phase is to decide, which project incentives will be further developped and proceeded into the planning phase and what will be the essential "modus operandi" that will be used for implementation.

      Project incentives - sources

      In the real world, there is a constant process of generating incentives for the implementation of new projects. Their goal is to innovate existing products, services or processes so that the organization maintains and strengthens its position in the market. Incentives to implement new projects can therefore come from many sides, both externally and internally.


      Internal sources:
      - top management - in connection with new visions and strategic goals of the organization
      - intermediate level of management - in an effort to streamline existing processes / services / products
      - ordinary employees who are most thoroughly acquainted with specific problems of practice
      - HR employees - in an effort to strengthen the position of the organization as an attractive employer in the labor market
      - finance department - in an effort to reduce costs and increase profits

      - quality control department,

      - customer relationship management department,
      ...

      External sources:
      - customers - feedback on provided services / products (complaints, awards)
      - outputs of scientific research and technological development
      - results of surveys and inquiries
      - recommendations of consulting companies
      - competition - in an effort to keep up or outperform the range of services / products
      - state authorities incl. new legislative regulations, norms, standards
      ...

      As you can see, the number of those, who may come up with an idea for a new project is very large. However, not all ideas may be taken all the way to the realisation. Therefore, a complex evaluation of all incentives must be completed by the appropriate level of management and all proposals must be evaluated in respect of their compliance with strategic goals and visions of the organisation as well as available sources (incl. time and finances). This decision making process requires a reasonable amount of data, that has to be gathered as a knowledge base for a well-considered decision.

      The following information set is usually required by bodies that are responsible for the final "go/no-go decision" on the side of the investing organisation:

       

      - the reason for the initiative for change
      - potential benefits (quantitative and qualitative)
      - potential associated risks
      - financial indicators (general budget, TCO, ROI, cash flow, financing methods, etc.)
      - key resources (incl. human)
      - general timetable
      - assumptions

      - links (other projects, surroundings of the organization, etc.)

      - "modus operandi". In IT projects eg. in-house, investor as a system integrator, external company as a system integrator, SaaS.

      ...

      Often, all of the data is summarized in a document that is called "business case". 

      Go and now ???

      If the decision of the appropriate responsible body is "go" and an external company is to be the main supplier of the particular process, a document called "Request for Information" may be completed.

      Request for Information

      When looking for external suppliers, you need to get an overview of the situation on the market. Based on the outcomes of your initial research you may distribute the so called (RFI) to the potential suppliers. The aim of the RFI is to get a better understanding of the products/solutions/services offered by those companies in a non-binding way. In the RFI, the investors usually provide basic information about the type of solutions they are looking for without any further detail. 

      The response is usually a very brief, marketing-like description of the product/service/solution. This description is usually not adjusted to the particular needs of the investor. Often, a presentation or reference visit is proposed to the investor.

      The outcomes of the RFI serve as a basic documentation of the preliminary selection process of potential suppliers. In the next step, the selection process on a much more specific level is initiated by the investor as the so called Request for Proposal is sent out to the pre-selected companies. 

      Request for Proposal (RFP)

      Request for Proposal differs from RFI in two major ways: it´s binding and often confidential. 

      In the RFP the investor is already much more specific in its description of 

      - desired outcomes of the project and expected benefits

      - current environement 

      - time constraints

      - budget etc.

      When writing a RFP, be careful:

      - to be as precise as possible in description of your requirements, so that the responses to your RFP are mutually comparable

      - to describe problems that you desire to solve - NOT SOLUTIONS!

      - to follow all legal requirements so that the selection process may be as smooth as possible and your project may start on time (particularly important in state organisations for which specific laws regulating procurement activities apply)

      - to assure that all the communication is confidential (NDA or labeld "confidential" with potential consequences in case confidentiality of the communication is breached)

      - to specify, how the whole procurement process will look like, how the responses will be evaluated.

      As you can see, the RFP brings us on the edge of iniation and planning phase.

    • TEST: Why is the initation phase of any project an important part of the project-life-cycle? Which factors may undermine your efforts to complete the initiation phase and get the regular outcomes of it in real-life situations?

    • Trends in information technology: Information resources

      1. Gartner: www.gartner.com

      Gartner Magic Quadrant

      Example:

      Gartner Magic Quadrant - example CRM cor Customer Engagement Center solutions, 2020

      How to read Magic Quadrant: 

      https://www.itworldcanada.com/blog/a-gartner-magic-quadrant-know-what-to-read-and-where-to-look/376099

      Gartner HypeCycle

      How to read Gartner Hype Cycle

    • In the end of this module, you will find know:

      • how do you deal with human resources in initiation and planning phases
      • what is a stakeholder analysis
      • how does an OBS look like
      • what is a project steering committee
      • what is RACI and how to use it
      • and which are the main IT professions that you might need in a project of system implementation

      Human resource management is one of the most important and at the same time the most difficult tasks of a project manager on any project. The tasks associated with this activity vary according to the stage at which the project is currently in its life cycle. The first tasks related to HR management occur already in the initiation phase of the project, the aim of which - as we said in previous modules - is to decide which stimuli will be transformed into new projects. In this phase, activities related to HR are primarily focused on a stakeholder analysis the aim of which is, among other things:

      -- to identify key human resources that are potentially critical for the successful implementation of the project, incl. finding out their real availability for a possible project

      - - to determine the significance of the initiative within the company-wide strategy,

      - - to identify potential risks and methods of their elimination

      - - to identify the motivations of individual players for the project and related concerns and limitations

      - - to get the support of top management, middle management and line employees throughout the organization

      If a projects gets a "go-decision" from the responsible body within the organisation, a project manager is usually assigned to run the whole project. It is important to note, that the position of a project managemer is usually not an executive position within a line management structure. In a matrix organisational structure (see above), project managers run projects accross all involved organisational lines and departments and in this way create space for a flexible and smooth implementation of desired outcomes. As such, project managers have limited executive power and are dependend on top management support as well as collaboration of other line management staff.

    • On IT projects, a large variety of IT specialisations may be needed. The required IT professions  will vary based on the exact specification of the project scope and the implementation scenario (in-house, external supplier as a system integrator, internaly orchestrated delivery of a set of external suppliers, SaaS etc.).

      It is always important to keep in mind, that without tight cooperation with the customer´s staff, no supplier can complete a successful IT project! Therefore, some of the positions have to be duplicated: eg. information architect on the side of the customer, information architect on the side of the supplier. However, nominations to the project team must be carefully considered so that all project tasks may be completed by qualified personnel on both sides.

      Examples of IT professions that might be needed on IT projects (note: terminology is fluid, not 100% fixed, different titles may be used in different environments):

      -        Project manager

      -        IT architect

      -        IT analyst

      -        Business analyst

      -        SW specialist

      -        HW specialist

      -        Network specialist

      -        Security specialist

      -        Database specialist, data analyst, information architecture specialist 

      -        Programmer, developper (back-end, front-end ...)

      -        UX/UI specialist/designer

      -        Tester

      -        Trainer

      -        (operations etc.)

      Examples of other professions needed on a project:

      -        Client rep

      -        Product specialist

      -        Line management

      -        Procurement department

      -        Financial department

      -        Quality control / Risk management

      -        Project office (administrator)

      -        (Public relationship rep.)

      As you can see on the two lists, a successful implementation of an IT project usually requires an intense involvement not only of IT experts, but also of the business side of the organisation. One of the roles in which a project manager is crutially needed is to bridge the potential gap between those groups.

       

       

    • Useful tools for managing human resources on the project:

      • organisational breakdown structure
      • RACI

      Organisational breakdown structure

      A project manager is required to complete and provide to all project team members a visualisation of the project team. This visualisation is usually in a hierarchical  format with easily destinguished areas of responsibility of all members. OBS is crutial particularly when a new team is established, in which people from different organisational units as well as external companies participate. OBS also serves as a base for smooth communication and information exchange.

      A project manager usually holds a management position on the upper part of the OBS. However, he/she usually reports to a higher management body - the steering committee (see below).

      RACI 

      A RACI chart is a simple matrix used to assign roles and responsibilities for each task. RACI stands for Responsible, Accountable, Consulted and Informed. 

      • Responsible: This team member does the work to complete the task. 
      • Accountable: This person delegates work and reviews the its outcomes before completion. 
      • Consulted: These people provide further input needed for the completion of the task taking in consideration the impact of the particular deliverable on their main domain of interest and expertise. 
      • Informed: These team members need to be kept informed about specific deliverables, outcomes or progress of the project. 

      The RACI matrix may help you clearly assign tasks and prevent misunderstandings and conflicts among parties involved in the work on the particular workpackage.

    • Steering committee

      Project Bliss defines a steering committee as "a top-level project governing body that’s formed at project initiation to provide oversight, guidance, and support for the project. The project steering committee is made up of high-level stakeholders who have your project success at heart. It’s composed of members from the different groups who each have a vested interest in the project success. To get the full benefit of a project steering committee, it’s important for it to be made up of stakeholder representation from various areas, incl. the end-users reps". 

      Because steering committees are made up of a diverse group of individuals from different areas, they come with different perspectives. While this is desirable, it can also lead to challenges, such as these listed below. 

      1. Conflict of interest. The very fact that there are representatives from different areas different can cause potential conflict of interest. If a group wants to rally for being the first adopters of a project’s solution, they may use their leverage on the steering committee to push for that. 

      2. Conflict in general. Differing viewpoints can at times lead to conflict. While conflict itself isn’t a bad thing, unhealthy and disrespectful conflict can be. As the project manager, be aware of the relationships and communication in the group to ensure that everyone communicates respectfully and the project success is the primary focus of the group. 

      3. Intimidation. If there are different levels of seniority on the steering committee, depending on the company culture, others may be hesitant to speak up. 

      4. Delays in decision-making.  It’s rare that a group votes unanimously in any decision. And having decision-by-committee can often delay a final decision being made. Which in turn delays action. 

      5. Misunderstanding of purpose and roles. If the group members are not familiar with participating in a steering committee, they may not be as effective as possible. This can be overcome by creating a charter and guidelines for the roles and activities of the steering committee. 

       

      Project Bliss identifies among other the following goals of the steering commitee:

      • Provide strategic direction to a project 
      • Identify project goals and objectives
      • Ensure the project goals align with business and strategic objectives
      • Ensure that expenses and work effort are in alignment with stakeholder expectations
      • Set targets for achievement of goals
      • Manage project conflicts that occur across departments
      • Provide guidance to the project team
      • Monitor budget allocations to avoid overruns
      • Monitor project scope and activities 
      • Ensure adherence to timelines
      • Ensure deliverables meet organizational needs
      • Look out for potential risks and uncertainties that may be a threat to project success
      • Serve as an advocate for the project’s success
      • Stay informed of the project’s activities, progress, and outcomes
      • Help resolve any conflicting priorities
      • Raise issues to ensure the project continues to move forward successfully
      • Approve changes to the project scope, budget, or timeline
    • TASK 1: What kind of informtion related to key project success factors can you as a project manager obtain from project sponsors and end-users?

      TASK 2: End-users tend to be resistent to change. Identify reasons for this resistance as well as means of overcoming it.

  • The roots of project scope definition start already in the initiation phase of a project. The project scope reflects the project goals and objectives that further contribute to the fulfilment of company´s vision and strategy . The projects goals and objectives are on a high level described in the basic document: project charter (for further information, see PMBoK).

    After the go-decision is made and a project proceeds into the planning phase, project scope is further refined with much larger focus on the level of detail. 

    At first, an in-depth analysis is to be made. In case of IT projects (eg. new ERP system implementation), the main attributes to be analysed:

    - current hardware, software, application and data architecture

    - current business processes

    - current business focus (customers, products, services ...)

    - future business development plans within which the project will be implemented

    - future vision of IT environment and its role in the company

    - functional and non-functional requirements (incl. eg. security, maintenance etc.)*

    - project implications to procurement and HR 

    - key project personnel etc.

    In this way, not only the current situation is described in adequate detail, but also the global and detail solution design incl. transition / migration process are set.

    The outcome of the analytical stage with all the above mentioned information is usually called an analytical study. An analytical study represents a baseline for the further stage - a stage of implementation. Any changes and adjustments of the project scope are in further stages subject to a change management process.

    Project goals must follow the SMART approach. That means that the goals must be:

    • S - specific
    • M - measurable
    • A - approved (achievable)
    • R - realistic (relevant)
    • T - timed

    We advice you to read more about the SMART approach here: https://www.mindtools.com/pages/article/smart-goals.htm

    *Functional and non-functional requirements should reflect needs and requirements of all stakeholders involved in the project. When gathering and analysing stakeholders´ requirements, you should always keep in mind that:

    - needs and requirements are not the same. Needs may be felt but unexpressed. 

    - some needs/requirements may be conflicting (eg. scale of functionality vs. price/time). In such a case, decision on priorities must be made.

    - users may not be aware of many IT innovations and possibilities - an IT professional should be there to assist them in understanding them thoroughly before the final project baseline is approved.

    - when analysing user needs/requirements concentrate not only on what users want, but also what they donˇt want, what are they used to (observation), what do they expect and fear!

    Take-away! Project scope must be clearly described, understood and accepted by all stakeholders. Without their support, contribution and acceptance is any project doomed to failure!!!

    Change management

    In the waterfall approach, all change requests that are raised after the project scope baseline is approved, must be subject to rigorous change management procedure.

    A project manager is in charge of putting a change management process in place already in the beginning of the planning phase. The objective is that all project team members understand:

    - who can raise a request for change and to whom

    - where to find the change request template and how to fill it in (incl. the basic information set...)

    - who and when makes a decision about the change request (depending on its type and impact)

    - where will be the final decision documented and who is responsible for further implementation of the change in case it is approved.

    Changes in a waterfall approach may be an expensive endeavour. If a need for change is recognised too late, it may be very costly to implement it. However, changes are not undesirable. In contrary - they may contribute to a larger project acceptance and success if managed properly. A project manager is always responsible for:

    - setting up the change management process

    - tracking, controlling and documenting all the steps related to individual change request

    - and ... !!! keeping the project triange in balance!!! Any change that may have an impact on resources and/or time must be accompanied by steps that assure that all attributes are always kept in balance.

    • In this module you will learn what is a workbreakdown structure, how does to construct it and use it as a major planning, tracking and control tool.

      A workbreakdown structure (WBS) is a visual, hierarchical and deliverable-oriented deconstruction of a project. It is an essential project management tool for planning and scheduling.

      A WBS helps the PM to

      • organize deliverables and tasks, 
      • establish and visualize project schedule baseline and track the actual project progress incl. potential variances 
      • decompose major tasks to subtasks and establish task dependencies
      • assign human and other resources to each task and estimate its duration, clarify work load and collaboration needs
      • identify a critical path of the project and mission critical tasks
      • identify risks and add risk mitigation activities
      • prevent time delays, scope creep and cost overrun etc.

      How does a WBS look like?

      The final deliverable rests on top of the diagram, and the levels below subdivide the project scope to indicate the deliverables and tasks that are needed to complete the project. That means that a WBS decomposes the project deliverables into more manageable pieces that are easier to plan and deliver. The number of WBS levels may differ based on exact project specifics.

      How to construct a WBS?

      The novices are usually adviced to start with a verb-oriented WBS that defines the deliverables as actions. (There are also noun-oriented WBS and time-phase oriented WBS, but in the APM course we will stick to a verb-oriented WBS).

      In the beginning, it is crutial to have a complete picture of the project, incl. project goals and objectives (project charter).

      Than you may proceed in top-down or buttom-up manner.

      Project team as well as expert audits are adviced for PM novices.

      WBS Components:

      • Task description
      • Task identification number
      • Task owner + resources
      • Task dependencies
      • Task duration estimates
      • Task costs
      • (Task status)

      Take-away 1: there is not a single way how to do a good WBS for your project. 10 people may construct 10 different WBS and they may all be correct. However, you must be sure that the moment you complete all the tasks and activities on the list, you may be sure that all the work to be done is completed and all you contractual obligations are met!

      Take-away 2: WBS is not a shopping list, nor it is a list of decisions to be made!

      Assignement:  Create a WBS for the following project.

      A subtenant moved away from the premises of a municipal library. A large room thus became available to the library management. A centre for life-long learning that should be open to local community is to be created.

      - the room is equipped with electricity, heating, windows, doors and carpet

      Prepare a hierarchical work-breakdown structure that would lead the project team all the way up to the opening of the centre to public. Focus on the scope of the tasks and their hierarchy. 

      In order to check the completeness of the WBS, imagine the task-walk-through from the position of the final beneficiaries.

      Format: Excel, Word or screen shot/photo.

      List any assumptions if necessary.

      To be submitted by Monday 28th April, 2022  till 10.00 am to the email address helena.lipkova@ff.cuni.cz.

    • Project estimates are the next step after you WBS is ready. In this module, you will learn how to proceed when estimating work efforts needed for every deliverable/activity on your WBS. By the end of the module, you will also know the various factors that must be taken into consideration when estimating. Remember, your estimates are not sufficiently accurate, your whole project schedule is going to collapse!

      You have now your WBS in hand. You know, which activities will have to be completed so that all project goals and objectives are met as required by the project sponsor and other stakeholders. The WBS with appropriate project estimates are the foundation of your future project schedule (and financials). Therefore it is important to complete the project estimation tasks with special care.

      Project estimates are expressed mostly in the unit of man-days or man-hours. The number of man-hours on a task represent the amount of time needed for completion of this task.

      What to take into consideration:

      For each individual it may take a different amount of time to complete a certain task. There are many factors that may influence this duration eg. the level of education achieved in the specific domain, the extend of previous experience, capacity of an individual to quickly learn and adapt etc. 

      When assigning human resources to individual WBS activities, you need to take many factors into consideration too: eg.:

      • How difficult and complex is this task to complete?
      • Is there a requirement for certification associated with this task?
      • How fast does it have to be done? 
      • Are there many risks involved?
      • Who needs to engage in delivery? Who should cooperate?
      • How high is my budget?
      • Which human resources are there available in that moment?

      Do not forget, that all your estimates should be based on the data submitted or approved by the task owners if possible. In other cases, it´s adviced to get an expert opinion on your tasks or discuss them with fellow project managers experienced in the particular domain of your project.

      Take-away No. 1: Never adjust your estimates to the expected outcome! If the final budget exceeds the original assumptions, re-check your estimates, re-consider the assignement of specialists high on the learning-curve and re-check project priorities from the perspective of scope!

      Take-away No. 2: Be cautious with estimates of your subcontrators. There are good reasons why they may under- or over-estimate their parts of the work. Get a clear understanding of their scope of work. Re-check!

  • fOnly after you complete your project estimates, the time is ripe for proceeding to fixing the project schedule. That means transfering your WBS + project estimates into a calendar. In this module, you will learn about the basic scheduling methods used in project management, types of links between tasks as well as about the critical path and it´s use in managing your projects.

    There are different methods that may be applied in project scheduling. Some examples are:

    • Precedence Diagram Method, 
    • Critical Path,
    • Critical Chain Method 
    • PERT (Programme Evaluation and Review Technique) etc.

    Most of the above listed methods however work with the same basic blocks:

    • activities (tasks that consume resources)
    • milestones (points in time that do not consume resources)
    • relationships (linkeages)
    • critical path

    Linkeages / task relationships:

    • Finish - start /FS/ (when using SW for scheduling activities, FS is the default value after all the activities are linked)
    • Start - start /SS/
    • Finish - finish /FF/
    • Lag time
    • Lead time
    • Early start
    • Eartly finish
    • Late start 
    • Late finish

    Assignement 1: Give examples of the FS, FF, SS, lag and lead times from your daily life.

    By linking all activities in you WBS, you get a network to integrate into calender time and get the baseline for your project schedule. 

    In the network, you may discover two different types of floats:

    Free Float – the amount of time a task can be delayed without affecting the succeeding task. 
    Total Float – this is the amount of time which an activity can be delayed without affecting the end date of the project.

    Critical path

    The critical path is the longest sequence of tasks that must be completed to successfully conclude a project, from start to finish. Therefore, it also represents the shortest time in which the whole project may be completed. The tasks on the critical path are known as critical activities because if they're delayed, the whole project will be delay. The so called float between these tasks equals zero. 

    Assignement 2: How can the critical path serve the project manager during the phase of project execution?

  • In this module, you are going to find out which software tools are there that can help you plan, manage and control your projects in real-life environment. 

    As many of the SW packages are really complex and rich in functionality we are going to focus mainly on aspects that directly link to the project management fundamentals that we have covered so far in the course. 

    In the end of the module, you should be be able to:

    - identify some of the SW products for project management (both customer-off-the-shelf as well as freeware) 

    - establish a new project

    - build up a work-breakdown structure 

    - establish WBS task hierarchy

    - establish and adjust links among WBS tasks, specify predecessors

    - put in the milestones

    - assign resources to WBS tasks

    - add re-occuring events like project meetings into your plan

    - use notes function to share comments and files to individual tasks

    • Microsoft Project Standard - User interface

      MSProject_1.JPG?time=1613984333024

      MSProject_2.JPG

    • Project Libre - User interface

      ProjectLibreUI.jpg