Software Project Management

15.1 Why Software Projects Need to Be Managed

15.1.1 Why Software Projects Must Be Managed

Software project management is an essential part of software engineering. Projects need to be managed because professional software engineering is always subject to various factors, including organizational budget and schedule constraints. The project manager's job is to make sure the project meets and overcomes these constraints while also delivering high-quality software.

One honest warning before anything else: good management cannot guarantee project success. That statement was repeated for a reason — it is the first thing a manager should accept. However, bad management usually results in project failure. When management fails, the software may be delivered late, it may cost more than the originally estimated cost, or it may fail to meet the expectations of the customers in terms of the requirements, features, and services they asked for. None of those outcomes require spectacular incompetence; ordinary bad management is enough.

15.1.2 Success Criteria for a Software Project

The success criteria for project management vary from project to project, but for most projects the important goals are:

1. Deliver the software to the customer at the agreed time. On-time delivery is an important criterion.
2. Keep the overall cost within budget. Time (the schedule) comes first, then cost.
3. Deliver software that meets the customer expectations.
4. Maintain a very coherent and well-functioning development team — this is the people dimension.

These success criteria are not unique to software engineering. They are the goals of all engineering projects of whatever size they may be. A bridge project, a shipbuilding program, and a small internal tool all want the same four things. What makes software different is not the goals but the path to them, which is the next topic.

15.1.3 Student Questions and Answers

Real-world connection. Every large software company — from product firms shipping consumer apps to consultancies building custom systems for banks and governments — runs a formal management structure around its projects for this reason. The stakes are concrete: a late delivery can mean a penalty clause triggered, a contract lost, or a competitor reaching the market first. The four success criteria are the same yardstick used in project reviews, in which senior management asks one question about every project: is it on time, on budget, meeting expectations, and is the team intact?

15.2 Why Software Project Management Is Uniquely Challenging

Software engineering differs from other types of engineering in a number of ways that make software project management particularly challenging. There are three big differences: the product is intangible, projects are often one-off, and software processes are not standardized.

15.2.1 The Intangible Product

The product is intangible. A manager of a shipbuilding or civil engineering project can see the product being developed. If a schedule slips, the effect on the product is visible — parts of the structure are still unfinished. Software cannot be seen or touched. Software project managers cannot see progress by looking at the artifact that is being constructed. Instead, they rely on other people to produce evidence that they can use to review the progress of the work.

15.2.2 One-off Projects and Rapid Technological Change

Large software projects are often one-off projects. Every large software development project is unique because every environment in which software is developed is in some ways different from all others. Even managers with a large body of previous experience may find it difficult to anticipate problems.

On top of that, rapid technological changes in computing and communications technology can make previous experience obsolete. Lessons learned from previous projects may not be readily transferable to new projects, as far as project management is concerned, because each project is unique. A manager who ran three successful client-server projects in the 2000s cannot simply replay that playbook on a cloud-native, microservices project today.

15.2.3 Non-standardized Software Processes

More often than not, software processes are not standardized. They are variable and they are specific to the projects, and most often sometimes to the organizations. The engineering organization here means any organizational unit, including the development team, the business unit, or the organization as a whole.

The engineering process for some types of software systems — say a banking system or an ERP system — might be better understood than some new projects that are based on new technologies. In civil engineering construction, the engineering process for typical systems like bridges and buildings is very well understood. But in software, different companies use different kinds of software development processes and each project varies. We cannot reliably predict when a particular software process is likely to lead to development problems. We saw earlier, when discussing software process improvement, that the goal is to try to remove bottlenecks — but even then, we do not know in advance where they will appear.

This is especially true when the software project is part of a wider systems engineering project, or when completely new software is being developed with no prior experience or knowledge to rely upon.

Because of these issues, it is not surprising that many software projects are late, over budget, and behind schedule. Software systems are sometimes new, very complex, and technically innovative. Given all these difficulties, it is perhaps quite remarkable that so many software projects are delivered on time and to budget.

15.2.4 Student Questions and Answers

Real-world connection. These three differences are why the software industry invented lightweight evidence-generation practices around project management — demos, build-and-test pipelines, dashboards, and definition-of-done checklists. Product companies such as Google and Microsoft and consultancies alike use them precisely because nothing about the software itself is visible, and because each project is unique enough that trust has to be rebuilt with fresh evidence every time.

15.3 Factors That Shape How Software Projects Are Managed

It is impossible to write a standard job description for a project manager. The job description of a software manager varies tremendously, depending on the manager, the software being developed, and other factors. Some of the most important factors that affect how software projects are managed are company size, the customer, software size, software type, organization culture, and the development process.

15.3.1 Company Size

Small companies can operate with informal management and informal team communications. They do not need formal policies and management structures, and they have less management overhead than larger organizations. In larger organizations, by contrast, there are a lot of management hierarchies, various levels of formal reporting, and detailed budgeting and detailed approval processes that must be followed for the software development process. All of that becomes the responsibility of the software project manager.

15.3.2 Customers

