Applied Software Project Management - Week 1 Notes

Module Descriptor

  • The aim of this module is to equip students with the knowledge and skills to manage software projects, both individually and in teams.

Module Learning Outcomes

  • MLO1: Demonstrate an understanding of software project management fundamentals.
  • MLO2: Create project plans and schedules using graphical tools.
  • MLO3: Apply project estimation and measurement skills.
  • MLO4: Assess project risks and apply risk management techniques in software development.
  • MLO5: Track software project progress using monitoring and control techniques.
  • MLO6: Demonstrate understanding of the importance of people factors in software development.

General Information

  • 5 credits.
  • Consists of 2-hour lectures and 1-hour practical/tutorial sessions.

Continuous Assessment

  • CA1: Written Assignment, due March 14th (W8).
  • CA2: Group Project, due May 2nd (W13).
  • 50% of the final grade is based on continuous assessment.
  • 50% of the final grade is based on the final exam.

Lecture Outline

  • What is software project management?
  • How do you know when a project has been successful?

Why is Project Management Important?

  • Large amounts of money are spent on IT.
    • In 2003-4, the UK government spent £2.3 billion on ICT contracts, versus £1.4 billion on road building.
    • England's public spending on IT was £5.8 billion ($7 billion) in 2017/18.
    • Increased to £17.3 billion ($21 billion) in 2023.

UK Project Management Examples

  • Department for Science, Innovation and Technology (DSIT) Expenditures:
    • Monthly expenditures over £25,000 throughout 2023.
    • Provide insights into significant investments in technology and related services.
  • Budget Commitments:
    • The government pledged up to £3.5 billion to support its ambitions of establishing the UK as a scientific and technological superpower.
  • Artificial Intelligence (AI) and Computing Investments:
    • The 2023 budget included a £900 million allocation for computing power and AI research.
  • NHS Digital Transformation:
    • The National Health Service (NHS) continued its digital transformation efforts, including the procurement process for a Federated Data Platform (FDP) in 2023.
    • The contract for the FDP was valued at up to £480 million.

Project Failure Rates

  • Standish Group claims only a third of IT projects are successful.
    • 82% were late.
    • 43% exceeded their budget.
  • Gartner: the failure rate of IT projects of €1m plus is 50% higher than projects with budgets below $350K.
  • Larger projects fail more often and deliver less.
  • Half of projects with a budget greater than $15m run 45% over budget, 7% behind schedule, and deliver 56% less functionality.

Reasons for Project Failure

  • Poor Project Management
  • Gartner suggests sufficient planning and risk recognition at the outset will help significantly on projects of all sizes.
  • Defining scope is critical.
  • BT Ireland cites the following as key reasons for poor outcomes for users:
    • Failure to define scope.
    • Underestimated timescales (with no contingency).
    • Poor governance and communications.
    • Poor risk management and change management.

Project Management Failure Example

  • PPARS Project:
    • Original budget in 1995 – €8.8m.
    • Use suspended in 2012 – spend over Euro €200m.
    • Still only 1 of 8 Payroll systems in use in the HSE.
    • Scrapped in 2013.
    • A major report on PPARS in 2005 found a failure to properly define business requirements prior to the system going live.

Defining 'Project'

  • “A specific plan or design”.
  • “A planned undertaking”.
  • “A large undertaking – for example, a public works scheme”.
  • Longmans dictionary.
  • ‘Unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements, including constraints of time, cost and resources’.
  • BSO ISO 10006: 1997*
  • Key points to note above are planning and size of task.

Jobs vs. Projects

  • ‘Jobs’ – repetition of very well-defined and well-understood tasks with very little uncertainty.
  • ‘Exploration’ – for example, finding a cure for cancer: the outcome is very uncertain.
  • Projects – in the middle!

