Week 1 - Intro

Why do software projects fail?

1. People begin programming before they understand the problem (feel of making progress, start to code early and see early gains, more and more complex later and project bogged down, code too soon will lead to good project solving wrong problems).

2. The team has unrealistic ideas about how much work is involved (too optimistic when solving problems).

3. Defects are injected early but discovered late (project solves wrong needs, incorrect requirements, design/architecture/code can be tech-flawed, inappropriate test plan).

4. Programmers have poor habits - and they don’t feel accountable for their work (bad source code managing, confusing code, devs don't test their code, the team doesn't have a good sense of what is called project health).

5. Managers try to test quality into the software (rely too much on testers, programmer arrogance).

How can we make sure that our projects succeed?

1. Make sure all decisions are based on openly shared information (transparency is needed, people need to feel comfortable when finding information, people who need something should have what they need, decisions are made with well-supported and explained).

2. Don’t second-guess your team members’ expertise (managers need to trust team members, don't veto ideas if don't have good reasons).

3. Introduce software quality from the very beginning of the project (review and test everything, but don't rely too much on review, the review is important).

4. Don’t impose an artificial hierarchy on the project team (all members are equal, a manager should not assume something is more difficult than others, just ... not assume).

5. Remember that the fastest way through the project is to use good engineering practices (managers and teams often want to cut important parts: estimation, review, requirements gathering, testing... but cutting them out → cost time and reduce quality).

Week 2 - Planning

Who needs software?

Most software is built-in organizations for people with specific needs

• A stakeholder: is anyone who has an interest (or stake) in the software being completed.

• A user: is someone who will need to use the software

• Sometimes stakeholders can be users, but OFTEN they aren’t.

Who builds software?

Typically by software engineers

• Business analysts/requirements analysts: talk to users/stakeholders, plan the behavior of software and requirements.

• Designers and architects: plan the technical solution.

• Programmers: code

• Testers: verify the program.

Project Manager in Project Management

The PM plans and guides the software project

• The PM is responsible for identifying the users/stakeholders and their needs.

• The PM coordinates the team, ensuring the task is assigned to an appropriate member.

• The PM must familiar with every aspect of SE.

Identifying Needs

The PM drives the scope of the project

• The PM should identify and talk to the main stakeholder

• The effective way to show that you understood their needs is when they are addressed in a vision and scope document.

Vision and Scope Document

Outline

• Problem Statement
  • Project background
  • Stakeholders
  • Users
  • Risks
  • Assumptions

• Vision of the Solution
  • Vision statement
  • List of features
  • Scope of phased release - optional
  • Features that will not be developed

Project Plan

Defines the work that will be done on the project and who will do it

• A statement of work - SOW: describes all work and people who will do it.

• A resource list: all needed resources and their availability.

• A work breakdown structure and set of estimates

• A project schedule.

• A risk plan: what might be encountered and how to face them.

Statement of Work

Is a detailed description of all the work products which will be created over the course of the project.

• A list of features to be developed

• A description of each intermediate deliverable or work product that will be built

• The estimated effort needed

Resource List

A resource can be a person, hardware, room, or anything else that is necessary for the project but limited in its availability

• Name

• One-line description

• Availability

• Cost - optional

Estimates & Project Schedule

• A work breakdown structure - WBS, is a list of tasks in which, if performed, will generate all of the work products needed to build the software

• A WBS includes estimated efforts needed.

• A project schedule is created by assigning resources and determining the calendar time required for each task.

Risk Plan

A risk plan is a list of all risks that threaten the project → having this will mitigate some/all risks

• Brainstorm the potential risks.

• Estimate probability and impact.

• A risk plan is constructed.

Week 3 - Estimation

What is estimation?

• The PM set expectations about the time required to complete the software

• The expectations must be realistic, if not, the stakeholders won't trust the team and the PM.

A Sound/Reasonable Estimate

A PM must have:

• A WBS, or a list of tasks

• An effort estimate

• A list of assumptions that explain for making estimates

• Consensus between the team about the estimate

Assumptions make Estimates more Accurate

The team member make assumptions about the work to be done

• An estimate must be based on a decision that has not yet been made ⇒ the team assumes the answer for the sake (benefit) of the estimate.

• Assumptions must be written down so anything happens to the estimates, then everyone can understand.

• Assumptions bring the team together at the early stage, to make important decisions.

Wideband Delphi

Is a process that a team can use to generate an estimate. The PM chooses an estimation team and gains consensus. WD is a repeatable estimation process as it consists of a straightforward set of steps that can be performed the same way each time.

1. Choose the team: about 3-7 members, including a mod - who should be familiar with the Delphi process but should not involve in the outcome of the session. The PM should not be a mod, be in the estimation team instead.

2. Kickoff Meeting: make sure everyone understands the process, scope, vision, documentations, needs... writes down assumptions, brainstorms, WBS, agreements.

3. Individual Preparation: each member prepares their own plans - estimates, efforts required, assumptions...

4. Estimation Session: during this, the team comes to a consensus on the effort required for each task in the WBS. Each fills out an estimation form containing their estimates. Then the rest of the time is about group discussion. Then the mod collects the forms, plots the sum of efforts for each form. The team then resolves any issues or disagreements. Each revises their estimates then, the mod plot again. Loop this until a consensus has been made.

5. Assemble Tasks: the PM works with the team to collect the estimates from the team members that the end of the meeting and complies final tasks list, estimates, and assumptions.

6. Review Results: the PM reviews the final task list with the estimation team.

Other estimation techniques: PROBE, COCOMO II, The Planning Game,

Week 4 - Project Schedules

What is a project schedule?

Is a part of the Project Plan and is a calendar that links tasks with the resources that will do them. The PM must have a WBS before + estimates.

• Effort = work required to perform a task (person per hours/days/weeks...)

• Duration = the amount of elapsed time when a task is started to its finish (hours/days/weeks...).

• Slack = the amount of time that a task can be delayed with no consequences.

• Overhead = is an effort that does not go to the core activities but is still required

Building a Project Schedule

1. Allocate resources: for each task in the WBS, one or more resources are assigned. Choose person/people based on qualifications, familiarity, and availability. Take overhead into account when calculating the duration.

2. Identify dependencies: a task can have a dependency = it involves something that is required by other tasks, one of the reasons is that they require the same resource. (4 combinations of Finish-Start)

3. Create the schedule: the Gantt Chart can be used.
   1. Reconcile the schedule: once the resources are allocated, the final date can be calculated, if it's unacceptable, the Project Plan must be changed (more resources or the scope got cut down)
   2. Add review meetings to the schedule: progress reviews are held regularly to check the progress, milestone reviews are held for the PM to schedule in advance.

4. Optimize the schedule: a critical path is a sequence of tasks that requires the minimum time to complete ⇒ any task that is only on the critical path will delay the project if it is delayed. A resource is over-allocated if more than 100% of resources are allocated simultaneously (if it is, it means there is a dependency between two tasks which was not discovered)

Don’t abuse buffers

Buffers are tasks added to the schedule with no specific purpose except to account for unexpected delays

• Pros: on a year-long project, everyone will take 2 weeks of vacation, then buffers can be used to account for these known delays.

• Cons: can be abused, overruns are expected = estimate is incorrect and buffers should not be used for this.

Project Metrics

• Baseline: a version of the schedule that has been approved, can be changed later based on the situation, if the deadlines after revising the schedule are later than the baseline, then the project has slipped.

• Variance: the difference between the estimated effort in the baseline and the actual effort performed.

• Earned value management: compare how much we earn to the budget
  • The budgeted cost for work scheduled - BCWS: is the estimated effort of the actual tasks that appear on the schedule to date.
  • The actual cost of work performed - ACWP: in the opposite, is the actual effort spent by the team.
  • Variance = BCWS - ACWP

• The cost performance index: is used to compare projects with each other or phases within the project. CPI = BCWS / ACWP

Week 5 - Reviews

When are reviews needed?

• Is to find and eliminate defects and to gain consensus among the project team, secure approval from stakeholders, and aid in professional development for team members

• Reviews help teams find defects soon after they are injected making them cost less to fix than they would cost if they were found in the test.

• All work products in a software project should be either reviewed or tested.

Types of Review: Inspections

• Inspections are moderated meetings in which reviewers list all issues and defects they have found in the document and log them so that they can be addressed by the author.

• The goal of the inspection is to repair all of the defects so that everyone on the inspection team can approve the work product.

• An inspection meeting:
  • A work product is selected for review and a team is gathered for the meeting
  • A mod is chosen to moderate the meeting
  • Each inspector prepares a list of defects.
  • Discuss each defect, and come up with solutions
  • The mod compiles all of the defect solutions into an inspection log

Type of Review: Deskchecks

• A Deskcheck is a simple review in which the author of a product distributes it to one or more reviewers.

• Unlike the Inspection, this does not produce written logs

• Can be predecessors to inspections

Type of Review: Walkthrough

• A formal way of presenting a technical document.

• Often happened in a meeting with some people that do not have technical expertise.

Type of Review: Code Review

• Is a special kind of inspection in which the team examines a sample of code and fixed any defects in it.

• It is important to review the code which is most likely to have defects, such as a portion of software that require the expertise to maintain, or some code that is hard or tricky to implement, or code written by someone who is inexperience, or code of new technique, or code will cause a catastrophic if there are defects...

Type of Review: Pair Programming

• Pair Programming is a technique that involves 2 programmers working simultaneously at a single computer and constantly reviewing each other’s work.

• Ensuring at least 2 programmers are able to maintain any piece of the software.

• One writes code, other watches and advises.

• The PM should not try to force pair programming, but try to introduce it slowly, with the least resistance received.

Week 6 - Requirements

Software Requirements

Are documents that completely describe the behavior that is required of the software before the software is designed built and tested. The requirements analysts build the requirements specifications through requirement elicitation.

• Interviews who involves

• Observe the users

• Compare, verify data gathered from interviews via a Discussion Summary

Discussion Summary

Discussion Summary Outline

1. Project background: a. Purpose of project; b. Scope of project; c. Other background information.

2. Perspectives: a. Who will use the system? b. Who can provide input about the system?

3. Project Objectives: a. Known business rules; b. System information and/or diagrams; c. Assumptions and dependencies; d. Design and implementation constraints.

4. Risks.

5. Known future enhancements.

6. References.

7. Open, unresolved, or TBD issues.

Use Cases

• Is a description of a specific interaction that a user may have with the system.

• Use cases are deceptively simple tools or describing the functionality of the software.
  • Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented.
  • They simply show how the steps that the user follows to use the software to do their work.
  • All of the ways that the users interact with the software can be described in this manner.

Functional Requirements

Define the outward behavior required of the software project. The goal: is to communicate the needed behavior in as clear and unambiguous a manner as possible. Material: lists, bullets, equations, pictures, references to external documents, and any other material that is easy to understand.

Nonfunctional Requirements

Define characteristics of the software which do not change its behavior. About: how good is the software, how quickly, reliable.

Software Requirements Specification - SRS

Represents a complete description of the behavior of the software to be developed. It includes a set of use cases, all functional/non-functional requirements

Requirements vs Scope vs Design

• Scope = the needs of the organization, and is documented in a vision and scope document.

• Requirements = the behavior of the software that will satisfy the needs.

• Design = how those requirements will be implemented.

Change Control

A method for implementing only those changes that are worth pursuing, prevent unnecessary or overly costly changes. It is an agreement between the team and the managers.

A change control board - CCB, is made up of the decision-makers, PM, stakeholders or users, and team members.

Process:

1. Write down the potential benefit of the change

2. If it’s worth, the PM updates the plan with new estimates

3. The CCB will decide to continue with the changes or not.

Week 7 - Design and Programming

Review the Design

• When the SRS has been approved, the implementation begins. Many options: start coding, designs UI, pictures, flowcharts, UML, design specifications...

• Design tasks should always include reviews.

• Any written documentation should be reviewed and inspected if possible.

Version Control

Is a system that allows the programmers to keep track of every revision of all source code files.

There are two kinds: copy-modify-merge (multiple) and lock-modify-unlock (one person can modify any file at a time)

Refactoring

• Is a programming technique in which the design of the software is improved without changing its behavior.

• It can be rewritten code that can be easily read and understood.

• It should happen in the code reviews.

• It can impact the review process.

Unit Testing

Before a build is delivered, the software should be tested via unit tests to verify each unit functions work properly.

Programmers create suites of unit tests, which can be a small block of code containing a specific challenge.

Most people use a framework as its convenience: auto and reports.

Everyone is responsible for the quality

Many kinds of testing for many kinds of purposes.

• Programmers - unit tests - verify if the program works properly.

• Software testers - unit tests - verify that if the software meets the requirements in the SRS, needs of users, stakeholders in the Vision and Scope document.

Many programmers are confused about what exactly the testers do, then the PM should help to clarify for them.

Project Automation

Many quality problems happen because the team is inconsistent in the way of building the software or tracking the health of the code. Automation can reduce these errors: a version control, run unit tests, reviews tool.

Week 8 - Software Testing

Quality

Quality means “conformance to requirements”

• The best testers can not find all defects.

• Testing does not make the software perfect.

• It's hard to meet the needs of a team that does not have good requirements for engineering practices.

Test Plans

Is to establish the list of tasks that, if performed, will identify all of the requirements that have not been met in the software.

• The test plan: as a summary of the test activities.

• Shows how the tests will be organized

• Should be inspected by members of the engineering team and senior managers.

Test Cases

Is a description of a specific interaction that a tester will have in order to test a single behavior of the software. Test cases are very similar to use cases, in that they are step-by-step narratives that define a specific interaction between the user and the software.

A typical test case includes:

• A unique name and number.

• A requirement in which test case is exercising.

• Preconditions, the state before the testing.

• Steps.

• Expected results.

Test cases must be repeatable.

Test Execution

Happen: after the alpha build is delivered, or when the programmers think the build is complete.

Alpha build: should be of high quality, ready for release.

There are many iterations:

1. Focus on new functionality

2. Focus on the changes

3. Test again all the test cases.

4. At least 2 loops of regression tests.

Defect Tracking

Is a program that testers use to record and track defects. Everything is recorded and tracked

Smoke Tests

Is a subset of the test cases that is typically representative of the overall test plan. Is to verify a proper deployment or non-invasive changes, or is ready to send to test. But it cannot replace actual functional testing.

Test Automation

Is a practice in which tests employ a software tool to reduce or eliminate repetitive tasks. But it is expensive to build, so consider it thoroughly.

Postmortem Reports

Is an overall account of the team’s exp in building the software, and of the exp of the users/stakeholders in working with the team. This is to highlight the team’s successes and identify any problems which should be fixed in future releases.

Week 9 - How to diagnose and fix a troubled software project

Lack of Leadership

It takes more than a talented and motivated team to make a successful project

Lack of leadership manifests itself in the team member suffering from:

• Tunnel vision

• Over-reliance on gut instincts

• Repeated false starts in the project

The Mid-Course Correction

A change in project priorities throws the team into disarray

This usually comes from a lack of understanding of the scope of the project

When the engineers don't understand the users’ and stakeholders’ needs, they build the wrong software.

The Detached Engineering Team

There is an artificial wall between developers and users.

They simply don't understand each other and throw false assumptions.

Fixing Planning Problem

If lack of leadership ⇒ The Mid-Course Correction and the Detached Engineering Team are the problems.

Then: use the vision and scope document to define the needs, project plan to keep everyone informed, risk plan to keep the plan realistic.

Padded Estimates Generate Distrust

Programmers add extra time to their estimates, because of unknowns, or they have often been late in the past.

Then the PM needs the answer from them for their estimates, and the dev does not have good answers!

Self-Fulfilling Prophecy

The PM under pressure can impose the deadline and unrealistic estimates

Then the team works nights and weekends to meet the deadlines

The PM feels vindicated.

The team eventually gets frustrated and disillusioned.

Fixing Estimation Problems

Padded estimates and the self-fulfilling prophecy are estimation problems

Then: use a repeatable estimation process like Wideband Delphi, writing down assumptions, then be able to handle risks without padding the time

Working Backwards From a Deadline

The PMs approach a non-negotiable deadline for a project by working backward

• Shorten the tasks in the schedule, cut them entirely until everything fits.

• If it's tight, any non-programming activities are cut

Misunderstood Predecessors

The PM doesn't take the time to understand how task depends on others.

Problems are discovered partway through the project.

Delays cascade through the project

Some devs are stuck waiting with nothing to do, while other works overtime

Fixing Scheduling Problems

Working backward and misunderstood predecessors are symptoms of underlying scheduling problems

Then: adopting good planning and estimation practices and creating a project schedule, some techniques as critical path analysis can help.

Problems Are Found Too Late

There are preventable defects in the software that aren't caught until late.

• Misunderstand the need

• Requirements may be missed or incorrect

• The design may be difficult to use or fail to take all of the features into account.

Big, Useless Meetings

The PM who has the big problems before try to avoid falling into the same trap, then he:

• Calls all members who could possibly have input

• The meeting then drags on for hours, without making any real progress.

• Eventually, everyone gives up and goes back to the way they did things before.

The Indispensable “Hero”

One critical person is seen as the clear top programmer, and all-important work is sent through him.

• He may have a unique skill or exp.

• Sometimes, he hoards all the information, so all tasks that rely on it must go through him.

• Sometimes, he causes bottlenecks for working a very long time.

Fixing Review Problems

Problems are found too late, big and useless meetings and the indispensable hero are problems which can be solved with reviews.

Then: review can catch the defects early, so it’s cheap to fix, a review meeting only includes who actually involved, code reviews can help the hero spread his expertise and knowledge.

Week 10 - Continue

Iteration Abuse

Iteration can be a useful tool, but it is often abused.

The programmer uses it as a guessing game: programmers deliver build after build with small different changes, the devs like it because they can dive in, users and stakeholders like it because they don't have to read documents or think about their needs.

Scope Creep

After the programming has started, users and stakeholders make changes. Each change is easy to describe and sounds small, then eventually the project slows to a crawl. It could be faster if the devs know what to do in the beginning.

Fixing Requirements Problems

The Iteration Abuse and Scope Creep are problems of having insufficient and specified requirements.

Then: the team can adopt software requirements engineering practices to write done most of the changes before doing, and/or to use a change control process.

Haunted by Ghosts of Old Problems

Devs find that old bugs suddenly reappear without warning, because of the growing code - hard to keep under control, or problem with shared folders.

Broken Builds

The devs deliver a build that does not work - the testers then cannot do anything.

The devs get frustrated because they feel that they put a lot of effort in. And they blame the QA.

Spaghetti Code

Maintaining old code is a boring and tedious job in many organizations. Spaghetti code is often used as an excuse to do an unnecessary rewrite.

Fixing Programming Problems

The three problems above are results of bad programming habits.

Then: adopt good habits instead, get control over the versions and subversions, use unit tests and test-driven development to increase the quality of the build, use refactoring.

Requirements Haven’t Been Implemented

The team delivers the software missing behavior or entire features.

• Software is complex, and even with good review practices, it’s difficult for programmers to fully implement everything.

• Missing requirements are difficult to spot.

Obvious Bugs Slipped Through

Inexperienced testers are expected to just bang on the software.

Technical support staff, junior devs, end-users, outside temps, and salespeople are drafted as testers.

Even when experienced testers are used, they’re not given time to plan.

Decisions about release readiness are made based on the schedule rather than quality.

“But It Worked For Us!”

When a product is not tested in all environments in which it will be used, the tests will be thrown off.

Defects are missed when testers can’t adequately replicate the environment in which the software will be used.

Test data may not resemble actual production data

Fixing Testing Problems

If the code is delivered with too few requirements implemented and too many bugs included, the team needs better testing practices.

Then: software testers must be involved in every stage of development, test planning must be given adequate time on the schedule, sufficient budget must be provided for a testing environment.

Common Problems Can Be Avoided!

• Almost everyone has experienced at least a few of these problems.

• We know what causes them, and we have tools, techniques, and practices that can fix them

• All it takes is good project management and should software engineering... and any project team can do it.

Week 11 - Understanding Change

Why Change Fails

The short answer: politics

• Many project problems are bigger than just your project.

• You have to make changes to the way people in your organization work.

• Your ideas on how to improve work is done will not always be evaluated rationally.

Change is Uncomfortable

• Nobody likes to think they make mistakes.

• Making changes means talking about past mistakes = admitting that they are mistakes!

• You may make a great case for change and still fail to convince people to do it.

Common Excuses

• Because change is uncomfortable, people in organizations will resist it.

• PMs who try to change their organizations run into several common excuses when trying to implement tools, techniques, and practices.

• “This is just the way software projects always go.” They always know the problems are there, but they think that no one could do better.
  • If you bring up past failures, you are trying to blame people.
  • This leads to an environment where it's not possible to admit that projects go wrong.

• “Not invented here” Syndrome
  • People intentionally avoid research or innovations that were not developed within the organization.
  • The idea that we’re different leads to immediate resistance to outside ideas.
  • In some small organizations, it's even worse: “Our quirks mean we’re better”.

• “Too Theoretical!”
  • When ideas don't make intuitive sense, they are dismissed as merely academic.
  • Many hands-on managers must personally see a practice in place before they will accept its value.
  • Especially common in small teams facing growing pains.

• Just adds more bureaucracy
  • Any work other than programming is wasteful busywork that keeps the real work from getting done.
  • Planning the project, writing done requirements, and holding inspection meetings are seen as just pushing paper around.

• “You can’t give me more work!”
  • Asking someone to review a document or make an estimate is asking them to do more work.
  • When you change the way other people work, they may just say no. For no good reason.
  • If they have more power than you, they may getaway.

• “It’s Too Risky!”
  • A manager who backs a change puts his reputation on the line.
  • So it’s safer to let a project fail in a way it’s failed before than to make a change that might not work.

How to Make Change Succeed

Progress comes from making smart changes

Understand how people in your organization think about and react to changes, then prepare your organization, sell your change, account for common excuses in your pitch.

1. Prepare Your Organization

• “We’ve always done it like this”

• Be positive about the work that’s already being done

• Take credit for changes.

• Make changes seem straightforward

• Build support from the team

• Show that the changes will save time and effort

• Workaround stragglers.

• Stick to the facts

2. Plan for Change

Create a vision and scope document: similar to the old one, except it describes the scope of the change, inspect and approve the document to build consensus, add the changes to the schedule.

3. Push for Consensus

Get the project team members on board first, cause the managers are more likely to approve a change if the entire team is behind it.

Help people recognize the problem, they show that you have a solution.

Organizations do not change overnight.

Why Change Fails

The short answer: politics

• Many project problems are bigger than just your project.

• You have to make changes to the way people in your organization work.

• Your ideas on how to improve work is done will not always be evaluated rationally.

Change is Uncomfortable

• Nobody likes to think they make mistakes.

• Making changes means talking about past mistakes = admitting that they are mistakes!

• You may make a great case for change and still fail to convince people to do it.

Common Excuses

• Because change is uncomfortable, people in organizations will resist it.

• PMs who try to change their organizations run into several common excuses when trying to implement tools, techniques, and practices.

• “This is just the way software projects always go.” They always know the problems are there, but they think that no one could do better.
  • If you bring up past failures, you are trying to blame people.
  • This leads to an environment where it's not possible to admit that projects go wrong.

• “Not invented here” Syndrome
  • People intentionally avoid research or innovations that were not developed within the organization.
  • The idea that we’re different leads to immediate resistance to outside ideas.
  • In some small organizations, it's even worse: “Our quirks mean we’re better”.

• “Too Theoretical!”
  • When ideas don't make intuitive sense, they are dismissed as merely academic.
  • Many hands-on managers must personally see a practice in place before they will accept its value.
  • Especially common in small teams facing growing pains.

• Just adds more bureaucracy
  • Any work other than programming is wasteful busywork that keeps the real work from getting done.
  • Planning the project, writing done requirements, and holding inspection meetings are seen as just pushing paper around.

• “You can’t give me more work!”
  • Asking someone to review a document or make an estimate is asking them to do more work.
  • When you change the way other people work, they may just say no. For no good reason.
  • If they have more power than you, they may getaway.

• “It’s Too Risky!”
  • A manager who backs a change puts his reputation on the line.
  • So it’s safer to let a project fail in a way it’s failed before than to make a change that might not work.

How to Make Change Succeed

Progress comes from making smart changes

Understand how people in your organization think about and react to changes, then prepare your organization, sell your change, account for common excuses in your pitch.

1. Prepare Your Organization

• “We’ve always done it like this”

• Be positive about the work that’s already being done

• Take credit for changes.

• Make changes seem straightforward

• Build support from the team

• Show that the changes will save time and effort

• Workaround stragglers.

• Stick to the facts

2. Plan for Change

Create a vision and scope document: similar to the old one, except it describes the scope of the change, inspect and approve the document to build consensus, add the changes to the schedule.

3. Push for Consensus

Get the project team members on board first, cause the managers are more likely to approve a change if the entire team is behind it.

Help people recognize the problem, they show that you have a solution.

Organizations do not change overnight.

Week 12 - Management And Leadership

Responsibility, authority, and accountability

• A person has responsibility for a task if he is given sufficient authority to perform it and he is accountable for its completion.

• A person has the authority to perform a task only if he has adequate control over the resources necessary to complete the task.

• A person is accountable for a task if failure to adequately perform that task carries professional consequences.

Delegation

• Is assigning the responsibility of a task to a team member.

• When delegating a task, a PM must ensure that the team member has the authority to perform it and is accountable for the results.

Transparency

• When the PM creates a document, holds a meeting of interest to others, or makes an important project decision, all of the information produced should be shared and used with everyone involved in the project.

• All work products should be public: all should have access to everyone's work product produced for the project, the PM and the team then benefit because they make more informed decisions, and others are always kept informed.

• Decisions should be made based on known guidelines: published standards documents can help others understand the way certain roles must be filled, it should be based on templates, process documents ensure that each project is done using a repeatable process, performance plans set expectations for each.

Manage the Organization

• Prevent senior managers - SM from seeing software projects as a cost burden. A project is successful if it is worth it when compares to its costs. Establishing a track record of successful projects is the okay way for a PM to reverse dangerous attitudes in senior management.

• Show SM the impact of their decisions: often based on gut feelings instead of objective analysis, the decisions maker must understand the details, show SM that improving project management practices will help them meet their goals.

• Don’t confuse flexibility with always saying yes: don’t agree to an unrealistic schedule, change your approach when necessary, don’t confuse “easy to describe” with “to implement”.

Manage Your Team

• Avoid common management pitfalls: don’t manage from your gut, don't second-guess estimates, don’t expect consensus all of the time, make your mistakes public, accept criticism.

• Avoid micromanagement: don’t expect to review anything, don’t fall into the “hands-on manager” trap, use transparency to your advantage, don’t be afraid to let your team members make mistakes.

• Address performance problems early: develop a performance plan, set standards that are fair and attainable, make sure each team member’s progress against known and agreed-upon goals, correct performance problems as early as possible.

Week 13 - Managing an Outsourced Project

Prevent Project Failure

• Don’t be a hands-off client

• Constantly communicate project goals: the vendor’s goals always differ from the clients, don’t expect the team to ignore the vendor’s goals, work with the team to establish the goals of the project as an equal or greater priority.

• Transparency is especially important in an outsourced project

Estimate the Work

Vendors often estimate the work as part of contract negotiation: this happens before the team is assigned, when the team is assembled, it may be necessary to re-estimate the work, unrealistic estimates cause the project to fail.

Actively Manage the Project

A hands-off PM is usually surprised when the software is delivered, and it’s never a pleasant one.

It’s not enough to just have weekly status meetings with no follow-up: the PMs must know the team well.

The Vendor’s Management

Build a relationship with the vendors’ management

• If they don't support the PM’s goals or trust their decisions, the project is likely to fail.

• Don’t allow the vendor’s escalation process to interfere with the project.

• Make sure the management at the vendor recognizes and rewards good work.

The Project Team

Build the relationship with the team

• A PM doesn’t have the same kind of relationship with the team that he would with a team in his own organization.

• The PM isn’t always right and the team does not report to him.

• Gain credibility by making good decisions.

Collaborate With The Vendor

Plan and manage the project scope:

• Starts with the scope and a budget >< known resources (inhouse project)

• Plan for knowledge transfer.

• Recognize that success for the PM and success for the vendor are often 2 different things.

Maintain Tracking and Oversight

Don’t depend on the vendor to maintain the project plan and project schedule → It must be a PM.

Hold reviews and inspections: use a collaborative inspection process that has been optimized for outsourced projects.

Design and Programming

Don’t delegate the entire design and programming of the project to the vendor.

• Establish design constraints early on.

• If possible, design the software in-house or in collaboration with the vendor.

• Monitor the codebase using code reviews and project automation.

Software Quality

Take responsibility for the quality of the software

• Quality is not just another deliverable that can be bought and paid for.

• Don’t make decisions that undercut the QA team.

• Ensure that adequate time and budget are allocated for test planning and execution.

Don’t Blindly Trust the Vendor

• Even though individual team members may have certifications or degrees, it doesn’t mean that they are competent.

• The vendor’s organization is certified doesn’t guarantee that they know better than you do how to run your project.

• Don’t be intimidated by the vendor’s pedigree. If something is wrong, it is!

Week 14 - Process Improvement

Life Without a Formal Process

Many process improvement - PI, experts see the world as black and white

• They often feel that there are bad software teams without a formal process and vice versa.

• But the world is not that simple

Teams can be effective without a formal software process.

• There can be a team with all multi-field knowledge programmers who know all about the business

• “Skunkworks” programmers may often take initiative and build useful software without input.

• A highly capable development manager may be willing to put in an enormous effort.

An organization that produces software always has a software process

• It’s just not formal or documented, and repeatable.

• Without a formal process, the team can also be happy and productive when they can point to their successes!

• Except when their projects fail.

A team without a formal process does not scale up easily

• Start to feel that the software is bogged down when more and more code is added.

• Often happen when a small team project faces having to build a big project.

• Also when a team expands.

If there are no complaints about the way the team is building software, then there’s no reason to change!

Expanding the team is not the only place a formal process is useful: also helps where the experts, users, stakeholders... are no longer readily available to the programmers.

Software Process Improvement

• Is the art and science of changing an organization’s software process in order to build better software.

• Always involves looking at the big picture: identifying areas that can be improved.

Frameworks and Methodologies

• Models and certs that help assess the state of the organization’s process and serve as a framework for improving that process. (EX: CMM, ISO 9000, Six Sigma)

• Methodologies can help describe the complete set of activities, roles, and work products needed to build the software. (EX: Rational Unified Process, Extreme Programming)

Capability Maturity Model

Defines the characteristics of a mature, capable process in a way that can be measured and compared to processes at other organization

• Includes: areas of improvement, goals, specific practices.

• A software engineering process group within the organization identifies problems and inefficiencies and defines practices to address them

• Independent assessors verify that an organization is in compliance with CMM practices.

ISO 9000

Is a family of quality management standards defined by the International Standards Organization. It is based on core principles:

• Org must focus on their customers by understanding current and future needs.

• Leaders within the org must create and maintain an env in which people can become involved and fulfill the org’s objectives.

• People at all levels are important

• Activities and Resources are best managed as a process.

• Orgs have many interrelated processes, which must be understood and managed as a system.

• The Org should continually improve its performance.

• Decisions should be well informed and based on real data and information.

• An org and its supplies are mutually beneficial.

Six Sigma

Is an approach to improving quality in manufacturing and business processes, Six Sigma means “six standard deviations from the mean”

DMAIC is a 5-phases approach to Six Sigma improvement: Define opportunities, Measure performance, Analyze opportunity, Improve performance, Control performance.

Extreme Programming

Consists of a set of rules and practices that govern all areas of software development: planning, designing, coding, testing.

Goals: is to lower the cost of change, may need iterations.

Is a disciplined and well-defined process by making the stakeholders part of the team, XP addresses the problem of the hands-off customer.

Rational Unified Process

RUP Is a popular off-the-shelf process based on the idea of highly iterative development.

Includes a disciplined approach to requirements management that is based on the idea of managing changes. (Using UML, visual modeling system)

One of the core elements is the continuous assessment of the quality of the system