Each customer is different. If the customer is an internal customer — as in a software product development company, where the customer may be the marketing department — then customer communications can sometimes be informal. There is no need to fit in with the customer's way of working or adopt their standards.

But if you are developing custom software for an external customer, an agreement has to be signed: more formal communication channels, periodic reporting, and documentation. And if the customer is a government agency, the software company must operate according to the government agency's policies and procedures, which are likely to be quite bureaucratic — heavy documentation and lots of meetings.

15.3.3 Software Size and Software Type

Software size matters. Small systems can be built by small teams that simply get together in the same meeting room, discuss progress and other management issues, and each person does their coding, testing, and system building. For large systems, the project manager has to coordinate the activities of teams across countries and across companies, arrange for them to communicate with each other periodically, and ensure that meetings are productive and lead to progress in the project.

Software type is an important factor too. If the software being developed is a consumer product — like a Google product or a Microsoft product — formal, detailed records of project management decisions are often not kept. On the other hand, if it is a safety-critical system like an automotive control system, all project management decisions must be recorded and justified in detail, because these decisions may affect the safety of the system.

15.3.4 Organization Culture and Development Process

Organization culture depends on whether you are in a small or large company. Some organizations have a culture based on supporting and encouraging individuals; others are small-group-focused. Large organizations are often bureaucratic — you have to deal with various levels of people. Some organizations have a culture of taking risks, whereas some large organizations are risk-averse. You might have an innovative idea you want to try out to provide a solution. It may be risky, and there may be a risk of failure in the project — but still your manager might encourage you to go ahead and do it.

Finally, no software development process is the same as another. Large, plan-driven, bureaucratic processes require management monitoring to ensure that the development team is following the defined process, often in order to achieve software process improvement. Agile processes typically operate with very lightweight management and overhead.

15.3.5 Student Questions and Answers

Real-world connection. These factors explain real industry differences: a product startup (small company, internal customer, consumer software, risk-tolerant culture) runs on lightweight agile management, while a systems integrator building a government railway control system (large company, bureaucratic customer, safety-critical software) runs a heavily documented, plan-driven operation. A project manager moving between these worlds changes management style completely — the six factors are the reason.

15.4 Universal Project Management Activities

Even though project managers in different organizations work in quite different ways, a number of fundamental project management activities are common to all organizations, no matter how detailed or how informal their approach is. These universal activities include project planning, risk management, people management, reporting, and proposal writing.

15.4.1 Planning, Risk Management, and People Management

Project planning: the project manager is responsible for planning, estimating, and scheduling project development, and assigning people to tasks. The project manager supervises the work to ensure it is carried out to the required standards, and monitors progress to check that development is on time and within budget.

Risk management: project managers have to assess the risks that may affect the project, monitor these risks, and take action when problems arise.

People management: project managers are essentially going to manage the team members — the people. They have to choose people for their team, recruit them, train them, establish ways of working that lead to effective team performance, and ensure those ways of working are being adhered to.

15.4.2 Reporting and Communication

Project managers periodically write reports on various aspects and report to the leadership and senior management on the progress of the project. They have to report to the customers, and they have to report to their managers in the company — the developing organization. They also have to communicate at a range of levels: from detailed technical information to the team, to management summaries for top leadership. They have to write concise, coherent documents and reports that abstract detailed critical information from various project reports, and present this information using graphs and other tools during progress reviews in project meetings.

Invariably, project managers spend much of their time in meetings, either with their team or with their management, because they are responsible for reporting progress to their team and to the management above them.

15.4.3 Proposal Writing and the Bench

Very often, in between projects, a manager will be asked to write a proposal for a new project. Proposal writing may be the first stage of a project: writing a proposal to win a contract to carry out an item of work or development work. The proposal describes the objectives of the project and how it will be carried out. It usually includes cost estimates and schedule estimates, and justifies why the project contract should be awarded to a particular organization or team. Proposal writing is a critical task because the survival of many companies depends on having enough proposals accepted and contracts awarded.

A related reality of the industry is the bench. If there are not enough projects and there are too many developers and testers in the organization, people are simply put on the bench, which means they have no work. People on the bench may undergo online training or do other things. Being on the bench is very common in the software industry, especially when companies are not getting enough business. It is essentially a paid holiday — nice for some time, but it gets boring, and after six months on the bench you may feel like moving out of the organization to somewhere you get challenging work. Many people in many large organizations are on the bench most of the time, waiting for a project contract to be signed.

None of these manager tasks involve development, coding, and testing — the work you like most.

15.4.4 Career Tracks: Engineer or Manager

There are career tracks for people wanting to go into project management, and career tracks for people who want to remain engineers. As an engineer you may eventually become a chief architect — someone who designs complex systems and manages the technical design and implementation aspects. You may become a technical manager at a higher level, involved in the technical aspects of the system. This is like the chief engineer role in civil engineering, under whom many engineers work — but the chief engineer is still the technical person, not a regular project manager.

