Introduction

Good project management really boils down to a few basic principles - 2

A good PM doesn’t need to be a programmer, tester, requirements analyst,... BUT needs to know what these people do, why they are on your team, common pitfalls, and how to fix them. Also, the PM needs to be able to read and understand documents. An by relying on objective analysis (not gut feelings, personal references, perceived hierarchy within the team), the PM can make decisions based on the best interests.

1️⃣ Tell Everyone the Truth All the Time - 3

• Details

  A project manager is someone who makes decisions about the project based on information gathered by the team and trusted by management. Creating a transparent environment means making all of that information public and explaining the rationale behind your decisions. No software project goes exactly as planned; the only way to deal with obstacles is by sharing the true nature of each problem with everyone involved. When faced with a deadline that's clearly unrealistic, many managers will put pressure on their team to work late and make up the time. The only real solution to this is to be open and honest about the real status of the project. Every tool, technique, and practice in this book is based on the principles of freely sharing information and keeping the entire project team "in the loop" on every important decision.

2️⃣ Trust Your Team - 4

• Details

  Managing a project is all about forming a team and making sure that it is productive. Every project manager needs to understand at least the basic principles of software requirements engineering, design and architecture, programming, and testing in order to guide a software project through all of the phases of development. The most important thing that you can do to support your team is to trust them and listen to them.

3️⃣ Review Everything, Test Everything - 4

• Details

  The purpose of a review is not to make a perfect document or to generate a page of signature. Rather, a review does two things: it prevents defects in the software and it helps the project manager gain a real, informed commitment from the team. It is always faster and cheaper to hold a review meeting than it is to skip it, simply because it's easier to fix something on paper. Every hour spent reviewing documents saves well over an hour later in the project. Reviews also foster respect among the team members for each one's contributions.

  To come up with a quality product, the entire team needs to actively look for defects. It's the project manager's responsibility to make sure that this happens.

4️⃣ All Software Engineers Are Created Equal - 5

• Details

  No single work product is more important than any other; if any one of them has a serious error, that error will have an impact on the end product. Many people have some sort of hierarchy in their heads in which certain engineering team members are more valuable or more skilled than others. This idea has no place on an effective project team. Every discipline is equally important, and everyone on the team contributes equally to the project. A software requirements specification (SRS) is no more important than the code: the code could not be created without the SRS. The best way to make sure that the software is built well is to gain a true commitment from each person.

5️⃣ Doing the Project Right Is Most Efficient - 6

• Details

  There are many ways to implement every single one of these practices. But no matter which one you choose to implement first, you can be sure your project will be better off with it. This is because building software correctly the first time is always preferable to having to go back and fix it later. Every single tool, technique, and practice in this book is time-tested.

  These practices would not have found such widespread adoption if they were not efficient. Cutting out good project management practices will make the project take longer, not faster. You can be sure your project will go more smoothly with them in place than it would without them.

Software Project Planning

An urgent need can be a good motivator. As it usually is, for example, the stakeholders’ need is urgent helps to convince the organization to dedicate time and effort; for the software engineers, an urgent need means that their work will be appreciated and used in the foreseeable future.

But, it can cause difficult problems: people panic, gloss over important parts, rushing into anything without thoroughly understanding the needs. If a PM does not really understand the context in which the software is being built, then the only thing that the project team can see is the urgency and they lose track of the needs.

If the team doesn’t understand the needs, then they may end up with a narrow focus, then waste time addressing the wrong things. It’s easy to build great software that solves the wrong problems.

The only way to build the appropriate software is for everyone in the project to understand and agree on both why and how that software will be built before the work begin.

1. Understand the Project Needs

When a stakeholder does not feel that his needs are being met, he usually puts pressure on the PM to provide an early version of the software so that he can personally verify that the team really understands why the software is being built. Or, when a stakeholder asks for an early version/prototype of the software, he will ask for evidence that these needs are understood, then the programmers think that they are asked to know the details of what they are doing.

This is a big source of communication failure between people who need the software and the team members who are building it. A PM must identify the people who are making decisions that affect the project and understand why they need the software built. By talking to them and writing down their needs, the PM can set the project on its proper course and give the stakeholders the feeling that the team is taking their needs seriously.

1.1 Drive the Scope of the Project - 17

The scope of a software project is the most important thing a PM can do to get the project underway. It is usually counterproductive to do any other project activity before everybody agrees on the scope. By focusing on discussing the scope and writing a vision and scope document, the PM ensures that the team starts out moving in the right direction.

When a project team is first assembled, there is almost always a sense of anticipation and excitement among the project team and stakeholders. The PM can take advantage of this energy to drive the project in the right direction. Once he starts talking to individual people about what they expect to see in the project and writing down their thoughts, the scope will start to coalesce.

1.2 Talk to the Main Stakeholder

PMs' first task is to find the main stakeholder who will be most impacted by the project. The PM should try to form the same sort of relationship with each stakeholder that a tailor has with his customers. He can do this by working to understand exactly what it is that the stakeholder needs from the software. The PM should take responsibility for the delivery of the project from its beginning. Each stakeholder should feel like the manager is his main point of contact for any problem or issue.

Goodwill from a stakeholder can often be established in the early stages of a project. The PM can lead the stakeholder through a conversation about his specific needs, and then show that he really understands those needs. This can be done by writing out a vision and scope document for the project.

1.3 Write the Vision and Scope Document - 19

The vision and scope document (VaSDoc) is one of the most important tools that a PM has, also the easiest to implement. A good VaSDoc will help a project avoid some costliest problems, ensure all the members who are involved in the project understand the needs...

The VaSDoc should be constructed early before the first line of code has been written. In most cases, this will be fine, but sometimes, the PM must take over the projects on which it has been started - which is never an easy situation. It’s rare unless the project was in trouble, the senior manager (SM) won’t change the PM.

The outline of a VaSDoc:

1.4 Review the VaSDoc

Once the VaSDoc has been written, it should be reviewed by every stakeholder, by the team, and ideally some of the users. You may need to ask for their comments. When everyone reviewed and agreed that the VaSDoc is complete, the team is unified toward a single goal and the project can be planned.

2. Create a Project Plan - 23

