Software Engineering (CSI 321) Project Management

What is a Project? Project : A planned undertaking of related activities to reach an objective that has a beginning and an end.

What is Project Management? Project management is a controlled process of initiating, planning, executing, and closing down a project. Project management involves the planning, monitoring, and control of the people, process, and events that occur as software evolves from a preliminary concept to full operational deployment. Software project management is an umbrella activity within software engineering. It begins before any technical activity is initiated and continues throughout the modeling, construction, and deployment of computer software.

What is Project Management? Managing the accomplishments of a software development project according to a specific project plan, in order that a project is completed on time, and within its budget , and meets its design objectives. Project management activity encompasses measurement and metrics, estimation and scheduling, risk analysis, tracking , and control.

Why Project Management is important? Developing computer software is a complex undertaking, particularly if it involves many people working over a relatively long time. That’s why software projects need to be managed. Software project management is an essential part of software engineering and may be the most important aspect of software development. Effective Project Management helps ensure system development projects – Meet customer expectations Delivered within budget and time constraints

The Management Spectrum Effective software project management focuses on the four P’s: People – Organized, motivated, coordinated Product – Requirements well-understood Process – Appropriate for people & product Project – Must be organized in a manner that enables the software team to succeed.

People: The Stakeholders Senior managers/Business managers –defines business issues that often have significant influence on the project Project(technical) managers –must plan, motivate, organize, control practitioners who do software work Practitioners –deliver the technical skills that are necessary to develop a product Customers –specify the requirements for the software to be engineered End-users –interact with the software once it is released for production use

Characteristics of Team Leader/Project Manager A model of leadership: The MOI model Motivation - Ability to encourage technical people to produce to their best ability. Organization – Ability to mold existing processes that will enable initial concept to be translated into a final product. Innovation- Ability to encourage people to create and feel creative. Successful project leaders apply a problem solving management style. A software project manager should concentrate on understanding the problem to be solved, managing the flow of ideas, and at the same time, letting everyone on the team know that quality counts & that it will not be compromised.

Characteristics of Team Leader/Project Manager An effective project manager emphasizes four key traits: Problem solving Managerial identity Achievement Influence and team building

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

Software Teams What factors should be considered when the structure of a software team is chosen? 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

“Organizational Paradigms” for Software Teams Software engineers can be organized in a number of different team structures: Closed paradigm—structures a team along a traditional hierarchy of authority. Random paradigm—structures a team loosely and depends on individual initiative of the team members. 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. Synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves. …suggested by Constantine [CON93]

Avoid “Team Toxicity” Why do many software teams suffer from “Team Toxicity”? // What are the five factors that foster a potentially toxic team environment? A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed. High frustration (caused by personal, business, or technological factors ) that causes friction among team members. A “Fragmented or poorly coordinated” software process or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment. Unclear definition of roles on the software team (resulting in a lack of accountability and resultant finger-pointing). “Continuous and repeated exposure to failure” that leads to a loss of confidence and a lowering of morale.

Agile Software Development The characteristics of Agile Software Development Adaptable and incremental software process Encourages customer satisfaction Incremental delivery of software Small, highly motivated project teams Informal methods Overall development simplicity

Agile Teams An agile team is a self-organizing team that has autonomy to plan and make technical decisions. Team members must have trust in one another. The distribution of skills must be appropriate to the problem. Mavericks may have to be excluded from the team, if team cohesiveness is to be maintained. Stresses individual (team member) competency coupled with group collaborations as critical success factors for the team.

Agile Teams Team is “self-organizing” A small, highly motivated, and adaptive team structure Uses elements of Constantine’s random, open, and synchronous paradigms Significant autonomy

Team Coordination & Communication Formal, impersonal approaches SE documents and work products, project milestones, schedules, change request documents, error tracking reports Formal interpersonal approaches review meetings, inspections Informal interpersonal approaches group meetings for information dissemination and problem solving Electronic communication e-mail, video conferencing Interpersonal network Informal discussions with team members and those outside the project who may have experience or insight that can assist team members

The Product The Product(Software) scope: Software project scope must be unambigguous and understanable at the management and technical level. Scope is defined by answering the following questions – Context: How does the s/w to be built fit into a larger system or business context? What are constraints? Information objectives: What customer-visible data objects are produced as output? What data objects are required for input? Function: What functions does the s/w perform to transform input data into output? Performance: Are there any special performance characteristics to be addressed?

The Product Problem decomposition Also called partitioning or problem elaboration Sits at the core of software requirements analysis Applied in two major areas Functionality that must be delivered The process used to deliver it To develop a reasonable project plan, you must decompose the problem. List of functions/use-cases User stories(for agile work)

The Process Common Process Framework Activities: Communication Planning Modeling Construction Deployment Work tasks may vary but the common process framework activities are invariant. The framework activities that characterizes the software process are applicable to all software projects. The problem is to select the process model that is appropriate for the software to be engineered by the project team.

The Process The project manager must decide which process model is most appropriate for – customers developers characteristics of the product project development environment

Customer Communication Activity Customer Communication Activities for a small and relatively simple project: Develop list of communication issues Meet with customer to address clarification issues Jointly develop a statement of scope (Statement of Work) Review statement of scope/work (SoW) with all concerned Modify SoW as required

Customer Communication Activity Customer Communication Activities for a large and relatively complex project: Review customer request Plan and schedule formal meeting with customer (regular) Conduct research to specify the proposed solution and existing approaches Prepare working doc and agenda for the formal meeting Conduct the meeting Jointly develop mini-scope Review SoW with all concerned Modify SoW doc as required

The Project What are signs that a software project is in jeopardy? Software people don’t understand their customer’s needs. The product scope is poorly defined. Changes are managed poorly. The chosen technology changes. Business needs change (or are ill-defined). Deadlines are unrealistic. Users are resistant. Sponsorship is lost (or was never properly obtained). The project team lacks people with appropriate skills. Managers (and practitioners) avoid best practices and lessons learned.

Common-Sense Approach to Manage Software Projects Start on the right foot : Accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations. Maintain momentum: Project manager must provide incentives to keep turnover of personnel to an absolute 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. Track progress : Progress is tracked as work products are produced and approved as part of a QA activity. Make smart decisions: “keep it simple.” Conduct a postmortem analysis: Establish a consistent mechanism for extracting lessons learned for each project.

The W5HH Principle How to define key project characteristics? ==> Barry Boehm’s W5HH Principle Why is the system being developed? What will be done? When will it be done? Who is responsible for a function? Where are they organizationally located? How will the job be done technically & managerially? How much of each resource is needed?

Critical Software Practices Formal risk management Empirical cost and schedule estimation Metric-based project management Earned value tracking Defect tracking against quality targets People-aware program management