Whether to stay in engineering or move into management is one of the important questions in software engineering, and each person's answer may vary depending on their career objectives. Over time, if you acquire an MBA degree after your engineering years, you may want to become a project manager — you have been an engineer for five or ten years, and now you might manage fifty or sixty engineers. A project manager has to manage a thousand tasks at a time, apart from managing people. As you grow up the corporate ladder, other programmers take care of development while you take care of the larger issues of project management, which are not as easy as you think.

15.4.5 Student Questions and Answers

Real-world connection. The bench is a visible, often-cited industry reality: during business downturns, consultancies and product companies alike keep surplus developers on the bench (sometimes on training programs) rather than laying them off immediately, because rehiring skilled engineers is expensive. The two career tracks also map to real corporate ladders — principal engineer and staff engineer titles on the technical side, engineering manager and director on the management side — and many companies explicitly design parallel promotion paths so technical people are not forced into management to grow.

15.5 Risk Management: The Basics

Risk management is one of the most important jobs for a project manager, because risk can be anything.

15.5.1 What Is a Risk?

You may know Murphy's Law: if something can go wrong, it will. Something will suddenly come up: a component has crashed, a service request comes in, a change request arrives that is an emergency, and you have to divert all your resources from development work to fix bugs immediately. Risks are prevalent every time, and you have to plan and manage them.

Think of a risk as something you prefer not to happen. Risks are a reality — they always set on a project, on the software being developed, or on the organization developing the project. Risk management involves anticipating the risks that might affect the project schedule, the quality of the project, or the organization itself, and then taking action to avoid them. There can also be competition risk — risk from competition in the market. These are uncertainties, such as loosely defined requirements and so on.

15.5.2 Project, Product, and Business Risks

There are three types of risks:

• Project risks affect the project schedule or resources. An example is the loss of an experienced system architect who suddenly leaves to another organization. Finding a replacement for an experienced architect with the appropriate skill set and experience may take quite some time, and so it may delay the project significantly. Delay means cost, time, reputation — everything.
• Product risks are related to the quality and performance of the product software being developed. An example is the failure of a purchased component. You take an open source component or a purchased component, and it does not perform as expected. You expected it to have been tested reliably and to work reliably, but this newly integrated component may affect the overall performance of the system — it may become slower, or you may have to debug or fix the problem.
• Business risks affect the organization or business. An example is competition: a competitor may release a similar product first, or the market may change.

15.5.3 Overlapping Risk Categories

The risk categories overlap — there is no clear-cut distinction. Take an experienced engineer's decision to leave a project:

• It presents a major project risk, because the software delivery schedule will be significantly affected. It inevitably takes time for a new project member to be trained and to understand the details of the technical work done by the engineer. He or she cannot be immediately productive, and so the delivery of the system may be delayed.
• It can also be a product risk, because a replacement may not have the knowledge and experience required to design and implement the product. The replacement may be a cloud computing expert or have other domain experience, but to understand the product he could still make design and programming errors.
• Finally, it can be a business risk, because an experienced engineer's reputation may be a critical factor in winning a new contract. Many a time, winning a contract depends on the key people in the project. If a senior team leader or a highly skilled expert leaves, it becomes difficult to get a contract — the client would have said "we can do this project on time and with good quality because we have this expert with us," but once the expert has left, the business is affected.

So a single event — one person leaving a team — can be a project risk, a product risk, and a business risk at the same time.

15.5.4 The Risk Management Register

For large projects, you should record the results of the risk analysis in a risk management register, along with the consequence analysis. The register sets out the consequences of the risks for the product as well as for the business. Effective risk management makes it easier to cope with the problems and ensures that these do not lead to catastrophic budget or schedule overruns.

For small projects, you should still maintain formal risk recording at a minimal level — not as elaborate as for a large project — but the project manager should be aware of all the risks, the potential consequences, and how to manage them, even in a small team and a small project.

15.5.5 Student Questions and Answers

Real-world connection. Risk management is why companies institute key-person insurance-like practices: cross-training, documented architecture, and bus-factor planning (how many team members must be hit by a bus before the project stalls — a one means the project depends on a single person). Venture-funded startups and banks alike review top risks in executive meetings, because a risk that is written down and tracked is a risk that can be managed; one that lives only in the manager's head is invisible until it strikes.

15.6 Common Risks in Software Projects

The specific risks that may affect a project depend on the project and the organizational environment in which the project is developed. But there are also common risks that are independent of the type of software development — they can occur in any software development project.

15.6.1 The Common Risks

The common risks are typically project, product, and business risks:

• Staff leaving — a project risk; the project will be delayed.
• Change in management — for example, your company is acquired by another company and management procedures change. You might be in a large organization, but if you are acquired by an even larger, more formal, more bureaucratic one, the new company management may have different priorities: "your project is no longer important — we have other clients which are important." Suddenly your project may be dropped. This is a project risk.
• Hardware unavailability — if the technology or hardware you require for development is not available, the project will be delayed.
• Requirements changes — happen quite frequently all through the development phase and even during the maintenance phase. They affect both the project and the product.
• Specification delays — you do not get the requirements on time. The manager keeps chasing the customer for the requirement specification, and every specification keeps changing — today morning they give a specification, today afternoon they say they will make a small change. The specification is never frozen before it is given to you. This is both a project and a product delay.
• Size underestimation — very common because of the very competitive bidding process. Your company tries to bid at the lowest possible price. This is a major project and product risk, because the size of the system has been underestimated.
• Ineffective software tools — the CASE tools, the software developer tools, the IDEs are not effective or efficient and cannot do the task. If you have lousy, inefficient tools, your work suffers both in terms of quality and time. You demand better tools, but the manager says "I will put a request to the budget team and let them approve it" — by the time approval comes, half the project is done and the tool arrives too late.
• Rapid technology changes — a business risk. Today you have some technology, ERP technology; tomorrow it is on cloud or whatever. Your whole process of development and technology gets superseded. You have to train and develop people in the new technology.
• Product competition — a business risk. A competitive product may be released in the market. You might be working very secretly and confidentially on a breakthrough product, and before you can complete it, a competitor has already released it. You were not first to market. As a developer, you may not manage that worry — it is the worry of the marketing manager or the project manager.

15.6.2 Requirements Change: An Inevitable Risk

Requirements change is an inevitable, essential nature of software development. Requirements keep changing so often — that is why requirements management and change management are very essential. You should know the source of the requirement and the reason why the requirement was given.

A classic exchange happens after delivery: the customer says "it is a bug, it is not working properly." The typical software engineer's response is "it is not a bug, it is a feature" — because it is written somewhere in the fine print of the requirements document, which the customer did not even understand when he signed the contract. So as per the requirement specification, it is a feature — but it is a bug in the sense that it is not meeting the customer's real-world requirements. When a change request comes in after delivery, you have to see the impact of making that change — it should not collapse the whole software. Every time you deliver something, the customer says "this is not what I want, I want something else."

15.6.3 Size Underestimation and Fixed-Price Contracts

Size underestimation is very common. Because of requirement creep — frequent modifications and more features keep coming in — you may have quoted 1 lakh lines of code, and it becomes 10 lakh lines of code. But you might have signed a fixed-price contract for a fixed time and fixed date. What do you do then?

Sometimes companies deliver an incomplete project, because with a fixed-price contract, this much price covers this much delivery. For every other change they request, you cannot say "this is a bug" — it is a feature. Every new development change request has to be treated as a new development project, and the customer is charged accordingly. That way the developers may earn a profit also.

15.6.4 Student Questions and Answers

Real-world connection. The bug-versus-feature exchange is a recognized industry joke and a serious contract lesson at once — the expression "it's not a bug, it's a feature" is used across the industry, and its serious form is change control: every post-delivery change request goes through an impact analysis and a commercial decision. Fixed-price contracts likewise exist in the real procurement world (government and enterprise tenders), which is why experienced contractors write precise scope and change clauses before signing.

15.7 The Risk Management Process

15.7.1 The Four Stages

The risk management process involves four steps:

1. Risk identification — identifying the project risks, product risks, and business risks.
2. Risk analysis — checking the probability and the severity of the risks.
3. Risk planning — drawing plans to avoid the risks or minimize their effects. (This stage is sometimes called risk management itself, but the whole four-stage activity is what we call risk management.)
4. Risk monitoring — monitoring the risks continuously throughout the project.

For large projects, risk management is an iterative process that continues throughout the project. Once you have drawn up the initial risk management plan, you monitor the situation to detect emerging risks. As more information about the risks becomes available, you reanalyze the risks and decide if the risk priority has changed. You may then have to change your plans for risk avoidance and contingency management.

Risks and uncertainties can happen on an everyday basis. Suddenly there will be a power voltage problem, or suddenly there will be some noise outside and you cannot come to the office or cannot work from home. All these things keep happening, and risks are a matter of daily life — a routine thing to be managed on a daily basis.

15.7.2 Risk Management in Agile Development

Risk management in agile development is less formal. The same fundamental activities should still be followed and risks should be discussed, although they may not be formally documented in detail.

Agile development reduces some risks, such as the risk from requirement changes, because the requirements are captured in small stories. They are developed in small stories with the customer embedded in the team. The customer approves the requirements and the stories, and they are tested and modified before the next increment of the requirements can be taken up.

However, agile development also has a downside because of its reliance on the people — the small team involved. If there are only four or five people involved, staff turnover can have significant effects on the agile project as well as on product quality, the product, and the business. Because of the lack of formal documentation, and because risk management relies on informal communication, it is very hard to maintain continuity and momentum in a small team if key people leave. The team cannot suddenly make up for the loss of a key person in a small development team of five or six people. So it is a project risk and a business risk too, because the project will be delayed.

15.7.3 Student Questions and Answers

Real-world connection. The four-stage process is the standard shape of risk management in industry: large programs keep a formal risk register reviewed at every steering-committee meeting, while agile teams hold lightweight risk discussions in planning and retrospection sessions. The agile fragility point is why modern practice adds bus factor thinking and pair/triple programming even to small teams: spreading knowledge is cheap insurance against the 40%-loss event this example describes.