The Project Plan (PP) defines the work that will be done on the project and who will do it.

Includes:

• A statement of work (SOW): describes all work products (specifications, test plans, code, defect reports, and any other product of work) that will be produced and a list of people who will do it.

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

• A work breakdown structure (WBS) and a set of effort estimates.

• A project schedule (PS)

• A risk plan: identifies any risks that may be encountered and how to handle them, and the probability of happening.

It’s important to gain consensus on the PP. To get this, the plan should be inspected by the representatives of the team / senior management / stakeholders. And the PP should be reviewed periodically.

2.1 Statement of Work - 24

The SOW simply contains a detailed list of the work that must be done and all of the work products that will be produced.

Includes:

• A list of features being developed can be divided into phases, depending.

• A description of the intermediate deliverable or work product that will be built. Ex: software (SW) requirement specifications, design and architecture specifications, class or UML, code or software packages..., a brief description for each.

• The estimated effort involved for each work product to be delivered if known.

2.2 Resource List - 25

Contains a list of all resources that will be used on the project. It should contain a description of each resource and its availability.

Via: a function of the project management SW packages or a spreadsheet or word document.

2.3 Estimates and Project Schedule - 25

The PM can produce the PS in several steps:

1. A WBS is defined. It is a list of tasks in which, if performed, will generate all the work products needed to build the software.

2. An estimate of the effort required for each task in the WBS

3. A PS is created by assigning resources and determining the calendar time required for each task.

2.4 Risk Plan - 25

Uncertainty is the enemy of planning, a RP will mitigate some or all the risks.

Some risks will be much more likely to occur than others, if they do occur, they might cause much more damage than others.

A Risk Plan can be done in one meeting, properly 1 or 2 hours long. And there can be a script for manufacturing the RP.

3. Diagnosing Project Planning Problems.

Some problems may occur if the project is not planned well. If the PM doesn’t take the lead in defining the scope, the project will become chaotic. Or if the scope is well defined, the PM must ensure all the stakeholders understand and agree to avoid later on problems. Also, the team must buy into the scope as well, or they will make their own decisions.

Some possible reasons:

• Lack of Leadership - 30: It’s a common way of thinking that a team with all of the highly talented and motivated people will end up with a successful project, even the best people will have trouble if nobody takes the lead!
  • Tunnel Vision: all members know how to do a specific task, but, no way to plan for every detail of that task. They might be afraid of making decisions. EX: a person is sending the mail to all members that they know, requesting confirmation of an absolutely small decision.
  • Gut feelings: sometimes, not all one member’s decisions are in line with the needs of the stakeholders. Ex: he/she will choose to pursue the superior technical solution (at the expense of the deadline) despite the fact that the stakeholder’s needs would have been just as easily satisfied had he/she chosen the faster solution.

• The Mid-Course Correction - 31: A change in the project priorities partway through the project is one of the most frustrating ways that a software project can break down. The stakeholders often don’t fully recognize the problem in the early stage when the team brought the problem to them. They just want to add more features, this way, the team will be demoralized because it would have been much easier to build the right software from the beginning. This can be avoided by a good VaSDoc: straightforward, each feature clearly fulfills needs. Stakeholder reviews will be needed.

• The Detached Engineering Team - 31: In many organizations, there is an artificial wall between the people who need the SW and the people who build it. People who need the SW don’t really figure into the way engineers plan and carry out their work. This causes the SM and PM to feel frustrated with the development team sometimes. And in the other hand, the engineers will feel like they are already putting in overtime to meet the needs of the people who never seem to be satisfied! This can be avoided by a VaSDoc, it expresses the deadlines clearly, all will be able to keep track of and make appropriate decisions; also, the PP also helps as it represents an agreement between them.

Estimation

A good formal estimation process can allow the team to reach a consensus on the estimates, can improve the accuracy of those estimates, making it much more likely that projects will come in one time.

A PM can help the team to create successful estimates by using sound techniques and understanding what makes estimates more accurate.

Elements of a Successful Estimate

It starts with a WBS because it dictates how the work will be done. There are many ways to decompose a project into tasks: by feature, by phase, or mix.

Once the WBS is created, the team creates an estimate of the effort required to perform each task. The most reliable estimates are those based on prior experience.

No estimate is guaranteed to be 100% accurate: illness, leaving the team, change of needs... So estimates should not reflect the predicted future, instead, it is to gauge the honest, well-informed opinion of the effort required from those who have the knowledge and experience.

A PM can help the team create more accurate estimates by reducing the uncertainty about the project. It can be achieved by doing a thorough job creating a VaSDoc - ensure the team has reached a consensus on the tasks.

Assumptions Make Estimates More Accurate - 35

At the outset of the project, the team doesn’t have all of the information they need in order to produce estimates; nevertheless, they need to come up with numbers. So, to deal with incomplete data, they must make assumptions about the work to be done. By making assumptions, team members can leave placeholders for information that can be corrected later.

Assumptions are a good way to keep track of team decisions and find errors in their decisions. If an assumption turns out to be incorrect, the schedule will need to be adjusted. The bigger the list of assumptions, the lower the overall risk for the project. Identifying assumptions is a skill that improves with experience. There are a set of questions that can help a novice team member figure out what assumptions he or she needs to make in order to properly estimate software.

• More

  The PM can use some questions (pg. 36) to help lead the discussion to identify the assumptions. If two team members disagree, they can agree to write down an assumption to temporarily resolve the issue for the purposes of the estimate. Writing down the assumption allows the team to go back and revise the estimate later if it turns out that the initial decision was wrong. A moderated discussion of assumptions gives the project team a very effective forum to discuss the unknowns of the project. Identifying unknowns eliminates the source of many inaccuracies in estimates. By having senior managers review the assumptions, a project manager can reduce future delays.

Distrust Can Undermine Estimates

Estimation is, by its nature, a politically charged activity in most organizations. Estimates can either be a source of trust or distrust between the project team and their managers. Estimating can be an effective tool for team motivation, as each team member feels part of the process.

In many of these organizations, there are some kinds of estimates—especially those for quality and requirements tasks—that are particularly likely to not be taken seriously. SMs are often willing to take programmers' estimates at face value, even when those estimates are clearly padded. Or in some organizations, there is a "rule" that testing should always take exactly one-third of programming time.

