Chapter 1 Project Management Concepts First lecture Program

  • Slides: 31
Download presentation
Chapter 1: Project Management Concepts First lecture Program: 5 th. Semester Department: BS Due

Chapter 1: Project Management Concepts First lecture Program: 5 th. Semester Department: BS Due Date : 10 -09 -18 By: Serat

Chapter 1 Outline Ø Ø Ø Introduction to project management People Product Process Project

Chapter 1 Outline Ø Ø Ø Introduction to project management People Product Process Project

Project management v. Project management can be defined as the collection and implementation of

Project management v. Project management can be defined as the collection and implementation of tools and techniques to manage the use of diverse resources to accomplish a unique and complex job. v. Project management is the discipline of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria. v. Skillful integration of software technology, economics and human relations in the specific context of a software project. 3

The Four P’s v. Effective software project management focuses on the four P’s Ø

The Four P’s v. Effective software project management focuses on the four P’s Ø People: the most important element of a successful project. Ø Product: the software to be built. Ø Process: the set of framework activities and software engineering tasks to get the job done. Ø Project: all work required to make the product a reality. 4

The People o The cultivation of encouraged, skilled software people has been started since

The People o The cultivation of encouraged, skilled software people has been started since 1960 s. o Indeed, the people factor is so important because the Software Engineering Institute has developed a People Capability Maturity Model (People-CMM). o The reason was that every organization needs to frequently improve its ability to develop, motivate and organize the project to accomplish its strategic business objectives. 5

The People o The people capability maturity model defines the following key practice areas

The People o The people capability maturity model defines the following key practice areas for software people. Ø Staffing Ø Communication and coordination Ø Work environment and performance management Ø Training and compensation Ø competency analysis and development Ø career development, workgroup development, team/culture development, and others. 6

The People o In a study published by the IEEE the engineering vice presidents

The People o In a study published by the IEEE the engineering vice presidents of three major technology companies were asked what was the most important contributor to a successful software project. They answered in the following way: Ø VP 1: I guess if you had to pick one thing out that is most important in our environment, I’d say it’s not the tools that we use, it’s the people. 7

The People ØVP 2: The most important thing you do for a project is

The People ØVP 2: The most important thing you do for a project is selecting the staff, good people. ØVP 3: The only rule I have in management is to ensure I have good people real good people and that I grow good people and that I provide an environment in which good people can produce. 8

Stakeholders o The software process (and every software project) is populated by stakeholders who

Stakeholders o The software process (and every software project) is populated by stakeholders who can be categorized into one of five parts: Ø Senior managers: Who define the business issues that often have significant influence on the project. Ø Project (technical) managers: who must plan, motivate, organize, and control the practitioners who do software work. Ø Practitioners: Who deliver the technical skills that are necessary to engineer a product or application. Ø Customers: Who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. Ø End-users: Who interact with the software once it is released for production use. 9

Software Teams How to lead? How to organize? How to collaborate? How to motivate?

Software Teams How to lead? How to organize? How to collaborate? How to motivate? How to create good ideas? 10

Team Leader o Project management is a people-intensive activity, and for this reason, competent

Team Leader o Project management is a people-intensive activity, and for this reason, competent practitioners often make poor team leaders. o They simply don’t have the right mix of people skills. o In an excellent book of technical leadership, Jerry suggests a MOI model of leadership. Ø Motivation: The ability to encourage (by “push or pull”) technical people to produce to their best ability. 11

Team Leader Ø Organization: The ability to mold existing processes (or invent new ones)

Team Leader Ø Organization: The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Ø Ideas or innovation: The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application. o Another view of the characteristics that define an effective project manager emphasizes four key traits. 12

Team Leader q. Problem solving. An effective software project manager can diagnose the technical

Team Leader q. Problem solving. An effective software project manager can diagnose the technical and organizational issues, systematically structure a solution or properly motivate other practitioners to develop the solution, apply lessons learned from past projects to new situations. q. Managerial identity. A good project manager must take charge of the project. he must has the confidence to assume control when necessary and the assurance to allow good technical people to follow their natures. 13

Team Leader q. Achievement. A competent manager must reward initiative and accomplishment to improve

Team Leader q. Achievement. A competent manager must reward initiative and accomplishment to improve the productivity of a project team. q. Influence and team building. An effective project manager must be able to “read” people; he must be able to understand verbal and nonverbal signals and react to the needs of the people sending these signals. The manager must remain under control in high-stress situations. 14

Software Teams o The following factors must be considered when selecting a software project

Software Teams o The following factors must be considered when selecting a software project team structure … Ø The difficulty of the problem to be solved Ø The size of the resultant program(s) in lines of code or function points. Ø The time that the team will stay together (team lifetime) Ø The degree to which the problem can be modularized Ø The required quality and reliability of the system to be built Ø The rigidity of the delivery date Ø The degree of sociability (communication) required for the project. 15

Organizational Paradigms o Closed paradigm—structures a team along a traditional hierarchy of authority o