15.8 Risk Identification

Risk identification is the first stage of the risk management process. It is concerned with identifying the risks that could pose a threat to the software engineering process, the software product being developed, or the development organization — the business.

As a starting point for risk identification, you may classify risks into different types. Typically, these types of risks are included in a risk checklist of common risks:

• Estimation risks — arise from the management estimates of the resources required to build a system. If you estimate very low — you give the lowest quote and bag a big software contract — but it costs heavily much more than you estimated, you will incur significant losses. If the company is in deep financial trouble, will you get your next month's salary? No — you may even get a pay cut or no salary. On the one hand you have to bag the contract by being the lowest bidder; on the other hand, meeting the budget means you have to cut corners and give a lower quality or lower sized product.
• Organizational risks — arise from the organizational environment: whether the business environment is becoming competitive, changing new regulations, and so on.
• People risks — associated with the people in the development team: their skills, their level of competence, their leaving the team, and so on.
• Requirements risks — typically changes to the requirements from the customers, and the process of managing requirement change.
• Technology risks — from the software tools and technologies that are used to develop the system.
• Tools risks — from the software tools and other support software used to develop the system; tools are closely related to technology (the professor counts them as a sixth class, and the monitoring stage tracks them under technology indicators).

15.8.1 Student Questions and Answers

Real-world connection. Estimation risk is exactly what triggers the industry practice of contingency reserves in bids: professional estimators add a percentage buffer precisely because low-ball estimates have produced so many loss-making contracts. In regulated industries (banking, energy), risk identification is institutionalized in risk registers reviewed by compliance teams, using the same checklist idea — fixed categories plus project-specific brainstorming.

15.9 Risk Analysis

Risk analysis is the most important activity of the process. During risk analysis, you have to consider each identified risk and make a judgment about the probability and the seriousness of the risk — that is, the likelihood and the consequences.

There is no easy way to classify these. You have to rely on your judgment and your experience of previous projects and the problems that arose in those projects. You may not be able to extrapolate the same experience to this project, and it is not possible to make precise numeric assessments of the probability and seriousness of each risk. Instead, you may assign an approximate assessment of the probability: the probability of the risk might be assessed as insignificant, very low, low, moderate, high, or very high — you range them instead of giving numerical values like 0.1, 0.2, and so on.

The consequences — the seriousness of the risk — can also be assessed qualitatively:

• Catastrophic — threatens the survival of the project.
• Serious — would cause major delays.
• Tolerable — delays within significant allowed contingency limits.
• Insignificant — can be ignored for the time being; will be taken care of later.

You may tabulate the results of the risk analysis using a table ordered according to the seriousness of the risk: catastrophic, serious, tolerable, insignificant.

15.9.1 Worked Examples from the Risk Analysis Table

The five examples below are the rows of the risk analysis table, ordered by seriousness: catastrophic first, then serious, then tolerable, then insignificant.

15.9.2 Student Questions and Answers

Real-world connection. This qualitative banding is exactly how real companies run risk reviews — board and steering-committee risk matrices are colored grids with probability on one axis and impact on the other (green/yellow/red zones), and the catastrophic cell decides what gets escalated. The COVID layoffs at Facebook, Google, and Twitter are the financial-crunch scenario in the wild: a macro-economic event, low day-to-day probability, catastrophic project-level consequences.

15.10 Risk Planning

Risk planning develops strategies to manage the key risks that threaten the project. For each risk, you have to think of actions you might take to minimize the disruption to the project if the problem identified in the risk occurs. You should also think about the information you need to collect while monitoring the project, so that emerging problems can be detected before they become serious.

In risk planning, you have these strategies: risk avoidance strategies, risk minimization strategies, and contingency plans — what will happen if the risk arises, and what is the plan B to deal with the risk.

15.10.1 The What-If Questions

In order to do risk planning, you have to ask certain what-if questions that consider both individual risks and combinations of risks, and also external factors that affect these risks. Questions a risk manager might ask:

• What if several engineers are on leave at the same time?
• What if an economic downturn or recession leads to budget cuts of 20% or even 50% for the project?
• What if the performance of an open source software is inadequate, and the only expert on that open source software leaves?
• What if the company that supplies and maintains the software components goes out of business — whether it is open source or some other company, if suddenly everything vanishes, what happens?
• What if the customer fails to deliver the device requirements as predicted — he says "by tomorrow morning 11 o'clock I will give it," and it does not come; it takes another week?

Based on the answers to the what-if questions, you devise strategies for managing these risks: avoidance, minimization, and contingency plans.

15.10.2 Strategies for Specific Risks