This causes the testing effort to be shortchanged by only allowing that much time for it. An important part of running successful software projects is reaching a common understanding. A PM must ensure that estimates are made systematically, using an orderly process. This allows the engineers' work to be transparent to the rest of the organization and their needs and expectations to be met.

Wideband Delphi Estimation - 39

Other Estimation Techniques - 48

Diagnosing Estimation Problems - 49

Estimation problems almost always boil down to estimates that are either too high or too low. Ex: Padded estimates, where the team intentionally overestimates in order to give themselves extra time - too high; SMs give unrealistic, overly aggressive deadlines - too low.

Some problems: Padded Estimates Generate Distrust, Self-Fulfilling Prophecy

Project Schedules - 54

The Project Schedule is the core of the Project Plan. It is used by the PM to commit people to the project and show the organization how the work will be performed.

Building the Project Schedule

The PS is a calendar that links to tasks to be done with the resources that will do them.

Prerequisites are the WBS, an effort estimate for each task, and a resource list with availability. There are many PS SW products that can do much of the tedious work of calculating the schedule automatically or book tutorials... However, before using these, the PM should understand the concepts behind the WBS, dependencies, resource allocation, critical path, Gantt charts, and earned value.

Allocate Resources to the Tasks - 54

The first step in building the PS is to identify the resources required to perform each task. A resource is any person, item, tool, or service that is needed and has limited availability.

One or more resources must be allocated to each task. To do this, the PM must first assign the task to people (one or more) who will perform it. Then, the ones who have been assigned are not available until the task is completed. Some task requires certain people, if they are busy, then the task is pending.

Of course, some task requires more than one resource to perform. In this case, the PM must keep in mind the diff between effort and duration.

One resource can be assigned to two tasks simultaneously by assigning a percentage of the resource’s time to each task. EX: 30% for task A, and 70% for task B.

In cases where more than one person is in charge of a task, the PM must take overhead into account. It’s an effort that does not go the core activities but is still required to perform the task. Ex: A task needs 12 days to perform but with 2 people, it is not 6 days, instead, it will be 7 days; because they need an additional day to compare and integrate their work.

The PM should take care of the relative expertise of each member because the time to complete the same task of each people is different. Resource allocation is often the most difficult and time-consuming part for the PM because it requires the PM to know the team.

Identify Dependencies

The next step is to identify dependencies between tasks. A task has a dependency if it involves an activity, resource, or work product that is subsequently required by another task.

Many forms of dependencies: a test plan can’t be executed until a build is delivered, code may depend on classes or modules in earlier stages, the UI cannot be built until the design is completed...

There are many reasons why one task may be dependent on another: causal relationship or shared resources.

The easiest way to maintain the resource allocations and dependencies is to use a PM SW management package.

Create the Schedule - 57

Next, the information is enough for the PM to draw the schedule, calculate the dates... The most common form of the schedule is to use a Gantt Chart.

Reconcile the Schedule with the Organization’s Needs.

If the calculated due date is not appropriate to the organization, stakeholder’s needs, the PM should go back to the resource list to see if the tasks can be reallocated more efficiently. One way is to loop for large gaps in the schedule, maybe some of the resources can be slightly shifted or swapped.

Sometimes, there are technical solutions that can help reduce the schedule.

As a last resort, the project can be released in several phases. It then requires the PM to revisit the project’s scope, some features may be broken into phases, or some will be cut out entirely...

Add Review Meetings to The Schedule - 59

The final thing is to make sure the PS is used. The way to ensure that is to add regular review meetings to the schedule.

Progress review: to keep track of whether the schedule is accurate and plan action. The PM must make sure the agenda at every meeting includes a discussion of whether the project is still on track, and he should go through each task that is currently in progress. If some are late, the stakeholders need to know, sometimes, the schedule must be adjusted again, or the VaSDoc must be scaled back.

Milestone review: the PM schedules in advance to coincide with project events, often after the last task in a project phase. The PM should make sure all the representatives from many teams attend. The diff between this from progress reviews is the PM writes up a report after the meeting. It should list any schedule delays or changes, modifications to the scope, serious issues...

The Schedule should always be updated, with agreements.

Optimize the Schedule - 60

Many times, the PM has options in how the schedule is arranged: task order, who will be assigned...

In many schedules, there is some slack in the sequences: is the amount of time that any tasks can be delayed without causing the due date of the final task to be delayed as well.

The PM should be aware of the over-allocated resources - it means that there is a dependency between 2 tasks that was not discovered = the schedule is inaccurate.

Some PMs fall into the trap of using slack as a way to mitigate risk - which is usually a mistake. Instead, they should expand the definition of the task - the new task will be longer, and the schedule should be updated to reflect that.

One important tool for optimizing the schedule is the critical path. It is the sequence of tasks that represents the minimum time required to complete the project. So, if it is delayed, the project is delayed too. Every project has at least one critical path. There is no slack in these sequences. And the critical path should be monitored closely.

Don’t Abuse Buffers - 62

Many PMs add buffers to their schedules - are tasks added to the schedule with no specific purpose except to account for unexpected delays.

Sometimes, it’s useful. For a year-long project, every developer has 2 weeks of vacation and on average takes one week of sick days, so the project is guaranteed to lose 3 person weeks. Then, in this case, the buffer is valid because the size of the loss is known.

However, in most cases, it’s abused. The idea that overruns are expected = the estimate is incorrect! Then, why not include the buffer? Because the buffer lulls people, or the team can feel that they can ignore “small ” errors in their estimates.

For the potential risks, where will be a risk plan! if the risk plan is thorough, the stakeholders will not be blindsided by the potential problems, the team can avoid or mitigate risks.

Track the Performace of the Project - 63

Al the Schedule is completed and optimized, it is ready for review. The schedule should be inspected by the team. It is important to gain consensus on the Schedule, that, all of them see it represents a realistic plan.

A copy version of the Schedule that has been approved should be set aside and used as a baseline - a fixed schedule used to measure the performance of the project. If the Schedule is updated and approved, one actual baseline needs to be added as well.