Organizational Paradigms o Closed paradigm—structures a team along a traditional hierarchy of authority o Random paradigm—structures a team loosely and depends on individual initiative of the team members. o Open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm. o Synchronous paradigm— this is the compartmentalization(parts) of a problem and organizes team members to work on pieces of the problem with little active communication among themselves. suggested by Constantine for software team [Con 93] 16

Agile Teams o Team members must have trust in one another. o The distribution

Agile Teams o Team members must have trust in one another. o The distribution of skills must be appropriate to the problem. o To review, the agile philosophy encourages customer satisfaction and early incremental. o Delivery of software, small highly motivated project teams, informal methods, minimal software engineering work products, and overall development simplicity. 17

Team Coordination & Communication o There are many reasons that software projects get into

Team Coordination & Communication o There are many reasons that software projects get into trouble. o The scale of many development efforts is large, leading to complexity, confusion, and significant difficulties in coordinating team members. o To solve this issue new software must communicate with existing software and conform to predefined constraints imposed by the system or product. 18

The Product o Before a project can be planned, product objectives and scope should

The Product o Before a project can be planned, product objectives and scope should be established, alternative solutions should be provided and technical and management constraints should be identified. o Without this information, it is impossible to express reasonable and accurate estimates of the cost, an assessment of risk, an accurate breakdown of project tasks. o Once the product objectives and scope are understood, alternative solutions are considered. o Because it enable managers and practitioners to select a “best” approach, given the constraints forced by delivery deadlines, budgetary restrictions, personnel availability, technical interfaces and other factors. 19

Software scope o Scope is defined by answering the following questions: Ø Context. How

Software scope o Scope is defined by answering the following questions: Ø Context. How does the software to be built fit into a larger system, product, or business context, and what constraints are imposed as a result of the context? Ø Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input? Ø Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed? o Software project scope must be unambiguous and understandable at the management and technical levels. 20

Problem Decomposition o Sometimes called partitioning or problem elaboration o Once scope is defined

Problem Decomposition o Sometimes called partitioning or problem elaboration o Once scope is defined … o It is decomposed into essential functions o It is decomposed into user-visible data objects or o It is decomposed into a set of problem classes o Decomposition process continues until all functions or problem classes have been defined 21

The Process o A software process provides the framework from which a comprehensive plan

The Process o A software process provides the framework from which a comprehensive plan for software development can be established. o A small number of framework activities are applicable to all software projects, regardless of their size or complexity. o Finally, umbrella activities—such as software quality assurance, software configuration management, measurement and so on. 22

Melding the Problem and the Process 23

Melding the Problem and the Process 23

Process Decomposition o Small, relatively simple project might require the following work tasks for

Process Decomposition o Small, relatively simple project might require the following work tasks for the communication activity: o 1. Develop list of clarification issues. o 2. Meet with stakeholders to address clarification issues. o 3. Jointly develop a statement of scope. o 4. Review the statement of scope with all concerned. o 5. Modify the statement of scope as required. 24

The Project o Projects get into trouble when … o Software people don’t understand

The Project o Projects get into trouble when … o Software people don’t understand their customer’s needs. o The product scope is poorly defined. o Changes are managed poorly. o The chosen technology changes. o Business needs change or are ill-defined. o Deadlines are unrealistic. o Users are resistant. o Sponsorship is lost or was never properly obtained. o The project team lacks people with appropriate skills. o Managers and practitioners avoid best practices and lessons learned. 25

Common-Sense Approach to Projects o Start on the right foot. This is accomplished by

Common-Sense Approach to Projects o Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting accurate objectives and expectations. o Maintain momentum. The project manager must provide motivations to keep turnover of personnel to a complete minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team’s way. 26

Common-Sense Approach to Projects o Track progress. For a software project, progress is tracked

Common-Sense Approach to Projects o Track progress. For a software project, progress is tracked as work products (e. g. , models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. o Make smart decisions. In essence, the decisions of the project manager and the software team should be to “keep it simple. ” o Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project. 27

W 5 HH Principals for Simple Project Plan ØWhy is the system being developed?

W 5 HH Principals for Simple Project Plan ØWhy is the system being developed? It enables the parties to assess the validity of business reasons for the software work. It justifies the expenses of people, time, and money. Ø What will be done? It specifies the task set required for the project Barry Boehm [Boe 96] 28

W 5 HH Principals for Simple Project Plan ØWhen will it be accomplished? It

W 5 HH Principals for Simple Project Plan ØWhen will it be accomplished? It helps to determine the project schedule. It helps in determining when tasks are conducted and when milestones are reached. ØWho is responsible for a function? It helps to accomplish the role and responsibilities of each member of the software team. Barry Boehm [Boe 96] 29

W 5 HH Principals for Simple Project Plan ØWhere are they organizationally located? The

W 5 HH Principals for Simple Project Plan ØWhere are they organizationally located? The software team does not contain all the roles and responsibilities. The customers, users and stakeholders also have responsibilities. Ø How will the job be done technically and managerially? The management and technical strategy of project is defined once the scope of the product is established. Ø How much of each resource is needed? It helps in deriving estimates based on the answers to the above questions. 30

Thanks

Thanks