• Financial problems: you, as a senior project manager or senior vice-president, have to tell the senior management that your project is making very important contributions to the goals of the business, and so you cannot allow budget cuts to the project. You have to fight for it — you cannot let your project budget be cut quietly.
• Recruitment problems: you must tell the customer frankly that there are likely to be delays, and instead of development, you must investigate buying in certain components from other sources.
• Staff leaving: you may have to recruit, and reorganize the team so that others can cover for the other's work.
• Defective components: you can replace them.
• Requirements changes: you have to derive traceability information to assess requirement changes, and in fact maximize information hiding in the design so that a requirement change does not affect other requirements and other components.
• Organizational restructuring, which often happens: again, you have to make a presentation to your senior management saying why your project should not be discarded or stopped. Many situations exist where even though a project is going on very well, because of organizational restructuring — a takeover or acquisition — suddenly the project becomes unimportant and is abruptly stopped, and the team is asked to leave.
• Database performance problems: you can buy a better database.
• Underestimated development time: you can buy certain components to speed up development, and investigate the use of a code generator.

15.10.3 Student Questions and Answers

Real-world connection. What-if questioning is institutionalized in industry as scenario planning: security teams run tabletop exercises ("what if the database is ransomed?"), and project offices run budget-scenario reviews (20% and 50% cut cases), exactly the questions in this section. The plan-B habit is why organizations write business continuity plans and disaster-recovery runbooks — documented in advance, revealed when needed, so that the response does not have to be invented under pressure.

15.11 Risk Monitoring

Risk monitoring is the process of checking that your assumptions about the product risks, the process risks, and the business risks have not changed. You should regularly assess each of these identified risks to decide whether or not the risk is becoming more or less probable. You should also think about whether the effects of the risks have changed.

To do this, you look at other factors, such as the number of requirement change requests, which give you clues about the risk probability and its effects. These factors depend on the types of risks. The indicators for the six classes of risk — estimation, organization, people, requirements, technology, and tools (tools are related to technology) — include the following:

• Estimation risk indicators: failure to meet the agreed schedule; failure to clear reported defects; and the percentage of effort completed against time. You have time estimation and effort estimation — "this will take so many percentage of effort." If at the review time only 50% of the work is done when 60% was planned, you are behind schedule. Then you request more time to complete the work. How will you meet the agreed deadline when you are putting in a lot of work, burning the midnight oil, working day and night 24 by 7, and still have not met the target? The target may be unrealistic, because the effort required was underestimated. The project manager may have to request one more week for the delivery. Customers sometimes agree; sometimes they impose a penalty clause, depending on the contract.
• Organizational risk indicators: persistent issues where the organizational management — senior management — is not taking any action on festering, burdensome HR issues. For example, HR simply puts pressure on the project manager without understanding the difficulty of the work. If there is no action taken by the organization, you feel frustrated.
• People risk indicators: poor staff morale, poor relationships among people, high staff turnover — people leaving often.
• Requirements risk indicators: requirements keeping changing frequently; compliance customers; so many change requests.
• Technology risk indicators: poor hardware and software technology, delivered late; complaints about the tools; demands for high-powered workstations or more powerful software. The demand for better tools has always been there. Requests may not get approved — you may be working with a five-year-old laptop, and your request for a replacement has been lying with them for two years. Especially for high-end workstations, with two monitors to code and debug on, sometimes you will not get them on time.

You should monitor risks closely and frequently, and at every management review you should consider and discuss each of these key risks separately. You should also decide if the risk is more or less likely to arise frequently in the future, and if the seriousness and consequences of the risks have changed.

15.11.1 Student Questions and Answers

Real-world connection. Risk monitoring is exactly what project dashboards and status reviews institutionalize: burndown charts and velocity in agile, earned-value (planned percentage vs. actual percentage of effort) in plan-driven projects, and tooling requests tracked through procurement. The five-year-old laptop and the two-year-old request will be familiar to anyone in a large organization — and monitoring is what turns such complaints from anecdotes into tracked indicators.

15.12 People Management

Software is for the people, by the people. It is only people who are building software, and they are building software for people. Everything is done by the people, of the people, for the people. If you remove the "p" from software engineering, there is no software engineering at all — one leg of the tripod broken, and it cannot stand. Without people, there is no software. It is a human-intensive, creative activity, unlike digital manufacturing, where you can set up the process in detail and it will run automatically to produce product.

15.12.1 People Are the Greatest Asset

The people working in a software organization are its greatest assets. It is very expensive to recruit very good people, and even more expensive to retain them and motivate them. It is up to the software project managers to ensure that the engineers working on a project are quite motivated and as productive as possible.

If you are not having a good relationship with your manager, you will not be very productive or even happy. You will be not only frustrated with your work, but also unhappy with your manager. So the manager has to keep the people motivated and as productive as possible. In successful companies and economies, this productivity is achieved when people are respected by the organization and assigned responsibilities that reflect their skills and experience. You feel valued only when you are appreciated and given responsibilities that are commensurate with your talent and experience — not a simple testing job or documentation job.

15.12.2 Why Good Engineers Do Not Always Make Good Managers

It is important that software project managers understand the technical issues that influence the work of software development. Unfortunately, however, good software engineers do not always make good software people managers. Software engineers often have strong technical skills but may lack the management skills that enable them to manage, motivate, and lead a large project development team, and to interact with a variety of stakeholders.