When the due date for the actual schedule is later than the baseline, the project has slipped. Sometimes, it is because of late, or effort underestimate. The PM needs to track down the source of each slip to help improve the team’s estimates in the future or decide the next actions.

The most common way to understand the nature of the slip is to calculate the variance. It is the core of a PM system called earned value management, which tracks the project by considering effort “earned” against a budget.

Managing Multiple Projects - 66

Many PMs are responsible for multiple projects. If each is planned well, then managing them will be fine. If the projects share dependencies, there are challenges. There are two kinds of dependencies: rely on the same resources and the work product generated by one project is needed by the other.

Understand Dependencies Between Projects

Pipelined projects model is a way to maximize the capacity of one resource.

The trouble is when no two projects take exactly the same time, and the phases don’t always require the same percentage of the total effort.

The PM should make sure that shared resources are not overallocated. And the estimates should include overhead such as meetings, emails, customer services, talking to SMs...

Under-allocation is also a danger: get bored, unhappy. Low priority projects’ tasks can be assigned to an under-allocation member.

Another common way for 2 projects to be interdependent is when one project has tasks that has a processor in another project.

Prioritize Projects Realistically - 68

Use the Schedule to Manage Commitments

A PS represents a commitment by the team to perform a set of tasks. SMs feel that they can depend on the schedule as an accurate forecast of how the project is going to go. A common complaint among PMs is that the changes they make don't take root. When a project team member disagrees with implementing a new tool or technique, he or she may not bring it up in the meeting where it's introduced. This is because they might feel there isn't enough time, or fear that implementing the change will make the task late.

By explicitly adding a task to the schedule, the PM ensures that enough time is built in to account for the change. This cements the change into the PP, and makes it clear up front that the team is expected to adopt the practice. More importantly, it is a good consensus-building tool because it allows team members to bring up the new practice when they review the PP. By putting the change out in the open, the PM encourages real discussion of it and is given a chance to explain the reason for the practice during the review meetings. If the practice makes it past the review, then the PM ends up with a real commitment from the team to adopt the new practice.

Diagnosing Scheduling Problems - 70

Reviews - 73

A review is an activity in which a work product is distributed to reviewers who examine it and give feedback. Different work products will go through different kinds of reviews.

Reviews are useful not only for finding and eliminating defects, but also for gaining consensus among the project team, securing approval from stakeholders, and aiding in professional development for team members.

The goal of every review is to save the team time and effort. It is much easier to fix the problems on paper. An effective way to make sure defects a caught early is to schedule many reviews over the course of the project to catch defects before they become deeply embedded in the SW.

Inspections - 74

Is one of the most common sorts of review in Software Projects. The goal of the inspection is for all of the inspectors to reach a consensus on a work product and approve it for use in the project.

Inspections are easy to implement and have an immediate effect on quality and consensus-building. A small team spending a few hours inspecting a work product could potentially save weeks, or even months, of wasted effort. An effective inspection requires a well-chosen team, a moderator who is able to run the meeting, and an author willing to listen to criticism and fix it.

Choose the Inspection Team - 75

The PM must choose a team of 3 to 10 people to inspect the work product. The job of the inspection team is to identify any defects in the document. Once a problem is identified, the inspectors must work to come up with a solution that will fix the problem.

Select a Moderator - 76

An unbiased moderator is needed for an inspection meeting. A good moderator will have sufficient technical background to understand the work product being inspected. The moderator must also be able to control the meeting, and ensure that each issue is resolved or tagged as an open issue during an inspection. Moderator's job is to ensure that the meeting does not become personal criticism. An effective way to do this is to focus the discussion on each defect and come up with a specific resolution.

The moderator compiles all of the defect resolutions into an inspection log. An inspection log is a list of items that must be addressed before the work product can be inspected again. Each item is marked with the exact location of the defect and the solution proposed by the inspection team. In many cases, the solution is a wording change.

Inspect the Work Product - 78

Manage the Author’s Expectations - 80

The moderator's job is to keep the author from altering the understanding of the document through discussion. There is a simple rule in document inspection: if there is a misunderstanding about words in a document, they need to be clarified in the document and not just in the minds of the people who attended the inspection meeting. The moderator compiles all of the defects into a log, which is then sent back to the inspection team. Some organizations have found it useful to require that the authors not talk in the inspection meetings. In others, the author is excluded from the meeting entirely and is simply given the inspection log.

Help Others in the Organization Accept Inspections - 81

PMs often find that engineers are unhappy with the idea of inspections. Inspections are an effective way to prevent defects and make the most efficient use of engineers' time. For each hour spent inspecting documents, the team saves many hours that would otherwise be lost on correcting problems. The most effective way a project manager can sell inspections is to show the savings in terms of time and money. By instituting inspections, engineers other than the author of a work product are cross-trained on it. This allows them to maintain it if the author is busy or has left the organization.

Other kinds of review techniques

Use Inspections to Manage Commitments - 92

A successful project needs more than just a blanket agreement between team members. An inspection meeting allows each person to find problems and help the rest of the team find a solution. This ensures that each person feels like he or she made a real contribution to the document. It can eliminate many conflicts that can cause problems later on in the project. Inspections are important for gaining real, meaningful approval for a document.

When a document is not correct, that puts team members in a very difficult situation. Each member of the inspection team is given the authority to withhold approval until it meets their needs or has been explained to them.

Diagnosing Review Problems - 93

Software Requirements - 97

Software requirements - SR engineering is the art and science of developing an accurate definition of the behavior of software that can serve as the basis for software development.

Requirements Elicitation - 98

Elicitation involves fact-finding, validating one's understanding of the information gathered, and communicating open issues for resolution. The objective of all elicitation activities is to create a complete list of what the users and stakeholders believe are the important needs that must be filled by the software. A variety of elicitation practices can be used to gain a complete understanding of user needs.

Conduct Interviews - 99

Interviews with users and stakeholders are the requirements analyst's most important elicitation tool. The goal of the interview is to identify specific needs that the person being interviewed has for the software. This generally requires understanding what the interviewee does on a day-to-day basis. Interviewees should be people whose software is already out in the field. The software doesn't get developed for its own good; a project is usually started because someone inside an organization needs it. Questions should center on the interviewee's problems, not the interviewer's predispositions.