Characteristics of Projects

  • Repetitive jobs:
    • A similar task is carried out repeatedly.
    • For example, Kwikfit replacing a tire on a car or a lecturer giving an introductory talk on project management.
    • The task is well-defined and there is very little uncertainty.
    • In some organizations, software development might tend to be like this – in these environments, software process management might be more important than software project management.
  • Exploratory activities:
    • Some research projects can be like this – we may not be sure what the outcome will be, but we hope that we will learn some things of importance.
    • It may be very difficult to produce precise plans, although we would probably have some idea of a general approach.
  • Projects seem to come somewhere between these two extremes.
    • There are usually well-defined hoped-for outcomes but there are risks and uncertainties about achieving those outcomes.

Project-like Tasks

  • A task is more ‘project-like’ if it is:
    • Non-routine
    • Planned
    • Aiming at a specific target
    • Carried out for a customer
    • Carried out by a temporary work group
    • Involving several specialisms
    • Made up of several different phases
    • Constrained by time and resources
    • Large and/or complex

Examples of Projects

  • Producing an edition of a newspaper.
  • Putting a robot vehicle on Mars.
  • Getting married.
  • Amending an IT system to deal with issues arising from Brexit.
  • A second-year programming assignment for a computing student.
  • Researching what makes a good human-computer interface.
  • Investigating why a user is having a problem with a game (prototype).
  • Writing an operating system for a new computer.
  • Installing a new version of word processing package in an organization.

Software Projects vs. Other Projects

  • Are they different? Not really, but…
    • Invisibility: when a physical artifact such as a bridge is constructed the progress can be seen. With software, progress is not immediately visible.
    • Complexity: per dollar, pound, or euro spent, software products contain more complexity than other engineered artifacts.
    • Conformity: software developers must conform to the requirements of the human clients.
    • Flexibility: it is expected that the software will change to accommodate the other components rather than vice versa. Thus, software systems are particularly subject to change.
  • (Brooks, 1987)
  • However, it is the combination of Invisibility, Complexity, Conformity, and Flexibility that makes software more problematic to build than other engineered artifacts. (Brooks, 1987)

Contract Management vs. Technical Project Management

  • Projects can be:
    • In-house: clients and developers are employed by the same organization.
    • Out-sourced: clients and developers employed by different organizations.
    • ‘Project manager’ could be:
      • a ‘contract manager’ in the client organization.
      • a technical project manager in the supplier/services organization.

Activities Covered by Project Management

  • Feasibility study:
    • Is project technically feasible and worthwhile from a business point of view?
    • Feasibility study may need its own plan.
  • Planning:
    • Only done if the project is feasible.
  • Execution:
    • Implement plan, but plan may be changed as we go along.
    • An evolving plan allows us to control the project.

Software Development Life-Cycle (SDLC) ISO 12207

  • First introduced in 1995, it aims to be a primary standard that defines all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.
  • The Software Development Life Cycle:
    • Is a technical model.
    • Identifies the technical constraints on the order activities are done.
    • This does NOT imply that a ‘waterfall’ approach is the only way to organize projects.
    • The technical model could be implemented as increments or in an evolutionary manner.

ISO 12207 Life -Cycle: System

  • System Requirements v Software Requirements:
    • For example, a system must respond within 1 second.
    • Transaction time will be part of system requirements.
    • What the transaction does is part of the software requirements.
  • The system architecture design is an input to the software requirements analysis.
    • For example, some existing system components might be kept as is.
  • Later architecture design maps software requirements to software components.

ISO 12207 Life-Cycle: System

  • Requirements analysis:
    • Requirements elicitation: what does the client need?
    • Analysis: converting ‘customer-facing’ requirements into equivalents that developers can understand.
    • Requirements will cover:
      • Functions
      • Quality
      • Resource constraints (i.e. costs)
  • The key point here is that requirement analysis must face in (at least) two different directions.
    • It needs to communicate and elicit the requirements of the users, speaking in their language.
    • It needs to organize and translate those requirements into a form that developers can understand and relate to.

