Why do software projects fail?

  • People begin programming before they understand the problem
    • Everyone likes to feel that they’re making progress
    • When the team starts to code as soon as the project begins, they see immediate gains
    • When problems become more complex (as they always do!), the work gets bogged down or slowed down
    • In the best case, a team that begins programming too soon will end up writing good software that solves the wrong problem
  • The team has an unrealistic idea about how much work is involved.
    • From far away, most complex problems seem simple to solve
    • Teams can commit to impossible deadlines by being overly optimistic and not thinking through the work
    • Few people realize the deadline is optimistic until it’s blown or drive or carry
  • Defects are injected early but discovered late.
    • Projects can address the wrong needs
    • Requirements can specify incorrect behavior
    • Design, architecture and code can be technically flawed or faulty
    • Test plans can miss functionality
    • The later these problems are found, the more likely they are to cause the project to fail
  • Programmers have poor habits – and they don’t feel accountable for their work.
    • Programmers don’t have good control of their source code
    • Code written by one person is often difficult for another person to understand
    • Programmers don’t test their code, which makes diagnosing and fixing bugs more expensive
    • The team does not have a good sense of the overall health of the project.
  • Managers try to test quality into the software.
    • Everyone assumes that the testers will catch all of the defects that were injected throughout the project.
    • When testers look for defects, managers tell them they are wasting time.
    • When testers find defects, programmers are antagonized because they feel that they are being personally criticized.
    • When testers miss defects, everyone blames them for not being perfect.

How can we make sure that our projects succeed?

  • Make sure all decisions are based on openly shared information
    • It’s important to create a culture of transparency, where everyone who needs information knows where to find it and is comfortable looking at it.
    • All project documents, schedules, estimates, plans and other work products should be shared with the entire team, managers, stakeholders, users and anyone else in the organization who wants them.
    • Major decisions that are made about the project should be well-supported and explained.
  • Don’t second-guess your team members’ expertise
    • Managers need to trust team members.
    • Just because a manager has responsibility for a project’s success, it doesn’t mean that he’s more qualified to make decisions than the team members.
    • If you don’t have a good reason to veto an idea, don’t.
  • Introduce software quality from the very beginning of the project
    • Review everything, test everything.
    • Use reviews to find defects – but don’t expect the review to be perfect.
    • Use reviews to gain a real commitment from the team.
    • It’s always faster in the long run to hold a review than it is to skip it.
  • Don’t impose an artificial hierarchy on the project team
    • All software engineers were created equal.
    • A manager should not assume that programming is more difficult or technical than design, testing or requirements engineering.
    • Managers should definitely not assume that the programmer is always right, or the tester is always raising false alarms.
  • Remember that the fastest way through the project is to use good engineering practices
    • Managers and teams often want to cut important tasks – especially estimation, reviews, requirements gathering and testing.
    • If it were faster to build the software without these practices, we would never use them.
    • Every one of these practices is about saving time and increasing quality by planning well and finding defects early. Cutting them out will cost time and reduce quality.

Who needs software?

  • Most software is built in organizations for people with specific needs.
    • A stakeholder is a anyone who has an interest (or stake) in the software being completed
    • A user is someone who will need to use the software to perform tasks.
    • Sometimes stakeholders will be users; but often the stakeholder will not use the software.
      • For example, a senior manager (like a CEO or CTO in a company) will usually have a stake in the software that is built (since it affects the bottom line), even if she won’t ever use it.

Who builds software?

  • Software is typically built by a team of software engineers, which includes:
    • Business analysts or requirements analysts who talk to users and stakeholders, plan the behavior of software and write software requirements
    • Designers and architects who plan the technical solution
    • Programmers who write the code
    • Testers who verify that the software meets its requirements and behaves as expected

Project Management

  • The project manager plans and guides the software project
    • The project manager is responsible for identifying the users and stakeholders and determining their needs
    • The project manager coordinates the team, ensuring that each task has an appropriate software engineer assigned and that each engineer has sufficient knowledge to perform it
    • To do this well, the project manager must be familiar with every aspect of software engineering

Identifying Needs

  • The project manager drives the scope of the project.
    • The project manager should identify and talk to the main stakeholder
    • The effective way to show stakeholders that their needs are understood and that those specific needs will be addressed is with a vision and scope document

Vision and Scope Document

  • A typical vision and scope document follows an outline like this one:
    • 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

  • The project plan defines the work that will be done on the project and who will do it. It consists of:
    • A statement of work (SOW) that describes all work products that will be produced and a list of people who will perform that work
    • A resource list that contains a list of all resources that will be needed for the product and their availability
    • A work breakdown structure and a set of estimates
    • A project schedule
    • A risk plan that identifies any risks that might be encountered and indicates how those risks would be handled should they occur

Statement of Work

  • The statement of work (SOW) is a detailed description of all of the work products which will be created over the course of the project. It includes:
    • A list of features that will be developed
    • A description of each intermediate deliverable or work product that will be built.
    • The estimated effort involved for each work product to be delivered

Resource List

  • The project plan should contain a list of all resources that will be used on the project.
    • A resource is a person, hardware, room or anything else that is necessary for the project but limited in its availability
    • The resource list should give each resource a name, a brief one-line description, and list the availability and cost (if applicable) of the resource

Estimates and Project Schedule

  • The project plan should also include estimates and a project schedule:
    • A work breakdown structure (WBS) is defined. This is a list of tasks which, if performed, will generate all of the work products needed to build the software.
    • An estimate of the effort required for each task in the WBS is generated.
    • 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, along with a plan to mitigate some or all of those risks.
    • The project manager selects team members to participate in a risk planning session:
      • The team members brainstorm potential risks
      • The probability and impact of each risk is estimated
      • A risk plan is constructed

Risk Plan

Didn't Find Any Subjects/Contents?

Click on the contribute button to contribute subjects materials on Study Notes Nepal.


Leave a Reply

Your email address will not be published. Required fields are marked *

Join Our Facebook Community Group

Study Notes Nepal