Observe Users at Work - 101

Watching users at work provides a more accurate understanding of their activities than simply asking them to communicate the steps involved in performing their tasks. Observing a user's day-to-day work allows a requirements analyst to see problems that the user encounters with the current system.

Use a Discussion Summary - 102

Use cases - 105

A use case is a description of a specific interaction that a user may have with the software. Use cases are deceptively simple tools for describing the behavior of the software. A typical use case includes these sections, usually laid out in a table. Table 6-2 shows a template for describing a use case.

Software Requirement Specification - SRS - 110

A software requirements specification (SRS) is a complete description of the behavior of the software to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. The SRS is the most important work product that is produced by the requirements engineering project activities.

SRS Template - 110

Develop the SRS Iteratively - 115

Like use cases, the SRS should be developed in a highly iterative manner.

A good PM knows that the fastest way to finish a project is to take the time upfront to get the requirements right. Any defects in the SRS will get magnified in later work products. The best way to prevent defects is through iteration. The PM needs to resist the urge to declare an SRS "good enough".

There is a risk that nontechnical people will fail to understand what is written in it and simply agree to whatever is written down. Users and stakeholders may object to sitting through a walkthrough meeting rather than waiting until the programmers produce something. A defect that only takes a few minutes to fix in a draft of an SRS can take days, weeks or even months to fix after it's coded.

Requirements Differ from Design

Many people have trouble understanding the difference between scope and requirements for software development. ‘Scope’ is the needs of the organization, while ‘requirements’ are the behavior of the software to be implemented. This is a very important distinction that every project team should be familiar with in order to succeed at their job.

SRS Inspection Checklist - 118

Change Control - 120

Many poorly managed software projects have been driven to failure because of uncontrolled changes. Change control is a method for implementing only those changes that are worth pursuing. It helps managers evaluate the impact of a change before implementing it and keeps them from derailing the project.

Establish a Change Control Board - 121

The most important part of change control is a change control board (CCB). There are people who have the power to change ‘scope’ of the project. For change control to be effective, these people must be part of the CCB.

The job of the tester is to understand the change and why it should be changed.

Change Control Process - 122

Evaluate Changes in the CCB Meeting - 122

Analyze the Impact of Each Change - 123

The PM is the person responsible for guiding each change through the change control process. He or she needs to take the time to understand why each change is needed and how much work it will be to make it.

The PM also needs to ensure that each CCB member is given enough information to understand the change. There is some overlap between the PM and that of the QA team. This is true both when the issue is a defect and when it is a change. As long as a QA member on the CCB initiates each change, they will still be kept in the loop.

Introduce Software Requirements Carefully - 124

Diagnosing Software Requirements Problems - 127

Design and Programming - 130

Many programming teams lose control of their own code. A PM can improve the code by helping the team adopt good programming practices. There are some basic changes that programmers can make that will improve the quality of the code they produce.

Review the Design - 133

In many project teams, programmers begin coding as soon as they have a software requirements specification. The first programming tasks usually involve building a user interface that supports each use case. The design tasks should be estimated and included in the PS. This requires that the team agree on a single design approach from the outset of the project.

The design tasks should always include reviews, even when there is no written design specification.

Any written documentation should be reviewed and, if possible, inspected. However, it is important that the reviews and inspections reach the correct audience.

Version Control with Subversion - 134

The purpose of a version control system is to bring a project's source code under control. Modern version control systems can identify exactly what changed between two different versions of a file. This allows the team to roll back those changes, even if they were made a long time ago. Subversion is a free and open-source version control system. It is available for many operating systems and platforms, including Linux, BSD, Solaris, BeOS, OS/2, Mac OS X, and Windows. Subversion provides many advanced features for bringing source code under control.

More about Version Control

Refactoring - 149

To refactor a program is to improve the design of that program without altering its behavior. There are many different kinds of improvements, or refactorings, that can be performed.

Refactoring introduces a new concept: adding, removing, or changing source code for the sole purpose of making it easier to maintain.

More about refactoring

Unit Testing - 156

Code is made up of a set of objects, functions, modules, or other non-trivial units. The purpose of unit testing is to create tests for each unit to verify that it performs its function correctly. Many people require that unit tests have no dependencies on external systems. A test case is a piece of code that verifies one particular behavior of the software. The most common way to do unit testing is to use a framework, which runs the tests and reports the results. Table 7-9 shows some of the test frameworks available for various languages.

More about Unit Testing

Everyone Is Responsible for Quality - 163

Automated unit tests can help programmers and testers work more effectively together. Many programmers are confused about exactly what it is that software testers do. A good PM will help clarify this by making sure that the programmers understand what kind of testing they are expected to do.

The QA team's job is to simulate complex actions that could be performed by the users. By adopting unit tests, programmers can develop a very clear picture of exactly what their testing responsibilities are. Implementing automated unit tests can ensure that those units work, letting QA concentrate on more complex behavior.

Unit Testing Saves Programming Time and Effort - 164

Most programmers who adopt unit tests find that it reduces the total time it takes to build software. It may take time to write the tests upfront, but it costs more time to go back later and fix bugs. This is a common trap that plagues object-oriented design.

Programmers often find that effort is wasted when one person has to use an object that was designed by someone else. In practice, test-driven development is an effective way to avoid that trap. The programmer can build a series of simple unit tests before the object is built.

Use Automation - 165

Automation can help to ensure that software is built the same way each time. Before, programmers had to manually verify each function and user interface element before delivering a build.

Some populate automated build tools - 165: Make, GNU Make, Apache Ant, Jam.

Be Careful with Existing Projects - 166

An overeager project manager can easily sour a team on these tools if the team doesn't see the benefits. Migrating from an antiquated source control system to Subversion is relatively straightforward. Refactoring can also bring immediate benefits, but programmers should be careful about how it is applied. Unit testing should probably be avoided on large legacy code and kept to new developments. It's possible to gain many of the benefits of refactoring without unit tests. Unit testing should generally be confined to new code until programmers are comfortable with test-driven development.

Diagnosing Design and Programming Problems - 167

Software Testing - 170