As a project manager, you should always be aware of the potential problems of people management and try to avoid such issues, and also develop strong people management skills. Most projects fail because of poor people management — poor people management is an important contribution to project failure. Many people leave their jobs due to bad managers rather than anything else.

Usually managers are not technical — some are direct MBAs from some consumer goods company and they hardly have any understanding of the technical work required in software engineering. Managing a software team like managing a consumer goods factory may not be acceptable to software engineers, who are more creative and intellectually oriented. They need to be respected, motivated, and given quality of work that is commensurate with their competence. We have all heard of people quitting jobs because of poor managers who are not cooperating with them.

15.12.3 The Four People Management Factors

There are four critical factors that influence the relationship between a manager and the people in the team that she or he manages:

1. Consistency. All the people in the project team should be treated in a comparable way. No one expects all rewards to be identical, but people should not feel that their contribution to the organization is undervalued.
2. Respect. Different people have different skills, and managers should respect these differences. All members of the team should be given an opportunity to make a contribution. In some cases you will find that people simply do not fit into a team and cannot continue — they may not be cooperative or may not work well with others — but it is important not to jump to conclusions about them at an early stage of the project, though they may be kept aside and counselled.
3. Inclusion. People contribute effectively when they feel that others listen to them and take into account their proposals. It is important to develop a good working environment where the views of all — even those of the least experienced staff — are considered.
4. Honesty. As a manager, you should always try to be honest about what is going on well with the project and what is going on badly in the team or in the project. You should also be honest about your level of technical knowledge and be willing to defer to staff with more knowledge whenever necessary. If you try to cover up your ignorance or problems, you will eventually be found out, and you will lose the respect of the group. A general manager who does not know anything about software should delegate technical decisions and leave them to the experts — not try to manage technical things they do not understand. That is honesty.

15.12.4 Student Questions and Answers

Real-world connection. The "people are the greatest asset" claim is why successful technology companies invest heavily in retention — competitive pay, growth paths, and manager training — because recruiting is expensive and losing a skilled engineer costs far more than their salary. The four factors are also the basis of modern people-management practice: consistency shows up in standardized promotion rubrics, inclusion in feedback and review processes that hear junior voices, honesty in leadership principles that reward candor over covering up problems.

15.13 Motivation and Maslow's Hierarchy

15.13.1 The Hierarchy of Needs

Practical people management has to be based on experiences, and motivation theory is a large part of it. You have likely seen Maslow's hierarchy of needs before — the triangle: basic psychological needs like food and shelter at the base, then safety needs, then social needs, then esteem needs (that you need to be appreciated), and self-actualization needs at the highest level. It has been a century-old concept.

At the top level, self-actualization is where you need to give people responsibility for their work, assign them challenging tasks, and provide opportunities for growth. Training is important here.

15.13.2 Different People, Different Motivations

There are various personality types. You have seen people who are focused only on the task but do not interact with others. And there are people who are focused only on their career and their next promotion — trying to backstab others, self-centered people who try to get credit for everything the team does and get a promotion at the cost of others. Then there are interaction-oriented people. Every person has a different personality; these are just some classifications.

Some are motivated by the work, some by their promotion, some by teamwork — they go to the office because they like to meet people and chat with them, and go and have a cup of tea or coffee in the canteen. Nowadays all companies have made it compulsory to work from the office, but most have a hybrid model — three days at the office and three days from home, which many like. Some people like going to the office just to chat up with friends, while task-oriented people prefer the solitude and peaceful environment of home, where they can focus on the work comfortably.

15.13.3 Student Questions and Answers

Real-world connection. Maslow's hierarchy is the century-old framework behind modern retention practice: companies satisfy social needs with office spaces designed for meeting (Google's campus social spaces are a classic example), esteem needs with public recognition programs, and self-actualization with training budgets and stretch assignments. The task/self/interaction personality classification is used in real team building — a good team mixes task-oriented doers, self-oriented finishers, and interaction-oriented communicators.

15.14 Teamwork

Most professional software is developed by teams that can range in size from two people to several hundred people. However, it is impossible for everyone in a large group to work together on a single problem. So large teams are usually split into a number of smaller teams and smaller groups, where each group is responsible for developing a part of the overall system.

15.14.1 Group Size

The best size for a software engineering group is four to six people, and groups should never have more than 12 members, even in a large team. If the groups are small, communication problems are reduced: people know each other, and the whole group can get around the meeting room to discuss the project and the software they are developing.

15.14.2 Group Composition and Cohesion

Putting together a group that has the right skills — the right technical skills, experience, and personalities — is a critical management task of the project manager. However, successful groups are more than simply a collection of individuals with the right balance of skills. A good group is cohesive and thinks of itself as a strong single unit. After you achieve success and deliver a successful project, the group says "we did it," not "I did it." That is what a cohesive group is about.

15.14.3 Group Organization and Communication

The effectiveness of the team depends on the people in the team. You need the right group of people involved in diverse activities — people like project managers, who negotiate, along with programmers and testers. The group should be organized, and the technical and managerial communications between the group and the project should be managed systematically.