ISO 12207 Life-Cycle: Design

  • Architecture design:
    • Based on system requirements.
    • Defines components of system: hardware, software, organizational.
    • Software requirements will come out of this.

ISO 12207 Life-Cycle

  • The software project will almost certainly be part of a larger project which has non-software elements.
    • In a software engineering environment, it could be the software will be embedded in a hardware product of some kind.
    • Thus, there are system requirements for the product as a whole and software requirements for the software element.
  • In a business information systems environment, the software development could be a relatively minor part of a much larger organizational change project.

ISO 12207 Life-Cycle: Code & Test (Software & System)

  • Detailed design:
    • Each software component is made up of several software units.
  • Code and test:
    • Of individual components.
  • Integration:
    • Putting the components together.
  • Qualification testing:
    • Testing the system (not just the software).

ISO 12207 Life-Cycle: Code & Test (System)

  • Installation:
    • The process of making the system operational.
    • Includes setting up standing data, setting system parameters, installing on operational hardware platforms, user training etc.
  • Acceptance support:
    • Including maintenance and enhancement.

Plans, Methods, and Methodologies

  • A plan of an activity must be based on some idea of a method of work.
  • While a method relates to a type of activity in general, a plan takes one or more methods and converts them into real activities by identifying:
    • Start and end dates.
    • Who will carry it out.
    • What tools and materials would be needed.
  • A methodology is a set of related methods.
    • Strictly speaking 'methodology' ought to mean the study of methods!

Categorizing Projects

  • Distinguishing between different types of projects is important as different types of task need different project approaches. For example,
    • Voluntary systems (such as computer games) versus compulsory systems (the order processing system in an organization).
    • Information systems versus embedded systems.
    • Objective-based versus product-based.
    • Information Systems projects tend to be more objectives-based.
      • For example, a SAP or Oracle ERP implementation (Enterprise Resource Planning - a large software package impacting on multiple business units, finance, manufacturing, supply chain).
    • Software Engineering on the other hand tends to produce products.
      • For example, a website, an app, a new game etc.
  • With objective-based projects, a general objective or problem is defined, and there are several different ways in which that objective could be reached.
    • The project team has the freedom to select what appears to be the most appropriate approach.
  • With product-based projects, the product is already very strictly defined, and the team must implement the specification with which they have been presented.
  • Arguably, information systems projects are more likely to be objective-based than is the case with software engineering.
  • In many cases, an objective-based project could consider a problem and recommend a solution that is then implemented by a product-based project.

Stakeholders

  • These are people who have a stake or interest in the project.
    • In general, they could be users/clients or developers/implementers.
  • They could be:
    • Within the project team.
    • Outside the project team, but within the same organization.
    • Outside both the project team and the organization.
  • Different stakeholders may have different objectives – need to define common project objectives.
    • Each stakeholder will have their own goals and concerns in relation to the project which may be different from those of the project.
      • For example, a software developer might work to make a living, pay the mortgage, learn new things, solve interesting problems.
    • The main stakeholders need, however, to understand and accept overall project objectives that everyone can agree to.

Setting Objectives

  • Answering the question ‘What do we have to do to have a success?’
  • Need for a project authority.
    • Sets the project scope.
    • Allocates/approves costs.
    • Could be one person - or a group.
      • Project Board.
      • Project Management Board.
      • Steering Committee.
  • Different stakeholders will have different interests in the project and are likely to see different outcomes as being important.
    • For example, end-users would want a system that is ‘user-friendly’, that is, easy to learn and to use, and a system that helps rather than hinders them from doing their jobs. Their managers may be more interested in whether the new system would allow them to reduce staffing levels.
  • It is important therefore that a set of clearly defined objectives are identified and published for the project.
    • Some individual or group needs to be pinpointed who acts as the main client for the project.
  • Informally, the objective of a project can be defined by completing the statement:
    • The project will be regarded as a success if…
  • Rather like post-conditions for the project.
    • Focus on what will be put in place, rather than how activities will be carried out.
    • Or what the situation will be when the project is completed.
  • The objectives should avoid describing activities:
    • For example, ‘a new payroll application will be operational by 4th April’ not ‘design and code a new payroll application’.
    • Focus on the ways the world will be different when the project is complete.