In software testing, quality is defined as "conformance to requirements". Every use case, functional requirement, and other software requirement defines a specific behavior that the software must exhibit. By putting in place good software testing practices, a PM can help assure the quality of the software.

Test Plans and Test Cases - 172

The test plan represents the overall approach to the test. It shows how the tests will be organized and outlines all of the testers' needs. The bulk of the test planning effort is focused on creating the test cases.

Test cases are step-by-step narratives that define a specific interaction between the user and the software.

Test Execution - 178

The software testers begin executing the test plan after the programmers deliver a build that they feel is feature complete. If no defects are uncovered, then the testers move on to perform a regression test.

Regression testing usually involves executing all test cases that have previously been executed. After each iteration of testing, the testers create a test report. This is a list of all test cases that failed or were not executed. Reports are used to determine the general health of the product in order to allow the project team to understand its maturity and readiness for release.

Defect Tracking and Triage - 180

When a tester discovers a defect, it should be entered into a defect tracking system. This is a database used for storing information about defects and routing them through a workflow of evaluation and repair. Many of the metrics used to measure the health of the product are gathered from this database.

Triage is one of the most important and time-consuming tasks in software quality assurance. In some organizations, one senior-level manager reviews and makes decisions on contentious bugs. Triage should be done by project stakeholders, or at least one trusted by them to make those decisions.

Test Environment and Performance Testing - 181

It is important for the PM to get involved in setting standards for verifying that software has sufficient performance. Performance requirements should be in place as early as the scope definition phase. Planning for performance testing can be a very costly operation, but it is one that must be fought for. Even if the software under test does not have demanding performance requirements, it can be challenging to plan for, budget, and set up an adequate test environment. If the users will use multiple hardware or operating system platforms, each of those must be replicated in the test environment.

It is easy to take down a production system during testing if the test environment is not completely separate from the production one. This is especially true of software that depends on a central database located in the same office as the programmers and testers, or that relies on their network.

More about Smoke Tests, Test Automation, Postmortem Report

Using Software Testing Effectively - 189

Software testing is often the most difficult area of software development to put in place. Unlike other disciplines of software engineering, many people have a negative attitude toward it. If a PM works to combat the negative attitudes about testing, he can achieve these results on his own projects.

The expectations put on software testers are not only impossible to meet, but often contradictory. Software testers do not add to the software; they "just" run it and report any problems. The actual mechanics of testing seem almost stagnant to people who don't really understand its purpose.

Diagnosing Software Testing Problems - 196

Understanding Change - 203

Building better software is also about changing the way things are done in your organization. There are some simple techniques that make it easier to get an organization to change how the software is built.

Why Change Fails - 204

A PM's job is to make changes to the way software is built. Sometimes the biggest obstacles come from outside of what a project manager typically controls. If you feel that the change is necessary, you will need to handle it politically - and be able to persuade people. Many PMs ignore the fact that their organizations are made up of people who need to be convinced of the importance of a change. By exploring the feelings, fears, and justifications for resisting change that project managers commonly encounter, these reactions can be unraveled and understood.

Change Is Uncomfortable - 205

People can also be afraid of change. When a project's scope or requirements are repeatedly changed, delays and defects usually result. It would be difficult to work in an organization that welcomes any change without considering the impact. Too drastic a change can cost you your project.

Everybody on the team needs to understand why new practices are put in place. It can become too difficult for each person to keep track of his day-to-day tasks, and people can lose their sense of purpose.

We Already Build Software Well - 206

It's often assumed that delays and problems are just part of how software is built. Part of your job as a PM is to help people in your organization learn from their mistakes. This means that you need to learn to acknowledge those mistakes and work with others to fix them. Getting people to talk about their problems is a start, but it's not enough. For many people, talking about the need for improvement means digging up old, painful projects that they would just as soon leave buried. Making changes to the status quo seems too risky because the organization has always developed software this way. In many organizations, there is no standardized way of building software. Since no two projects are ever done the same way, an excuse for not doing it this way is still used.

“Not Invented Here” Syndrome - 208

"Not Invented Here" syndrome (NIH syndrome) is a serious problem. People intentionally avoid research or innovations that were not developed within the organization. Some teams waste many hours defining procedures, creating tools, and building their own solutions to problems that have already been solved elsewhere.

NIH syndrome is an especially virulent strain of NIH syndrome that is commonly found in small entrepreneurial companies. NIH syndrome often leads to outright rejection of any change based on a tool or technique that works for large companies.

It’s “Too Theoretical” - 209

When an idea does not make intuitive sense, many will dismiss it as a result of "academic research," which could not possibly apply to the world they live in. For example, to someone without a project management or software engineering background, it may not be immediately obvious that reviews reduce defects. Growing pains typically occur when programmers are added to a small team. Many of the problems start to occur, and the manager gets frustrated. He finds himself trying to do everything the same way it's always been done, but his projects continue to break down.

It Just Adds More Bureaucracy - 210

Programming is usually less than 40% of the effort on a successful software project. Most project problems are caused by the team not understanding what software should do. Project planning goes wrong when the scope creeps, or when there are problems that could have been foreseen. To some people, planning the project, writing down requirements, and holding inspection meetings are seen as just pushing paper around. There may be a project schedule, but this is just used as a tool to help the rest of the organization understand what it is the programmers are doing.

It's easy to justify any activity or expense that is done to benefit programming, while all other expenses are regarded suspiciously. In an organization where this attitude is prevalent, it's common to see a much higher value placed on anything that has to do with programming.

You Can’t Give Me More Work! - 212

Most of the changes that a project manager makes will increase the workload of other people. People are often unhappy to be asked to attend meetings. If you are in an organization where everyone hates going to meetings, you might be unhappy and provoked into doing something about it.

When a project manager tries to put new tools or techniques in place, it is frustrating to encounter resistance from the very people who will benefit from them. Even if you win the battle, he could cause damage to your project by stonewalling and causing delays.

It’s Too Risky - 213

When you make a change in an organization, you're affecting how people relate to each other. A change that goes wrong can ruin someone's reputation and career. If a project fails, but many other projects failed in the same way, the failure is seen as inevitable. The risk is that if the project still runs into problems, the manager who implemented the new tools can be held responsible.