Group organization raises the question: should the project manager be the technical leader of the group? The technical lead should technically be a technical lead — the person involved in critical decisions, in how knowledge is to be shared, and so on. The project manager has many other non-technical jobs to do.

Group communication covers the informal groups, the size, the group structure, the group composition, and the physical environment. A good office environment — conducive to work and good communications — can make work effective. A noisy open office, where everyone is on a call and you are mentally and acoustically disturbed, does not help.

15.14.4 Student Questions and Answers

Real-world connection. The four-to-six rule and the 12-member ceiling match the real design of software organizations: scrum teams are typically five to nine people, and large programs split into sub-teams rather than one giant group. The communication-links calculation is why managers resist over-staffing teams — and the open-office lesson is behind the industry-wide shift to hybrid layouts with quiet zones, focus rooms, and remote-work policies that let task-oriented people find silence.

15.15 Key Takeaways and a Classic Book

15.15.1 The End-of-Class Summary

Good software project management is essential. Software engineering projects are to be developed on schedule, within budget, and at good quality — and quality is the most important part. Software project management is much more challenging than other engineering management because:

• software is intangible;
• projects may be novel or innovative, so there is no prior body of experience to guide their management;
• software processes are unique and not structured and mature like traditional engineering processes.

Risk management involves identifying, assessing, planning, and managing risks. You should plan to avoid, manage, or deal with the likely risks if and when they arise.

People management means choosing the right people, providing the right environment, and making people as motivated and as productive as possible. People are motivated by interacting with other people, but there are technical people who are happy working independently in solitude. Software development groups should be fairly small and good, cohesive, friendly teams who can understand each other's work.

The key factors that influence the effectiveness of a group are the people in the group, the way they are organized, and the communication between groups. Communication between groups is influenced by the factors of the group members, the size of the group, the gender composition of the group, their personalities, and the various available communication channels, which can be face-to-face or distributed.

15.15.2 The Mythical Man-Month

Real-world: if you have time later in your career, read a book called The Mythical Man-Month — a book on project management with a set of essays on software engineering, written by Frederick Brooks way back in 1975, fifty years ago. Most of the points are still valid.

One of the popular sentences in The Mythical Man-Month is about adding petrol to put out a fire: you will not put the fire out — you will just add to it. Adding people to a late project will only make it later. If a project is already delayed and you recruit two or three fresh graduates into the organization, will it delay the project further or finish it faster? You cannot finish it faster by recruiting a dozen freshers straight from college. Even if you employed nine women, the process of pregnancy and childbirth will still take nine months. Adding more people will not reduce the time — that is one of the key lessons in project management.

Real-world connection. Brooks's 1975 book, written from his experience managing the IBM OS/360 operating system, remains the classic reference in project management reading lists — the anniversary edition is still widely read. The man-month lesson is taught in every project management course and explains real industry behavior: managers resist last-minute staffing additions, and delivery-date recovery is sought through scope reduction, overtime, or schedule change — never through recruiting freshers the week before the deadline.

Exam Guidance Summary

• The comprehensive exam is an open book exam, unlike the mid-semester exam, which was closed book. During the exam you can refer to the book and to the lecture material, and you can write and upload your answers.
• The textbook has a chapter on managing people — people management and team management — which covers these topics in detail. Refer to it when preparing.
• There may be one question related to how people should be managed, if at all it is necessary.
• No questions will be asked on Maslow's hierarchy of needs in the exam.
• Software project estimation and costing are not part of the course syllabus, so they are not covered here and will not be examined.
• This topic is a general topic that is not essentially part of the syllabus, but it is covered in this class because it is the last class before the exams next week.
• The syllabus will be posted on the course page, and the relevant material is uploaded so that you can prepare well for the exams in the coming week.

Key Industry Applications

• Real-world: Layoffs are a catastrophic business risk in action — during the COVID period, Facebook, Google, and Twitter laid off thousands of people, sometimes overnight.
• Real-world: The bench is a standard industry practice — people between projects are kept on bench (no work, sometimes online training, essentially a paid holiday) until the next contract is signed.
• Real-world: Winning contracts often depends on key people: clients award projects because of named experts in the team, so the loss of a star engineer is a business risk, not just a schedule problem.
• Real-world: Fixed-price contracts in the software industry: companies deliver only what the price covers and treat every post-delivery change request as a new development project charged to the customer.
• Real-world: Consumer product companies (for example, Google and Microsoft product teams) keep lighter project management records, while safety-critical industries such as automotive control systems must record and justify every management decision.
• Real-world: Technology risk is visible in the shift from on-premises ERP technology to cloud — companies must retrain people every time the technology stack supersedes the previous one.
• Real-world: Agile development with the customer embedded in the team reduces requirements-change risk, but small teams of four or five people are fragile: losing two members can stall the project.
• Real-world: The Mythical Man-Month (Frederick Brooks, 1975) remains the classic industry reference: adding people to a late project makes it later.
• Real-world: Maslow's hierarchy of needs is the century-old motivation framework behind self-actualization practices: give people responsibility, challenging tasks, and growth opportunities.