SMART Objectives

  • Specific: State what you'll do - Use action words
  • Measurable: Provide a way to evaluate - Use metrics or data targets
  • Achievable: Within your scope - Possible to accomplish, attainable
  • Relevant: Makes sense within your job function - Improves the business in some way
  • Time-bound: State when you'll get it done - Be specific on date or timeframe

Goals/Sub-Objectives

  • These are steps along the way to achieving the objective.
  • Informally, these can be defined by completing the sentence:
    • To reach objective X, the following must be in place:
      • A……………
      • B……………
      • C……………
  • Scoring a goal in football is a ‘goal’ or sub-objective on the way to achieving the overall objective of winning the match.
    • Sub-objectives and objectives can be nested in a hierarchy, so that the objective of winning the match could itself be a goal or sub-objective on the way to winning the league etc.
  • Often, a goal can be allocated to an individual.
    • The individual might have the capability of achieving the goal on their own, but not the overall objective. For example:
      • Overall Objective – user satisfaction with software product.
      • Analyst Goal – accurate requirements.
      • Developer Goal – reliable software.
  • Goals can represent what an individual or group needs to do to contribute to the success of the project’s objectives.
    • For example, the analyst or developer, by themselves, cannot guarantee user satisfaction; however, the analyst can contribute to the achievement of the objective by making sure the users’ requirements are accurately recorded, and the developer by making sure that the software is reliable.

Measures of Effectiveness

  • How do we know that the goal or objective has been achieved?
  • By a practical test, that can be objectively assessed.
    • For example, for user satisfaction with software product:
      • Repeat business – they buy further products from us.
      • Number of complaints – if low…

The Business Case

  • Benefits of delivered project must outweigh costs.
  • Costs include:
    • Development
    • Operation
  • Benefits:
    • Quantifiable
    • Non-Quantifiable

Project Success / Failure

  • Degree to which objectives are met.
  • In general, if, for example, the project is running out of time, this can be recovered by reducing scope or increasing costs.
    • Similarly, costs and scope can be protected by adjusting other corners of the ‘project triangle’.

Other Success Criteria

  • These can relate to longer-term, less directly tangible assets:
    • Improved skill and knowledge.
    • Creation of assets that can be used on future projects.
      • For example, software libraries.
    • Improved customer relationships that lead to repeat business.

What is Management?

  • This involves the following activities:
    • Planning – deciding what is to be done.
    • Organizing – making arrangements.
    • Staffing – selecting the right people for the job.
    • Directing – giving instructions.
    • Monitoring – checking on progress.
    • Controlling – taking action to remedy hold-ups.
    • Innovating – coming up with solutions when problems emerge.
    • Representing – liaising with clients, users, developers, and other stakeholders (Ince et al., 1993).

Management Control

  • Data – the raw details.
    • For example, ‘6,000 documents processed at location X’.
  • Information – the data is processed to produce something that is meaningful and useful.
    • For example, ‘productivity is 100 documents a day’.
  • Comparison with objectives/goals
    • For example, we will not meet the target of processing all documents by 31st March.
  • Modelling – working out the probable outcomes of various decisions.
    • For example, if we employ two more staff at location X how quickly can we get the documents processed?
  • Implementation – carrying out the remedial actions that have been decided upon.

Key Points

  • Projects are non-routine – thus, uncertain.
  • There are specific problems associated with software projects.
  • Clear objectives which can be objectively assessed are essential.
  • Stuff happens. Not usually possible to keep precisely to plan – need for control.
  • Communicate, communicate, communicate!