People are justifiably reluctant to go against the conventional wisdom in their organization. Forcing a stakeholder to accept poor software is a terrible reason to make changes to the software process. If there are client or stakeholder problems, they need to be dealt with directly, not by changing the way the group builds software. Not all improvements will help in every situation.

How to Make Change Succeed - 214

Prepare Your Organization - 215

There's no single solution to any of the problems in the previous section, though. There are several strategies that you might use to "sell" your change to the people in your organization. Try to feel out the sorts of arguments that you will run into, in order to get a feel for your audience.

• Some Strategies

  1. “We’ve always done it like this” - 215: Organizations uncomfortable with any kind of change are the hardest to deal with. Pitch the effort as preserving the status quo: "We've always built software like this" This approach can buy you time to get people used to some of the changes you want to make.

  2. Be positive about the work that’s already being done - 216: When people are in denial about the need for change, it is often because they need to see themselves as successful. Find examples in past projects of things that support your changes. This can help you build consensus among the project team and in the organization. It can be the kernel of justification for an effort to build a vision and scope document.

  3. Take credit for the changes - 216: If your organization suffers from NIH syndrome, it may make sense to act as you thought of the changes yourself. Don't talk about the changes as a process improvement effort that standardizes the way you build software. Justify them as tools that are responding to specific problems in your organization.

  4. Make the changes seem straightforward - 217: When someone feels that a tool or technique is "too theoretical," what he is really saying is that he doesn't fully understand it, and can't immediately imagine a situation in which it would work. Be careful in this situation if you're proposing a change that has not been directly borne out by his experience.

  5. Build support from the team - 217: Show the team that you are working to help them. For example, using Wideband Delphi estimation may seem needlessly "bureaucratic" to them. By showing that there are clear benefits to what you are doing or suggesting, you can avoid some of the knee-jerk reactions.

  6. Show that the changes will save time and effort - 218: When someone talks about a change adding too much bureaucracy, they usually mean it takes time and effort. You need to convince them that for every hour they spend in a meeting, they are shaving off an hour at the end of the project. Explain the impact of the problems on each person's work, and show how the tool will reduce that impact.

  7. Workaround stragglers - 218

  8. Stick to the facts - 220

Plan for Change - 220

• Create a vision and scope document

• Inspect the vision and scope document

• Schedule the changes

• Push for Consensus

• Use a Pilot Project to Build a Track Record

Measure Your Progress - 226

• Measuring cost

• Measuring quality

Bring In an Expert - 228

Management and Leadership - 231

Take Responsibility - 232

Many PMs are constantly clashing with other managers because of "dashed-line" structures. Managers routinely throw around the word "responsibility," often in the context of a subordinate "not taking responsibility" for a task. A good PM must have a more sophisticated understanding of responsibility.

A person has responsibility for a task only if he is given sufficient authority to perform the task and is held accountable for the results.

Ensure That You Have Authority to Do the Project - 233

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

Giving a PM authority to carry out a project means giving him control over the resources (people, office space, hardware, software, etc.). Since resources cost money, a sufficient budget for the project must be allocated within the organization. In this case, the PM does not need to have a corporate credit card to buy the necessary hardware or software.

You Are Accountable for the Project’s Success - 234

A person is accountable for a task if failure to adequately perform that task carries professional consequences. If there are no consequences, or those consequences are not particularly damaging, then there is little incentive to complete the task in the first place. Failure may be justified out of a sense of duty, loyalty, or personal responsibility.

Grant Authority and Accountability to Team Members - 234

When you are responsible for a software project, you are accountable for its success. However, you must distribute that accountability fairly among the project team. The best way to ensure that each team member has sufficient authority is to discuss it directly at team meetings. All engineers must have control over their time. Designers and programmers must feel free to make decisions without having to clear them with senior managers.

Testers must be allowed to request requirements specifications, technical specifications, and preliminary builds. If a project is late or runs into problems, you must work hard to identify the root cause of the problem.

Defend Your Project Against Challenges to Your Authority - 235

You only have authority if you can command the resources necessary to complete a task. When resources are pulled off of your project, your authority is being challenged. You must recognize this challenge and defend your project against it. This is difficult and often requires patience and negotiation. If your manager does not back you up in defending your authority, your hands are tied.

You will either have to renegotiate the schedule or accept the consequences. The best way to prepare is to have plenty of documentation so that you can show what caused the delay.

Do Everything Out in the Open - 236

Publish Your Work Products - 236

All work products should be kept in a public repository. This ensures transparency for both team members and the organization's management. Managers also benefit from the transparency of work products. Publishing the work products allows everyone to use them as reference materials.

Make Decisions Based on Known Guidelines - 237

If you do things the same way every time, people will come to understand your reasoning behind them. One way to help others understand your perspective is to publish the standards by which you manage.

There are several ways that guidelines can help make your decisions more predictable: standards documents, templates, process documents, performance plans

Manage the Organization - 238

Senior Managers See Software Projects as a Cost Burden - 238

PMs find that SMs have an increasingly antagonistic view of their software projects. SMs only see the cost of the development, and often fail to see how the software projects help the organization. Establishing a track record of successful projects is the most effective way for project managers to reverse dangerous attitudes.

Show Senior Managers the Impact of Their Decisions - 239

In good organizations, decisions are based on objective standards and metrics that were developed in advance. Decisions are frequently made based on gut feelings instead of objective analysis. While gut decisions can be successful, they will often lead to serious project problems. Many small businesses have successfully built and sold software products using mostly gut instincts. In a small company, senior managers are happy if they are making more money this year than last year.

Don’t Confuse Flexibility with Always Saying Yes - 241

PMs need to be flexible. Flexibility can mean listening to dissenting opinions and making changes to the way a project is being managed. It also means understanding that the project is in a difficult situation, and agreeing on the course it will take - but not having to cave into unreasonable requests.

• Don’t agree to an unrealistic schedule

• Change your approach when necessary

• Don’t confuse “easy to describe” with “easy to implement”

Manage Your Team - 243

Avoid Common Management Pitfalls - 244

• Don’t manage from your gut

• Don’t second-guess estimates

• Don’t expect consensus all of the time

• Avoid micromanagement

• Make your mistakes public

• Avoid lists

Accept Criticism - 251

Understand What Motivates Your Team Members - 252

Don’t Be Thrown by Dishonesty - 253

Address Performance Problems Early - 253

Managing an Outsourced Project - 255

Leading an outsourced project requires a different set of skills than most project managers are familiar with. Gartner predicts half of IT outsourcing projects in the next 2 years will fail. 60 percent of organizations that outsource customer-facing processes will find that hidden costs and problems have wiped out any cost savings.

Prevent Major Sources of Project Failure - 256

Get Involved

There's a misconception that it's possible to extract the work from an outsourced project team without getting involved in the day-to-day management of the individual team members and their tasks. That very management overhead at the vendor can be a major source of problems on your project. Many times, the client's needs and the needs of the vendor are not perfectly aligned. This creates distance between the client and the vendor, which can lead to some specific ways that many outsourced projects fail. The most common mistake a PM makes is assuming that the vendor will take care of everything.

Constantly Communicate Project Goals - 257

You are the only person working with the project team who has your organization's needs and goals in mind. Outsourcing teams are more susceptible to the "Do what I mean, not what I say!" problem because they don't have the same context that an in-house team does. Many outsourced projects fail because PMs fail to understand or compensate for this. You have to act as a rudder, constantly steering the team toward the goals of the project. This can be very difficult and time-consuming, but it is easily the most important thing that you can do to make sure your project does not fail.

Project managers often feel the project manager's job is to balance the needs of the vendor with the project's goals. The more you are able to integrate the outsourced team with your organization, the more context they will have for your organization's culture and needs.

Make Sure the Project Is Estimated Well - 259

Sometimes it's the client's fault that realistic goals are not set for the project. Vendors tend to promise things they can't deliver. Some companies may be cheaper because they don't understand the project being proposed, while some may just not be very good. Vendors are aware of the myths about outsourcing and are happy to let you believe them.

Get involved in the estimation process, and make sure that the people who are going to do the work buy into the estimates that the project plan is based on. Don't be afraid to meet with the vendor's project team and hold your own estimation sessions.

Management Issues in Outsourced Projects - 260

Actively Manage Your Project

If you have a relatively small project with well-defined requirements, known acceptance criteria, and a specific deadline, then it will probably work out fine. Many organizations outsourcing their work do not have a good grasp on their requirements and often have not put much thought into what they need from the project or the vendor. If you're managing an outsourced project, it's important to know the status of your team. Here are some tips on how to get a good handle on the health of your outsourcing project from within your own organization. Ask for daily build reports and unit test results.

Transparency is the key to building trust with your outsourcing vendor. Set up standards that let the people at the vendor monitor themselves and give you information that you need to monitor the project. The team should be as autonomous as possible, but productive and report back to you.

Share Information with Your Management - 261

Build a Relationship with the Vendor’s Management - 263

Build a Relationship with Your Team - 265

Collaborate with the Vendor - 268

Plan and Manage the Project Scope

In an in-house project, you start with the project scope and the set of resources already known to the organization. An outsourced project starts with a scope and a budget, and the vendor provides an estimate on the number of resources and the time expected to complete the project. Most outsourcing projects are set up so that the project manager has a very small role in the project, and the contractor is responsible for keeping the team on track. It takes time and effort to work with the individual team members to verify that the work is being done properly.

Do Your Own Estimation - 269

Maintain Your Own Project Schedule - 270

Hold Reviews and Inspections - 271

A review is one of the most important tools a project manager has for knowledge transfer, and it is difficult to overstate the importance of reviews and inspections in an outsourced project

Maintain Control of Design and Programming - 274

Take Responsibility for Quality - 275

You are responsible for the quality of your products, even when you contract the workout. It’s easy to forget this. If you are paying a vendor to build a project, it somehow makes it easy to consider quality just another deliverable. It’s not—it’s a responsibility.

Process Improvement - 277

Life Without a Software Process

Teams Can Be Effective Without a Formal Process - 278

"Skunkworks" are programmers who take the initiative and build software that was not necessarily asked for, but addresses certain users' or clients' needs. This is a highly satisfying way for a programmer to work with no pressure, no expectations, and high rewards. A software process is a set of activities that, if done, will result in software. These activities can include programming but also requirements management, project planning, configuration management, and other tasks meant to ensure that the software is of sufficient quality. Making improvements to the process will positively affect the way the team builds software in the future.

Projects get harder and harder to do as the scope of the software project gets wider or the team gets bigger, or the users and stakeholders become less available. Suddenly, they have to retain more knowledge about the users' and stakeholders' needs than they can keep in their heads. The knowledge needed to define the behavior of the software does not exist anywhere in the organization, especially if it is meant for non-employees.

Lack of Process Maturity Is Not “Immature” - 280

Many successful organizations do not have a formal software process. Process improvement experts often talk about process improvement in ways that are insulting to software professionals, writes Paul Callan-Morton of the Center for Process Makers' Marketer's (CMM) Censors. What's worse than insulting people into changing is evangelizing to them, but this is exactly what many process improvement experts do. People distrust evangelists and suspect they have more of an allegiance to the process than to the organization and the team.

If Things Are So Great, Why Change? - 281

Organizations often run into problems when they try to expand the team or get people to work together on larger projects. Having a formal process in place ensures that there is consistency between projects, so an expanding team can rely on a library of past estimates and guidelines for working together.

Software Process Improvement - 282

Software process improvement is the art and science of changing an organization’s software process in order to build better software.

Software process improvement always involves looking at the big picture. This generally means writing down the entire software process as a whole and making sure that it is followed on each project. It involves not just diagnosing specific problems and attacking them individually, but also looking at entire projects and identifying areas that can be improved.

Models and Certifications - 283

• The Capability Maturity Model - 283

• ISO 9000 - 286

• Six Sigma - 287

Processes and Methodologies - 288

• Processes and Methodologies - 289

• Rational Unified Process - 291

Moving Forward - 293

There is no single process, framework, or methodology that works all the time. Every organization is different. What’s more, organizations are made up of people who need to be convinced that the change really is necessary. While these practices can be very useful as guidelines, the most important part of improving the software process is helping people in your organization understand their role in the development of software.